Let’s talk about Docker and Nix today. Before explaining what Nix is, if you don’t know yet, and before going into the details, I will show you a snippet similar to a Dockerfile for creating a Redis image equivalent to the one in docker hub.
The final image will be around 42mb (or 25mb) in size, compared to 177mb.
If you want to try this, the first step is to install Nix.
Build it with:
Load it with:
docker load < result
Once loaded, you can see with
docker images that it takes about 42mb of space.
Fundamental differences with classic docker builds
- We do not use any base image, like it’s done for most docker images including redis from the hub. It starts from scratch. In fact, we set up some basic shadow-related files with the
shadowSetuputility, enough to add the redis user and make
- The Redis package is not being compiled inside Docker. It’s being done by Nix, just like any other package.
- The built image has only one layer, compared to dozens usually spitted by a readable
Dockerfile. In our case, having multiple layers is useless because caching is handled by Nix, and not by Docker.
A smaller image
We can cut the size down to 25mb by avoid using id from coreutils. As an example we’ll always launch redis without the entrypoint:
You might ask: but coreutils is still needed for the
mkdir and other commands like that!
The secret is that those commands are only used at build time and are not required at runtime in the container. Nix is able to detect that automatically for us.
It means we don’t need to manually remove packages after the container is built, like with other package managers! See this line in Redis
Dockerfile for example.
Using a different redis version
Let’s say we want to build a Docker image with Redis 2.8.23. First we want to write a package (or derivation in Nix land) for it, and then use that inside the image:
Note we also added the tag 2.8.23 to the resulting image. And that’s it. The beauty is that we reuse the same redis expression from nixpkgs, but we override only the version to build.
A generic build
There’s more you can do with Nix. Being a language, it’s possible to create a generic function for building Redis images given a specific package:
We created a “redisImage” function that takes a “redis” parameter as input, and returns a Docker image as output.
Build it with:
nix-build redis-generic.nix -A redisDocker_3_0_7
nix-build redis-generic.nix -A redisDocker_2_8_23
Building off a base image
One of the selling points of Docker is reusing an existing image to add more stuff on top of it.
Nix comes with a completely different set of packages compared to other distros, with its own toolchain and glibc version. This doesn’t mean it’s not possible to base a new image off an existing Debian image for instance.
dockerTools.pullImage it’s also possible to pull images from the Docker hub.
Build it with:
nix-build redis-generic.nix -A redisOnDebian.
Note that we added a couple of things. We pass the base image (
debianImage), to our generic
redisImage function, and that we only initialize shadow-utils if the base image is null.
The result is a Docker image based off latest Debian but running Redis compiled with nixpkgs toolchain and using nixpkgs glibc. It’s about 150mb. It has all the layers from the base image, plus the new single layer for Redis.
That said, it’s as well possible to use one of the previously defined Redis images as base image. The result of `pullImage` and `buildImage` is a .tar.gz docker image in both cases.
You realize it’s possible to build something quite similar to docker-library using only Nix expressions. It might be an interesting project.
Be aware that things like PAM configurations, or other stuff, created to be suitable for Debian may not work with Nix programs that use a different glibc.
Other random details
The code above has been made possible by using nixpkgs commit 3ae4d2afe (2016-04-14) onwards, commit at which I’ve finally packaged
gosu and since the size of the derivations have been notably reduced.
Building the image is done without using any of the Docker commands. The way it works is as follows:
- Create a layer directory with all the produced contents inside. This includes the filesystem as well as the json metadata. This process will use certain build dependencies (like
- Ask Nix what are the runtime dependencies of the layer directory (like
gosu). Such dependencies will be always a subset of the build dependencies.
- Add such runtime dependencies to the layer directory.
- Pack the layer in a .tar.gz by following the Docker specification.
I’d like to state that Nix has a safer and easier caching of operations while building the image.
As for Docker, great care has to be taken in order to use the layer cache correctly, because such caching is solely based on the
RUN command string. This blog post explains it well.
This is not the case for Nix, because every output depends on a set of exact inputs. If any of the inputs change, the output will be rebuilt.
So what is Nix?
The Nix concept is simple: write a Nix expression, build it. This is how the building process works at a high-level:
- Read a Nix expression
- Evaluate it and determine the thing (called derivation) to be built.
- By evaluating the code, Nix is able to determine exactly the build inputs needed for such derivation.
- Build (or fetch from cache) all the needed inputs.
- Build (or fetch from the cache) the final derivation.
Nix stores all such derivations in a common nix store (usually
/nix/store), identified by an hash. Each derivation may have dependencies to other paths in the same store. Each derivation is stored in a separate directory from other derivations.
Won’t go deeper as there’s plenty of documentation about how Nix works and how its storage works.
Hope you enjoyed the reading, and that you may give Nix a shot.
Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/IbZq1HcAU2E/cheap-docker-images-with-nix_15.html