The base wg has been wondering the same for containers, and at this point we may follow this guidance regarding libvirt too. I'll probably advocate this at our next meeting.
Thanks
On Mar 3, 2014 6:09 AM, "Stephen Gallagher" <sgallagh@xxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/28/2014 07:19 PM, Lennart Poettering wrote:
> 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.
>
Thank you very much for this detailed response, Lennart. It's much
appreciated.
With this in mind, I'm going to revise the document to recommend
libvirt as the preferred container management tool.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMUcSAACgkQeiVVYja6o6MdygCfYhBWlOQkLXqNJ1PEPE4kncFl
gUEAniBac8H2rMi3vZxodq4kib8LlNtD
=T5Mz
-----END PGP SIGNATURE-----
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
