Bootc : Linux image-based, l'OS qui se déploie comme un conteneur

Le système d'exploitation Linux server se construit toujours majoritairement par paquets et package manager. On installe Debian, on apt update, on assemble la stack avec mille petits ajustements. Un peu d'Ansible pour systématiser, mais le runtime drift reste : deux serveurs censés identiques divergent en six mois.

L'approche image-based renverse le modèle. L'OS n'est plus un état mutable, c'est une image immuable construite par un Containerfile, déployée comme on déploie un conteneur. Mises à jour atomiques, rollback A/B garanti, runtime impossible à modifier hors de l'image.

Bootc est le projet qui finalise cette vision pour Fedora, CentOS Stream et RHEL. Démarré par Red Hat, gradué stable en 2025, Bootc unifie le format conteneur OCI et le système opérationnel. Pour des opérateurs qui en ont assez du drift et veulent traiter leurs serveurs comme des Pods, c'est le moment d'y regarder.

• Le problème : drift et configuration mutable
• Le concept image-based : OSTree, A/B updates
• Bootc : OS bootable depuis un Containerfile
• Bootc vs Talos, MicroOS, CoreOS, Flatcar
• Build d'un OS Bootc personnalisé
• Déploiement et rollback en pratique
• Cas d'usage où c'est rentable
• Limites et signaux d'alerte

Trois pathologies récurrentes que l'image-based résout.

Drift permanent. Sur 50 serveurs Debian 12 censés identiques, six mois plus tard, hash de /etc/ divergent partout. Patches manqués, hotfixes locaux, paquets oubliés. L'audit conformité devient un cauchemar.

Mises à jour à risque. Un apt full-upgrade qui touche 200 paquets est une opération avec quelques pourcents de risque de casser quelque chose. Sans rollback automatique, l'incident est manuel et stressant.

Reproductibilité illusoire. Reconstruire à l'identique un serveur Debian deux ans après son install est presque impossible : versions des paquets divergent, repos archivés, dépendances cassées.

L'image-based traite ces trois problèmes :

• Le système est immuable au runtime. /usr est readonly. Pas de drift.
• Les updates sont atomiques A/B. Échec = rollback automatique.
• L'image est un artefact versionné. On peut redéployer la même image dix ans après.

OSTree est le moteur. Stocke deux versions du système (A et B) sur le disque. Au boot, sélectionne l'une ou l'autre. À l'update, télécharge la nouvelle image dans la slot inactive. Reboot. Si le nouveau boot fonctionne (signal applicatif), l'image est validée. Sinon rollback automatique au boot suivant.

Modèle A/B éprouvé : Android, Chromebook, ESXi font ça depuis des années. Dans le monde Linux server, OSTree porte ce modèle.

Le format de l'image OSTree compresse bien : déduplication par contenu (comme Git), incréments compressés. Pousser une nouvelle version d'OS sur 1000 serveurs ne télécharge que les diffs.

Bootc ajoute la couche : l'image OSTree est un conteneur OCI. On la build avec podman build ou buildah à partir d'un Containerfile. On la push dans n'importe quel registre OCI. Les serveurs la pullent comme on pull une image conteneur.

Containerfile typique pour un OS Bootc :

FROM quay.io/fedora/fedora-bootc:40

RUN dnf install -y \
    nginx \
    chrony \
    fail2ban \
    podman \
  && dnf clean all

COPY etc/ /etc/

RUN systemctl enable nginx chrony fail2ban

Build et push :

podman build -t registry.exemple.fr/os/edge-node:1.0 .
podman push registry.exemple.fr/os/edge-node:1.0

Sur un serveur qui tourne déjà sur Fedora Bootc :

sudo bootc switch registry.exemple.fr/os/edge-node:1.0
sudo systemctl reboot

Au reboot, le serveur démarre sur la nouvelle image. Si le boot échoue, rollback automatique à l'image précédente.

Le pipeline qui produit ces images est le même que pour packer-ansible-golden-images ou pour les images Docker. CI build, scan vulnérabilités, signature avec Cosign, push dans le registre.

Talos Linux est l'OS purement K8s, immutable, sans shell. Le plus radical.

CoreOS et Flatcar sont anciens dans le segment, fortement K8s-centric.

MicroOS (openSUSE) est plus proche de Bootc en philosophie, mais avec btrfs snapshots au lieu d'OSTree, et sans le format OCI universel.

Bootc se distingue par : OS généraliste (pas K8s only), workflow Containerfile familier, intégration registres OCI standards, support officiel Red Hat (RHEL Image Mode dispo en GA).

Pour un déploiement DC type, le Containerfile complet :

FROM quay.io/fedora/fedora-bootc:40

# Packages baseline
RUN dnf install -y \
    podman \
    chrony \
    fail2ban \
    rsyslog \
    aide \
    auditd \
    && dnf clean all

# Hardening
COPY etc/ /etc/
RUN /usr/bin/setfacl -R -m u:nobody:--x /var/log/audit

# Services activés
RUN systemctl enable chrony fail2ban auditd rsyslog

# Users via /etc/passwd packagé (read-only)
RUN echo "ops:x:1000:1000::/home/ops:/bin/bash" >> /etc/passwd

# Pas de mot de passe : SSH par cert YubiKey FIDO2
COPY ssh_ca.pub /etc/ssh/ssh_ca.pub
RUN printf "TrustedUserCAKeys /etc/ssh/ssh_ca.pub\n" > /etc/ssh/sshd_config.d/ca.conf

Ce Containerfile produit une image Bootc qui :

• A les paquets baseline (NTP, fail2ban, audit).
• Est durcie avec audit, AIDE, SELinux.
• Accepte des utilisateurs uniquement par certificat SSH (step-ca SSH ou openssh-ca).
• Pas de mot de passe local, pas de sudo éditable.

À pousser dans le registre, à déployer sur les serveurs cibles. Le runtime est verrouillé par construction.

Cycle nominal :

# Sur un serveur Bootc
sudo bootc status
# Affiche : booted=image:1.0, deployed=image:1.0, rollback=image:0.9

sudo bootc switch registry.exemple.fr/os/edge-node:1.1
# Télécharge image 1.1 dans la slot inactive

sudo systemctl reboot
# Reboot, démarre sur 1.1

# Si tout va bien : 1.1 devient booted, 1.0 passe en rollback

sudo bootc rollback
# En cas de problème : reboot sur l'image précédente

Pour automatiser sur un parc, programmer bootc upgrade sur cron, avec validation applicative post-reboot. Si applicatif KO sous 5 minutes, rollback. C'est exactement le modèle de Talos Linux appliqué à n'importe quel serveur.

Logs et monitoring : journalctl reste dispo, l'image n'est immuable que pour /usr. /var et /etc sont mutables avec persistance entre boots.

Edge computing. 100+ noeuds en bord de site (industriels, agences, kiosques). Les mises à jour atomic + rollback éliminent les déplacements physiques pour réparer un serveur cassé après update.

Cluster K8s baremetal. Les noeuds K8s n'ont pas besoin de package manager runtime. Image-based simplifie l'opération.

Serveurs SHPV / hébergeur avec déploiement standardisé. Au lieu de provisionner par Ansible, on déploie une image Bootc définie en Containerfile, partageable entre 100 serveurs.

Conformité stricte. PCI-DSS, HDS, ISO 27001 demandent traçabilité de la conf serveur. Une image Bootc est versionnée, signée, scannée. Auditeur heureux.

CI/CD pour l'infra. Les CI/CD existants pour les images conteneurs (build, scan, signature, push) s'appliquent directement aux OS Bootc.

Pas pour : serveurs avec besoins très spécifiques (drivers exotiques, kernel patché custom), équipes sans expérience conteneurs, environnements legacy avec contrats de support couplés à des distributions classiques.

Maturité Fedora vs RHEL. Fedora Bootc évolue vite. RHEL Image Mode est stable mais plus conservateur sur les mises à jour. Choisir selon l'appétence pour la nouveauté vs la stabilité longue.

Persistance des données. /var est mutable, mais une mauvaise compréhension du modèle peut conduire à mettre des fichiers dans /usr qui seront perdus. Discipline obligatoire.

Customisations complexes. Pour une stack très spécifique avec des modifs profondes, le Containerfile devient long. Contrairement à un Ansible Playbook structuré, le Dockerfile/Containerfile reste linéaire.

Pas de live patch. Toute mise à jour passe par reboot. Pas de kpatch style live kernel patching. Si on a besoin de zero-downtime kernel updates, repenser l'architecture (HA proper).

Distribution support. Bootc est solidement Red Hat / Fedora-centric. Debian Bookworm et Ubuntu n'ont pas d'équivalent natif au niveau de maturité 2026. SUSE va sa propre voie avec MicroOS.

Outillage encore jeune. Bootc est utilisable en prod mais l'écosystème (monitoring spécifique, intégrations CI/CD officielles) se construit encore. Compter une courbe d'apprentissage de quelques semaines pour une équipe qui maîtrise déjà conteneurs et Linux.

Bootc tient ses promesses : drift mort, rollbacks fluides, conformité simplifiée. La courbe d'adoption initiale est réelle, le temps de basculer du modèle "Ansible runtime" au modèle "image immuable". Pour remplacer un parc géré par configuration management classique, la migration se mène par étapes, avec runbook et bascule progressive, et peut se confier à une équipe d'exploitation si le modèle image est encore neuf pour vos équipes.

• Bootc documentation officielle : référence install, config, ops.
• GitHub containers/bootc : code source.
• Red Hat Image Mode for RHEL : positionnement enterprise.
• Fedora bootc community : roadmap et discussions.
• OSTree project documentation : moteur sous-jacent A/B updates.
• LWN - bootc and the future of fedora : analyse technique externe.