Distributions Linux immuables pour serveur : guide

Ce qu’est une distribution Linux immuable

Une distribution Linux immuable fournit le système d’exploitation sous la forme d’une image. Vous remplacez donc le système au lieu de le mettre à jour sur place. Aucun processus ne réécrit apt upgrade les fichiers sous /usr sur un serveur en fonctionnement. Vous construisez ou récupérez une nouvelle image. La machine la prépare à côté de l’image actuellement utilisée, puis le prochain redémarrage active l’autre image. L’ancienne image reste présente sur le disque. Pour annuler une mauvaise mise à jour, il suffit donc de redémarrer.

Le terme « immuable » est quelque peu excessif. Rien n’empêche physiquement root d’écrire sur le disque. Ces systèmes montent les répertoires du système en lecture seule et en confient la gestion à l’image. Les données persistantes résident dans /var. La configuration propre à la machine réside dans /etc. Tout ce qui se trouve sous /usr appartient à l’image. C’est pourquoi deux serveurs qui exécutent le même tag d’image contiennent des fichiers système identiques.

Red Hat utilise les noms les plus clairs pour désigner ces deux modèles : mode paquet et mode image. Le mode paquet correspond à un système en fonctionnement associé à un gestionnaire de paquets qui le modifie. Le mode image correspond à une étape de build exécutée ailleurs, qui produit un artefact, ainsi qu’à un serveur dont le seul rôle est de démarrer l’artefact que vous lui indiquez. Tout ce qui suit découle de cette différence fondamentale.

Pourquoi un système en lecture seule est plus important sur un serveur

Un serveur qui fonctionne depuis deux ans possède un historique que personne n’a consigné. Un make install ajouté lors d’une soirée précipitée. Un dépôt tiers ajouté pour installer un paquet. Un fichier de configuration modifié pendant une panne, puis jamais restauré dans votre gestion de configuration. Ce phénomène s’appelle la dérive de configuration. C’est pourquoi reconstruire « le même » serveur à partir de vos notes produit si souvent une machine au comportement différent. Les notes décrivent l’intention. Le disque contient la réalité.

Le mode image supprime l’endroit où la dérive s’accumule. /usr est en lecture seule à l’exécution. Une installation effectuée manuellement échoue donc immédiatement ou est enregistrée comme une couche que vous pouvez lister avec une seule commande. La différence entre deux machines devient ainsi visible au lieu de nécessiter une analyse archéologique. C’est le même problème qu’attaque une checklist classique de maintenance Linux, mais avec la discipline du système de fichiers.

Une restauration consiste à redémarrer, et c’est tout l’intérêt

Ce modèle est conçu pour l’échec que nous documentons déjà : un VPS qui ne redémarre pas après une mise à jour du kernel. En mode paquets, vous récupérez la machine depuis la console de secours du fournisseur. Vous montez le disque, vous utilisez chroot, puis vous supprimez manuellement un paquet du kernel. Cette méthode fonctionne parce que le bootloader conserve les anciens kernels, mais seul le kernel est versionné de cette façon. La mise à jour de glibc et les modifications de systemd installées lors de la même transaction sont déjà appliquées. Aucune commande unique ne permet de les annuler ensemble.

En mode image, l’unité de déploiement est le système entier. Sur un hôte bootc :

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback rétablit l’ordre du bootloader pour revenir à l’entrée de démarrage précédente. Il s’agit de l’image utilisée une heure plus tôt, avec le kernel et l’espace utilisateur correspondants. Rien n’est téléchargé et rien n’est reconstruit, car l’ancienne image est toujours présente sur le disque.

Fedora CoreOS fait la même chose avec d’autres noms :

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

Arrêtez d’abord Zincati. Zincati est l’agent qui maintient une machine Fedora CoreOS sur la version la plus récente. Si vous le laissez fonctionner, il préparera la mise à jour que vous venez d’annuler. -r redémarre la machine une fois la restauration préparée. Pour conserver un déploiement auquel vous faites confiance et empêcher sa suppression automatique :

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status affiche les déploiements dans l’ordre dans lequel le bootloader les proposera, marque le déploiement en cours avec un point et affiche Pinned: yes sur celui que vous avez épinglé.

Talos effectue cette opération avec un seul appel API depuis votre poste de travail :

talosctl rollback --nodes 10.20.30.40

Flatcar conserve deux partitions /usr et bascule de l’une à l’autre. Chaque emplacement possède une priorité et un compteur de tentatives dans la table de partitions. Ainsi, un emplacement qui ne démarre jamais correctement épuise ses tentatives et le bootloader sélectionne l’autre. Vérifiez l’emplacement utilisé et s’il a été marqué comme valide :

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

Un emplacement en cours d’exécution et sain affiche une ligne contenant priority=1 tries=0 successful=1. L’absence de ligne correspondante signifie que l’emplacement actuel n’a jamais été confirmé. C’est l’état d’une machine entre une mise à jour et son premier démarrage réussi.

Qu’est-ce qui remplace « installer un paquet » : bootc et un Containerfile

bootc est l’outil qui a généralisé ce modèle. Il se présente comme un outil de mise à jour transactionnelle, sur place, du système d’exploitation à l’aide d’images de conteneurs OCI (Open Container Initiative). C’est également un projet CNCF Sandbox. Votre serveur devient un Containerfile. En août 2026, l’image de base Fedora est quay.io/fedora/fedora-bootc:44 et l’image de base CentOS Stream est 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

Construisez et envoyez l’image comme n’importe quelle autre image :

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

Puis, sur le serveur :

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

bootc upgrade interroge la source de l’image et met la nouvelle image en attente pour le prochain démarrage. --check indique si une mise à jour est disponible et ne modifie rien. --apply redémarre le serveur sur cette image. bootc switch registry.example.com/edge/web:next configure la machine pour utiliser une autre image tout en conservant /etc et /var. C’est ainsi que vous déplacez un serveur entre différents flux d’images sans le réinstaller.

Pour les mises à jour automatiques, activez le timer fourni par le projet :

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

C’est l’équivalent, en mode image, des mises à jour automatiques sur Ubuntu et de dnf-automatic sur Rocky et Alma. La différence concerne ce qui est installé. Un timer en mode paquet applique les versions présentes dans le dépôt ce soir-là. L’ensemble obtenu diffère donc légèrement sur chaque machine. Un timer en mode image applique un artefact que vous avez déjà démarré ailleurs.

Deux règles de build découlent de ce Containerfile. Les données modifiables doivent se trouver sous /var. Les logiciels qui exigent d’écrire dans leur propre répertoire d’installation nécessitent donc un lien symbolique ou l’ajout, lors du build, d’une directive systemd BindPaths=. Et /etc fait l’objet d’une fusion à trois sources lors des mises à jour. Un fichier que vous n’avez jamais modifié reçoit la nouvelle version de l’image, tandis qu’un fichier que vous avez modifié localement est conservé.

Lorsque vous avez besoin d’un outil sur un serveur en production pour une seule session de débogage :

sudo bootc usr-overlay
sudo dnf -y install strace

Cette commande ajoute une surcouche modifiable temporaire sur /usr. Elle est supprimée au prochain redémarrage. Elle sert à analyser un problème, pas à le corriger. Vous ne pouvez pas modifier le kernel de cette manière. Tout ce que vous installez disparaît au redémarrage, comme prévu.

Fedora CoreOS : provisionné une fois, mis à jour pour toujours

Fedora CoreOS n’a pas d’installateur interactif. Vous écrivez un fichier YAML Butane, vous le transpilez en JSON Ignition, puis vous le transmettez à la machine lors de son premier démarrage :

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

Ignition s’exécute dans l’initramfs uniquement lors du premier démarrage. C’est la principale différence pour les utilisateurs venant de cloud-init. Si la configuration ne contient aucune clé SSH, vous ne pouvez pas accéder à la machine. Il faut alors la provisionner de nouveau depuis zéro. Testez la configuration sur une machine temporaire avant de l’utiliser sur un serveur important.

Installation sur un disque depuis un environnement live :

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

Les mises à jour sont automatiques par défaut. Vous contrôlez leur moment, pas leur exécution. Déposez un fichier TOML dans /etc/zincati/config.d/55-updates-strategy.toml pour sélectionner la stratégie périodique :

[updates]
strategy = "periodic"

Avec cette stratégie, vous ajoutez une fenêtre de maintenance par entrée de tableau de tables. Chaque fenêtre commence par le nom updates.periodic.window, écrit entre doubles crochets, comme en-tête, puis par trois clés :

• days, une liste de jours, par exemple "Sat" et "Sun".
• start_time, l’heure d’ouverture de la fenêtre, écrite au format "22:30".
• length_minutes, sa durée, par exemple 60.

Ces horaires sont exprimés en UTC. Pour désactiver complètement les mises à jour, exécutez sudo systemctl disable --now zincati.service, en sachant que vous devez alors gérer vous-même le calendrier d’application des correctifs.

La superposition de paquets constitue une solution de dernier recours :

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

Cette commande crée un nouveau déploiement avec le paquet ajouté. La modification ne prend effet qu’après le redémarrage. Le coût apparaît plus tard. Votre ensemble de paquets superposés est réappliqué par-dessus chaque nouvelle image de base. Ainsi, si un paquet a disparu du dépôt le jour d’une mise à jour, celle-ci échoue. La documentation Fedora recommande d’utiliser des conteneurs pour les besoins importants, et une image bootc lorsque vous devez réellement modifier le système d’exploitation.

Flatcar Container Linux : aucun gestionnaire de paquets

Flatcar est la continuation de CoreOS Container Linux et l’option la plus stricte parmi les distributions généralistes. Il n’y a aucun gestionnaire de paquets disponible en secours. Tout ce que vous exécutez est un conteneur. Le provisioning se fait avec Ignition, comme avec Fedora CoreOS. Les mises à jour utilisent les deux partitions A/B /usr décrites plus haut. Elles sont pilotées par update_engine, tandis que locksmithd détermine le moment du redémarrage.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT signifie que le slot passif contient déjà la nouvelle image et que seul le redémarrage reste à effectuer. La stratégie de redémarrage par défaut est reboot, avec un délai de cinq minutes. Un VPS de production unique redémarre donc selon sa propre planification, sauf indication contraire de votre part. Définissez une fenêtre dans /etc/flatcar/update.conf :

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

REBOOT_STRATEGY=off vous laisse effectuer le redémarrage vous-même. SERVER=disabled dans le même fichier désactive complètement la vérification des mises à jour. Dans un cluster, REBOOT_STRATEGY=etcd-lock combiné à locksmithctl set-max 4 limite le nombre de nœuds pouvant redémarrer simultanément. Une mise à jour ne peut ainsi jamais mettre toute la flotte hors service en même temps.

Talos Linux : pas de shell, pas de SSH, pas de console

Talos est le plus spécialisé des quatre et définit le plus clairement son objectif. Il exécute les nœuds Kubernetes. Il n’y a ni daemon SSH, ni shell, ni connexion à la console. Chaque opération est un appel d’API gRPC effectué avec talosctl depuis votre poste de travail, à partir d’une configuration machine conservée dans git.

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

Remplacez la balise par la release vers laquelle vous migrez. La mise à niveau utilise un schéma A-B qui conserve le kernel et l’image du système d’exploitation précédents. Ainsi, si la nouvelle version ne démarre pas, Talos revient automatiquement à la version précédente, sans intervention. Le dépannage est différent, car il n’y a pas de shell : vous utilisez talosctl logs et talosctl dmesg au lieu de journalctl directement sur la machine.

Si votre charge de travail n’est pas Kubernetes, Talos n’est pas adapté. Si elle l’est, Talos supprime toute une catégorie d’incidents, car le scénario « quelqu’un s’est connecté à un nœud et a modifié quelque chose » ne peut pas se produire.

Ce que le locataire d’un VPS abandonne réellement

Les installations ponctuelles sur un système en fonctionnement. C’est le point principal. sudo apt install htop à 2 h du matin pendant un incident n’est pas disponible. Avec bootc, vous obtenez un overlay temporaire qui disparaît au redémarrage. Avec Fedora CoreOS, vous obtenez un déploiement avec couches qui nécessite un redémarrage. Avec Flatcar et Talos, vous n’obtenez rien.

Un pipeline de build que vous n’aviez pas auparavant. Ajouter un package implique de modifier un Containerfile, de builder l’image, de la pousser vers un registry, puis de redémarrer progressivement les serveurs. C’est simple lorsque le pipeline existe. Sa mise en place demande un vrai travail lorsqu’il n’existe pas. Elle nécessite aussi un registry accessible depuis les serveurs, ce qui ajoute un autre service à exploiter ou une autre facture à payer.

Les modules du kernel. Le kernel provient de l’image. Un module compilé pour le kernel en cours d’exécution ne résiste donc pas à la mise à jour suivante. Les modules externes et les packages DKMS (dynamic kernel module support) doivent être intégrés à l’image, pour le kernel de cette image. Tout ce qui nécessite un module absent de l’image de base devient un problème de build plutôt qu’un problème d’installation.

Les agents des fournisseurs et des prestataires. Les agents de supervision et de sauvegarde sont généralement livrés sous la forme d’un .deb ou d’un .rpm avec un script d’installation qui écrit dans /usr et active une unité. Sur un système en lecture seule, ce script échoue. Certains fournisseurs publient un conteneur ou documentent une installation en image mode. Beaucoup ne le font pas. Vérifiez ce point avant de vous engager, car un parc que vous ne pouvez pas superviser est pire qu’un parc qui dérive.

L’image elle-même. Presque aucun panneau de contrôle VPS ne propose Fedora CoreOS, Flatcar ou Talos aux côtés d’Ubuntu et de Debian. Vous fournissez le disque. C’est l’objet de la section suivante.

Installer l’un de ces systèmes sur un VPS que vous louez

Vérifiez d’abord deux points auprès de votre fournisseur : vous devez disposer d’un accès à une console hors bande, c’est-à-dire VNC ou une console série, et pouvoir démarrer un système de secours. Sans console, une machine qui ne redémarre pas devient un ticket auprès du support au lieu d’un correctif de cinq minutes.

Si le fournisseur accepte les images personnalisées, envoyez l’image raw ou qcow2 du fournisseur et le tour est joué. Sinon, écrivez vous-même le disque depuis le système de secours. Flatcar fournit un script autonome prévu exactement pour cela, et il s’exécute depuis n’importe quel système Linux :

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

Exécutez-le depuis le système de secours, jamais depuis le serveur que vous remplacez, car le script repartitionne le périphérique cible pendant son exécution. Il lui faut au moins 8 GB d’espace utilisable sur le périphérique, et l’environnement de secours doit fournir bash, bzip2 ou lbzip2, lsblk, wget, udevadm, gpg et gawk. Votre ignition.json doit contenir une clé SSH, sinon le système installé ne pourra pas vous laisser vous connecter.

Fedora CoreOS suit le même principe, et son programme d’installation s’exécute dans un conteneur :

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

Vérifiez le nom du périphérique avec lsblk avant de l’exécuter. Écrire sur le mauvais périphérique détruit ce qu’il contenait, et aucune confirmation n’est demandée.

bootc propose la seule méthode qui évite le mode rescue, car il convertit sur place un système Linux en cours d’exécution :

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

Lisez la documentation de l’image de base utilisée avant de l’exécuter, et testez-la sur un serveur que vous pouvez supprimer. Après le redémarrage, la machine exécute l’image et l’ensemble de paquets que vous aviez installé a disparu.

Qui devrait utiliser un serveur immuable, et qui devrait s’en abstenir

Choisissez cette approche si vos serveurs sont du bétail. Plusieurs machines déployées à partir de la même recette. Des runners de CI (intégration continue) qui ne vivent qu’une heure. Des nœuds k3s ou Kubernetes qui sont remplacés plutôt que réparés. Plus généralement, si la réponse à une machine défaillante est déjà « supprimez-la et créez-en une autre ». Cette approche est aussi utile lorsque vous devez prouver à un auditeur ce qui s’exécute sur une machine, car la réponse est un digest d’image plutôt qu’une liste de paquets.

N’utilisez pas cette approche si vous avez un seul VPS entretenu manuellement, avec trois services, que vous installez au fur et à mesure de vos besoins et que vous n’avez aucun pipeline de build. Le mode image ne supprime pas le travail. Il déplace ce travail du serveur vers le build, et vous impose un registry ainsi qu’un pipeline. Si vous disposez de l’infrastructure nécessaire, vous obtenez des serveurs identiques et un rollback qui se résume à un redémarrage. Dans le cas contraire, vous ajoutez des composants à une machine qui fonctionnait correctement et vous rendez les interventions à 2am plus difficiles.

Le compromis moins sophistiqué reste efficace : une distribution standard avec des mises à jour de sécurité automatiques, ainsi qu’une reconstruction que vous avez réellement testée. Le choix de cette base est une décision distincte, traitée dans choisir le système d’exploitation à utiliser sur votre VPS. Le mode image n’est que l’épisode le plus récent d’un très vieux débat sur la manière dont les logiciels doivent parvenir sur une machine, et l’histoire des distributions Linux est en grande partie la répétition de ce débat.

FAQ

Une distribution Linux immutable est-elle vraiment immutable ?

Non, et ce nom prête à confusion. root peut toujours écrire sur le disque. En pratique, /usr est monté en lecture seule au runtime, puis entièrement remplacé par l’image suivante, tandis que /etc et /var restent accessibles en écriture et persistent lors des mises à jour. Les modifications effectuées sous /usr sont soit refusées immédiatement, soit supprimées lors de la mise à jour suivante. En pratique, les répertoires système ne changent donc que lorsque l’image change.

Puis-je exécuter Fedora CoreOS ou Flatcar sur un VPS qui ne les propose pas ?

En général, oui, si le fournisseur vous donne accès à un système de secours et à une console. Démarrez sur le système de secours, écrivez l’image disque de la distribution sur le périphérique bloc, puis redémarrez. Le script flatcar-install de Flatcar effectue cette opération depuis n’importe quel système Linux, et Fedora CoreOS fournit coreos-installer sous forme de conteneur, que vous pouvez exécuter de la même manière. Les deux nécessitent un fichier Ignition contenant votre clé SSH, car aucune invite de mot de passe n’est proposée au premier démarrage. Sans accès à la console, n’essayez pas : si la machine ne redémarre pas correctement, vous ne pourrez rien examiner.

Comment installer un paquet sur un serveur immutable ?

Ajoutez-le à l’image, puis redéployez-la. Avec bootc, ajoutez une ligne RUN dnf -y install ... dans le Containerfile, effectuez un rebuild et un push, puis exécutez sudo bootc upgrade --apply sur la machine. Sur Fedora CoreOS, vous pouvez utiliser sudo rpm-ostree install pour ajouter le paquet à l’image et redémarrer, au prix de sa réinstallation lors de chaque mise à jour ultérieure. Flatcar et Talos n’ont pas de gestionnaire de paquets. La solution consiste donc à utiliser un conteneur. Pour un outil de débogage ponctuel sur un hôte bootc, sudo bootc usr-overlay fournit un /usr accessible en écriture, qui disparaît au redémarrage suivant.

Le mode image corrige-t-il un VPS qui ne démarre plus après une mise à jour du kernel ?

Il transforme la récupération depuis la console de secours en simple redémarrage. L’image précédente, avec son kernel et son userspace, se trouve toujours sur le disque. sudo bootc rollback ou sudo rpm-ostree rollback -r vous permet donc de revenir à cette image. Talos et Flatcar vont plus loin : ils effectuent automatiquement un rollback si le nouvel emplacement ne démarre pas, car une entrée de démarrage ne devient l’entrée par défaut qu’après un démarrage réussi. Rien de tout cela n’empêche une mise à jour défectueuse. Cela permet simplement de l’annuler facilement.

Quelle distribution immutable choisir pour un serveur ?

Choisissez bootc si vous voulez un serveur Linux généraliste que vous construisez comme une image de conteneur et que vous pouvez installer sur une machine existante. Choisissez Fedora CoreOS si vous voulez ce modèle avec une image construite pour vous et des mises à jour automatiques activées par défaut. Choisissez Flatcar si vous voulez un hôte de conteneurs minimal, avec un schéma de mise à jour A/B et sans gestionnaire de paquets utilisable. Choisissez Talos uniquement si la machine est un nœud Kubernetes, car il n’a pas de shell et n’exécute rien d’autre.