Hacker News Reader

Comment by rudolph9 | Hacker News Reader

One thing people forget is containers don’t necessarily not to be created with Docker.

Lately I’ve been creating containers using NixOS and couldn’t be more happy with the ability to have everything in the container configured by a configuration.nix file. https://nixos.org/nixos/manual/#ch-containers

The idea of a Docker Ubuntu, Arch, Alpine, etc base image is kind of silly when you think about it. The idea that we have separate repo for sharing massive container images sometimes multiple GB rather that a simple file that can be tracked in git and will produce the same image every-time has been very eye opening.

Note: NixOS isn’t perfect but it has a growing community and hands down the best thing out there except for maybe guix which has container support too https://guix.gnu.org/blog/2018/tarballs-the-ultimate-contain...

View on HN

How is a configuration.nix any different than a Dockerfile?

Dockerfiles are imperative and the order of steps changes the container image that ultimately gets built.

Nix packages are declarative and idempotent. Everything is based on a functional package manager and when you configure your container via nix you get the same thing every time and can easily mix and match other packages and dependencies.

A contrived example is you have a program that depends on multiple versions of python, because nix does not globally set dependencies rather links them locally you can have both with versions of python without any conflicts

Containers built from Dockerfiles are difficult to exactly reproduce too. A very common practice is to update the package manager in which depending on what the server returns will be different from one day to the next where as nix hash addresses and builds from source everything (you can use caches to speed this up) and you get the same thing every time.

Note: NixOS isn’t perfect in terms of being purely functional as many package builds use scripts in pearl,bash,etc but from my understanding these are usually source specific reproducibility issues with Building particular packages and generally speaking things works as expected.

Then have your Dockerfile build from source. Many of the public layers that people build their containers upon do that for that exact reason.

If NixOS is only "generally speaking" correct because of the order it runs its scripts, then put it in a Docker container, where the whole point is to perfectly reproduce the order you run your scripts in order to minimize the errors that arise from doing otherwise. Still worried? That's why layers exist, so that every step you run you now have a static binary that you know will never shift under you, and that you can keep on building on top of.

In practice, building Dockerfiles is unreliable and can produce errors because they inherit all of the deficiencies of aptitude, python packaging, javascript packaging, et al.

In practice, building nix dependencies is reliable and reproducible because of the militant isolation of build environments, hash integrity checks on _all_ inputs, explicit dependencies, and the long tail of bug fixes related to non-determinism in unix tooling.

This is my personal experience, not abstract.

That's a great a vote of confidence. I would've thought that nix would only manage packages on the OS-level. How does it re-implement pip to be reliable? I currently have to stage a couple of `apt-gets` and `pip installs` before my `pip install requirements`, and it took a couple of tries to lock in the right sequence that worked. How does nix solve those problems?

Ha! I did this but the containers end up being somewhat large since you have all the NixOS package stuff in the container too.

However, building the container from a configuration.nix file gives you exactly what you need in the container and nothing more. It's like basing your container from scratch in a Dockerfile and copying only the needed compiled dependencies and nothing more into the container.

The declarative and idempotent container specification seems like a nice developer QOL improvement over docker but...

> Containers built from Dockerfiles are difficult to exactly reproduce

This isn't true in my experience, at least for a level of exactness that could have an impact on the behavior of the software running in the container. I have been working with docker in various contexts for 5 years and have never experienced any issues related to reproducibility (which is pretty much the primary selling point of docker). To your point though, I can see how reproducibility issues could happen in theory, but since its not a problem in practice it doesn't make for a very compelling reason to try nix instead. Just to be clear, I'm not trying to disparage nix, it honestly sounds pretty interesting, especially as a way to automatically provision a local workstation (docker is not good at this), but I am still curious as to the practical tradeoffs in terms of nix vs docker as a tool for building containers.

Here is a decent example of a docker image being created from nixPkgs https://github.com/input-output-hk/plutus#how-to-run-a-local...

Another advantage is a unified development environment as I can run the server in the container or directly on host machine in an isolated nix-shell.

Yet another advantage, is unlike the layer of a docker container, isolated dependencies are isolated and linked so packages link together based on a hash-address/path of a dependency in the nix store so there is no need to worry about order of steps but rather what depends on what making the cache misses in a nix-store vs a docker layer more efficient. For example if the first step in a Dockerfile needs to be changed all proceeding steps need to be rebuilt where as if a dependency in a nix file say paython-2 to python-3, every package that depends on python just get re-linked and only those packages need to be updated and you already have python-3 used in a nix-shell or in another container odds are it's already cached and ready to go!

Huge nix fan. Question: how do you deploy these with k8s? Do you just build a NixOS docker image "wrapper" around all the other stuff?

Haven’t actually deployed to k8s, currently using them to isolate local development but there I know (at least at one point) kubernetes supported other images than just docker images but even if they do t NixOS containers supports generating docker images...

I imaging a ci/cd flow where it build the image and installs your app via a local Nix package built from source in your git repo and all that needs to be shared is the git repo and you have everything you need to reproduce the container er running in production.

Reply on news.ycombinator.com