Nix is not only a functional language with dynamic typing but also an entire ecosystem and a DevOps toolkit. Today we will look at what it brings to the table, but first, let’s figure out what DevOps is.
DevOps
DevOps is short for Development Operations. It’s a culture, a methodology if you will. The DevOps movement started around 2008 and aimed to solve the accumulated problems of the industry. Many companies still see these problems in the interaction between the development and operation teams.
Nix for DevOps
As anyone who has ever had to generate a makefile of 10,000 lines will confirm, having a full-fledged programming language to define your assemblies is a great idea. Any sufficiently complex assembly at some point will require some steps that can’t be declared – this is where Nix DevOps service comes in.
To fully understand the benefits that Nix offers, it is necessary to have an understanding of the various projects in the Nix ecosystem:
- Programming Language. The basic idea of Nix is that assembly instructions and dependency management are best performed using a full-fledged declarative programming language.
- Nix CLI Tools are programs that evaluate Nix applications for building or installing packages, debugging Nix code, and managing installed packages.
- Nixpkgs, the Nix Package Archive, is one of the world’s largest package repositories in the form of a git repository containing Nix code. It also includes a standard library for the Nix programming language.
- NixOS is a full-fledged Linux distribution created and managed entirely using Nix.
Having a mono-repository for all packages is also a kind of social technology that allows contributions from everywhere while simultaneously providing a central place for testing and quality control. nixpkgs contains over 55,000 projects, and only Arch’s AUR has more.
How does Nix solve problems?
Let’s take another look at packaging and development issues that Nix can solve:
- Individual dependencies. With Nix, you can harden the Nixpkgs version, which simplifies the packages. In addition, Nix makes it easy to redefine packages only to the version you need, so you have more control.
- Separation of runtime. Using pkgs.buildEnv is easy to create a development environment that includes all runtime dependencies plus development packages, and you don’t refer to this environment in the runtime.
- Avoid manual installation actions. In Nix, you either prefix the executed commands with the nix run -c or enter the development shell with the nix run -c $SHELL. Nix language extends the PATH to make the packages you need available. At startup, Nix creates a default.nix file, so the latest version is always used.
- Atomic installation. Nix installs packages along a path that depends on all the build source data, so a new version is installed along with the old one. First, ensure that all the necessary files are present, and then you can atomically replace one system unit file or symbolic link in /usr/bin and make it link to a new path.
- Instant rollback. Since the old version is not deleted when installing a new version of the package, the rollback is as easy as if a symbolic link or system unit were pointing to the previous path again. The old versions are garbage collected at some point.
- Sharing resources between versions. By putting extensive resources into separate Nix packages, they can be shared by multiple versions of our services. Since multiple versions are installed next to each other, services reference precisely the version they need, and atomic deployment still works, which would not be possible with APT packages.
As you can see, Nix offers a lot of solutions. Yes, becoming a DevOps engineer from scratch is not easy, but you can always outsource some of the tasks to expert Nix programmers and increase the efficiency of the whole system. As with Nix, it becomes much more straightforward.
