Environment containers

[Thompson, David]

Hello Guix hackers,

I am pleased to announce that the patch for adding Linux container
support to 'guix environment' has just landed in master!

Why is this cool, you ask?  Well, it enables one to truly isolate
development environments from the rest of the system, much more so
than --pure does.  The --pure option only clears the environment
variables, but --container goes further and "unshares" kernel
resources (such as the user, mount, and pid namespaces) and creates a
chroot environment that has no file system access to what might be
considered "impurities."  The only file systems from the host that
make it into the container by default are the current working
directory and the store paths for all of the needed software.  This is
especially useful when running Guix on top of another host distro,
where sometimes things from the host sneak into your build environment
because a tool decided to inspect the contents of /usr or something.

You can use it like this:

    guix environment --container guix

The above command will create an isolated container with everything
you need to build Guix from source.

There's more fun to be had, too.  Sometimes it's nice to make ad-hoc
sandboxes just to play around in.  The below command will run a
sandboxed Guile REPL:

    guix environment --container --ad-hoc guile -- guile

By default, containers have no network access.  To share the host
network, use the --network flag.

This is just the beginning!  There's lots more to do.  It would be
nice to be able to create a network bridge so that the container can
have network access without sharing the host devices, a la Docker and
friends.  It would also be great to incorporate cgroups to arbitrarily
restrict container resources.

Coming soon is 'guix system container', which creates full-blown
GuixSD containers.

Since I mentioned Docker, I'd like to point some significant
advantages that Guix containers have over other implementations:

1) The container tools I'm working on are completely declarative.  No
imperative Dockerfiles!  This means that you don't have to worry about
order of operations, something that you have to think about constantly
when using Docker, especially when trying to maximize the use of the
image cache.

2) There are no disk images.  Disk images are opaque blobs that are
often not reproducible, whereas the items in the Guix store tell you
the full story of how the software came to be.  Thus, Guix containers
do not worry at all about the complications involved with layering
disk images in an overlayfs-style setup.  They are simply not needed.

3) Software and other files shared amongst many containers are
deduplicated system-wide.  This is a big deal from my perspective.
With Docker, container images *must* share as many base image layers
as possible to take advantage of deduplication, and there's
limitations to how smart overlay file systems can be to do
deduplication in memory (citation missing because I can't find the
article that explained the issues.)  Some people say that Docker is a
higher-level form of static linking, but instead of static linking the
executables, you "statically link" an entire, albeit more minimal,
operating system for each application that you run.  I'm inclined to
agree, and I'm happy to say that Guix doesn't have this problem.  A
store item present in N containers exists in exactly one place: in the
host store.  We take great advantage of bind mounts to share
everything without duplication.  Once again the fundamental building
block of every Guix tool, the immutable store, proves to be an
invaluable asset in overcoming the problems of our imperative
predecessors and contemporaries.

I hope this excites some of you.  Containers are all the rage right
now, and they have some seriously good properties if you can look past
the Docker hype.  I'd love to get some more hands to help make Guix
containers more featureful and robust in order to compete with the
mainstream tools.

Until next time, happy hacking!

- Dave