{"id":3623,"date":"2024-12-31T16:15:45","date_gmt":"2024-12-31T15:15:45","guid":{"rendered":"https:\/\/informatik.htwk-leipzig.de\/seminar\/?p=3623"},"modified":"2025-01-15T22:26:24","modified_gmt":"2025-01-15T21:26:24","slug":"nix-nixos","status":"publish","type":"post","link":"https:\/\/informatik.htwk-leipzig.de\/seminar\/ankuendigungen\/2024\/nix-nixos\/","title":{"rendered":"Nix & NixOS"},"content":{"rendered":"

Nix & NixOS<\/h1>\n

Lesezeit: Acht Minuten<\/em><\/p>\n

Ein Problem so alt wie die Softwareentwicklung selbst: Nach einem Update funktioniert *nix* mehr.
\nDieses Problem ist Ihnen sicher schon einmal begegnet.
\nSei es ein einfaches Grafiktreiber-Update, welches dazu f\u00fchrt, dass die eigene Maschine nicht mehr grafisch bootet oder ein Update beliebiger Anwender-Software, nach welchem jene nicht mehr wie gewohnt funktioniert.<\/p>\n

Selbst bei gr\u00fcndlichster Testung steht jede Software vor der zentralen Frage: Funktioniert die Software beim Anwender?<\/p>\n

In diesem Blog-Beitrag betrachten wir, wie ein revolution\u00e4rer, deklarativer Ansatz von Nix<\/em><\/strong> und NixOS<\/strong><\/em> diese Frage \u00fcberfl\u00fcssig macht und warum betriebliche Informationssysteme davon profitieren k\u00f6nnen.<\/p>\n

\u00d6ko-System: Nix ist nicht gleich Nix<\/h2>\n

Wer schon einmal mit Nix in Ber\u00fchrung gekommen ist, der denkt an einen Paket-Manager. Das ist auch vollkommen richtig, denn der Paket-Manager\u00a0Nix<\/strong><\/em>\u00a0ist der zentrale Bestandteil des Nix-\u00d6ko-Systems. Zus\u00e4tzlich gibt es aber auch\u00a0Nix<\/strong><\/em>: eine dom\u00e4nenspezifische Sprache zur Beschreibung von Build-Instruktionen. Zur Differenzierung bezeichnen wir diese im Nachfolgenden auch mit dem etwas un\u00fcblicheren Namen der\u00a0Nix Expression Language.<\/strong><\/em>\u00a0Aufbauend auf dem Paket-Manager Nix gibt es noch eine Linux-Distribution\u00a0NixOS<\/strong><\/em>, welche die funktionale Idee des Paket-Managers auf System-Ebene \u00fcbernimmt. Erw\u00e4hnenswert, aber in diesem Beitrag nicht weiter betrachtet ist\u00a0Nixpkgs<\/strong><\/em>: das Paket-Repository f\u00fcr Nix-Pakete.<\/p>\n

\n
\n

Nix ist deklarativ – alles ist deklarativ<\/h2>\n<\/div>\n
\n
\n

Nix Expression Language<\/h3>\n<\/div>\n

Die Nix Expression Language ist eine touring-vollst\u00e4ndige dom\u00e4nenspezifische Sprache zur Beschreibung der Erstellung von Paketen. Angelehnt an die funktionale Programmiersprache Haskell ist diese ebenfalls deklarativ und rein funktional – aber dynamisch typisiert.<\/p>\n

Betrachten wir das Universum als Menge von Paketen\u00a0P\u00a0(z.B.\u00a0gcc<\/code>), Konfigurationen\u00a0C\u00a0(z.B. Flaggen f\u00fcr\u00a0gcc<\/code>) und Daten\u00a0D\u00a0(z.B. Quellcode-Dateien). Ein Nix-Paket ist dann Funktionswert einer Transformation\u00a0t:2P\u00d7C\u2192P. Jedes Paket h\u00e4ngt also von bestimmten Eingaben (Dependencies) ab und produziert eine Ausgabe (Derivation – Nix-Name f\u00fcr ein Paket).<\/p>\n

Aufgrund der rein funktionalen Natur von Nix ist nicht verwunderlich, dass allgemeiner alle Nix-Ausdr\u00fccke B\u00e4ume sind. Bl\u00e4tter sind Konfigurationen\u00a0C\u00a0oder Daten\u00a0D\u00a0und Knoten sind Transformationen\u00a0t:2P\u00d7C0,1\u00d72D\u2192P\u2223C\u2223D. Da identische Teilb\u00e4ume aus Performance-Gr\u00fcnden allerdings untereinander geteilt werden (engl.\u00a0sharing<\/em>), sind die Ausdr\u00fccke in Wirklichkeit kreisfreie, gerichtete Graphen (engl.\u00a0directed acyclic graph<\/em>\u00a0– kurz\u00a0DAG<\/em>).<\/p>\n

Aufgeschrieben werden Nix-Ausdr\u00fccke in Dateien mit Endung\u00a0.nix<\/code>.<\/p>\n

\n

Nix<\/h3>\n<\/div>\n

Gebaut werden die Pakete in einer dedizierten System-Umgebung, dem sogenannten\u00a0Nix-Store<\/strong><\/em>. Unter Linux entspricht dieser dem Pfad\u00a0\/nix\/store<\/code>\u00a0im Root-Dateisystem und unter MacOS sogar einer eigenen System-Partition. Im Folgenden betrachten wir ausschlie\u00dflich die Verwendung von Nix unter Linux. Der Speicher-Ort eines Pakets wird durch die Addition des Hashes eines Pakets zum Pfad des Nix-Stores bestimmt. Ein Paket\u00a0p\u00a0wird mit einer Hash-Funktion\u00a0h:P\u2192N\u00a0also unter\u00a0\/nix\/store\/h(p)<\/code>\u00a0gespeichert.<\/p>\n

Wie die Expression Language ist auch der Nix-Store rein funktional, was bedeutet, dass alle Pakete unver\u00e4nderlich (engl.\u00a0immutable<\/em>) sind. Zusammen mit der Hash-Funktion gilt folgende Eigenschaft:<\/p>\n

\u2200p1,p2\u2208P:(h(p1)\u2260h\u2032(p1\u2032)\u2227p2=t(P,c)\u2227p1\u2208P)\u2192Rebuild(p2,h\u2032)<\/p>\n

\u00c4ndert sich eine Dependency eines Paketes\u00a0p, dann muss dieses neu gebaut werden. Das neu gebaute Paket\u00a0p\u2032\u00a0erh\u00e4lt dann einen neuen Hash und somit eine neue Speicherstelle. Das alte Paket\u00a0p\u00a0an der alten Stelle bleibt dabei dennoch erhalten, sodass der Nix-Store referentielle Transparenz aufweist. Diese Eigenschaft garantiert zusammen mit den ausschlie\u00dflich puren Funktionen der Nix Expression Language, dass Pakete tats\u00e4chlich Funktionswerte mathematischer Funktionen sind, also ausschlie\u00dflich von ihren Eingaben abh\u00e4ngen und somit vollst\u00e4ndig reproduzierbar sind.<\/p>\n

\n
\n

NixOS<\/h3>\n<\/div>\n

Nix implementiert pures und rein funktionales Paket-Management. Diese Art von Management kann allerdings auch auf System-Ebene gehoben werden. Genau das macht\u00a0NixOS<\/strong><\/em>, eine Linux-Distribution auf Basis des Paket-Managers Nix. So wie bei Nix jedes Paket durch eine Build-Instruktion in einer\u00a0.nix<\/code>-Datei beschrieben werden kann, kann auch ein ganzes Betriebssystem in einer einzigen\u00a0.nix<\/code>-Datei beschrieben werden. Betrachten wir beispielhaft folgendes Betriebssystem, auf welchem sowohl ein OpenSSH- als auch ein Apache-Server laufen:<\/p>\n

\"\"<\/p>\n

Abbildung: Beispielhafte und vereinfachte System-Konfiguration in NixOS<\/em><\/p>\n<\/div>\n

Wie auch bei Nix wird hier deutlich, dass jedes System ein DAG aus Paketen, Konfigurationen und Daten ist. Zus\u00e4tzlich kommen hier noch Skripte hinzu, um ausf\u00fchrbare Dienste zu erm\u00f6glichen.<\/p>\n<\/div>\n

\n

Vorteile von NixOS in betrieblichen Informationssystemen<\/h2>\n<\/div>\n
\n

Durch diese deklarative und rein funktionale Natur von Nix und NixOS ergeben sich einige Vorteile, die insbesondere in betrieblichen Informationssystemen von Nutzen sind. Im Folgenden betrachten wir einige davon.<\/p>\n

\n

Sichere Updates durch Rollbacks<\/h3>\n<\/div>\n

Systemupdates werden durch \u00c4nderungen der Konfigurationsdatei durchgef\u00fchrt. Um die \u00c4nderungen zu \u00fcbernehmen, muss das System mit\u00a0nixos-rebuild<\/code>\u00a0neu gebaut werden. Da die Konfiguration der entsprechenden Paketversionen durch eine Konfigurationsdatei beschrieben ist, kann jede „Generation“ des Systems in einer Historie festgehalten werden. Sollten Aktualisierungen zu Problemen oder Instabilit\u00e4t f\u00fchren, kann mithilfe von\u00a0nixos-rebuild --rollback switch<\/code>\u00a0auf eine \u00e4ltere Generation zur\u00fcckgewechselt und die vorherige Konfiguration wiederhergestellt werden. Au\u00dferdem besteht die M\u00f6glichkeit neue Konfigurationen mit\u00a0nixos-rebuild build-vm<\/code>\u00a0vorher in einer VM auszutesten. Damit kann Downtime in produktiven Umgebungen durch fehlerhafte Updates minimiert werden.<\/p>\n

Um Rollbacks zu gew\u00e4hrleisten, speichert NixOS standardm\u00e4\u00dfig alle vorherigen Systemzust\u00e4nde. Dies kann mitunter zu einem hohen Speicherverbrauch f\u00fchren, was insbesondere in ressourcenbegrenzten Umgebungen wie der Cloud problematisch sein kann.<\/p>\n

\n

Skalierbarkeit und Automatisierung<\/h3>\n<\/div>\n
\n

\u00c4hnlich wie klassische Docker-basierte Systeme wie beispielsweise GitHub Actions, bietet das auf Nix basierende Tool\u00a0Hydra<\/em><\/a>\u00a0eine Umgebung zum Ausf\u00fchren von automatisierten Pipelines. Dabei wird vollst\u00e4ndig auf Docker verzichtet, sodass stattdessen ausf\u00fchrbare System-Images direkt mit Nix-Konfigurationen deklariert werden.<\/p>\n

Alternativ ist es auch m\u00f6glich, NixOS in einer Docker-Umgebung zu verwenden, um die Vorteile beider Systeme zu kombinieren. Damit k\u00f6nnen deklarative Umgebungen, die sich garantiert immer gleich verhalten in weit verbreiteten Systemen eingesetzt werden, in denen NixOS nicht direkt unterst\u00fctzt wird. Ein Beispiel daf\u00fcr sind Cloud-Applikationen, die Docker in Verbindung mit Kubernetes zum Skalieren verwenden.<\/p>\n

F\u00fcr die Verwendung unter Amazons EC2 k\u00f6nnen virtuelle System-Images direkt aus Nix-Konfigurationen heraus gebaut werden. Der Befehl\u00a0nix-build<\/code>\u00a0nimmt daf\u00fcr als Argument einerseits die Nix-Konfigurationsdatei und andererseits das bereitgestellte EC2 Base-Image f\u00fcr die passende Architektur.<\/p>\n

\n

Sicherheit<\/h3>\n<\/div>\n

Betriebliche Informationssysteme k\u00f6nnen durch den Einsatz deklarativer Konfigurationen zuverl\u00e4ssiger h\u00f6heren Sicherheitsstandards entsprechen. In einer deklarativen Umgebung wird der gew\u00fcnschte Endzustand explizit beschrieben und das System automatisch so konfiguriert, dass dieser erreicht wird. Dadurch werden unbeabsichtigte Nebenwirkungen oder nicht dokumentierte Zust\u00e4nde, wie sie bei klassischen imperativen Ans\u00e4tzen (direkte Befehle, manuelle Konfiguration) auftreten k\u00f6nnen, vermieden.<\/p>\n

Au\u00dferdem k\u00f6nnen Sicherheitspr\u00fcfungen in einer einzelnen Umgebung durchgef\u00fchrt werden und auf alle anderen Umgebungen \u00fcbertragen werden, auf denen diese Konfiguration zum Einsatz kommt. Durch die zustandslose Konfiguration kann somit garantiert werden, dass alle Umgebungen den gleichen Sicherheitsstandards entsprechen.<\/p>\n

Weiterhin ist es m\u00f6glich, durch die Versionierung von Systemzust\u00e4nden direkt nachzuvollziehen, wer was wann wie ge\u00e4ndert hat und welche Auswirkungen diese \u00c4nderungen hatten. So k\u00f6nnen Breaking-Changes, oder \u00c4nderungen an sicherheitskritischen Komponenten direkt isoliert und nachvollzogen werden.<\/p>\n

Alle \u00c4nderungen, die am System vorgenommen werden, sind zudem atomar. Jede \u00c4nderung wird also vollst\u00e4ndig \u00fcbernommen oder gar nicht. In klassischen Systemen kann es dazu kommen, dass bei fehlgeschlagenen Installationen das System in einem halbfertigen, potenziell unsicheren Zustand zur\u00fcckgelassen wird. Diese Zust\u00e4nde werden hier vermieden, womit die damit verbundenen Sicherheitsl\u00fccken nicht auftreten k\u00f6nnen.<\/p>\n

\n
\n

Anwendungsbeispiel Pinterest<\/h2>\n<\/div>\n

Ein prominentes Beispiel, bei welchem NixOS erfolgreich in einem betrieblichen System zum Einsatz kommt, stellte das Pinterest Engineering Team in einem\u00a0Blog-Beitrag<\/a>\u00a0vor. Konkret ging es um die Pipelines zum automatisierten Bauen und Testen der Pinterest iOS-App. Die Ausgangssituation, die viele Probleme verursachte, sah wie folgt aus:<\/p>\n