Server Technical Specification: Agenda and First Draft

[Lennart Poettering]

On Fri, 28.02.14 15:37, Daniel J Walsh (dwalsh at redhat.com) wrote:

> > <drago01> sgallagh: "systemd-nspawn will be used to manage containerization
> > capabilities. " did I miss something or doesn't upstream say that it should
> > not be used for anything that needs secruity? <sgallagh> drago01: Last I
> > heard, the Dans (Walsh and Berrange) had SELinux working with it now. 
> > <mclasen> dargo01: I think that statement may be evolving ? <sgallagh> And
> > Docker is moving to systemd-nspawn and away from lxc <mclasen> but
> > certainly valuable to raise the question on the list, and see if lennart,
> > dan or dan want to chime in <drago01> sgallagh: "Note that even though
> > these security precautions are taken systemd-nspawn is not suitable for
> > secure container setups. Many of the security features may be circumvented
> > and are hence primarily useful to avoid accidental changes to the host
> > system from the container. The intended use of this program is debugging
> > and testing as well as building of packages, distributions and software 
> > involved with boot and systems mana <drago01> gement." [1] <sgallagh> So
> > it's definitely the way forward. <drago01> sgallagh, mclasen : ok makes
> > sense
> > 
> > So I am not sure if that has changed yet or not but if it has we should at
> > least get the man page updated.
> > 
> > 1: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html (man
> > page)
> > 
> Well this has changed again.   Docker is now going native.  It will support
> containers directly and not require a different set of tooling like lxc,
> systemd-nspawn or libvirt-lxc.
> 
> This will be the default, and I guess people could experiment with others.

Originally, nspawn was mostly just a debugging tool for us, since that
way we could boot up a systemd instance in an environment that is pretty
much like a real system but allows us to attach gdb easily. We never
intended it really to be more than that. That said, it considerably grew
in features over time (espcially, after Dan asked us to add a couple of
features for them), and it is quite a powerful tool now.

At this time I am aware of some people using it in production, simply
because it is much easier to use as you don't need to set up any
configuration for it. However, I personally am very much of the opinion
that libvirtd is the right choice if you want to deploy something. It
has all those management features, APIs, and tries to be general
purpose, and nspawn doesn't have or try anything of that. Hence it
should be libvirt-lxc that Fedora should advertise for deployment on its
server edition. People are of course welcome to use nspawn, but it
appears wrong to me to advertise it for servers, nspawn is not
specifically designed to be deployed or to be server tool.

The container hook-up work we are doing within the systemd project is
always designed to be compatible with any container manager people
choose as long as it follows these guidelines:

http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/

Both libvirt-lxc and nspawn implement these interfaces, you will get the
same level of integration with them.

Docker is will use its own containerization code soonishly. I am pretty
sure that that's actually the right choice for them. They are following
the container guidelines too, to provide the same level of integration.

(And regarding the comments on security from the man page: yes, with
nspawn we do not make any claims about being secure, but that's mostly
inherent to the underlying technologies and hence mostly applies to the
other container managers in the same way too).

So, from my PoV that wiki text should really just say "libvirtd", and
nothing else. For both VM and container virtualization.

Lennart

-- 
Lennart Poettering, Red Hat