Re: Containers on Guix

[ludo@gnu.org (Ludovic Courtès)]

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