Nix, ein besserer Docker-Image-Builder als der Image-Builder von Docker

Nix ist besser als der Image-Builder von Docker

• Nix hat drei Aspekte: Paketmanager, Sprache und Betriebssystem.
• Das Erstellen von Docker-Images mit Nix hat Vorteile gegenüber dem Image-Builder von Docker selbst.
• Nix macht es möglich, alle im Build-Prozess benötigten Abhängigkeiten im Voraus zu kennen, und erlaubt Builds auch ohne Internetverbindung.

Vorteile von Nix

• Mit Nix lassen sich Docker-Images effizienter erstellen.
• Nix teilt Abhängigkeiten in möglichst wenige Docker-Layer auf, sodass bei Updates nur minimale Änderungen übernommen werden.
• Wenn mehrere Services dasselbe Repository verwenden, können sie Docker-Layer gemeinsam nutzen, was effizient ist.

Beispiel eines Douglas-Adams-Zitat-Service

• Es wird erklärt, wie ein Go-Programm mit Nix paketiert und in ein Docker-Image umgewandelt wird.
• Mit der Funktion dockerTools.buildLayeredImage kann ein Layered Image erstellt werden.
• Das Ergebnis ist ein gewöhnliches Container-Image, das überall bereitgestellt werden kann.

Meinung von GN⁺

• Der Einsatz von Nix kann die Verwaltung von Abhängigkeiten und die Reproduzierbarkeit von Builds im Softwareentwicklungsprozess erheblich verbessern.
• Im Vergleich zu Docker kann Nix durch die deterministischen Eigenschaften seiner Builds langfristig Zeit und Ressourcen sparen.
• Allerdings können die neuen Konzepte und die Bedienung von Nix für Einsteiger etwas schwierig sein, und auch die Integration in bestehende CI/CD-Pipelines kann herausfordernd sein.
• Bei der Einführung dieser Technik sind Schulung im Team und eine Eingewöhnungszeit nötig; außerdem sollte die Kompatibilität mit der bestehenden Infrastruktur berücksichtigt werden.
• Ein anderes Tool mit ähnlichen Funktionen wie Nix ist Guix, das ebenfalls deterministische Paketverwaltung und Builds bietet.

[GN⁺]

Hacker-News-Kommentare

• Ich habe mehrfach versucht, Sympathie für Nix zu entwickeln, aber ich denke, es ist an der Zeit, aufzugeben.

  • Ich habe zwei Systeme, die Nix verwenden, aber ich habe Angst, sie anzufassen.
  • Theoretisch ist Nix idempotent und deterministisch, aber wenn man nicht jeden Teil der Abhängigkeiten genau versteht, kann man auf seltsame Ergebnisse und wenig hilfreiche Fehler stoßen.
  • Die Dokumentation ist sehr schlecht, und die Tutorials helfen nur teilweise.
  • Die Stärke von Docker liegt im Chaos selbst: Mit nur einem grundlegenden Verständnis von Shell und Paketmanager kann man fast alles leicht bauen.

• Nix und NixOS befinden sich in einem ähnlichen Zustand wie git vor GitHub.

  • Die Grundidee basiert auf ernsterer Informatik als das heutige SVN oder Docker.
  • Mit dem Release von flox könnte sich die Lage geändert haben; flox ist einfach zu benutzen.
  • Ohne flakes und nix-command ergibt Nix keinen Sinn, und diese sind experimentell und standardmäßig deaktiviert.
  • Nix/NixOS oder etwas Ähnliches wird Docker in denselben Zustand versetzen, aber nicht vor dem GitHub-Moment.

• Ich habe 2–3 Tage damit verbracht, auf Darwin Docker-Images zu bauen, und dieser Artikel fühlt sich an, als würde er mich verspotten.

  • Nix ist das beste Tool, um zu erreichen, was man will, aber manchmal gibt es dunkle Ecken, die einem die Seele aussaugen.

• Im Blogpost fehlt eine Erklärung, warum gemeinsam genutzte Docker-Layer nützlich sind.

  • Wegen des Cachings sind sie nützlich. Je mehr Images sich denselben Layer teilen, desto besser funktioniert das Caching.
  • Nix speichert Abhängigkeiten ohnehin bereits per Hash, daher sind Layer immer mit derselben Version und Konfiguration identisch.

• Die Erfahrung, Docker-Images für Java-Anwendungen mit Nix zu bauen, war nicht besonders angenehm.

  • Nachdem gradle2nix eingestellt wurde, gibt es keine klare alternative Methode, um Docker-Images für Gradle-basierte Java-Anwendungen zu bauen.

• Es ist nützlich, wenn man Nix bereits eingeführt hat, und ich hoffe, dass deklarativere Paketmanagement-Lösungen wie Nix oder Guix populärer werden.

  • Wenn man Docker nutzt und Nix schrittweise einführen möchte, gibt es einen alternativen Ansatz, bei dem man das Dockerfile beibehält und die Nix-Konfiguration baut.

• Als Platform Engineer würde ich Nix gern mögen, aber es ist nicht für alle einfach.

  • Ich bevorzuge es zum Beispiel, Pakete mit devbox add python@3.11 hinzuzufügen.

• Nix ist mit Upstream für die meisten Bibliotheken so inkompatibel, dass erheblicher Paketierungsaufwand nötig ist.

  • Bei komplexen C- oder C++-Bibliotheken macht es einen erheblichen Teil der Arbeit aus, alles für Nix zu wrappen.

• Kürzlich habe ich versucht, ein CI-Basis-Image mit Nix zu bauen, aber das Image war zu groß, und wegen Linking-Problemen funktionierten einige Jobs nicht richtig.

  • Um Multi-Arch-Images zu bauen, versucht man tatsächlich, sie auf der anderen Architektur auszuführen, was nur Hardware-Virtualisierung mit qemu unterstützt.

• Ich nutze Dagger, und als zweiter Versuch der Docker-Gründer löst es die meisten Probleme.

  • Man kann Pipelines in der Sprache schreiben, die man bereits verwendet, und dabei fortgeschrittene BuildKit-Funktionen wie Layer-Graphen und erweitertes Caching nutzen.