Update on GuixSD containers

[Thompson, David]

Hey folks,

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

Where 'container-config.scm' is:

    (use-modules (gnu))

    ;; Minimal GuixSD configuration suitable for a Linux container.
    (operating-system
      (host-name "container-test")
      (timezone "America/New_York")
      (locale "en_US.UTF-8")
      ;; Unused
      (bootloader (grub-configuration (device "/dev/sdX")))
      ;; Dummy FS
      (file-systems (cons (file-system
                            (mount-point "/")
                            (device "dummy")
                            (type "dummy"))
                          %base-file-systems))

      (users (cons (user-account
                    (name "alice")
                    (comment "Bob's sister")
                    (group "users")
                    (supplementary-groups '("wheel" "audio" "video"))
                    (home-directory "/home/alice"))
                   %base-user-accounts)))

The activation and boot scripts for the system have been tweaked to
DTRT for a container, and DMD is able to start successfully and start
all of the base services, sans the console-font-tty services for some
reason.

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.

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.

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.

Happy hacking,

- Dave