„Mit NixOS hat man keine Angst mehr, sein System neu zu deployen.“

Vor ein paar Tagen ist NixOS 17.09 „Hummingbird“ erschienen. An Bord sind nicht nur Updates und Neuerungen wie beispielsweise das Handling von UIDs/GIDs, sondern auch zahlreiche neue Services.

Die dafür verantwortlichen Release-Manager Franz und Robin sind Admins in unserem Münchner Mayflower-Büro – und wer hätte es geahnt: Beide besitzen eine ausgeprägte Leidenschaft für das Betriebssystem, das vor allem im Bereich des Configuration Managements einiges anders macht als andere Linux-Distributionen und Puppet, Ansible und Co damit vergessen macht.

Zur Feier des Releases lassen wir die beiden zu Wort kommen und über die Vorzüge des im Mainstream noch recht unbekannten Systems sprechen.

NixOS 17.09 Hummingbird

Franz, Robin – ihr seid beide aktiv in der NixOS-Community; welche Rollen nehmt ihr dort ein?

Franz: Ich bin im NixOS-Security-Team und Release Manager der Versionen 17.09 und 18.03.

Robin: Ich bin der Release-Manager von Version 17.03. Allerdings haben wir zwei Release Manager für jede Version; das bedeutet, dass der, der das schon zwei Versionen gemacht hat, herausrotiert und ein neuer hineinwechselt, damit man einen besseren Wissensaustausch hat auch immer einen in dem Team hat, der schon mal released hat. Nachdem der einzige andere Release Manager das approved hat, sind wir beide also Release Manager für NixOS 17.09.

Ihr würdet wohl nicht mehr umsteigen auf ein anderes System?

Franz: Mit jeweils ungefähr 1000 Commits in dem Haupt-Repo sind wir ziemlich commited, glaube ich … (lacht)

Wie groß ist der Vorteil der eingebauten Tools in der Praxis, wenn man nicht von externen Tools abhängig ist?

Robin: Bei anderen Distributionen ist es ein großer Aufwand …

Wir haben viele Jahre lang Puppet genutzt; dort hat man als Puppet-Modul-Autor das Problem, dass man sein Modul für jedes unterstützte System oder Linux-Distribution anpassen muss. In jeder Distribution sind die Pfade und die Pakete anders aufgebaut; hinzu kommen verschiedene Versionen der einzelnen Distributionen, in denen sich das Vorgehen zum Teil unterscheiden kann. Man muss also immer sehr viele Eventualitäten abdecken.

Hat man 30 oder 40 Module als Abhängigkeit, bedeutet es einen enormen Zeitaufwand, sie up to date zu halten.

Dann geht es damit weiter, dass alle Module von verschiedenen Entwicklern geschrieben werden und diese Module dann nicht unbedingt miteinander kompatibel sind. Um zum Beispiel ein NGINX mit einem PHP zu verdrahten, muss man, je nachdem wie komfortabel es am Ende in der Benutzung sein soll, relativ viel Glue-Code schreiben. Wir hatten beispielsweise ca. 30 oder 40 Module, die wir als Abhängigkeiten in unserem Puppet-Code hatten … die up to date zu halten bedeutet schon einen enormen Zeitaufwand.

Wir haben mit Puppet aufgehört, als es das Update von Puppet 3 auf Puppet 4 anstand, da dort ziemlich viele Backward Incompatible Changes anstanden und wir dadurch sehr viel Code hätten updaten müssen. Das war der Punkt, an dem wir uns dafür entschieden haben, lieber von Puppet wegzugehen und etwas Neues auszuprobieren.

Franz: Man hätte sowas wie Chef, Ansible oder Salt nehmen können. Aber der Punkt war, dass diese Konfigurationsmanagement-Systeme nach dem selben Prinzip wie Puppet funktionieren; sie haben also die selben systemischen Probleme.

Ein typisches Configuration-Management-Tool fasst das bestehende System an und transformiert es in einen neuen, von uns gewünschten State. Das ist aber ein Problem, denn man kümmert sich ja nur um den wirklich definierten State und nicht um die Dinge, die außen herum passieren. Im schlechtesten Fall können noch Nutzer mit Default-Credentials existieren, um die man sich aber nicht kümmert, weil man von ihnen ja nichts weiß.

Bei NixOS ist das anders, da man das System jedes Mal von Grund auf neu baut. Man weiß also genau, was im System passiert, weil ja nichts anderes sein kann, wie beispielsweise ein bestehender User oder ein Paket, das bereits installiert war, oder ein Service, der schon gelaufen ist.

Was bedeutet das für die Performance, wenn du sagst, dass das System jedes Mal neu gebaut wird?

Franz: Das ist kein Problem, da natürlich die selben Sachen nicht immer neu gebaut werden. Das bedeutet lediglich, dass die Sicht, die das System auf den aktuellen Stand hat, manuell gebaut wird – es sind aber nur Symlinks, die neu generiert werden. Natürlich muss man auch teilweise Pakete neu bauen, aber das ist ein anderes Problem. Allein die Konfiguration neu bauen ist jedoch überhaupt kein Aufwand – das ist zum Teil schneller als Puppet.

Bevor wir auf NixOS umgestiegen sind, hatten wir beispielsweise Puppet Catalog Compiles auf unserem Puppet-Master, die über zwei Minuten gedauert haben. Bei NixOS dauert es zwar auch ein wenig, die Config zu generieren, aber am Ende ist es vom zeitlichen Aufwand her vergleichbar oder sogar weniger Zeit, die in Anspruch genommen wird.

Robin: Ich würde sogar sagen, dass es deutlich kürzer dauert – es ist abhängig davon, was noch nachgeladen wird. Was Downloads angeht, ist der Aufwand bei beiden relativ ähnlich, aber bei Puppet kommt hinzu, dass das System Packages genau so installiert, aber darum herum viel mehr Arbeit verrichten muss, um den State zu bekommen, den es versucht zu erlangen.

Wie groß sind die Hürden beim Umstieg von einem klassischen System auf NixOS?

Franz: Die sind leider vergleichbar hoch … Man gewinnt zwar sehr viel bei einem Umstieg, aber das Problem ist, dass dieser pur-funktionale Paketmanager eine eigene Sprache verwendet, die ebenfalls Nix heißt: die Nix Expression Language. Dabei handelt es sich um eine funktionale Sprache und wahrscheinlich sind viele Programmierer und vor allem Sysadmins dieses Programmierparadigma nicht gewohnt. Das ist eine kleine Hürde.

Die Doku wird zwar ebenfalls langsam besser, aber nicht alle kleinen Tricks, die man so anwenden muss, sind in der Doku zu finden. Da liegt noch ein wenig Arbeit vor uns.

Hat man die Hürden jedoch gemeistert – und man schafft es, in ca. ein bis zwei Wochen wirklich flüssig in Nix zu werden und das ganze Ökosystem zu verstehen – gewinnt man schon sehr viel damit, auf NixOS umzusteigen.

Wenn man mit Nix anfängt, sollte man sich von der gefühlten Komplexität, der man gegenübersteht, nicht erschlagen fühlen.

Wenn man mit Nix anfängt, sollte man sich von der gefühlten Komplexität, der man gegenübersteht, nicht erschlagen fühlen. Systembedingt ist sehr viel anders – der Linux-Filesystem-Hierarchy-Standard wird beispielsweise nicht mehr eingehalten. Das ist aber zwingend notwendig für die Vorteile, die einem Nix bietet. Deswegen sollte man am Ball bleiben, bis man diese Hürde überschritten hat und die Vorteile wirklich zu schätzen weiß

Wie fühlt sich NixOS im Vergleich zu „klassischen“ Systemen in Produktion an?

Robin: Ganz einfach: Man hat keine Angst mehr, sein System neu zu deployen.

Es ist tatsächlich gefühlt so, dass wenn man irgendwas bei Puppet geändert und dann Puppet Deploy ausgeführt hat, brach erstmal irgendwas. Man musste das fixen und dann konnte man erst tatsächlich sinnvoll deployen.

Bei NixOS wird alles evaluiert. Es gibt zwar kein statisches Typsystem, aber Typen werden an relativ vielen Stellen im Config Management gecheckt; man sieht sehr vielen der wirklichen Änderungen also schon zur Evaluierungszeit der Config. Das Deployment läuft dann eigentlich immer – wenn man nicht gerade selber irgendwo herumgepfuscht hat – reibungslos.

Man hat mit NixOS keine Angst mehr, sein System neu zu deployen.

Franz: Der größte Vorteil dabei ist, dass selbst wenn man mal irgendwas falsch gemacht hat – man kann auch eine Config falsch schreiben oder eine falsche Information hinterlegen – kann man ohne Probleme einen Rollback machen, was bei Puppet und anderen Systemen unmöglich ist.

Bei anderen Systemen muss man immer nach vorne gehen und einen Fix hinterher schieben. Bei NixOS kann man ohne Probleme einen Rollback auf eine alte Version machen, bei der alles neu gebaut wird, und das sogar atomic: Am Ende wird also nur ein Symlink umgebogen, ein Activation Script ausgeführt und das System ist auf die alte Version zurückgerollt. Man muss sich um nichts kümmern, es läuft einfach von dort aus weiter.

… das heißt also, NixOS ist ein Traum für Admins?

Franz: Ja, genau. Es geht sogar so weit, dass dass man mit dem Boot Manager – GRUB oder systemd-boot – bei einem Neustart einfach auswählen kann, in welche Version des Systems man booten möchten, da alle alten Versionen auf dem System sind.

Wie sieht es im Bereich Security aus?

Franz: Wir haben ein dediziertes Security-Team, das sich um Security Issues in den Programmen kümmert, die wir packagen; das funktioniert relativ gut. Was uns fehlt, ist noch ein wenig Automatisierung, aber das kommt langsam.

Was das System selbst angeht: Wir benutzen seit kurzem diese Hardening Compiler Flags, die Mayflower für NixOS Open Source gemacht hat. Wir machen nach und nach noch mehr Sachen wie etwa Service Hardening, dass wir zum Beispiel mit systemd die Services so weit wie möglich einschränken. Für AppArmor und SELinux haben wir leider aktuell keinen guten Support, aber auch das wird bald kommen.

In der Most-Reviewed-Kategorie bei GitHub ist NixOS relativ weit oben vertreten.

Im Prinzip ist es ähnlich wie bei anderen Linux-Distributiuonen, wobei die Community natürlich kleiner ist, das muss man schon sagen. Schaut man ins Octoverse mit den aktivsten Open-Source-Projekten, das GitHub jährlich veröffentlicht, sind wir in der Most-Reviewed-Kategorie relativ weit oben.

Du hast gerade schon die Community angesprochen – wie verbreitet ist NixOS?

Franz: Es ist nicht so verbreitet im Mainstream. Aber gerade bei Startups, die schon auf funktionale Programmiersprachen wie Haskell setzen, aber auch bei einigen Unternehmen, die Consulting für funktionale Programmierung anbieten, ist NixOS extrem populär.

Robin: Es sind auch schon einige große Firmen, die NixOS einsetzen. Mozilla benutzen zum Beispiel nur den Paketmanager für ihre Builds. Die Teams, dass sich um die Builds der Software kümmern, setzen seit einiger Zeit auf NixOS und machen da viel damit.

Bei Tumblr wird intern für Datenbanktesting und Datenbank-Cluster-Testing das NixOS-Testframework benutzt. Und bei Team Viewer laufen deren Reverse Proxys auf NixOS.

Franz: … und es gibt Hoster, die komplett auf NixOS setzen, wie beispielsweise Flying Circus.

Robin: Holiday Check benutzt intern Nix, um Docker-Container zu bauen …

Franz: … und Development Environments für Entwickler zu bieten – inklusive aller NodeJS-Abhängigkeiten und was sonst noch so dazu gehört.

Was gibt es sonst noch spannendes zu NixOS zu sagen?

Robin: Vielleicht nicht zu NixOS direkt, aber es gibt noch ein Tool, das NixOps heißt … das spielt in das ganze Configuration Management rein. Das ist quasi das Tool, um auf ne ganze Menge an Servern NixOS-Konfigurationen zu deployen; quasi, um eine zentrale Config auf einem Server zu haben und von dort zu deployen.

NixOps ist ein Tool, mit dem man eine Config von einem zentralen Server auf eine ganze Menge an Servern deployen kann.

Franz: Man kann damit beispielsweise EC2-Instanzen, Google Cloud Engine oder VMs managen oder eben lokale VMs oder Virtual Boxen als Vagrant-Ersatz benutzen, oder Container deployen …

Robin: Und noch so ein bisschen Ausblick: Es ist jetzt bereits möglich, Docker-Container aus Nix-Paketen zu bauen. Das ist ein großer Fortschritt in diesem ganzen Docker-Bau-Prozess, da man damit Reproduzierbarkeit von den Containern reinbekommt und auch dafür sorgt, dass die Container neu gebaut werden, wenn es zum Beispiel Sicherheitsupdates gibt – das ist aktuell bei Containern oft nicht der Fall.

Das wird aktuell auch von den Entwicklern von HolidayCheck vorangetrieben. Wir haben auch großes Interesse daran, da weiter daran zu arbeiten, dass das ein bisschen benutzerfreundlicher wird und man aus den NixOS-Services auch gleich Docker-Container bauen kann. Wobei das dann noch ein kleiner Weg ist.

Wie weit seid ihr damit?

Robin: Also, das Bauen von Docker-Containern wird bereits unterstützt und funktioniert schon ganz gut. Was für die Services fehlt ist ein Abstraktionslayer, wie die Services definiert werden. Und das wird ein größerer Prozess – aber da gibt es bereits einige Ideen, wie man das lösen könnte.

Franz: Konkret geht es darum, dass man ja nicht ein komplettes NixOS-System inklusive systemd und aller Services in einem Container haben möchte, am Ende will ich ja nur einen Service im Container haben. Das wird aktuell von dem Modul-System und dem Configuration-Management-System nicht unterstützt. Ich kann nur ein Paket reinlegen, und dann muss ich die Binary mit bestimmten Argumenten aufrufen.

Was ich haben möchte: Wir haben ja das Modulsystem, bei dem wir die Konfiguration deklarativ bestimmen können. Genau dieses Modulsystem möchte ich auf Docker-Container anwenden, dass ich z. B. sage: Ich werfe diesen NGINX in einen Docker-Container und benutze die normale NixOS-NGINX-Config, die total abstrahiert ist, und dann läuft genau das in dem Container. Dafür brauchen wir einen Service-Abstraction-Layer. Wenn wir diesen Service-Abstraction-Layer haben, können wir zum Beispiel das Init-System austauschen und statt systemd etwas anderes benutzen. Tatsächlich ist dieser Abstraction Layer ein Punkt, in den wir noch ein wenig Zeit investieren wollen.

Was bringt das für Admins?

Robin: Das wir fertige Definitionen für Container haben, die komplett reproduzierbar sind, und wir tatsächlich eine Art Trigger haben, sie neu zu bauen, wenn sich irgendwo in der Dependency Chain ein Paket ändert.

Wir wissen ganz genau, was sich geändert hat – wann wir also neu bauen und deployen müssen.

Franz: Aktuell ist es meistens so, dass Docker-Images einfach neu gebaut werden. Eine typische Sache, die man bei Docker-Images of sieht, ist apt-get update, apt-get upgrade. Und das sind Kommandos, die nicht reproduzierbar sind, da sie auf dem Zeitpunkt der Ausführung basieren – genau den Stand der Pakete bekommst du dann. Deswegen ist der Default, dass täglich Docker-Images neu gebaut und deployed werden, auch wenn es nicht notwendig wäre – sie wissen einfach nicht, wann sie neu bauen müssen. Wir wissen das jedoch ganz genau, wann sich etwas geändert hat, wann wir also neu bauen und deployen müssen. Wir müssen nicht einfach jeden Tag das selbe deployen, wenn sich nichts daran geändert hat.

Wie tief müsst ihr dafür in Docker eintauchen?

Franz: Das ist schon fertig. Es muss nur am Nix-internen Code geschraubt werden. Ein paar Abstraktionen geschaffen, ein paar Sachen rausgezogen, ein paar Services angefasst … es ist ein wenig Arbeit, aber es ist machbar.

Aufmacher:
Levi Jones