Immutable Linux op een server: de beste keuzes

Wat een immutable Linux-distributie is

Een immutable Linux-distributie levert het besturingssysteem als één image, waardoor u het systeem vervangt in plaats van het ter plekke bij te werken. Er is geen sprake van het herschrijven van bestanden onder apt upgrade op een draaiende machine via /usr. U bouwt of haalt een nieuwe image op, de machine plaatst deze naast de actieve versie en bij de volgende herstart wordt de actieve versie gewisseld. De vorige image blijft op de schijf staan, waardoor het ongedaan maken van een foutieve update slechts een herstart vereist.

De term "immutable" is enigszins misleidend. Niets houdt root fysiek tegen om naar de schijf te schrijven. Wat deze systemen doen, is de systeemmappen alleen-lezen koppelen en het eigendom daarvan toewijzen aan de image. Persistente gegevens bevinden zich in /var. Machinespecifieke configuratie bevindt zich in /etc. Alles onder /usr behoort tot de image; dit is de reden waarom twee servers die dezelfde image-tag draaien, identieke systeembestanden bevatten.

De namen die Red Hat hanteert voor de twee modellen zijn het meest duidelijk: package mode en image mode. Package mode is een draaiend systeem met een pakketbeheerder die het systeem aanpast. Image mode is een bouwstap die elders plaatsvindt en een artifact produceert, waarbij de enige taak van de server is om op te starten vanaf het artifact waarnaar u verwijst. Alles hieronder vloeit voort uit dat ene verschil.

Waarom een read-only systeem belangrijker is op een server

Een server die twee jaar draait, heeft een geschiedenis die niemand heeft gedocumenteerd. Een make install van een gehaaste avond. Een repository van derden toegevoegd voor één pakket. Een configuratiebestand aangepast tijdens een storing dat nooit is teruggezet in uw configuratiebeheer. Dit verschijnsel heet configuration drift, en het is de reden waarom het opnieuw opbouwen van "dezelfde" server op basis van uw aantekeningen vaak resulteert in een machine die zich anders gedraagt. De aantekeningen bevatten de intentie. De schijf bevat de waarheid.

Image mode verwijdert de plek waar drift zich ophoopt. /usr is read-only tijdens runtime, waardoor een handmatige installatie direct faalt of wordt vastgelegd als een laag die u met één commando kunt opvragen. Dat maakt het verschil tussen twee machines zichtbaar in plaats van archeologisch. Het is hetzelfde probleem dat een reguliere onderhoudschecklist voor Linux-servers met discipline aanpakt, maar dan afgehandeld door het bestandssysteem zelf.

Rollback is een reboot, en dat is de kern van het concept

Het falen waarvoor dit model is ontworpen, is het scenario dat we reeds documenteren: een VPS die niet opstart na een kernel-update. In de pakketmodus herstelt u het systeem via de rescue-console van de provider. U koppelt de schijf, voert een chroot uit en verwijdert handmatig een kernel-pakket. Dit werkt omdat de bootloader oude kernels bewaart, maar alleen de kernel wordt op die manier geversioneerd. De glibc-update en de wijzigingen in systemd die in dezelfde transactie zijn meegekomen, zijn al toegepast en er is geen enkel commando dat deze gezamenlijk terugdraait.

In de imagemodus is de eenheid het volledige systeem. Op een bootc-host:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback wisselt de volgorde in de bootloader terug naar het vorige boot-item; dit is de image die u een uur geleden draaide, inclusief kernel en userspace. Er wordt niets gedownload en niets opnieuw opgebouwd, omdat de oude image nooit van de schijf is verwijderd.

Fedora CoreOS doet hetzelfde onder andere namen:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

Stop eerst Zincati. Zincati is de agent die een Fedora CoreOS-machine op de nieuwste release houdt; als u deze laat draaien, zal deze de update die u zojuist heeft teruggedraaid opnieuw klaarzetten. -r start opnieuw op zodra de rollback is voorbereid. Om te voorkomen dat een deployment die u vertrouwt wordt verwijderd door de garbage collector:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status toont de deployments in de volgorde waarin de bootloader ze aanbiedt, markeert de actieve met een punt en toont Pinned: yes bij de deployment die u heeft vastgezet.

Talos voert dit uit als één API-aanroep vanaf uw werkstation:

talosctl rollback --nodes 10.20.30.40

Flatcar houdt twee /usr-partities bij en schakelt tussen beide. Elke slot heeft een prioriteit en een pogingenteller in de partitietabel, waardoor een slot die nooit succesvol opstart geen pogingen meer over heeft en de bootloader de andere kiest. Controleer in welke slot u zich bevindt en of deze als goed is gemarkeerd:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

Een gezonde, actieve slot toont een regel met priority=1 tries=0 successful=1. Als er geen overeenkomstige regel is, betekent dit dat de huidige slot nooit is bevestigd; dit is de status waarin een machine zich bevindt tussen een update en de eerste succesvolle boot.

Wat vervangt "een pakket installeren": bootc en een Containerfile

bootc is de tool die dit patroon heeft gegeneraliseerd. Het omschrijft zichzelf als transactionele, in-place besturingssysteemupdates met behulp van OCI (open container initiative) container images, en het is een CNCF Sandbox-project. Uw server wordt een Containerfile. Sinds augustus 2026 is de Fedora base image quay.io/fedora/fedora-bootc:44 en de CentOS Stream base image quay.io/centos-bootc/centos-bootc:stream10.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

Bouw en push deze zoals elke andere image:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

Voer vervolgens op de server uit:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade bevraagt de image-bron en zet de nieuwe image in de wachtrij voor de volgende boot. --check rapporteert of er een update beschikbaar is en wijzigt niets. --apply herstart de machine in de nieuwe image. bootc switch registry.example.com/edge/web:next wijst de machine naar een andere image terwijl /etc en /var behouden blijven; dit is hoe u een server verplaatst tussen image-streams zonder deze opnieuw te installeren.

Schakel voor onbeheerde updates de timer in die het project meelevert:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

Dit is het antwoord van de image-mode op onbeheerde upgrades op Ubuntu en op dnf-automatic op Rocky en Alma. Het verschil zit in wat er wordt toegepast. Een timer in package-mode past elke versie toe die de repository op dat moment bevat, waardoor de resulterende set op elke machine licht verschilt. Een timer in image-mode past één artifact toe dat u al ergens anders heeft opgestart.

Uit die Containerfile volgen twee bouwregels. Beschrijfbare data hoort thuis onder /var, dus software die erop staat om in de eigen installatiemap te schrijven, heeft een symlink of een systemd BindPaths=-regel nodig die tijdens het bouwen wordt toegevoegd. En /etc wordt bij een update via een three-way merge samengevoegd; dit betekent dat een bestand dat u nooit heeft aangepast de nieuwe versie van de image overneemt, terwijl een bestand dat u lokaal heeft bewerkt behouden blijft.

Wanneer u een tool nodig heeft op een draaiend systeem voor een eenmalige debug-sessie:

sudo bootc usr-overlay
sudo dnf -y install strace

Dit voegt een tijdelijke beschrijfbare overlay toe op /usr die bij de volgende reboot wordt verwijderd. Dit is bedoeld voor het onderzoeken van een probleem, niet voor het oplossen ervan. U kunt de kernel op deze manier niet wijzigen en alles wat u installeert verdwijnt volgens ontwerp bij een reboot.

Fedora CoreOS: eenmalig geconfigureerd, voor altijd bijgewerkt

Fedora CoreOS heeft geen interactief installatieprogramma. U schrijft een Butane YAML-bestand, transpileert dit naar Ignition JSON en voert dit uit bij de eerste keer opstarten van de machine:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition draait alleen tijdens de eerste keer opstarten in de initramfs. Dit is het punt waar gebruikers die van cloud-init komen vaak de fout in gaan. Als de configuratie geen SSH-sleutel bevat, start de machine op zonder toegangsmogelijkheid en is de enige oplossing om deze volledig opnieuw te provisioneren. Test de configuratie op een wegwerp-machine voordat u deze toepast op een server die u belangrijk vindt.

Installeren op een schijf vanuit een live-omgeving:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

Updates zijn standaard automatisch. U bepaalt wanneer, niet of. Plaats een TOML-bestand op /etc/zincati/config.d/55-updates-strategy.toml waarin u de periodieke strategie selecteert:

[updates]
strategy = "periodic"

Onder die strategie voegt u per array-of-tables-item één onderhoudsvenster toe. Elk venster begint met de naam updates.periodic.window tussen dubbele vierkante haken als kop, gevolgd door drie sleutels:

• days, een lijst met dagen, zoals "Sat" en "Sun".
• start_time, het tijdstip waarop het venster opent, geschreven als "22:30".
• length_minutes, de duur dat het venster open blijft, zoals 60.

Deze tijden zijn in UTC. Om updates volledig te stoppen, voert u sudo systemctl disable --now zincati.service uit en accepteert u dat u vanaf dat moment zelf verantwoordelijk bent voor het patchschema.

Package layering bestaat als een ontsnappingsroute:

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

Dit bouwt een nieuwe deployment met het toegevoegde pakket; de wijziging wordt pas na een herstart van kracht. De kosten hiervan merkt u later. Uw gelaagde set wordt opnieuw toegepast boven op elke nieuwe basisimage. Een pakket dat op de dag van een update uit de repository is verdwenen, zorgt er daarom voor dat de update mislukt. De documentatie van Fedora zelf adviseert om voor substantiële zaken containers te gebruiken, en om over te stappen op een bootc-image wanneer u daadwerkelijk het besturingssysteem moet wijzigen.

Flatcar Container Linux: geen pakketbeheerder aanwezig

Flatcar is de voortzetting van CoreOS Container Linux en de meest strikte optie voor algemeen gebruik. Er is geen pakketbeheerder om op terug te vallen. Alles wat u uitvoert, is een container. Provisioning verloopt via Ignition, hetzelfde als bij Fedora CoreOS. Updates worden afgehandeld via de twee A/B /usr-partities zoals hierboven beschreven, aangestuurd door update_engine, waarbij locksmithd bepaalt wanneer de herstart plaatsvindt.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT betekent dat de passieve partitie al de nieuwe image bevat en alleen de herstart nog moet plaatsvinden. De standaard herstartstrategie is reboot met een vertraging van vijf minuten, dus een enkele productie-VPS zal uit zichzelf herstarten volgens zijn eigen schema, tenzij u anders aangeeft. Stel een venster in via /etc/flatcar/update.conf:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off laat de herstart aan u over. SERVER=disabled in hetzelfde bestand stopt de updatecontrole volledig. Voor een cluster beperkt REBOOT_STRATEGY=etcd-lock in combinatie met locksmithctl set-max 4 hoeveel nodes er tegelijkertijd mogen herstarten, zodat een update nooit het volledige cluster tegelijkertijd offline haalt.

Talos Linux: geen shell, geen SSH, geen console

Talos is de meest beperkte van de vier en de meest duidelijke over zijn doel. Het draait Kubernetes-nodes. Er is geen SSH-daemon, geen shell en geen console-login. Elke bewerking is een gRPC API-aanroep die wordt uitgevoerd met talosctl vanaf uw werkstation, gericht op een machineconfiguratie die u in git beheert.

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

Vervang de tag door de release waarnaar u overstapt. De upgrade gebruikt een A-B-schema dat de vorige kernel en OS-image behoudt. Als de nieuwe versie niet opstart, rolt Talos automatisch terug zonder tussenkomst. Debuggen werkt anders omdat er geen shell is: u gebruikt talosctl logs en talosctl dmesg in plaats van journalctl op de machine zelf.

Als uw workload geen Kubernetes is, dan is Talos niet de juiste keuze. Als dat wel zo is, elimineert Talos een hele categorie incidenten, omdat "iemand is ingelogd op een node en heeft iets gewijzigd" simpelweg niet mogelijk is.

Wat een VPS-huurder daadwerkelijk opgeeft

Ad-hoc installaties op een draaiend systeem. Dit is het belangrijkste punt. sudo apt install htop om 02:00 uur tijdens een incident is niet mogelijk. Bij bootc krijgt u een tijdelijke overlay die verdwijnt bij een herstart. Bij Fedora CoreOS krijgt u een gelaagde implementatie die een herstart vereist. Bij Flatcar en Talos krijgt u niets.

Een build-pipeline die u voorheen niet had. Het toevoegen van een pakket betekent het bewerken van een Containerfile, het bouwen van de image, het pushen naar een registry en het uitrollen van de servers. Dat is eenvoudig wanneer de pipeline bestaat. Het is echter aanzienlijk werk om dit op te zetten als die er niet is, en het vereist een registry die de servers kunnen bereiken; dit is weer een extra service om te draaien of een extra rekening om te betalen.

Kernelmodules. De kernel is afkomstig uit de image, dus een module die is gecompileerd tegen de draaiende kernel overleeft de volgende update niet. Out-of-tree modules en DKMS (dynamic kernel module support) pakketten moeten in de image worden ingebouwd, tegen de kernel van die specifieke image. Alles wat een module vereist die niet in de basis-image aanwezig is, wordt een build-probleem in plaats van een installatieprobleem.

Agents van leveranciers en providers. Monitoring- en backup-agents worden meestal geleverd als een .deb of .rpm met een installatiescript dat naar /usr schrijft en een unit inschakelt. Op een systeem met een alleen-lezen bestandssysteem mislukt dat script. Sommige leveranciers publiceren een container of documenteren een installatie in image-modus. Velen doen dit echter niet. Controleer dit voordat u een besluit neemt, want een vloot die u niet kunt monitoren is slechter dan een vloot die afwijkt van de standaard (drift).

De image zelf. Vrijwel geen enkel VPS-configuratiescherm vermeldt Fedora CoreOS, Flatcar of Talos naast Ubuntu en Debian. U levert de schijf zelf aan, wat het onderwerp is van de volgende sectie.

Een image op een gehuurde VPS plaatsen

Bevestig eerst twee zaken bij uw provider: dat u beschikt over out-of-band consoletoegang, zoals VNC of een seriële console, en dat u kunt opstarten in een rescue-systeem. Zonder console is een machine die niet meer opstart een supportticket in plaats van een reparatie van vijf minuten.

Als de provider aangepaste images accepteert, upload dan het raw- of qcow2-image van de leverancier en het werk is gedaan. Anders schrijft u de schijf zelf vanuit het rescue-systeem. Flatcar levert een op zichzelf staand script hiervoor, dat vanuit elke Linux-omgeving draait:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

Voer dit uit vanuit het rescue-systeem, nooit vanaf de server die u vervangt, omdat het script de doel-schijf opnieuw partitioneert tijdens het proces. Er is minimaal 8 GB aan bruikbare ruimte op het apparaat vereist en de rescue-omgeving moet beschikken over bash, bzip2 of lbzip2, lsblk, wget, udevadm, gpg en gawk. Uw ignition.json moet een SSH-sleutel bevatten, anders heeft het geïnstalleerde systeem geen manier om u toegang te verlenen.

Fedora CoreOS heeft dezelfde werkwijze en de installer draait als een container:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

Controleer de apparaatnaam met lsblk voordat u het commando uitvoert. Schrijven naar het verkeerde apparaat vernietigt alle aanwezige data en er volgt geen bevestigingsvraag.

bootc biedt een methode die de rescue-modus overslaat, omdat het een draaiend Linux-systeem ter plekke converteert:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

Lees de documentatie van het base-image dat u gebruikt voordat u dit uitvoert en test het op een server die u kunt missen. Na de herstart draait de machine het image en is de voorgaande pakketset verwijderd.

Voor wie is een immutable server geschikt, en voor wie niet

Kies hiervoor als uw servers 'cattle' (vee) zijn. Veel machines op basis van één recept. CI (continuous integration) runners die slechts een uur bestaan. k3s- of Kubernetes-nodes die worden vervangen in plaats van gerepareerd. Alles waarbij het antwoord op een defecte machine al is: "verwijder hem en maak een nieuwe". Het loont ook wanneer u aan een auditor moet bewijzen wat er op een machine draait, omdat het antwoord een image digest is in plaats van een pakketlijst.

Kies hier niet voor als u één handmatig beheerde VPS heeft met drie services, u dingen installeert wanneer u ze nodig heeft en u geen build-pipeline heeft. Image-modus verwijdert het werk niet. Het verplaatst het werk van de server naar de build, en brengt u kosten in rekening voor een registry en een pipeline voor deze verplaatsing. Als u een plek heeft om dat werk onder te brengen, krijgt u servers die identiek zijn en een rollback die neerkomt op een herstart. Als u dat niet heeft, heeft u bewegende onderdelen toegevoegd aan een systeem dat prima werkte, en heeft u het lastiger gemaakt voor uzelf om 02:00 uur 's nachts.

De saaie middenweg werkt nog steeds: een normale distributie met automatische beveiligingsupdates, plus een rebuild die u daadwerkelijk heeft geoefend. Het kiezen van die basis is een beslissing op zich, die wordt behandeld in het kiezen van het OS voor uw VPS. Image-modus is slechts de nieuwste ronde van een zeer oude discussie over hoe software een machine moet bereiken, en de geschiedenis van Linux-distributies is grotendeels die discussie die zichzelf herhaalt.

FAQ

Is een immutable Linux-distributie echt onveranderlijk?

Nee, en de naam zorgt voor verwarring. De root-gebruiker kan nog steeds naar de schijf schrijven. Wat er in werkelijkheid gebeurt, is dat /usr tijdens runtime als read-only wordt gemount en in zijn geheel wordt vervangen door de volgende image, terwijl /etc en /var beschrijfbaar blijven en behouden blijven na updates. Wijzigingen die u aanbrengt onder /usr worden op dat moment geweigerd of bij de volgende update verwijderd. Het praktische gevolg is dat systeemmappen alleen veranderen wanneer de image verandert.

Kan ik Fedora CoreOS of Flatcar draaien op een VPS die deze niet aanbiedt?

Meestal wel, mits de provider u een rescue-systeem en consoletoegang biedt. U start de rescue-omgeving, schrijft de disk-image van de distributie naar het block device en start vervolgens opnieuw op. Het flatcar-install-script van Flatcar doet dit vanuit elke Linux-omgeving, en Fedora CoreOS levert coreos-installer als een container die u op dezelfde manier kunt uitvoeren. Beide hebben een Ignition-bestand nodig met uw SSH-sleutel, omdat er geen wachtwoordprompt bij de eerste opstart is om op terug te vallen. Probeer dit niet zonder consoletoegang: een machine die niet meer opstart, geeft u geen mogelijkheid om de fout te onderzoeken.

Hoe installeer ik een pakket op een immutable server?

U voegt het toe aan de image en voert een redeploy uit. Bij bootc is dat een RUN dnf -y install ...-regel in het Containerfile, gevolgd door een rebuild, een push en vervolgens sudo bootc upgrade --apply op de machine. Op Fedora CoreOS kunt u het pakket "layeren" met sudo rpm-ostree install en opnieuw opstarten, met als nadeel dat het pakket bij elke toekomstige update opnieuw moet worden toegepast. Op Flatcar en Talos is er geen pakketbeheerder, dus het antwoord is een container. Voor een eenmalige debugging-tool op een bootc-host geeft sudo bootc usr-overlay u een beschrijfbare /usr die verdwijnt bij de volgende herstart.

Lost image-mode een VPS op die niet meer opstart na een kernel-update?

Het verandert het herstelproces van een taak via de rescue-console in een simpele herstart. De vorige image, inclusief kernel en userspace, staat nog steeds op de schijf, dus met sudo bootc rollback of sudo rpm-ostree rollback -r keert u hiernaar terug. Talos en Flatcar gaan verder en rollen automatisch terug wanneer de nieuwe slot niet opstart, omdat een boot-entry pas de standaard wordt na één succesvolle opstart. Dit voorkomt geen slechte updates, maar maakt het ongedaan maken ervan eenvoudig.

Welke immutable distributie moet ik kiezen voor een server?

Kies bootc als u een algemene Linux-server wilt die u bouwt als een container-image en die u kunt installeren op een machine die u al heeft. Kies Fedora CoreOS als u dat model wilt waarbij het bouwen voor u wordt gedaan en automatische updates standaard zijn ingeschakeld. Kies Flatcar als u een minimale container-host wilt met een A/B-updateschema en zonder pakketbeheerder waar gebruikers naar kunnen grijpen. Kies Talos alleen als de machine een Kubernetes-node is, aangezien deze geen shell heeft en niets anders uitvoert.