Re: [atomic-devel] systemd-docker

[Clayton Coleman <ccoleman redhat com>]

Systemd is such a powerful tool that getting Docker to integrate more directly with it (as Rocket has done) is pretty important to the long term stability and usability of the containers that get run.  Using Docker to download images and create (but not start the container) is great, but we should then also be able to let systemd manage the processes of the container and take Docker out of the loop.  The benefits are significant:

* log stdout/stderr directly to the journal, no user-space log proxy in docker (or writing logs to disk and then having to rotate them)
* let more sophisticated process models exist, since systemd already has support for *every* process management pattern
* socket activation
* proper cgroup handling
  * live cgroup manipulation

The only piece necessary to do this today is a "docker run" equivalent that does all of the libcontainer calls to bootstrap the container directly, instead of delegating to the docker daemon.  Fortunately, Docker is aware of the value of this and starting to move in this direction with things like dist.  It's just unfortunate that it's not possible today, even for those who want more power.

----- Original Message -----
> This thread was linked from a LWN article; I hadn't
> seen it before, but it's quite good:
> https://groups.google.com/forum/#!msg/coreos-dev/wf7G6rA7Bf4/Olmxmo13WKQJ
> 
> Here's my personal thoughts on this:
> 
> - Systemd should expose a workable API for container systems
>   not included in the systemd codebase to operate effectively.  The
>   onus is on us as part of Project Atomic to help ensure that.
> 
> - Management of individual containers is important, but what
>   makes the container story significantly more compelling
>   is clustering - going beyond "containers as lightweight virtualization"
>   to a model where applications are distributed redundant
>   micro-services.  Given that, what matters most is a good
>   Kubernetes experience.
> 
>