Any good approach to service specific containers on Gentoo ?

nissarin · n00b Joined: 16 Nov 2008 Posts: 10

A bit of a background - we have a few old servers running kvm based (Debian) "machines", however we plan to replace them with one (+spare parts) or two new servers to handle everything.

I could use kvm again but I personally see this as a bit of a overkill, I just want to have the ability to better manage resources (hardware) and have a bit of security on top of that (yes, I know the limitations of containers).

So, the plan for now is to use host to create binary packages with use flags (dependencies) as needed but I really don't know what would be the best way to go forward. I would rather avoid situation where I would have to create "image" each time I want to update something, ideally I would want to update each guest container from inside host but it's just a wishful thinking I suppose, any good ideas or pointers how to move forward or what would be the best approach ?

skunk · Posted: Wed Jan 25, 2017 8:09 pm Post subject:

so, what's the problem?
you can upgrade each container by running emerge if they're gentoo based or apt-get if they are debian based...

nissarin · n00b Joined: 16 Nov 2008 Posts: 10

I'm lazy. Ideally I would want the services to have different "view" of the system but really only have to bother about the host (update host -> containers updated "for free").
I can run complete system in each container but having to update them separately aside, there is potentially a lot of duplicated data, so maybe using something like overlayfs I could at least deal with some of the cruft which is shared by all of them.

skunk · Posted: Wed Jan 25, 2017 11:37 pm Post subject:

you're better off sharing the same portage tree (including distfiles and packages directories) from the host and always emerge with --buildpkg and --usepkg flags set, this way if you've already build the same package somewhere else you just need to install the resulting tarball without having to compile it again...
believe me, overlayfs would only complicate your life with upgrades, because you would end up with a mess if you think to upgrade the underlying file system that you share with all the containers and keep the same overlaying file system unique to each container...

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

Exactly how much isolation do you want in the per service view? Do you need services to be unaware that other services are even installed on the same device? Most services store their configuration in /etc and also want access to at least some common files directly in /etc. You can use bind mounts and mount namespaces to give isolated filesystem views, but there is a balance between convenience of setup and level of isolation. The more information you want to hide from confined services, the more targeted (and therefore complicated) your setup will become.

nissarin · n00b Joined: 16 Nov 2008 Posts: 10

Depends on service, in some cases I want to have access to "full" system, others - just some base system + what's necessary to run them and I do want to share between them, e.g. database in all of them. So in the end I think I'll just go with the initial plan and use host as bin package sources/use separate installation per service.

PS:
BTW, on of the reasons why I asked in the first place is because I know portage provides some degree of flexibility, I was hoping I could abuse some of it's features, which normally would be used to create stages or other kinds of images on "live" system running in containers.

pilla · Posted: Thu Jan 26, 2017 1:01 pm Post subject:

I started playing with Docker containers 3 or 4 months ago and migrated some services in a Ubuntu server with success. I have LDAP, phpldapadmin, and gitlab (actually it is a container for Redis, another one for Postgresql and finally one for Gitlab itself). Apache and NFS are still running in the server itself and I don't intend to change that.

One of the most appealing features of containers for me is the possibility of testing upgrades before rolling them out. Another one is to reduce side effects of upgrades in one service to the other ones. Both of these would be denied by your strategy. You would still have some rollback capabilities if you used a Dockerfile to define configuration or committed the current state of the containers before an upgrade though. But sharing too much with the rest of the system may harm those capabilities as well.

I would share at most the portage tree and binary packages, and my update scripts would make sure that I had a backup for the containers before rolling out the updates.
_________________
"I'm just very selective about the reality I choose to accept." -- Calvin