Disclaimer: I work for SUSE, specifically on Docker and other container technologies.

Docker containers /in principle/ do work with systemd. They are implemented as transient units when you use --exec-opt native.cgroupdriver=systemd (in your daemon's cmdline). I've been working on getting this support much better (in runC and therefore in Docker), however systemd just has bad support for many of the new cgroups when creating transient units.

So really, Docker has systemd support. Systemd doesn't have decent support for all of the cgroup knobs that libcontainer needs (not to mention that systemd has no support for namespaces). I'd recommend pushing systemd to improve their transient unit knobs.

But I'd rather like to know why the standard cgroupfs driver doesn't fulfil your needs? The main issues we've had with systemd was that it seems to have a mind of it's own (it randomly swaps cgroups and has its own ideas about how things should be run).

im not sure if we are talking the same thing here. I'm talking about systemd inside a container (as pid 1). I think that's the part that's not working.

Every few days someone comes up with a new run script for docker (baseimage "my_init", etc). I personally use supervisord. Since systemd is already universal, might as well use that.

Somebody posted this yesterday - https://news.ycombinator.com/item?id=11019143

Im already running my containers on a debian host with systemd - so that is ok. Overlayfs is still causing some problems though.

> I'm talking about systemd inside a container (as pid 1). I think that's the part that's not working.

Ah sorry, I misunderstood. I'm not sure why you'd want to use systemd as your process manager in a container. systemd has a very "monolithic" view of the system and I'm not sure you gain much by using systemd over supervisord (I'd argue you lose simplicity for useless complexity).

> Overlayfs is still causing some problems though.

I've been looking into overlayfs and I really encourage you to not use it. There have been an endless stream of bugs that the Docker community has discovered in overlayfs, and as far as I can see the maintainer is not particularly responsive. There's also some other issues (not being POSIX complete) which are pretty much unresolvable without redesigning it.

Whoa... Thank you so much for pointing out the issue with overlays. There seems to be no real consensus on what should be used. Could you talk about what should be used?

Just FYI - we use Debian on Linode.

Devicemapper works (make sure you don't use loop devices) okay. Unfortunately it's slow to warm up, but it's probably the most tested storage driver (it's the default on a bunch of systems).

btrfs works pretty well and is quite a bit faster. It's the default for SLE and openSUSE (as well as other distros which use btrfs by default). I'd recommend it (but I can't remember if it requires you to use btrfs on your / partition, which might be an issue for you).

ZFS, while being an awesome filesystem, I doubt has had much testing under Docker, so I'd be wary about using it.

And I've already told you what I thought about overlay. I'd like to point out that it's a good filesystem for what it was designed for (persistent or transient livecds) but the hacks in Docker in order to use it for their layering keeps me up at night.

Yeah - all of which mean that I have to move away from Linode. They can't backup anything other than a vanilla ext4 volume. I setup a direct lvm docker vm on Linode (was surprisingly easy) - but Linode is refusing to back it up.

Oh well, should have done this long ago.

If Linode supports ZFS, you could use ZFS send-recieve to make backups to your local machine. But like I said, the ZFS storage driver probably hasn't been well tested.

nope. no backup for anything other than EXT4. Its really weird and limiting. I mean LVM volumes have to be pretty standard right ? (I would argue more standard than ZFS).

Whats advantage of having a "supervisor" inside the container, rather than just "supervising" the container itself?

Because "only one process in a container" is a dangerous rule (because it has so many exceptions). In certain cases, that idea makes sense, but you shouldn't contort your app such that you only have one process in every container. Not to mention that there are other issues (PID 1 has unique problems that databases and your app aren't used to having to deal with).

maybe you should read this [1]. We have always run all processes under a supervisor.

[1] https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...

I think this was the problem [1] was targeting [1] http://engineeringblog.yelp.com/2016/01/dumb-init-an-init-fo...

One of many.

Which is why u think might as well get systemd working on docker...

I see, so it looks like if your process spawns other processes and doesn't reap them when they die, you end up in trouble with zombie processes in docker.