# NixOS Flakes Masterclass: Reproduzierbarkeit perfektioniert

TL;DR / Management Summary Während die klassische NixOS-Konfiguration (Artikel 201) bereits revolutionär war, heben Flakes die Sicherheit und Reproduzierbarkeit auf ein neues Level. Flakes führen ein Lock-File (flake.lock) ein, das exakt definiert, welche Versionen aller Abhängigkeiten genutzt werden. Dies eliminiert das “Es funktioniert auf meinem Rechner” Problem endgültig. Wer NixOS heute einsetzt, nutzt Flakes.

# 1. Einführung & Konzepte

Weg von den Channels.

Früher nutzte NixOS “Channels”, die global auf dem System definiert waren. Flakes machen die Konfiguration autark. Jedes Projekt bringt seine eigene Paket-Quelle mit.

# Der Flake-Workflow (Mermaid)

graph TD
    A[flake.nix: The Blueprint] --> B[flake.lock: Exact Versions]
    B --> C[Inputs: nixpkgs, other flakes]
    A --> D[Outputs: NixOS Config, Packages]
    D --> E[nixos-rebuild switch --flake]
    subgraph "The Result"
        E --> F[Immutable System Generation]
    end

# 2. Aktivierung & Erstes Setup

Flakes freischalten.

Da Flakes noch als experimentelles Feature gelten, müssen sie in der configuration.nix aktiviert werden:

nix.settings.experimental-features = [ "nix-command" "flakes" ];

# 3. Die Anatomie der flake.nix

Struktur und Logik.

Datei: /etc/nixos/flake.nix

{
  description = "Enterprise NixOS Configuration";

  inputs = {
    # Wir pinnen die NixOS-Version
    nixpkgs.url = "github:nixos/nixpkgs/nixos-23.11";
  };

  outputs = { self, nixpkgs, ... }: {
    nixosConfigurations.server01 = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        ./configuration.nix # Die klassische Config einbinden
      ];
    };
  };
}

# Anwenden der Konfiguration

sudo nixos-rebuild switch --flake .#server01

# 4. Day-2 Operations: Updates & Modul-Management

Kontrolle über die Zeit.

# Den Stand aktualisieren

Um auf neuere Paket-Stände (innerhalb des Branches) zu wechseln:

nix flake update

Dies aktualisiert das flake.lock File. Checken Sie dieses File unbedingt in Git ein!

# Modularisierung

Trennen Sie Hardware-spezifische Teile von der Applikations-Logik:

modules = [
  ./hardware-configuration.nix
  ./modules/nginx.nix
  ./modules/security.nix
];

# 5. Troubleshooting & “War Stories”

Wenn die Reinheit zu strikt ist.

# Story 1: “Der Zugriff auf lokale Dateien”

Symptom: Ein Skript will eine Datei lesen, die im gleichen Ordner wie die flake.nix liegt, aber Nix meldet “File not found”. Ursache: Flakes kopieren nur Dateien in den Build-Kontext, die in Git registriert sind (staged oder committed). Lösung: git add <file> ausführen. Nix nutzt Git als Filter für den “reinen” Build-Kontext.

# Story 2: “Inkompatible Inputs”

Symptom: Ein System-Update schlägt fehl, weil zwei verschiedene Flake-Inputs unterschiedliche Versionen der gleichen Library verlangen. Ursache: “Input Overload”. Lösung: Nutzen Sie follows, um Sub-Flakes anzuweisen, die gleiche Paketquelle wie das Hauptprojekt zu nutzen: inputs.home-manager.inputs.nixpkgs.follows = "nixpkgs".

# 6. Fazit & Empfehlung

• Zukunftssicherheit: Flakes sind der neue Standard. Beginnen Sie kein neues NixOS Projekt mehr ohne Flakes.
• Wartbarkeit: Die flake.lock Datei ist Ihre Lebensversicherung bei Audits. Sie beweist exakt, welcher Code auf dem Server läuft.
• Wahl: Nutzen Sie Home Manager als Flake-Input, um auch die User-Konfigurationen (Dotfiles) deklarativ zu verwalten.

# Anhang: Cheatsheet