On Fri, 28.02.14 15:37, Daniel J Walsh (dwalsh@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
