I like the transactional approach of Ubuntu Core together with snaps and other container types and prepare a pilot for it. While these technologies give us good and easy configuration management for the immutable parts of the snaps, I am wondering what people are doing with the non-immutable configuration.
Let’s take the example of the Ubuntu Core documentation: the nextcloud snap. I think it is typical for web applications. We have
Immutable applications (Apache, MySQL, Redis etc. in /snap/nextcloud)
Configuration data (in /var/snap/nextcloud -> mostly in “current” there), containing even basic things like trusted host names and https certificates.
User data (in /var/snap/nextcloud -> mostly in “common” there and in the DBMS)
The group 1 is well managed by snap :-). I was wondering how people are handling the data of group 2 in a well defined state across many instances?
Usually I would expect some configuration management systems like Chef or whatever is your favorite. But I did not find them in the snap store. This system would even need access in the data area of other snaps, which is hardly possible on Ubuntu Core.
We could imagine something like company specific add-ons or overlays for snaps to configure the group 2 data and make it immutable as well.
There might be more ideas …
How would you or do you manage the configuration of your Ubuntu Core servers? Any ideas welcome.
you would use a brand store, which gives you the ability to have a snap declare the snapd-control interface in some configuration agent snap … through such a snap you can then manage the configs of your snap packages (like with snap set/get)… the snaps themselves should have configure hooks that run when snap set/get is called …
I would setup a snap for a configuration management agent. Maybe I am naive, but let’s assume, I take something existing and adopt it to use the snapd-control interface. Well nothing out of the box. But maybe in a year that could be available with the spreading of Ubuntu Core and Fedora Core OS.
The set/get concept seems logical. But in practice, I see some issues with it: If we look at the example of the nextcloud snap, it currently has five configuration options on the snap (ports, mode, nextcloud cron-interval and php memory limit). If I compare this with the main options of the affected configuration files (nextcloud itself, redis, mysql, apache, php), I suppose I would easily come up with around 30 to 50 options plus some files like an https certificate. Will we expect all this on the configuration interface in the future? (Not to speak about the core18 snap, which would have hundreds of configuration parameters.)
Yes, I think your first point of a snap with a snapd-control interface is good. But what about all those configuration parameters being on the snap’s configuration interface?
getting the config options you require into a snap is a matter of talking to the packager (or fork the snap into a brand store and make your own changes if wanted (if the snapcraft.yaml for said snap is public))
there is source of a management solution from canonical you could use:
