Hacker News new | ask | show | jobs
by lobochrome 564 days ago
Could someone please help me understand the benefit of Nix versus just using docker-compose?

Also please don't tell me k8s it. Way too heavy.

I run a few applications on a souped-up Raspi (paperless-ngx, jellyfin, some postgres dbs). I can't see why this would improve things. :)

Honest question.

6 comments

In this context, I think the prime advantage would be that instead of: - Managing/setting Ubuntu/$distro for the host - Installing Docker compose on host - Writing a docker-compose.yaml file to declare your container architecture - (potentially) Writing a systemd service to bring docker-compose up with the host boot

You just: - Mange/setup nixos - Add container architecture definition to nixos config

The containers, being systemd units, would have all the normal systemd log management like the rest of your system, instead of having to dig through docker-compose logs with a different mechanism than "normal" systemd service logs.

You'd also get all the normal benefits of a nixos system: the config file can be placed on a new system to completely reproduce the system state (modulo databases et all), rollbacks are trivial, etc.

This hits the nail on the head. Well said.

I really like being able to manage the managing and host machine in one configuration. It's a blessing from an Op's perspective.

Nix is a language, package manager, and OS. This post discusses NixOS.

While docker-compose allows you to compose your containers with a yaml/Dockerfiles, NixOS allows you to compose the system that all of your containers run on (from userspace down to kernel selection/configs, file system, etc), as well as your containers - all in a declarative .nix file. That .nix file can be used to spin up any number of identitically configured systems.

It's also reproducible, in that you can specify the sources (refined to a specific commit if you prefer) for any and all packages on the system - and build them with Nix within a sandboxed environment protecting dependencies and env configurations (Nix is also a powerful build system).

Agreed, reproducibility is a huge benefit. Being able to spin up a new machine quickly with a config you already know works is an awesome feeling.
From my experience,

1. There are many services that is already "implemented" in NixOS, with sane default configurations and easy to customize (because the contributors have designed good abstractions, and also because of the flexibility of Nix language). One good example is `nginx`. Btw `paperless-ngx` and `jellyfin` are also already implemented. In this case you do not need to use docker at all.

2. Because of the good abstraction in the service implementation, I usually do not need to go very deep to understand the common configurable options for each of the services.

3. All those services become systemd services once up. As long as you are familiar with how to manage systemd services at runtime, you know how to work with them.

4. Even for those ones that do not exist in NixOS, as the authoer suggested you can still start them as docker-based systemd services, with very simple and intuitive nix configurations.

5. NixOS configuration are mostly deterministic and modular. I can use git to manage all the configurations for different servers. There can be occasions that I will need to migrate the services to a differen machine (e.g. upgrade, replicate, ...). With the NixOS configuration of those services, I can simply re-use the configuration code and have a very high confidence that they will work as expected on a new machine.

6. The above also makes it very easy to revert my deployment to any previous successful version. Without having to worry about breaking anything, it also gives me the confidence to quickly try out different ideas.

> with sane default configurations

What entity is responsible for the security of those combinations of default settings? And how are security updates handled?

The contributors to nixpkgs for the most part, the whole thing is on github and it's one of (if not the) largest Linux package repo of any distro. You can override defaults easily. Security updates are handled by updating your nix channel and rebuilding the system, or updating your flake and a rebuild (if the maintainer has released a more recent version, if they haven't you can make an overlay and bump the version, add your own patches to the build or 'derivation'. Rollbacks are baked in until you remove them from the 'nix store'. You can configure all the things!
I run several services on my home server. For those that are well packaged for Nix, I just use those. For ones that are poorly packaged or not available, I use oci-containers. They all run as systemd services and operate the same way, so it's a consistent interface.
Nix is more about package management (and a OS) while docker is more container focused.

But because the individual software on nix is so well separated / encapsulated it carries similar benefits to containers. So they’re different but with overlap

1. There are many services that is already "implemented" in NixOS, with sane default configurations and easy to customize (because the contributors have designed good abstractions, and also because of the flexibility of Nix language). One good example is `nginx`. Btw `paperless-ngx` and `jellyfin 2. Because of the good abstraction in the service implementation, I usually do not need to go very deep to understand the common configurable options for each of the services.