On Fri, Jan 23, 2015, at 08:07 AM, Lennart Poettering wrote:
Which is something I find a really questionable idea btw. There's
lot of stuff systemd does, and it's naive to believe you can just not
do them and get away with it in a container.
The discussion is more subtle than that - with "bare container apps",
we do expect that deployments do things like bind mount the container's
/tmp to the host filesystem, e.g. /var/tmp/containers/$uuid or so. This
isn't something Docker at least does by default, but it's easy to script.
In general, to avoid writing data to the container images. Newer Docker
versions finally make it easy to do with:
So the *host* systemd is still doing (some of) its job. Other parts
like process supervision of Docker containers really would be best
done by systemd, but
Apps need APIs, and
systemd provides quite a few of them, which are unavailable if you
don't run systemd. But it's also mundane things like cleaning up /tmp
from time to time. Or pretty much any non-trivial app probably already
needs more than a single service, in which case you need service
management and stuff.
For Project Atomic, we currently use Kubernetes for multi-component
container management. The concerns there about overlap with
systemd still exist, but those are mostly Docker side issues.
I am pretty sure it would be good idea to emphasize the APIs Fedora
offers as a system to app developers. By not providing them in a
container we are certainly not making things easier for people...
A number of people agree with this, and there are pending patches
upstream to support things like /run as a tmpfs.
But anyway, I can see that people disagree with this... I am not
convinced though that we should fuck up the packaging of systemd too
badly, just to accomodate for broken ideas...
There are a lot of valid real world use cases that don't need a full
systemd inside the container.