In dit artikel legt de auteur uit waarom NixOS een gevoel van zekerheid geeft bij het beheren van servers. Aan de hand van de installatie van FreshRSS wordt aangetoond dat NixOS het proces versimpelt tot enkele regels code, wat herstel bij een crash extreem snel maakt. De auteur contrasteert dit met traditionele installatiemethoden en container-images, die vaak fragieler zijn of complexer in onderhoud. Uiteindelijk concludeert de auteur dat NixOS superieur is aan tools als Ansible of k3s voor persoonlijke projecten, omdat het fungeert als een vorm van uitvoerbare documentatie die consistent dezelfde resultaten oplevert.
NixOS maakt me minder angstig
De afgelopen jaren stonden mijn RSS-feeds alleen lokaal op mijn telefoon. Daar zat een goed idee achter [1], maar in de praktijk werkte het nooit echt goed. Ten eerste zijn veel dingen makkelijker te lezen op een groter scherm. Maar het was ook riskant om te vertrouwen op een telefoon-app voor het beheren van de gelezen/ongelezen status van duizenden artikelen over honderden feeds [2]. Vooral toen ik overstapte naar een andere telefoon kon ik alle feeds migreren, maar de status van wat er gelezen was ging verloren. Wat ik echt wilde was een server-side feed aggregator. Dit is software die op een server draait, de RSS-feeds beheert en waardoor ik de feeds kan lezen via een webinterface of via client-applicaties. Ik wilde dit al een tijdje, maar ik heb nooit de stap gezet, omdat het weer een extra zijproject zou zijn waarvan ik de implementatie moet onderhouden.
Nu echter, met wat NixOS-ervaring, kostte het toevoegen van een werkende FreshRSS-configuratie (inclusief back-ups) slechts 9 regels Nix-code [3]. Daarnaast waren er nog een dozijn regels nodig voor de nginx reverse proxy-configuratie. Het werd iets ingewikkelder omdat ik wilde proxy_pass vanuit een specifiek location-blok, wat het herschrijven van cookie-paden vereiste. Maar dat is een probleem van mij, niet een probleem van NixOS. Die installatie heeft de afgelopen maanden simpelweg probleemloos gewerkt. Als die server kapotgaat, kan ik een nieuwe opstarten met exact dezelfde configuratie, waarschijnlijk in ongeveer 15 minuten. Wanneer we zoiets kunnen doen, is er letterlijk geen reden om nieuwe software niet gewoon te proberen.
Contrast met traditionele installaties
Contrasteer dit met hoe FreshRSS buiten NixOS wordt geïnstalleerd. Dan zouden we:
- een archief downloaden en uitpakken op de juiste locatie;
- de rechten configureren volgens de instructies;
- nginx en php-fpm installeren op de server, inclusief de nodige extra afhankelijkheden;
- php-fpm pools configureren en nginx zo instellen dat verzoeken worden doorgestuurd naar php-fpm;
- Let’s Encrypt-certificaten instellen;
- back-ups instellen; en
- hopen dat we ons herinneren hoe we al het bovenstaande moeten doen als er iets kapotgaat en we FreshRSS later op een nieuwe of geüpgradede server moeten herinstalleren.
Natuurlijk biedt het FreshRSS-project een container-image aan, wat het proces iets zou verkorten. Deze claimt Apache met mod_php op de juiste manier op te zetten en te configureren. We zouden dan alleen nog back-ups moeten configureren, een systemd-service moeten maken die de container draait, en nginx moeten beheren als een tls-terminating reverse proxy ervoor, omdat de container-image redelijkerwijs geen tls-ondersteuning heeft. Dit zijn nog steeds zaken die je moet onthouden, en er is geen garantie dat hetzelfde zes maanden later nog werkt bij een herinstallatie, tenzij we hebben opgeschreven welk exact container-image we hebben gedownload [4]. Het helpt niet om het container-image uit de broncode te bouwen, omdat twee builds van dezelfde Dockerfile met een tijdstussenpoos kunnen resulteren in vrij verschillende container-images.
Configuratiebeheer en onderhoud
Ik heb eerder genoemd hoeveel ik een hekel heb aan het onderhouden van zijprojecten. Dat geldt voor mijn eigen code, maar ook voor self-hosted services die door iemand anders zijn ontwikkeld. Ik vind een paar minuten onderhoud hier en daar prima, maar het moeten inplannen van uren ononderbroken werk om iets te upgraden, of het besteden van enige tijd aan noodonderhoud, doodt echt mijn zin om met computers te werken.
Je zou denken dat iemand met mijn instelling zich volledig zou verdiepen in configuratiebeheer, container-orchestratie, of beide, maar dat is niet zo. Ik heb eerlijke pogingen gedaan met CFEngine, Ansible, podman en k3s, maar geen van deze verbeterde mijn installatie-, configuratie- of deployment-ervaring significant ten opzichte van (a) het zorgvuldig opschrijven van zaken, en soms (b) het omzetten van die zorgvuldige aantekeningen in een shell-script dat een reeks ssh-commando's uitvoert [5]. Ja, dit is in feite het opnieuw uitvinden van Ansible – maar minder fragiel. Het zal niet breken de volgende keer dat iemand zijdelings naar pip kijkt. Het nadeel van het shell-script is dat het vaak vertrouwt op aannames die na verloop van tijd ongeldig worden, of wanneer het in een andere omgeving wordt gebruikt. Een NixOS-configuratie leest veel als de zorgvuldige instructies aan mezelf, behalve dat ze uitvoerbaar zijn en elke keer hetzelfde resultaat produceren.
***
Voetnoten
[1] Ik kan meestal tijd vinden om te lezen wanneer ik weg ben van mijn computer. [2] In het bijzonder: toen ik overstapte naar een andere telefoon kon ik alle feeds migreren, maar de gelezen/ongelezen status ging onderweg verloren. [3] Plus een dozijn regels voor de nginx reverse proxy-configuratie. Het werd iets ingewikkelder omdat ik wilde proxy_pass vanuit een specifiek location-blok, wat het herschrijven van cookie-paden vereiste. Maar dat is een probleem van mij, niet een probleem van NixOS. [4] Het helpt niet om het container-image uit de broncode te bouwen, omdat twee builds van dezelfde Dockerfile met een tijdstussenpoos kunnen resulteren in vrij verschillende container-images. [5] Ja, dit is in feite het opnieuw uitvinden van Ansible – maar minder fragiel. Het zal niet breken de volgende keer dat iemand zijdelings naar pip kijkt.
NixOS maakt me minder angstig
De afgelopen jaren stonden mijn RSS-feeds alleen lokaal op mijn telefoon. Daar zat een goed idee achter [1], maar in de praktijk werkte het nooit echt goed. Ten eerste zijn veel dingen makkelijker te lezen op een groter scherm. Maar het was ook riskant om te vertrouwen op een telefoon-app voor het beheren van de gelezen/ongelezen status van duizenden artikelen over honderden feeds [2]. Vooral toen ik overstapte naar een andere telefoon kon ik alle feeds migreren, maar de status van wat er gelezen was ging verloren. Wat ik echt wilde was een server-side feed aggregator. Dit is software die op een server draait, de RSS-feeds beheert en waardoor ik de feeds kan lezen via een webinterface of via client-applicaties. Ik wilde dit al een tijdje, maar ik heb nooit de stap gezet, omdat het weer een extra zijproject zou zijn waarvan ik de implementatie moet onderhouden.
Nu echter, met wat NixOS-ervaring, kostte het toevoegen van een werkende FreshRSS-configuratie (inclusief back-ups) slechts 9 regels Nix-code [3]. Daarnaast waren er nog een dozijn regels nodig voor de nginx reverse proxy-configuratie. Het werd iets ingewikkelder omdat ik wilde proxy_pass vanuit een specifiek location-blok, wat het herschrijven van cookie-paden vereiste. Maar dat is een probleem van mij, niet een probleem van NixOS. Die installatie heeft de afgelopen maanden simpelweg probleemloos gewerkt. Als die server kapotgaat, kan ik een nieuwe opstarten met exact dezelfde configuratie, waarschijnlijk in ongeveer 15 minuten. Wanneer we zoiets kunnen doen, is er letterlijk geen reden om nieuwe software niet gewoon te proberen.
Contrast met traditionele installaties
Contrasteer dit met hoe FreshRSS buiten NixOS wordt geïnstalleerd. Dan zouden we:
- een archief downloaden en uitpakken op de juiste locatie;
- de rechten configureren volgens de instructies;
- nginx en php-fpm installeren op de server, inclusief de nodige extra afhankelijkheden;
- php-fpm pools configureren en nginx zo instellen dat verzoeken worden doorgestuurd naar php-fpm;
- Let’s Encrypt-certificaten instellen;
- back-ups instellen; en
- hopen dat we ons herinneren hoe we al het bovenstaande moeten doen als er iets kapotgaat en we FreshRSS later op een nieuwe of geüpgradede server moeten herinstalleren.
Natuurlijk biedt het FreshRSS-project een container-image aan, wat het proces iets zou verkorten. Deze claimt Apache met mod_php op de juiste manier op te zetten en te configureren. We zouden dan alleen nog back-ups moeten configureren, een systemd-service moeten maken die de container draait, en nginx moeten beheren als een tls-terminating reverse proxy ervoor, omdat de container-image redelijkerwijs geen tls-ondersteuning heeft. Dit zijn nog steeds zaken die je moet onthouden, en er is geen garantie dat hetzelfde zes maanden later nog werkt bij een herinstallatie, tenzij we hebben opgeschreven welk exact container-image we hebben gedownload [4]. Het helpt niet om het container-image uit de broncode te bouwen, omdat twee builds van dezelfde Dockerfile met een tijdstussenpoos kunnen resulteren in vrij verschillende container-images.
Configuratiebeheer en onderhoud
Ik heb eerder genoemd hoeveel ik een hekel heb aan het onderhouden van zijprojecten. Dat geldt voor mijn eigen code, maar ook voor self-hosted services die door iemand anders zijn ontwikkeld. Ik vind een paar minuten onderhoud hier en daar prima, maar het moeten inplannen van uren ononderbroken werk om iets te upgraden, of het besteden van enige tijd aan noodonderhoud, doodt echt mijn zin om met computers te werken.
Je zou denken dat iemand met mijn instelling zich volledig zou verdiepen in configuratiebeheer, container-orchestratie, of beide, maar dat is niet zo. Ik heb eerlijke pogingen gedaan met CFEngine, Ansible, podman en k3s, maar geen van deze verbeterde mijn installatie-, configuratie- of deployment-ervaring significant ten opzichte van (a) het zorgvuldig opschrijven van zaken, en soms (b) het omzetten van die zorgvuldige aantekeningen in een shell-script dat een reeks ssh-commando's uitvoert [5]. Ja, dit is in feite het opnieuw uitvinden van Ansible – maar minder fragiel. Het zal niet breken de volgende keer dat iemand zijdelings naar pip kijkt. Het nadeel van het shell-script is dat het vaak vertrouwt op aannames die na verloop van tijd ongeldig worden, of wanneer het in een andere omgeving wordt gebruikt. Een NixOS-configuratie leest veel als de zorgvuldige instructies aan mezelf, behalve dat ze uitvoerbaar zijn en elke keer hetzelfde resultaat produceren.
***
Voetnoten
[1] Ik kan meestal tijd vinden om te lezen wanneer ik weg ben van mijn computer. [2] In het bijzonder: toen ik overstapte naar een andere telefoon kon ik alle feeds migreren, maar de gelezen/ongelezen status ging onderweg verloren. [3] Plus een dozijn regels voor de nginx reverse proxy-configuratie. Het werd iets ingewikkelder omdat ik wilde proxy_pass vanuit een specifiek location-blok, wat het herschrijven van cookie-paden vereiste. Maar dat is een probleem van mij, niet een probleem van NixOS. [4] Het helpt niet om het container-image uit de broncode te bouwen, omdat twee builds van dezelfde Dockerfile met een tijdstussenpoos kunnen resulteren in vrij verschillende container-images. [5] Ja, dit is in feite het opnieuw uitvinden van Ansible – maar minder fragiel. Het zal niet breken de volgende keer dat iemand zijdelings naar pip kijkt.
Groetjes,