Containers have become a hot topic. Docker, LXC, Rkt, systemd-nspawn,
etc. are popular and make a lot headlines on technology news websites.
There are even entire conferences dedicated to "containerization."
The next release of GNU Guix, a purely functional package manager,
will feature basic support for Linux containers, dubbed
call-with-container. GNU Guix is written in the Guile Scheme
programming language. Thus, in typical Scheme fashion, we have used
the call-with-* naming convention (like our old friend
call-with-current-continuation, for example) to refer to the
container implementation, which allows the user to apply an arbitrary
Scheme procedure in a new, containerized process. For those familiar
with Guile, it’s like a fancier version of primitive-fork. In
addition to forking via clone(2), call-with-container unshares
resources such as the network, mount, and user namespaces from the
host system and creates a temporary file system in a chroot (though we
actually use pivot_root instead), among other things.
So, given the fast-paced world of Linux container development and the
companies investing huge sums of money into the aformentioned tools,
why add another implementation to the mix? What’s wrong with the
status quo? What can Guix possibly add? Let’s dive into the
motivation behind Guix containers, how they differ from the status
quo, and how they solve issues that other implementations cannot.
The Trouble with Disk Images
The term "container" has in practice come to mean a disk image whose
binaries are run in a lightweight virtualization with kernel
namespaces. Docker and friends work with raw disk images, or layers
of them, as their fundamental data unit. There are several issues
with this approach. This presents issues with regards to disk and
memory usage and file system complexity. Containers typically include
the minimal core software of a GNU/Linux distribution within them,
plus the extra software that is application-specific.
WRITEME: Deduplicating software amongst containers via
content-addressable storage (/gnu/store) and full dependency graph
Imperative vs. Functional – The Dockerfile Problem
WRITEME: Functional > Imperative. Mention issues with imperative
Dockerfiles and how the order of operations influences how well the
cache is utilized. Docker cannot possibly know the details that Guix
knows because Docker defers to other package managers to do things
that are opaque to it.
Guix and GuixSD Containers
WRITEME: Simple, unprivileged containers with ‘guix environment’. Add
example for sharing file systems from the host.
WRITEME: GuixSD containers with ‘guix system container’. Mention the
use of a real init system (dmd) and the full-system configuration
WRITEME: An arbitrary Scheme script that launches a container, showing
that (guix build linux-container) is a generic library to be re-used as
WRITEME: The future: cgroups, networking, orchestration. Reach out
As an aside, before I bid you farewell, dear reader: I live in the
Boston area and I’m looking for local meetups and conferences that
would welcome a technical presentation about GNU Guix and the benefits
of the functional package and configuration management paradigm. If
you have the connections and I have piqued your interest, please send
an email to davet at gnu dot org.
From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.