Re: Update on GuixSD containers

[Ludovic Courtès]

"Thompson, David" <address@hidden> skribis:

> I'd like to give a quick update on the state of wip-container branch.
> As of this morning, one can run the below commands and have a somewhat
> functional GuixSD container:
>
>   # Hardcoded /tmp/container as the container root directory until I
>   # add a command line switch.
>   mkdir /tmp/container
>   guix system container container-config.scm

Wonderful!  I’ve given it a try, and it works as advertised. ;-)
I was a bit afraid the first time I ran the ‘run-container’ script as
root, but everything went like a charm.

I tried adding this dummy service:

  (define (bash-service)
    (with-monad %store-monad
      (return (service
               (documentation "Run Bash from PID 1.")
               (provision '(shell))
               (start #~(make-forkexec-constructor
                         (string-append #$bash "/bin/bash")))
               (stop #~(make-kill-destructor))
               (respawn? #t)))))

... but it dies for some reason.  So no shell prompt.

> So, this is cool, but much work remains to be done.  Our containers
> operate in 5 of 6 possible Linux namespaces: mount, PID, UTS, IPC, and
> network.  The remaining namespace to get working is the user
> namespace, which is especially tricky.  I don't think even Docker can
> use user namespaces properly yet, but I might be wrong.  Additionally,
> our containers have a loopback device, but have no way of accessing an
> outside network such as your LAN or a virtual network on the host
> system.  There's also no support for cgroups, which would allow us to
> limit the resource usage of containers like you can with a VM
> hypervisor.

OK.

> For the long term, we'll need a container daemon to keep track of all
> containers on the system to allow for easily starting and stopping
> them (right now you have to 'sudo kill -9 <dmd pid>'), spawning new
> processes within them (for example, launching bash for an interactive
> environment), and whatever else we might want.

Having launched a bunch of containers and then hacked to kill all the
dmds, I can see why keeping track of containers matters.  :-)

Until there’s a daemon to keep track of containers, “guix system
container” could return the PID of the container’s PID1, to make it
easier to kill it later?

> In closing, things aren't exactly usable, but I encourage
> brave/curious people to take 'guix system container' for a spin and
> hack on it to make Guix the best container management tool yet!  Also,
> I think the code is very easy to follow (unlike Docker's
> libcontainer), so if you want to understand what containers *really*
> are beyond a buzzword, have a look at gnu/build/linux-container.scm
> and gnu/system/linux-container.scm.

Indeed I find the new code easy to read and well integrated; I like it!

It’s a shame that only CLONE_NEWUSER is available to non-root users.  I
wonder what the rationale was.  AIUI, Docker’s daemon performs clone(2)
on behalf of clients, right?

Thanks for the great work!

Ludo’.