NixOS: A Combination Linux OS and Package Manager
If you are game for a new way to think about building and deploying containers-based applications, the NixOS Linux distribution offers the promise of faster repeatable builds across different types of systems.
But there are still potential drawbacks of switching over to this open source technology, explained Reddit engineer, and author of Production Kubernetes, Josh Rosso, in a technical session at KubeCon+CloudNativeCon last month on this topic.
By day, Rosso works at Reddit. The social news aggregation site does not use Nix, though Rosso shared some insights where it could be used in similar settings.
“I really like Nix. I think it is really freaking cool,” he enthused. “The backbone is solid. The things that you can compose and build are insane.”
Nonetheless, “I would not introduce Nix at Reddit,” he told the audience.
Created in 2003 as a research project, NixOS is a Linux distribution that uses its own packaging system, Nix, to build itself and support other Linux applications, using a declarative model and a functional build language.
With Nix you build the OS you want.
“In NixOS, only sh and /usr/bin/env is available by default. Everything else is declaratively added into your root system. This way, I’m always aware of exactly what I have available on my system,” wrote software engineer Jethro Kuan in a 2018 post exploring the technology.
Nix for Infrastructure Provisioning
In many ways, Nix predates the current craze of Infrastructure as Code (IaC). A single blueprint can be used to quickly build multiple copies of the OS or other container-based apps, sometimes from scratch and sometimes copying previous builds. A Nix container can be based on different platforms. You can also do atomic upgrades and rollbacks.
This reproducibility could explain a growing interest in the technology. In its annual Octoverse report, GitHub notes that NixOS/nixpkgs has topped the list of open source projects by contributors, for the last two years.
The Cloud Native Computing Foundation found that, in the past year anyway, Nix has more commits (57,941) than Kubernetes itself (42,680), though Kubernetes has a few more contributors (3,662) than Nix (3,087).
Nix Packages and Modules (and Derivatives)
Rosso first came to the Nix when he had discovered a configuration file he had forgotten to copy over from his local drive. The ensuing headache of running a build again sent him looking for an easier way.
In his talk, Rosso demonstrated how to use Nix to set up a hypervisor, a virtual machine, and a container image, running them all together to build a fully functioning Kubernetes cluster.
“One of the most compelling things I’ve enjoyed the Nix is that this module model. We can build APIs for our systems, let people plug values into those APIs and do some pretty darn complex things,” Rosso said.
Nix has modules and packages: Libraries such as libvert are all packaged, and the modules offer installations of these packages for specific platforms. Users can specify which of the 80,000 packages (10,000 just for NixOS alone) they want to use, and Nix will fetch them from their repositories and install them seamlessly on their respective systems.
For instance, within each instance of NixOS, the systemd.network configuration file is augmented with modules for the specific hardware being used to run the OS. The OS or the app can be moved to another platform simply by swapping out the appropriate modules.
Nix keeps track of all these builds through a hashing system, and can even recreate build on the fly, at a fraction of the time it would take to build anew if there was a similar build on file.
Nix to Deploy Kubernetes
To show how Nix could be used to manage Kubernetes, Rosso set up a virtual machine disc image populated with Kubernetes, containerd, and kubeadm, and then spun up three instances. A download/install from the Nix shell of a container network interface (Cilium) got a functioning cluster, with CoreDNS support.
To build the containers, Nix has utilities such as dockerTools, a Dockerfiles-esque tool, for building fully-layered images, with each package its own layer.
“It’s turtles all the way down with Nix,” Rosso said. “It’s a bunch of Nix language specifying these pure functions. They take an input, they build a thing, and they provide an output. ”
Worse Is Better?
So why would Rosso not use Nix at his specific day job?
For one, there are already a number of container-native Linux distributions that work in a similar fashion, such as BottleRocket and Flatcar Linux (the latter based on the distribution from CoreOS where Rosso once worked). (Also — and a bit further out — on this frontier of container-based package management is Chef Habitat).
Also, there is a learning curve with the API. Perhaps as when LISP was eclipsed by the emergence of C++, Nix is too pure, and can trip up new users with obtuseness. The project still needs to find ways to better reach end users, Rosso suggested.
So for now, anyway, the value Nix may bring is not quite worth the learning curve it would take to get there, for many organizations.
Watch Rosso’s entire presentation, which is quite entertaining, here:
TNS analyst Lawrence Hecht contributed to this report.