I have been using a container as a mini system for a while (LXC 1.0.6) and it’s been really nice.
I actually use a squashfs as root and I have a script that repacks it using the changes and fires up the container again but I separate my /home and in this case /var/mysql and in general just use the “dir” storage, but because it is squashfs it is really custom now.
(I never knew about all these stores lol).
So backup is easy: take the squashfs, tar the home, tar any config files, any mysql, and tar the changes to the rootfs, put it all in one big tar and upload it somewhere.
I then currently use rdiff to generate rdiffs against a previous backup if I want to create a differential one and it is all a bit self-concocted but it works nicely.
However I would like to add another container but the complexity of the Linux filesystem makes it a bit hard.
I would want to have a generic container that is very close to my ‘first’ ‘production’ container except for customizations only pertinent to that host.
I can create a generic rootfs with a generic /etc and a generic /var that only contains /var/lib/apt and /var/lib/dpkg and whatever else is essential to getting the system ‘booted’, which is not a lot,
but to keep this generic I have to have a pristine /var, but a pristine /var can only be had from a fresh installed system containing all the packages that the main container has.
at that point I can overlay the / and the /etc and the /var with that of the main container but I cannot actually integrate any changes from the main container anymore apart from repeating package installs on the generic container, and even repeating configuration changes on the generic container, unless I explicitly put /etc files into the generic container that I need to have there, but this is still a problem for /var.
so if I were to do installations on the main container I would need to track changes to /etc and /var and move that to the generic container (filesystem) but this is a problem for /etc files I have customized.
Thus, the only true way to keep those changes pristine is to do it in the generic container but this precludes easy customization that is supposed to be container-system-wide and do it on the main container at the same time. I do not want to work on the generic container, I just want it to keep the results.
I realize that the best way to do this is probably to have everything automated and to just execute a playbook on all containers but I prefer merging for now.
IF I repeat my changes on the generic container by way of some script, or a repeat of some audit file, that are automatic (apt in this case) then I would have to create a difference of the main and generic container, and keep the changes in an overlay for the main container, while moving changes that are meant to be generic into the ‘underlay’ (so that there is no longer a diff) at which point the changes disappear from the overlay and have become generic indeed.
But honestly config file changes are usually not that many and it wouldn’t even be hard to grab any pristine files from the packages directly.
But /var/lib can be a bigger problem.
But since there is no individual /usr, /sbin, /bin, /lib, the primary container will have a rw overlay for these things, and all containers will have a rw overlay for /etc, there is barely any individual stuff there. So at this point I am working from overlays anyways, or changesets.