Open Stack

On Wed, 2014-10-15 at 11:24 -0400, David Vossel wrote:
> 
> ----- 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.

Well, neither is systemd: fleet management has a variety of solution.

> > 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)

I won't comment on what init should be.  However, init should not be
running in application containers, as I have said because it complicates
the situation.  Application containers are more compelling the simpler
they are constructed because they're easier to describe in xml +
templates.

> > 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. 

If the container is an OS container, what you run inside is a full OS
stack; the only sharing is the kernel, so you get whatever the distro is
using as init and for some of them, that's systemd.  You have no choice
for OS containers.

> > 
> > 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.

It's the standard Service Provider use case: containers are used as
dense, lightweight Virtual Environments for Virtual Private Servers.
The customer can be provisioned with whatever OS they like, but you
still get 3x the density and the huge elasticity improvements of
containers.

James