Re: Containers on Guix
Quoting David Thompson (2014-11-19 21:34:49) I did some reading about how Docker creates containers and discovered that it uses systemd-nspawn[0] to do it. Since Guix uses dmd, using systemd-nspawn isn't an option. Does anyone have thoughts on how we might have similar functionality in the Guix distro? I'm not so sure that docker actually needs systemd -- the docker documentation has instructions for a number of systems that don't use systemd. A quick scan suggests they're using lxc, at least on some systems. Would an nspawn equivalent be appropriate for dmd? Or a completely separate program? This seems to be a Linux only feature, so if we added a container creation program, would it make it harder to support the Hurd? I'm sure there are other things already packaged that don't really have any hope of working on top of another kernel. This is going to be hard to do portably, but I don't think it's worth worrying about too much yet. Probably some work will have to happen upstream on the Hurd project. signature.asc Description: signature
Re: Containers on Guix
Ian Denhardt i...@zenhack.net skribis: I'm sure there are other things already packaged that don't really have any hope of working on top of another kernel. I think packages that are Linux-specific by design are all in (gnu packages linux). This is going to be hard to do portably, but I don't think it's worth worrying about too much yet. Yes, agreed. Probably some work will have to happen upstream on the Hurd project. The Hurd supports fine-grain virtualization, so it wouldn’t be hard to do (“sub-hurds” correspond to completely isolated containers, launching a separate ‘proc’ server gives you a separate PID name space, etc.) Thanks, Ludo’.
Re: Containers on Guix
David Thompson dthomps...@worcester.edu skribis: Ludovic Courtès l...@gnu.org writes: A container is programs or full os running in an isolated environment. For a full container with rootfs, we can: build the rootfs: of Guix:by using a form of `guix system init' I think it’s enough and cheaper to build the system (as per ‘guix system build’) and to bind-mount its closure in the container’s file system. I'm having trouble with this approach. pflask tries to create a /proc directory but can't because that would be writing to the store. Hmm, the store should be under /container/gnu/store, not /container, no? Do I need to bind-mount each sub-directory within the /gnu/store/...-system directory so that the root of the container directory is still writable? Let’s say /container is the root of the container. It must be a regular, writable directory. As a first step it’s OK to bind-mount all of /gnu/store to /container/gnu/store. What guix-daemon does is to bind-mount precisely each element of the store that is needed, so there’s no “leak”. HTH! Ludo’.
Re: Containers on Guix
On Thu, Nov 20, 2014 at 8:30 AM, 宋文武 iyzs...@gmail.com wrote: David Thompson dthomps...@worcester.edu writes: I did some reading about how Docker creates containers and discovered that it uses systemd-nspawn[0] to do it. Since Guix uses dmd, using systemd-nspawn isn't an option. Does anyone have thoughts on how we might have similar functionality in the Guix distro? I think what we need is pflask: https://github.com/ghedo/pflask A container is programs or full os running in an isolated environment. For a full container with rootfs, we can: build the rootfs: of Guix:by using a form of `guix system init' of Debian: by using debootstrap get it running: # pflask --chroot=rootfs /sbin/init For a lightweight container without rootfs, we can: build the activate script by `guix build' get it running: $ pflask --user=$USER activate (could run by normal user by using User namespace) Wow, thanks! I think pflask is exactly what I'm looking for. I'll write a guix package and do some experiments with it soon. Would an nspawn equivalent be appropriate for dmd? Or a completely separate program? Isolation is archieved by using Linux namespaces, IMO dmd will work well. It seems that with pflask, there's no need to add anything to dmd. We could extend guix system to use it to generate containers. This is a really great starting point. Thank you very much for pointing me in the right direction. - Dave
Re: Containers on Guix
Hello! Disclaimer: I’ve never used systemd-nspawn, and I’m not knowledgeable in this area. :-) AIUI, “containers” are basically what the daemon creates: an execution environment that uses a separate file system name space, network name space, etc. (see ‘DerivationGoal::startBuilder’ in libstore/build.cc.) For what you have in mind, one may want to be able to select which parts should be separate (apparently systemd-nspawn allows that), rather than the completely-isolated policy of guix-daemon. So, in terms of functionality, I think we want that subset of the daemon, in a more modular fashion (that subset would also be useful for Plash-like sandboxed execution, something I’d like to have eventually.) It doesn’t have to be part of the init system IMO, because it doesn’t have much to do with it. However, there has to be a mediating process with root privileges that can create these containers on behalf on unprivileged users–much like guix-daemon. In terms of code, I can think of several approaches. 1. Fork guix-daemon, and modularize it to do what we want. Perhaps it would be enough to add RPCs to create and configure a container (see worker-protocol.hh and (guix store).) Alternately, create a C library that provides just the container-handling logic (possibly with Guile bindings), and use it to write a separate daemon responsible for container handling. 2. Translate/rewrite the container-handling logic in Scheme. Use it to write a separate daemon, with the eventual goal of having a new build daemon that uses the same code base (all in Scheme.) 3. Use LXC to implement containers (?). liblxc seems to be perhaps too high-level from the examples on the web page; does anyone know? #2 is forward-looking, but quite a lot of work. #1 and #3 are more pragmatic. I hope that makes some sense. Ludo’.
Re: Containers on Guix
宋文武 iyzs...@gmail.com skribis: I think what we need is pflask: https://github.com/ghedo/pflask Indeed, that seems like a good fit! A container is programs or full os running in an isolated environment. For a full container with rootfs, we can: build the rootfs: of Guix:by using a form of `guix system init' I think it’s enough and cheaper to build the system (as per ‘guix system build’) and to bind-mount its closure in the container’s file system. Thanks, Ludo’.
Re: Containers on Guix
Ludovic Courtès l...@gnu.org writes: A container is programs or full os running in an isolated environment. For a full container with rootfs, we can: build the rootfs: of Guix:by using a form of `guix system init' I think it’s enough and cheaper to build the system (as per ‘guix system build’) and to bind-mount its closure in the container’s file system. I'm having trouble with this approach. pflask tries to create a /proc directory but can't because that would be writing to the store. Do I need to bind-mount each sub-directory within the /gnu/store/...-system directory so that the root of the container directory is still writable? -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate
Re: Containers on Guix
The missing footnote: [0] http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate
