Die Nix-Adoptionsleiter: Sechs Stufen reproduzierbarer Infrastruktur

Nix: From Zero to Hero — A Hands-On Path to Reproducible Everything

The hands-on Nix path: install, nix-shell, flakes, packaging, dockerTools images, NixOS — plus caches, secrets, disko, and tests.

Der Nix-Spirit

Nix wird oft als radikaler Bruch dargestellt: ein komplett neues Betriebssystem, eine neue Art, Software zu bauen, ein neues mentales Modell für alles. Diese Darstellung schreckt Teams ab, denn „alles auf NixOS umstellen“ klingt nach einer Migration über mehrere Quartale ohne Zwischenstopps.

Die Realität sieht anders aus. Nix ist eine Leiter — man kann Sprosse für Sprosse aufsteigen, und jede Sprosse rentiert sich, bevor man entscheidet, ob man weiter klettert. Der „Nix-Spirit“ ist kein spezifisches Tool; es ist eine Reihe von Eigenschaften, die man inkrementell übernehmen kann:

• Reproduzierbarkeit — derselbe Input erzeugt immer denselben Output, auf das Byte genau fixiert.
• Deklarativer Zustand — der gewünschte Endzustand lebt im Code; die Maschine folgt diesem.
• Eine einzige Quelle der Wahrheit (Single Source of Truth) — kein Drift zwischen dem, was man letztes Jahr geschrieben hat, und dem, was heute läuft.
• Komponierbarkeit — Bausteine, die zusammenpassen, von einer Dev-Shell bis hin zu einem bootfähigen Image.

Dieser Artikel definiert sechs Stufen der Übernahme dieses Spirits, von „fixierten Tools in einer Shell“ bis hin zu „immutablen, selbstheilenden Appliances“, und begründet jede Stufe anhand realer Deployments: ein neun-Knoten-K3s-Cluster, provisioniert mit OpenTofu und Ansible, ein air-gapped drei-Knoten-K3s-Cluster mit Ceph-Storage und ein Groupware-Stack (SOGo, OpenLDAP, Stalwart), dessen Container-Images mit Nix gebaut werden.

Level 0 — Die imperative Baseline

Die Baseline, von der die meisten Infrastrukturen starten: Per SSH auf einen Host einloggen, Dinge apt install, Konfigurationsdateien manuell bearbeiten und hoffen, dass das Backup der Konfigurationsdatei aktuell ist. Der Zustand lebt auf der Maschine, nicht im Code.

Das Versagensmuster ist der Drift. Die Person, die den Host provisioniert hat, ist ausgeschieden; die Wiki-Seite, die den speziellen Cronjob erklärt, ist weg; der Monitoring-Alarm für den Dienst, von dem „niemand weiß, wer ihn eingerichtet hat“, wird stummgeschaltet. Audits werden zur Archäologie.

Sie wissen, dass Sie bereit für Level 1 sind, wenn einer der folgenden Punkte zutrifft:

• Die Einrichtung einer neuen Workstation oder eines Jump-Hosts dauert länger als eine Stunde und erfordert ein README mit 40 Befehlen.
• Zwei Engineers im selben Projekt nutzen unterschiedliche Versionen desselben CLI, und „auf meiner Maschine funktioniert es“ ist ein täglicher Satz.
• Ein Build, der im Januar funktionierte, schlägt im Juni aus Gründen fehl, die niemand erklären kann.

Level 1 — Nix als Developer-Tool: Die fixierte devShell

Die erste Sprosse ist die günstigste und am unmittelbarsten nützlichste: Nutzen Sie Nix, um zu definieren, welche Tools in Ihrer Shell existieren. Eine flake.nix mit einer devShell ersetzt den Abschnitt „Installieren Sie diese 12 Tools“ in Ihrem README durch einen einzigen Befehl — nix develop —, der jedem Contributor die exakt gleiche Toolchain auf jeder Linux- oder macOS-Maschine zur Verfügung stellt.

Ein reales Beispiel aus einem Kubernetes-Operations-Repo:

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let pkgs = nixpkgs.legacyPackages.${system};
      in {
        devShells.default = pkgs.mkShell {
          packages = [
            pkgs.kubectl
            pkgs.kubernetes-helm
            pkgs.helmfile
            pkgs.ansible
            pkgs.yq-go
          ];
        };
      });
}

Dies ist kein Spielzeugbeispiel — es ist das Muster, das verwendet wird, um die exakte Admin-Toolchain (kubectl 1.32.3, helm 3.15.3, helmfile 0.150.0, ansible 2.16.0, yq) für ein Multi-Cluster-Deployment zu fixieren. Die Vorteile in der Praxis:

• Versionsfixierung standardmäßig. Das Flake lockt jeden Input auf einen Content-Hash in flake.lock. Niemand schleicht eine Änderung einer Minor-Version des CLI ein, die sich in der Produktion anders verhält.
• Identische Umgebungen. Dieselbe nix develop funktioniert auf einem Laptop, einem Jump-Host hinter einem HTTP-Proxy und einem CI-Runner. In einer air-gapped Umgebung wird die Closure entweder vorab abgerufen oder aus einem lokalen Cache bereitgestellt — keine curl | sh aus dem Internet.
• Keine Systemverschmutzung. Tools leben im Nix-Store und verschwinden aus der Shell, wenn man sie verlässt. Keine „which kubectl“-Mehrdeutigkeiten mehr.

Was es kostet: Das Erlernen der Flake-Syntax und einiger Nix-Idiome. Das ist ein Wochenende, kein Quartal. Wann man hier aufhört: Wenn Ihr Problem ausschließlich darin besteht, dass „die Tools zwischen den Maschinen variieren“, löst dieses Level das bereits.

Level 2 — Nix in der Build-Pipeline: Container-Images aus einem Flake

Die zweite Sprosse: Nutzen Sie Nix, um die Artefakte zu bauen, die Ihr Deployment konsumiert — am häufigsten OCI-Container-Images. dockerTools.buildImage und buildLayeredImage erzeugen Images, die reproduzierbar sind, über den Store-Pfad Layer-gecached werden und frei von der Unsicherheit „letzten Dienstag von Docker Hub gezogen“ sind.

Das Muster, das sich in der Praxis bewährt hat, ist ein Flake pro Service, wobei das Image als Package-Output dient und derselbe Ausdruck als CI-Check wiederverwendet wird:

{
  description = "Nix flake for OpenLDAP container images";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/release-24.05";
  };

  outputs = { self, nixpkgs, ... }@inputs:
    let
      supportedSystems = [ "x86_64-linux" "aarch64-linux" ];

      mkImage = system:
        import ./images/openldap.nix {
          inherit system;
          pkgs = nixpkgs.legacyPackages.${system};
        };
    in {
      packages = nixpkgs.lib.genAttrs supportedSystems (system: {
        openldap = mkImage system;
        default = mkImage system;
      });

      checks = nixpkgs.lib.genAttrs supportedSystems (system: {
        default = mkImage system;
      });
    };
}

Drei Eigenschaften dieses Flakes sind es wert, kopiert zu werden:

1. Multi-Arch vom ersten Tag an. genAttrs über supportedSystems leitet x86_64- und aarch64-Images aus einem einzigen Ausdruck ab — keine separaten Dockerfiles, die auseinanderdriften. Derselbe Trick, via extendModules, leitet Umgebungsvarianten aus einer einzigen Basis-Konfiguration ab.
2. Das Image ist gleichzeitig ein Check. Die Auflistung der Derivation unter checks bedeutet, dass nix flake check in der CI sie auswertet und baut. Wenn der Ausdruck bricht, bricht die CI — bevor irgendetwas in eine Registry gepusht wird.
3. Der Build ist die Dokumentation. Das Patchen eines Dienstes ist ein Nix-Ausdruck, kein Haufen von sed-Befehlen in einem Dockerfile. Ein Groupware-Frontend, das Accessibility-Fixes benötigte (ein z-index-Bug bei einem Dialog, ein Kontrastproblem bei einem Platzhalter, ein Theme-Mismatch), wird als Patch ausgeliefert, der während des Builds angewendet wird — der exakte Satz an Änderungen ist in der Versionsverwaltung sichtbar und für immer reproduzierbar.

In einem air-gapped Cluster rentiert sich diese Sprosse sofort: Images werden einmal gebaut, in eine lokale Registry geladen, und die Nodes benötigen überhaupt keinen Zugriff auf Docker Hub. nix build + docker load + docker tag + push ist die gesamte Publish-Pipeline. Was es kostet: eine dockerTools Lernkurve und anfangs langsamere Iterationen als bei einem Dockerfile. Wann man hier aufhört: wenn Ihr Team eine Handvoll Images verwaltet und der Schmerzpunkt darin liegt: „Was genau ist in diesem Image und wer hat es wann gebaut“.

Level 3 — Nix als Distributionsmechanismus: Caches, CI-Gates und Qualität

Die dritte Stufe befasst sich mit dem Ökosystem rund um die Builds: Nix wird zum gemeinsamen Substrat dafür, wie Code im Team formatiert, geprüft und verteilt wird.

• Formatierung und Linting als Flake-Output. treefmt mit nixfmt (Formatter), statix (Linter mit Autofix) und deadnix (Entfernung von totem Code) wird zur einzigen Quelle der Wahrheit („Single Source of Truth“) dafür, was „formatiertes Nix“ bedeutet. Ein nix fmt pro Repo, erzwungen in der CI.
• nix flake check als CI-Gate. Eval-only-Checks, Image-Builds und sogar vollständige NixOS-Integrationstests (testers.runNixOSTest, die eine VM booten und das Service-to-Service-Verhalten prüfen) laufen, bevor etwas gemergt wird.
• Binary Caches für die Flotte. nix-serve, Attic oder harmonia mit signierten Store-Pfaden ermöglichen es jedem Node und jedem CI-Runner, vorab gebaute Artefakte zu ziehen, anstatt sie lokal zu bauen. Ein post-build-hook lädt jeden neuen Pfad automatisch hoch. In einem Air-Gapped-Netzwerk ist dies der Unterschied zwischen „der Cluster baut in Minuten neu“ und „der Cluster baut einen Tag lang neu“.
• Remote- und verteilte Builds. Eine dedizierte Build-Maschine (oder ein VM-Builder auf der Maschine eines Entwicklers) wird über nix.buildMachines und nix.distributedBuilds zur Build-Farm der Flotte.

Ein subtiles, aber mächtiges Muster auf dieser Ebene: Nix als Konfigurationsgenerator. Anstatt Kubernetes-Manifeste händisch zu schreiben, generiert das Deployment diese aus Nix — eine Library mit einer k8s Funktion wandelt typisierte Nix-Werte in YAML um. Alle 57 Services eines Deployments (von ArgoCD und Monitoring bis hin zum Mail-Stack) werden aus einem einzigen Expression-Tree abgeleitet. Die Manifeste sind im Cluster weiterhin YAML, aber es ist generiertes YAML mit einem einzigen Ursprung, und die Neugenerierung ist ein Build-Schritt, keine manuelle Bearbeitungssitzung.

Was es kostet: Infrastruktur (ein Cache-Server, eine Build-Maschine) und CI-Plumbing. Wann man hier aufhört: wenn Ihre Images mit Nix gebaut werden, Ihre Nodes und Maschinen aber immer noch imperativ verwaltet werden — Level 4 ist ein anderes Projekt.

Level 4 — NixOS auf den Nodes: Das Betriebssystem als Code

Die vierte Stufe ist diejenige, die sich die meisten Menschen vorstellen, wenn sie „Nix“ hören: das OS selbst wird in einem Flake deklariert. /etc wird aus der Konfiguration generiert; ein Rollback ist ein Eintrag im Boot-Menü; Secrets sind im Repo verschlüsselt und nicht über Hosts verteilt.

Die modernen Muster, die alle im Ökosystem praxiserprobt sind:

• Disk Provisioning as Code — disko deklariert Partitionen, Dateisysteme und LUKS-Verschlüsselung im selben Flake; nixos-anywhere installiert eine Remote-Maschine aus dieser Deklaration über SSH, ohne dass man eine ISO-Installation begleiten muss.
• Impermanence — das Root-Dateisystem wird bei jedem Boot gelöscht; nur explizit deklarierter State (via impermanence oder systemd StateDirectory=) überlebt. Eine kompromittierte oder korrupte Maschine kehrt durch einen Neustart in ihren deklarierten Zustand zurück.
• Secrets außerhalb des Stores — der Nix-Store ist weltweit lesbar, daher landen Secrets niemals darin. agenix und ININ21 verschlüsseln Secrets im Repo; systemd LoadCredential= übergibt sie den Services zur Laufzeit.
• Fleet Deployment — Colmena und comin verwalten viele Hosts aus einem Flake; nixos-rebuild pro Host bleibt für den Single-Machine-Fall.
• Rollback als Feature — jede Aktivierung ist eine neue Generation im Bootloader. „Gestern hat es noch funktioniert“ ist eine Auswahl im Boot-Menü, keine Wiederherstellung aus einem Backup.

Wo lässt das einen Cluster, der bereits Kubernetes ist, stehen? Die ehrliche Antwort aus Erfahrung: NixOS-Nodes und K8s-Workloads ergänzen einander. Die Nodes des Clusters werden reproduzierbar, selbstheilend und synchron gepatcht (ein Flake = ein bekannt-gut funktionierendes Node-Image), während die Workloads weiterhin in Containern mit ihrem eigenen Lebenszyklus laufen. Ansible hat immer noch eine Rolle beim Bootstrap und für Dinge, die Nix nicht gut modelliert — aber die driftanfällige Zwischenschicht (händisch editierte /etc, Ad-hoc-Pakete, manuelle sysctls) verschwindet.

Was es kostet: die steilste Lernkurve bisher; NixOS hat seine eigene Art, Networking, Benutzer und Services zu handhaben. Wann man hier aufhört: wenn Ihre Flotte klein ist und Ihre Nodes bereits „Pets“ sind, die Sie selten anfassen, ist der ROI möglicherweise noch nicht gegeben.

Level 5 — Immutable, Self-Healing Appliances

Die oberste Stufe: Die Maschine hört auf, eine Maschine zu sein, und wird zu einem Appliance. Alles Vorherige gilt, plus:

• A/B-Updates mit automatischem Rollback — systemd-sysupdate (oder das nixos-appliance-ota-update Muster) hält zwei Slots bereit; ein fehlgeschlagener Boot führt automatisch zum vorherigen Slot zurück.
• Read-only, verity-geschützter Store — der Nix-Store auf einem Squashfs-Image, geschützt durch dm-verity; Manipulationen werden erkannt, nicht toleriert.
• UKI-Boot mit Secure Boot — lanzaboote signiert Unified Kernel Images; TPM-basierte Festplattenverschlüsselung bindet die Disk an die Hardware.
• Tests vor dem Deployment — Integrationstests laufen gegen exakt das Image, das ausgeliefert wird, da das Image aus demselben Expression-Tree gebaut wird, den die CI testet.

Auf dieser Ebene ist das „Updaten eines Servers“ nicht mehr von einem „Deployment neuer Firmware“ zu unterscheiden. Dies ist das Muster für Edge-Devices, Kiosks und Remote-Standorte, an denen niemand per SSH einbauen kann, um ein fehlgeschlagenes Upgrade zu reparieren — aber es ist auch ein legitimes Endziel für Core-Infrastruktur-Nodes.

Wo die Deployments heute stehen

Um ehrlich zu bleiben, hier ist die Position der Deployments hinter den Beispielen dieses Artikels auf der Leiter:

Der Migrationspfad, sortiert nach Wert pro Aufwandseinheit:

1. Einführung des Flake-Quality-Gates (treefmt + checks) — Tage an Arbeit, sofortige Konsistenz.
2. Aufbau des Binary Caches — ermöglicht schnelle Rebuilds im Air-Gap und macht die nächsten Schritte schmerzfrei.
3. Umstellung einer Node-Klasse auf NixOS (beginnen Sie mit der Registry oder einem Worker) — beweisen Sie das Muster an einem Node, dessen Rebuild niemanden beunruhigt.
4. Upgrade der Core-Nodes auf Appliance-style Updates, sobald Impermanence und Rollback Routine sind.

Die Wahl Ihres Levels

Die Leiter ist kein Befehl, die Spitze erreichen zu müssen. Das richtige Level hängt von drei Fragen ab:

• Wie viel kostet Sie Drift? Ein Prototyp, der monatlich neu gebaut wird, kann ewig auf Level 0 bleiben. Ein Mailserver, dessen Konfiguration sich niemand mehr erinnert, zahlt bereits die Preise von Level 4, ohne die Vorteile zu haben.
• Wie viele Maschinen teilen sich eine Form? Ein einziger, einzigartiger Host: NixOS lohnt sich vielleicht nicht. Zwanzig identische Worker: Jede Stufe wirkt sich multiplikativ aus.
• Wie schwer ist die Maschine zu erreichen? Wenn ein fehlgeschlagenes Upgrade eine Autofahrt oder ein Wartungsfenster bedeutet, ist das automatische Rollback von Level 5 kein Luxus.

Beginnen Sie diese Woche mit Level 1 — pinnen Sie Ihre Toolchain in einem devShell, committen Sie die flake.lock und machen Sie „works on my machine“ zu einer historischen Phrase. Alles darüber hinaus ist eine Serie von kleinen, einzeln sinnvollen Wetten, keine Revolution.

Verwandte Artikel

• SOGo + Stalwart + OpenLDAP: Dockerized Groupware Deployment — der Mail-Stack, dessen Images mit Nix gebaut werden
• Stalwart vs Dovecot 2.4 CE: Head-to-Head on Kubernetes — Evaluierung der Workloads, die auf diesen Clustern laufen
• K3s Production Upgrades, Backup & Disaster Recovery — Node-Lifecycle-Management auf Cluster-Ebene
• GitOps Secrets Management in Production — Secrets-Muster, die mit agenix/sops-nix harmonieren
• The Open-Source Infrastructure Stack for Production, 2026 — der umfassendere Stack, dessen Teil diese Deployments sind