Open Stack

----- Original Message -----
> On Tue, 2014-10-14 at 19:52 -0400, David Vossel wrote:
> > 
> > ----- Original Message -----
> > > Ok, why are you so down on running systemd in a container?
> > 
> > It goes against the grain.
> > 
> > From a distributed systems view, we gain quite a bit of control by
> > maintaining
> > "one service per container". Containers can be re-organised and re-purposed
> > dynamically.
> > If we have systemd trying to manage an entire stack of resources within a
> > container,
> > we lose this control.
> > 
> > From my perspective a containerized application stack needs to be managed
> > externally
> > by whatever is orchestrating the containers to begin with. When we take a
> > step back
> > and look at how we actually want to deploy containers, systemd doesn't make
> > much sense.
> > It actually limits us in the long run.
> > 
> > Also... recovery. Using systemd to manage a stack of resources within a
> > single container
> > makes it difficult for whatever is externally enforcing the availability of
> > that container
> > to detect the health of the container.  As it is now, the actual service is
> > pid 1 of a
> > container. If that service dies, the container dies. If systemd is pid 1,
> > there can
> > be all kinds of chaos occurring within the container, but the external
> > distributed
> > orchestration system won't have a clue (unless it invokes some custom
> > health monitoring
> > tools within the container itself, which will likely be the case someday.)
> 
> I don't really think this is a good argument.  If you're using docker,
> docker is the management and orchestration system for the containers.

no, docker is a local tool for pulling images and launching containers.
Docker is not the distributed resource manager in charge of overseeing
what machines launch what containers and how those containers are linked
together.

> There's no dogmatic answer to the question should you run init in the
> container.

an init daemon might make sense to put in some containers where we have
a tightly coupled resource stack. There could be a use case where it would
make more sense to put these resources in a single container.

I don't think systemd is a good solution for the init daemon though. Systemd
attempts to handle recovery itself as if it has the entire view of the 
system. With containers, the system view exists outside of the containers.
If we put an internal init daemon within the containers, that daemon needs
to escalate internal failures. The easiest way to do this is to
have init die if it encounters a resource failure (init is pid 1, pid 1 exiting
causes container to exit, container exiting gets the attention of whatever
is managing the containers)

> The reason for not running init inside a container managed by docker is
> that you want the template to be thin for ease of orchestration and
> transfer, so you want to share as much as possible with the host.  The
> more junk you put into the container, the fatter and less agile it
> becomes, so you should probably share the init system with the host in
> this paradigm.

I don't think the local init system and containers should have anything
to do with one another.  I said this in a previous reply, I'm approaching
this problem from a distributed management perspective. The host's
init daemon only has a local view of the world. 

> 
> Conversely, containers can be used to virtualize full operating systems.
> This isn't the standard way of doing docker, but LXC and OpenVZ by
> default do containers this way.  For this type of container, because you
> have a full OS running inside the container, you have to also have
> systemd (assuming it's the init system) running within the container.

sure, if you want to do this use systemd. I don't understand the use case
where this makes any sense though. For me this falls in the "yeah you can do it,
but why?" category.

-- Vossel

> 
> James
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>