Distributions Linux immutable pour serveur : que choisir ?

Ce qu’est une distribution Linux immutable

Une distribution Linux immutable fournit le système d’exploitation sous la forme d’une seule image. Vous remplacez donc le système au lieu de le mettre à jour sur place. Aucun apt upgrade ne réécrit les fichiers sous /usr sur une machine 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 redémarrage suivant active l’autre image. L’image précédente reste sur le disque. Pour annuler une mauvaise mise à jour, il suffit donc de redémarrer.

Le terme « immutable » est exagéré. Rien n’empêche physiquement root d’écrire sur le disque. Ces systèmes montent les répertoires 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 deux termes les plus clairs pour désigner ces modèles : package mode et image mode. Le package mode correspond à un système en fonctionnement associé à un gestionnaire de paquets qui le modifie. Le image mode correspond à une étape de build exécutée ailleurs, qui produit un artefact, et à 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 créé à la hâte un soir. Un dépôt tiers ajouté pour installer un paquet. Un fichier de configuration modifié pendant une panne, puis jamais réintégré 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 qui se comporte différemment. 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 devoir être reconstituée à partir de traces anciennes. C’est le même problème que traite une checklist de maintenance Linux classique, mais avec la discipline imposée par le système de fichiers.

Un retour arrière est un redémarrage, et c’est tout l’intérêt

Ce modèle est conçu pour le problème que nous documentons déjà : un VPS qui ne démarre plus après une mise à jour du kernel. En mode paquet, vous récupérez le système depuis la console de secours du fournisseur. Vous montez le disque, vous utilisez chroot, puis vous supprimez manuellement un paquet du kernel. Cela fonctionne parce que le bootloader conserve les anciens kernels, mais seul le kernel est versionné de cette manière. La mise à jour de glibc et les modifications de systemd incluses dans la même transaction sont déjà appliquées. Aucune commande unique ne permet de les annuler ensemble.

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

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback rétablit l’ordre du bootloader et sélectionne l’entrée de démarrage précédente, c’est-à-dire 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 le système une fois le retour arrière préparé. Pour empêcher le garbage collector de supprimer un déploiement auquel vous faites confiance :

sudo ostree admin pin 0
rpm-ostree status

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

Talos effectue cette opération avec un seul appel API depuis votre workstation :

talosctl rollback --nodes 10.20.30.40

Flatcar conserve deux partitions /usr et bascule de l’une à l’autre. Chaque slot contient une priorité et un compteur de tentatives dans la table de partitions. Ainsi, lorsqu’un slot n’arrive jamais à démarrer correctement, son nombre de tentatives s’épuise et le bootloader sélectionne l’autre slot. Vérifiez le slot utilisé et indiquez s’il a été marqué comme fonctionnel :

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

Un slot sain et en cours d’exécution affiche une ligne contenant priority=1 tries=0 successful=1. Si aucune ligne correspondante n’est affichée, le slot actuel n’a jamais été confirmé. C’est l’état dans lequel se trouve une machine entre une mise à jour et son premier démarrage réussi.

Que remplace « installer un paquet » : bootc et un Containerfile

bootc est l’outil qui a généralisé ce modèle. Il se décrit comme un outil de mise à jour transactionnelle, sur place, du système d’exploitation à partir d’images de conteneurs OCI (Open Container Initiative). Il s’agit d’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-la et envoyez-la 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 sur cette image. bootc switch registry.example.com/edge/web:next bascule la machine vers une autre image tout en conservant /etc et /var. C’est ainsi que vous déplacez un serveur d’un flux d’images à un autre sans le réinstaller.

Pour les mises à jour sans intervention, 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 à niveau sans intervention sur Ubuntu et de dnf-automatic sur Rocky et Alma. La différence concerne ce qui est déployé. Un timer en mode paquet applique les versions présentes cette nuit-là dans le dépôt. 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.

Ce Containerfile impose deux règles de build. Les données inscriptibles doivent se trouver sous /var. Les logiciels qui exigent d’écrire dans leur propre répertoire d’installation ont donc besoin d’un lien symbolique ou d’une ligne systemd BindPaths= ajoutée au moment du build. Et /etc est fusionné selon une stratégie à trois voies lors de la mise à jour. Un fichier que vous n’avez jamais modifié reçoit la nouvelle version de l’image. Un fichier que vous avez modifié localement est conservé.

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

sudo bootc usr-overlay
sudo dnf -y install strace

Cette commande ajoute une surcouche inscriptible temporaire sur /usr, qui 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, par conception.

Fedora CoreOS : provisionnement initial, mises à jour permanentes

Fedora CoreOS ne possède pas d’installateur interactif. Vous écrivez un fichier YAML Butane, vous le transpilez en JSON Ignition, puis vous le fournissez à 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 le point qui surprend les personnes venant de cloud-init. Si la configuration ne contient aucune clé SSH, vous ne pouvez pas accéder à la machine, et vous devez 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 le moment où elles s’appliquent, pas leur activation. 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, ajoutez une fenêtre de maintenance par entrée de tableau, chaque fenêtre commençant par le nom updates.periodic.window écrit entre doubles crochets, comme en-tête, puis par trois clés :

• days, une liste de noms de jours, tels que "Sat" et "Sun".
• start_time, l’heure d’ouverture de la fenêtre, écrite au format "22:30".
• length_minutes, sa durée d’ouverture, 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 devrez alors gérer vous-même le calendrier d’application des correctifs.

La superposition de paquets constitue une solution de repli :

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

Cette commande crée un nouveau déploiement avec le paquet ajouté, mais la modification ne prend effet qu’après le redémarrage. Le problème peut apparaître plus tard. Votre ensemble de paquets superposés est réappliqué par-dessus chaque nouvelle image de base. Si un paquet a disparu du dépôt le jour d’une mise à jour, celle-ci échoue. La documentation de Fedora vous 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: no package manager at all

Flatcar is the continuation of CoreOS Container Linux and the strictest of the general-purpose options. There is no package manager to fall back on. Everything you run is a container. Provisioning is Ignition, the same as Fedora CoreOS. Updates are the two A/B /usr partitions described above, driven by update_engine, with locksmithd deciding when the reboot happens.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT means the passive slot already holds the new image and only the reboot is outstanding. The default reboot strategy is reboot with a five-minute delay, so a single production VPS will restart on its own schedule unless you say otherwise. Set a window in /etc/flatcar/update.conf:

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

REBOOT_STRATEGY=off leaves the reboot to you. SERVER=disabled in the same file stops the update check completely. For a cluster, REBOOT_STRATEGY=etcd-lock combined with locksmithctl set-max 4 caps how many nodes may reboot at once, so an update never takes the whole fleet down together.

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

Talos est le plus spécialisé des quatre systèmes et celui dont l’objectif est le plus clair. Il exécute des nœuds Kubernetes. Il n’y a ni daemon SSH, ni shell, ni connexion à une console. Toutes les opérations passent par des appels à une API gRPC effectués 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 OS précédents. Si la nouvelle version ne démarre pas, Talos revient automatiquement à la version précédente, sans intervention. Le débogage 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 workload n’est pas Kubernetes, Talos n’est pas adapté. S’il l’est, Talos supprime toute une catégorie d’incidents, car il n’est pas possible qu’une personne se connecte à un nœud et y modifie quelque chose.

Ce que l’on abandonne réellement avec un VPS

Les installations ponctuelles sur un système en fonctionnement. C’est le principal point. 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 en 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 signifie modifier un Containerfile, construire l’image, la pousser vers un registry, puis déployer la nouvelle version sur les serveurs. C’est peu coûteux lorsque le pipeline existe. Le mettre en place demande un vrai travail lorsqu’il n’existe pas. Il nécessite aussi un registry accessible aux serveurs, ce qui implique de gérer un service supplémentaire ou de payer une facture supplémentaire.

Les modules du kernel. Le kernel provient de l’image. Un module compilé pour le kernel en cours d’exécution ne survit donc pas à la mise à jour suivante. Les modules externes et les packages DKMS (dynamic kernel module support) doivent être intégrés à l’image et compilés 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 éditeurs et des fournisseurs. Les agents de monitoring et de sauvegarde sont généralement distribué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 éditeurs publient un conteneur ou documentent une installation en mode image. Beaucoup ne le font pas. Vérifiez ce point avant de vous engager, car une flotte que vous ne pouvez pas monitorer est pire qu’une flotte qui dérive.

L’image elle-même. Presque aucun panneau de contrôle de 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 loué

Vérifiez d’abord deux éléments 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’une réparation de cinq minutes.

Si le fournisseur accepte les images personnalisées, envoyez l’image raw ou qcow2 du fournisseur et l’opération est terminée. Sinon, écrivez vous-même l’image sur le disque depuis le système de secours. Flatcar fournit un script autonome prévu pour cela, qui 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. Le périphérique doit disposer d’au moins 8 GB d’espace utilisable, 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 permettra pas de 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 son contenu, sans aucune demande de confirmation.

bootc propose la seule méthode qui évite le mode de secours, car il convertit directement 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 doit utiliser un serveur immuable, et qui ne le doit pas

Cette approche convient si vos serveurs sont interchangeables. Vous déployez de nombreuses machines à partir d’une même recette. C’est le cas des runners de CI (intégration continue) qui ne vivent qu’une heure, des nœuds k3s ou Kubernetes que vous remplacez au lieu de les réparer, et de tout environnement où la réponse à une machine défaillante est déjà « supprimez-la et recréez-en une ».

Cette approche est également utile si vous devez prouver à un auditeur ce qui s’exécute sur une machine. La réponse est alors un digest d’image, et non une liste de paquets.

Ne choisissez pas cette approche si vous avez un seul VPS administré manuellement, avec trois services, que vous installez au besoin et sans pipeline de build. Le mode image ne supprime pas le travail. Il le déplace du serveur vers le build, et vous impose un registry ainsi qu’un pipeline pour effectuer ce transfert.

Si vous disposez d’un emplacement pour ce travail, vous obtenez des serveurs identiques et un rollback qui se résume à un redémarrage. Sinon, vous ajoutez des composants à une machine qui fonctionnait correctement et vous rendez les interventions à 2am plus difficiles.

Le compromis classique reste valable : une distribution normale avec des mises à jour de sécurité automatiques, ainsi qu’une reconstruction que vous avez réellement testée. Le choix de cette base constitue une décision distincte, présentée dans choisir le système d’exploitation à utiliser sur votre VPS. Le mode image n’est que le dernier épisode d’un très vieux débat sur la manière d’installer les logiciels sur une machine, et l’histoire des distributions Linux reprend en grande partie ce débat à chaque génération.

FAQ

Une distribution Linux immuable est-elle vraiment immuable ?

Non, et son nom prête à confusion. root peut toujours écrire sur le disque. En pratique, /usr est monté en lecture seule à l’exécution, puis entièrement remplacé par l’image suivante, tandis que /etc et /var restent accessibles en écriture et persistent entre les 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 ?

Généralement oui, si le fournisseur fournit un système de secours et un accès à la console. Démarrez 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 la forme d’un 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 disponible au premier démarrage. Sans accès à la console, ne tentez pas cette opération : si la machine ne redémarre pas correctement, vous n’aurez aucun moyen de l’examiner.

Comment installer un paquet sur un serveur immuable ?

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 le superposer avec sudo rpm-ostree install, puis redémarrer, au prix de la réinstallation de ce paquet lors de chaque mise à jour future. Sur Flatcar et Talos, il n’y a 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 redémarre pas après une mise à jour du kernel ?

Il transforme une 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 permet donc de revenir dessus. 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 mauvaise mise à jour. Cela permet simplement de l’annuler facilement.

Quelle distribution immuable 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 construction prise en charge et des mises à jour automatiques dès l’installation. Choisissez Flatcar si vous voulez un hôte de conteneurs minimal, avec un schéma de mise à jour A/B et aucun gestionnaire de paquets disponible. Choisissez Talos uniquement si la machine est un nœud Kubernetes, car il ne fournit pas de shell et n’exécute rien d’autre.