Guix: a factory for containers?

Note: This short post is an English adaptation from a presentation in JRES 2024 in Rennes. Thanks to Alain Zamboni and Rémi Cailletaud for hosting the session. And I am very grateful to them for their comments when preparing the paper and slides, and their patience.

What I would like to convince you is: Guix is an (almost) perfect factory to build containers and other virtual machines. What’s Guix? Well, if you are reading this post, you already know, almost surely! If not, please give a look to my other talks. Other than my boring blah? I recommend Steve’s material or this Cayetano's crash course. In short, Guix is tool that helps to compose computational environments, from package management to complete system.

Why Guix? Because Guix identifies software: it captures all the details (directed acyclic graph, DAG) – as all the other package managers around – and provides helpers for scrutinize and/manipulate these details, e.g., here or here or here or here or etc. Because we have a fine control on how the binaries are produced and packed into computational environment, it’s easy to redeploy the same configuration whenever or wherever. Guix’s rocks!

Roughly speaking, most (if not all) Dockerfile contains:

FROM debian:stable
RUN apt-get update && apt-get install python3 python3-numpy

where you might replace Debian by anything else as Alpine, r-base, etc. Obviously nothing wrong with Debian: the project paves the way about Reproducible Builds; checkout the nice talk Reproducible Builds: The First Eleven Years by Holger Levsen at DebConf24. And so, what’s the issue? Three questions:

How to inspect the base image?
How to know what update and install does and/or will do?
How to build a package variant?

That’s where Guix shines, for what my opinion is worth. Guix allows to inspect and control what is inside the container. In other words, my point is to replace these two lines by:

two files: manifest.scm and channels.scm
FROM produced-by-guix

This way, later you are still able to build the same base image (named produced-by-guix) with the invocation:

guix time-machine -C channels.scm -- pack -f docker -m manifest.scm

Why Guix’s a factory? Because instead of building a container with the Docker format, you could also build a container with the Singularity format, or any other supported formats (guix pack --list-formats). Concretely, consider the scenario:

alice@laptop $ guix time-machine -C channels.scm -- pack -f docker   -m manifest.scm
blake@desktop$ guix time-machine -C channels.scm -- pack -f squashfs -m manifest.scm

It means Alice and Blake generate two containers with two different formats (Docker and Singularity) using two different machines but the both containers contain the exact same binaries (described by the file manifest.scm). Cool, isn’t it?

Hey, I hear you: Dockerfile is more than often more complicated than just FROM and install a bunch of packages. Yes! And that does not change. All the question is to be able to control and predict what you get when you run docker build . whatever where or whenever when.

Somehow, using the same revision (056910e), you should get the same Guix profile (i620b8szr4dqq3vz9dqfzfr4r5jyz5zh) containing the same hello binary (0ce19e76e0a44e689e6c07daa6018adc). Are they? If no, let me know!

$ docker load <$(guix time-machine -q --commit=056910e \
                      -- pack -f docker hello coreutils bash)

$ cat Dockerfile
FROM hello-coreutils-bash
RUN ["sh", "-c", "echo path: $PATH"]
RUN ["sh", "-c", "md5sum $(type -P hello)"]
RUN ["hello"]
ENTRYPOINT ["hello"]

$ docker build . -t my-tag
Sending build context to Docker daemon  2.048kB
Step 1/5 : FROM hello-coreutils-bash
 ---> cc2fa8ef053a
Step 2/5 : RUN ["sh", "-c", "echo path: $PATH"]
 ---> Running in 14605a519037
path: /gnu/store/i620b8szr4dqq3vz9dqfzfr4r5jyz5zh-profile/bin
Removing intermediate container 14605a519037
 ---> de5f6af6f0b9
Step 3/5 : RUN ["sh", "-c", "md5sum $(type -P hello)"]
 ---> Running in cc52e3114f5f
0ce19e76e0a44e689e6c07daa6018adc  /gnu/store/i620b8szr4dqq3vz9dqfzfr4r5jyz5zh-profile/bin/hello
Removing intermediate container cc52e3114f5f
 ---> 9262a7956e02
Step 4/5 : RUN ["hello"]
 ---> Running in 0a34cd6aff9f
Hello, world!
Removing intermediate container 0a34cd6aff9f
 ---> 1850f5fd88b6
Step 5/5 : ENTRYPOINT ["hello"]
 ---> Running in 7a5796369713
Removing intermediate container 7a5796369713
 ---> 390753824a86
Successfully built my-tag:latest

$ docker run -ti my-tag
Hello, world!

Therefore, as complex as Dockerfile could be, what’s inside the container is reproducible because controlled by Guix. The main idea: decouple how to populate the container and how to configure it. Because containers are helpful when moving stuff from one place to another, after all. When house moving, what’s inside the boxes matter a lot, not so much the matter of the boxes or the type of truck.

Last, maybe the most adventurous of you would also like to configure all using Guix. Yeah, guix system is for you! Similarly, give a look to guix system --list-image-types.

Join the fun, join Guix!