Immutable Linux op een server: wat zijn de opties?

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 in /usr op een draaiende machine. U bouwt of haalt een nieuwe image op, de machine plaatst deze naast de actieve versie en bij de volgende herstart wordt gewisseld naar de nieuwe versie. De vorige image blijft op de schijf staan, waardoor een mislukte update ongedaan kan worden gemaakt door simpelweg opnieuw op te starten.

De term "immutable" is enigszins misleidend. Niets houdt root fysiek tegen om naar de schijf te schrijven. Wat deze systemen doen, is de systeemmappen als read-only koppelen en het eigendom ervan toewijzen aan de image. Persistente data bevindt zich in /var. Machine-specifieke configuratie staat in /etc. Alles onder /usr behoort toe aan de image; dit is de reden waarom twee servers die dezelfde image-tag draaien, identieke systeembestanden bevatten.

De termen die Red Hat gebruikt voor de twee modellen zijn het duidelijkst: package mode en image mode. Package mode is een draaiend systeem met een pakketbeheerder die wijzigingen aanbrengt. Image mode is een bouwstap die elders plaatsvindt en een artifact oplevert, 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 lang in bedrijf is, 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. De term hiervoor is configuration drift, en dit is de reden waarom het opnieuw opbouwen van "dezelfde" server op basis van uw aantekeningen vaak resulteert in een systeem dat zich anders gedraagt. De aantekeningen bevatten de intentie. De schijf bevat de waarheid.

Image mode verwijdert de plek waar drift zich ophoopt. /usr is tijdens runtime read-only, waardoor een handmatige installatie direct mislukt 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 Linux server onderhoudschecklist met discipline aanpakt, maar dan afgehandeld door het bestandssysteem zelf.

Rollback is een herstart, 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 reeds 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 de agent de update die u zojuist heeft teruggedraaid opnieuw klaarzetten. -r herstart zodra de rollback is voorbereid. Om te voorkomen dat een deployment die u vertrouwt wordt verwijderd door garbage collection:

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 versie met een punt en toont Pinned: yes bij de versie 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 deze twee. Elke slot heeft een prioriteit en een pogingenteller in de partitietabel, waardoor een slot die niet succesvol opstart geen pogingen meer overhoudt 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 correct werkende 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 geslaagde opstart.

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 voert een reboot uit naar 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 de manier waarop u een server verplaatst tussen image-streams zonder deze opnieuw te installeren.

Schakel voor onbeheerde updates de timer in die bij het project wordt geleverd:

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

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

Uit die Containerfile volgen twee bouwregels. Schrijfbare data hoort thuis onder /var, dus software die erop staat om in de eigen installatiemap te schrijven, heeft tijdens het bouwen een symlink of een systemd BindPaths=-regel nodig. En /etc wordt bij een update via een three-way merge samengevoegd, wat betekent dat een bestand dat u nooit heeft aangeraakt 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 live-systeem voor een debug-sessie:

sudo bootc usr-overlay
sudo dnf -y install strace

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

Fedora CoreOS: eenmalig provisioneren, voor altijd bijgewerkt

Fedora CoreOS heeft geen interactief installatieprogramma. U schrijft een Butane YAML-bestand, transpileert dit naar Ignition JSON en voert dit bij de eerste boot aan 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 boot in de initramfs. Dit is het punt waar gebruikers die van cloud-init komen vaak de mist in gaan. Als de configuratie geen SSH-sleutel bevat, start de machine zonder toegangsmogelijkheid en is de enige oplossing om deze opnieuw vanaf nul te provisioneren. Test de configuratie op een wegwerp-machine voordat u deze toepast op een server die u nodig heeft.

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 in /etc/zincati/config.d/55-updates-strategy.toml om de periodieke strategie te selecteren:

[updates]
strategy = "periodic"

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

• 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, en de wijziging wordt pas na een reboot van kracht. De kosten hiervan merkt u later. Uw layered set wordt opnieuw toegepast boven op elke nieuwe base image, waardoor een pakket dat op de dag van een update uit de repository is verdwenen, de update laat mislukken. De documentatie van Fedora zelf stuurt u richting containers voor alles wat substantieel is, en richting een bootc image wanneer u het OS daadwerkelijk moet wijzigen.

Flatcar Container Linux: geen pakketbeheerder aanwezig

Flatcar is de voortzetting van CoreOS Container Linux en de meest strikte van de algemene opties. 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 verlopen 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 planning, 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 zorgt REBOOT_STRATEGY=etcd-lock in combinatie met locksmithctl set-max 4 voor een limiet op het aantal nodes dat tegelijkertijd mag herstarten, zodat een update nooit het volledige cluster tegelijkertijd offline haalt.

Talos Linux: geen shell, geen SSH, geen console

Talos is de meest minimalistische van de vier en het meest duidelijk 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, op basis van 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 aangepast" onmogelijk is geworden.

Wat een VPS-huurder feitelijk 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 beschikbaar. Op bootc krijgt u een tijdelijke overlay die verdwijnt bij een reboot. Op Fedora CoreOS krijgt u een gelaagde implementatie die een reboot vereist. Op 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 goedkoop als de pipeline bestaat. Het is echter aanzienlijk werk om dit op te zetten als dat niet zo 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 gebouwd, tegen de kernel van die image. Alles wat een module vereist die niet in de basis-image zit, 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 via image-mode. Velen doen dat niet. Controleer dit voordat u beslist, 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 dergelijk systeem op een gehuurde VPS plaatsen

Controleer eerst twee zaken bij uw provider: of u beschikt over out-of-band consoletoegang, zoals VNC of een seriële console, en of u kunt opstarten in een rescuesysteem. 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 rescuesysteem. Flatcar levert hiervoor een op zichzelf staand script 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 rescuesysteem, nooit vanaf de server die u vervangt, omdat het script de doel-schijf opnieuw partitioneert tijdens het proces. Het vereist minimaal 8 GB bruikbare ruimte op het apparaat 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 opzet en het installatieprogramma 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 uitvoert. Schrijven naar het verkeerde apparaat vernietigt alles wat erop stond en er is geen bevestigingsvraag.

bootc biedt de enige 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 probeer het eerst op een server die u kunt missen. Na de herstart draait de machine het image en is de pakketset die u had verdwenen.

Wie zou een immutable server moeten gebruiken en 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 hebt met drie services, dingen installeert wanneer u ze nodig hebt en geen build-pipeline hebt. Image mode verwijdert het werk niet. Het verplaatst het werk van de server naar de build, en brengt u een registry en een pipeline in rekening voor deze verplaatsing. Als u een plek hebt om dat werk onder te brengen, krijgt u servers die identiek zijn en een rollback die neerkomt op een reboot. Als u dat niet hebt, hebt u bewegende onderdelen toegevoegd aan een machine die prima functioneerde, en maakt u het uzelf moeilijker tijdens een storing om 02:00 uur 's nachts.

De saaie middenweg werkt nog steeds: een normale distributie met automatische beveiligingsupdates, plus een rebuild die u daadwerkelijk hebt geoefend. Het kiezen van die basis is een beslissing op zich, die wordt behandeld in het kiezen van het besturingssysteem voor uw VPS. Image mode 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 aangekoppeld en bij de volgende update in zijn geheel wordt vervangen door een nieuwe image, terwijl /etc en /var schrijfbaar 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 zelf 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 het rescue-systeem, schrijft de disk-image van de distributie naar het block device en start vervolgens opnieuw op. Het flatcar-install-script van Flatcar voert dit uit vanuit elke Linux-omgeving, en Fedora CoreOS levert coreos-installer als 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: als een machine niet meer opstart, heeft u geen manier om te zien wat er mis is.

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 toevoegen 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 schrijfbaar /usr dat 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 voor 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 terug naar de vorige staat. Talos en Flatcar gaan verder en rollen automatisch terug wanneer de nieuwe versie 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 wel 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 met het bouwwerk al voor u gedaan en automatische updates standaard 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 wanneer de machine een Kubernetes-node is, aangezien deze geen shell heeft en niets anders uitvoert.