Distribuzioni Linux immutabili su un server: pro e contro

Che cos'è una distribuzione Linux immutabile

Una distribuzione Linux immutabile rilascia il sistema operativo come una singola immagine. Per aggiornarla, si sostituisce il sistema invece di applicare patch sul sistema in esecuzione. Non è prevista alcuna apt upgrade riscrittura dei file sotto /usr su un server in esecuzione. Si crea o si scarica una nuova immagine. Il computer la prepara accanto a quella attualmente in uso. Al riavvio successivo, cambia l'immagine attiva. L'immagine precedente resta sul disco. Per annullare un aggiornamento difettoso basta quindi riavviare.

Il termine "immutabile" è impreciso. Nulla impedisce fisicamente a root di scrivere sul disco. Questi sistemi montano le directory del sistema in sola lettura e le associano all'immagine. I dati persistenti risiedono in /var. La configurazione specifica del computer risiede in /etc. Tutto ciò che si trova sotto /usr appartiene all'immagine. Per questo, due server che eseguono lo stesso tag dell'immagine contengono file di sistema identici.

I nomi usati da Red Hat per i due modelli sono i più chiari: modalità a pacchetti e modalità a immagine. La modalità a pacchetti consiste in un sistema in esecuzione e in un package manager che lo modifica. La modalità a immagine consiste in una fase di build eseguita altrove, che produce un artifact, e in un server il cui unico compito è avviare l'artifact indicato. Tutto ciò che segue deriva da questa singola differenza.

Perché un sistema in sola lettura è più importante su un server

Un server in esecuzione da due anni conserva una cronologia che nessuno ha documentato. Una make install eseguita in fretta durante una serata di lavoro. Un repository di terze parti aggiunto per installare un pacchetto. Un file di configurazione modificato durante un’interruzione del servizio e mai ripristinato nella gestione della configurazione. Questo fenomeno si chiama deriva della configurazione ed è il motivo per cui ricostruire “lo stesso” server a partire dagli appunti produce spesso una macchina con un comportamento diverso. Gli appunti descrivono l’intento. Il disco contiene la realtà.

La modalità immagine elimina il punto in cui si accumula la deriva. /usr è in sola lettura durante l’esecuzione, quindi un’installazione manuale non riesce oppure viene registrata come un layer elencabile con un solo comando. In questo modo le differenze tra due macchine diventano visibili, invece di doverle ricostruire come reperti archeologici. È lo stesso problema che una normale checklist di manutenzione di Linux affronta con la disciplina, ma gestito dal filesystem.

Il rollback consiste in un riavvio: questo è il punto centrale

Il problema che questo modello è progettato per risolvere è quello che documentiamo già: una VPS che non si avvia dopo un aggiornamento del kernel. In modalità basata sui pacchetti, il ripristino avviene dalla console di ripristino del provider. Si monta il disco, si usa chroot e si rimuove manualmente un pacchetto del kernel. Questa procedura funziona perché il bootloader conserva i kernel precedenti, ma solo il kernel viene gestito con il versionamento in questo modo. L'aggiornamento di glibc e le modifiche a systemd incluse nella stessa transazione sono già state applicate e non esiste un singolo comando che le annulli insieme.

In modalità basata sulle immagini, l'unità di ripristino è l'intero sistema. Su un host bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback ripristina l'ordine del bootloader impostando come prima la voce di avvio precedente, cioè l'immagine in esecuzione un'ora fa, con kernel e spazio utente insieme. Non viene scaricato né ricompilato nulla, perché la vecchia immagine non ha mai lasciato il disco. Se è stato attivato il timer di aggiornamento automatico descritto più avanti, arrestarlo prima: la documentazione di bootc avverte che un agente incaricato degli aggiornamenti automatici può annullare il rollback.

Fedora CoreOS esegue la stessa operazione usando nomi diversi:

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

Arrestare prima Zincati. Zincati è l'agente che mantiene una macchina Fedora CoreOS sulla release più recente. Non reinstallerà il deployment appena ripristinato, ma continuerà a cercare aggiornamenti e passerà a qualsiasi release più recente venga resa disponibile. Eseguire quindi sudo systemctl disable --now zincati.service se la macchina deve rimanere nello stato attuale fino alla disponibilità di una correzione. -r riavvia la macchina dopo la preparazione del rollback. Per impedire che un deployment considerato affidabile venga eliminato dal garbage collector:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status elenca i deployment nell'ordine in cui il bootloader li proporrà, contrassegna quello in esecuzione con un punto e mostra Pinned: yes su quello bloccato.

Talos esegue l'operazione con una singola chiamata API dalla workstation:

talosctl rollback --nodes 10.20.30.40

Flatcar mantiene due partizioni /usr e alterna il loro utilizzo. Ogni slot contiene una priorità e un contatore dei tentativi nella tabella delle partizioni. Se uno slot non riesce mai ad avviarsi correttamente, esaurisce i tentativi disponibili e il bootloader seleziona l'altro slot. Verificare quale slot è in uso e se è stato contrassegnato come funzionante:

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

Uno slot in esecuzione e funzionante stampa una riga contenente tries=0 successful=1. Il numero di priorità sulla stessa riga stabilisce solo quale slot il bootloader preferisce, quindi può essere 1 o 2 anche su una macchina perfettamente funzionante. Se non viene trovata alcuna riga corrispondente, lo slot corrente non è mai stato confermato. Questo è lo stato di una macchina nel periodo compreso tra un aggiornamento e il primo avvio completato correttamente.

Cosa sostituisce «install a package»: bootc e un Containerfile

bootc è lo strumento che ha generalizzato questo modello. Si descrive come una soluzione per gli aggiornamenti transazionali e in-place del sistema operativo tramite immagini container OCI (Open Container Initiative) ed è un progetto CNCF Sandbox. Il server diventa un Containerfile. Ad agosto 2026, l'immagine di base Fedora è quay.io/fedora/fedora-bootc:44 e la base CentOS Stream è 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

Creala e pubblicala come qualsiasi altra immagine:

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

Quindi, sul server:

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

bootc upgrade interroga l'origine dell'immagine e accoda la nuova immagine per il boot successivo. --check verifica se è disponibile un aggiornamento senza apportare modifiche. --apply riavvia il sistema usando la nuova immagine. bootc switch registry.example.com/edge/web:next configura la macchina per usare un'immagine diversa mantenendo /etc e /var. In questo modo puoi spostare un server tra diversi stream di immagini senza reinstallarlo.

Per gli aggiornamenti automatici, abilita il timer incluso nel progetto:

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

Questa è la risposta in image mode agli aggiornamenti automatici dei pacchetti su Ubuntu e a dnf-automatic su Rocky e Alma. La differenza riguarda ciò che viene applicato. Un timer in package mode applica le versioni presenti nel repository quella notte, quindi l'insieme risultante è leggermente diverso su ogni macchina. Un timer in image mode applica un singolo artefatto che hai già avviato altrove.

Da questo Containerfile derivano due regole di build. I dati scrivibili devono trovarsi in /var. Di conseguenza, il software che richiede la scrittura nella propria directory di installazione ha bisogno di un symlink oppure di una riga BindPaths= di systemd aggiunta durante la build. Inoltre, /etc viene sottoposto a un merge a tre vie durante l'aggiornamento. Un file che non hai mai modificato riceve la nuova versione inclusa nell'immagine, mentre un file modificato localmente viene mantenuto.

Quando ti serve uno strumento su un sistema attivo per una singola sessione di debugging:

sudo bootc usr-overlay
sudo dnf -y install strace

Questo aggiunge un overlay temporaneo e scrivibile su /usr, che viene eliminato al riavvio successivo. Serve per analizzare un problema, non per risolverlo. Non puoi modificare il kernel in questo modo e tutto ciò che installi scompare al riavvio per progettazione.

Fedora CoreOS: provisioning una tantum, aggiornamenti continui

Fedora CoreOS non dispone di un installer interattivo. Si scrive un file YAML per Butane, lo si transpila in JSON per Ignition e lo si fornisce alla macchina al primo avvio:

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

Ignition viene eseguito nell'initramfs solo al primo avvio. Questo comportamento può creare problemi a chi proviene da cloud-init. Se la configurazione non contiene una chiave SSH, la macchina si avvia senza un accesso disponibile e per correggere il problema è necessario eseguire nuovamente il provisioning da zero. Testare la configurazione su una macchina usa e getta prima di applicarla a un server importante.

Installazione su un disco da un ambiente live:

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

Gli aggiornamenti sono automatici per impostazione predefinita. Si controlla quando vengono eseguiti, non se vengono eseguiti. Inserire un file TOML in /etc/zincati/config.d/55-updates-strategy.toml per selezionare la strategia periodica:

[updates]
strategy = "periodic"

Con questa strategia si aggiunge una finestra di manutenzione per ogni voce array-of-tables. Ogni finestra inizia con il nome updates.periodic.window scritto tra doppie parentesi quadre come intestazione, seguito da tre chiavi:

• days, un elenco di nomi dei giorni, ad esempio "Sat" e "Sun".
• start_time, l'ora di apertura della finestra, scritta come "22:30".
• length_minutes, la durata della finestra, ad esempio 60.

Gli orari sono espressi in UTC. Per interrompere completamente gli aggiornamenti, eseguire sudo systemctl disable --now zincati.service e accettare di dover gestire direttamente il calendario delle patch.

Il layering dei pacchetti è disponibile come soluzione alternativa:

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

Questo crea un nuovo deployment con il pacchetto aggiunto. La modifica diventa effettiva solo dopo il riavvio. Il costo si manifesta in seguito. L'insieme dei pacchetti aggiunti viene riapplicato sopra ogni nuova immagine di base. Di conseguenza, se un pacchetto scompare dal repository il giorno di un aggiornamento, l'aggiornamento non va a buon fine. La documentazione di Fedora consiglia di usare i container per tutto ciò che è sostanziale e un'immagine bootc quando è realmente necessario modificare il sistema operativo.

Flatcar Container Linux: nessun package manager

Flatcar è la continuazione di CoreOS Container Linux ed è l'opzione più restrittiva tra quelle general-purpose. Non è disponibile alcun package manager alternativo. Tutto ciò che viene eseguito è un container. Il provisioning avviene tramite Ignition, come in Fedora CoreOS. Gli aggiornamenti utilizzano le due partizioni A/B /usr descritte in precedenza e sono gestiti da update_engine; locksmithd stabilisce quando eseguire il reboot.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT indica che lo slot passivo contiene già la nuova immagine e che resta soltanto da eseguire il reboot. La strategia di reboot predefinita è reboot con un ritardo di cinque minuti. Di conseguenza, un singolo VPS di produzione si riavvia secondo la pianificazione predefinita, salvo diversa configurazione. Impostate una finestra in /etc/flatcar/update.conf:

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

REBOOT_STRATEGY=off lascia a voi il reboot. SERVER=disabled nello stesso file interrompe completamente il controllo degli aggiornamenti. In un cluster, REBOOT_STRATEGY=etcd-lock combinato con locksmithctl set-max 4 limita il numero di nodi che possono riavviarsi contemporaneamente. In questo modo, un aggiornamento non arresta mai l'intero parco di nodi nello stesso momento.

Talos Linux: nessuna shell, nessun SSH, nessuna console

Talos è il più specializzato dei quattro e definisce con maggiore chiarezza il proprio scopo. Esegue nodi Kubernetes. Non sono presenti un demone SSH, una shell di login né un accesso dalla console. La console fisica mostra un pannello per esaminare lo stato della macchina, non un prompt di login. Ogni operazione consiste in una chiamata all'API gRPC eseguita con talosctl dalla workstation, usando una configurazione della macchina conservata in git.

talosctl upgrade --nodes 10.20.30.40 \
  --image factory.talos.dev/metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v1.14.2

A partire da Talos 1.14 l'immagine ghcr.io/siderolabs/installer non viene più pubblicata; le immagini dell'installer provengono invece da Image Factory. L'ID lungo in quel percorso identifica lo schematic vuoto per una macchina senza personalizzazioni. Usa lo schematic da cui è stato installato il nodo, in modo da mantenere le relative estensioni di sistema, e sostituisci il tag con la release a cui vuoi eseguire l'aggiornamento. L'aggiornamento usa uno schema A-B che conserva il kernel e l'immagine del sistema operativo precedenti. Se la nuova versione non si avvia, Talos esegue automaticamente il rollback senza intervento. Il debugging funziona in modo diverso perché non esiste una shell di login: sulla macchina usi talosctl logs e talosctl dmesg invece di journalctl. Quando ti servono strumenti sul nodo, talosctl debug avvia un container privilegiato dall'immagine fornita e apre la relativa shell; il container viene rimosso quando esci.

Se il tuo carico di lavoro non è Kubernetes, Talos non è la scelta corretta. Se invece lo è, Talos elimina un'intera categoria di incidenti, perché non può verificarsi la situazione in cui qualcuno accede a un nodo e modifica qualcosa.

Cosa deve realmente sacrificare chi gestisce un tenant VPS

Installazioni ad hoc su un sistema in esecuzione. Questo è l'aspetto principale. sudo apt install htop alle 2am durante un incidente non è disponibile. Con bootc si ottiene un overlay temporaneo che scompare al riavvio. Con Fedora CoreOS si ottiene un deployment stratificato che richiede un riavvio. Con Flatcar e Talos non si ottiene nulla.

Una pipeline di build che prima non esisteva. Aggiungere un pacchetto significa modificare un Containerfile, creare l'immagine, inviarla a un registry e aggiornare i server. Quando la pipeline esiste già, il costo operativo è contenuto. Configurarla da zero richiede invece lavoro concreto e un registry raggiungibile dai server, cioè un altro servizio da gestire o un altro costo da sostenere.

Moduli del kernel. Il kernel proviene dall'immagine, quindi un modulo compilato per il kernel in esecuzione non sopravvive all'aggiornamento successivo. I moduli esterni all'albero del kernel e i pacchetti DKMS (dynamic kernel module support) devono essere integrati nell'immagine e compilati per il kernel di quella stessa immagine. Qualsiasi componente che richieda un modulo non incluso nell'immagine di base diventa un problema di build anziché di installazione.

Agent del fornitore e del provider. Gli agent di monitoraggio e backup vengono in genere distribuiti come .deb o .rpm con uno script di installazione che scrive in /usr e abilita una unità. Su un sistema in sola lettura, lo script non riesce. Alcuni fornitori pubblicano un container o documentano un'installazione in image mode. Molti non lo fanno. Verifica questo aspetto prima di procedere, perché una flotta che non puoi monitorare è peggiore di una flotta soggetta a configurazioni divergenti.

L'immagine stessa. Quasi nessun pannello di controllo VPS elenca Fedora CoreOS, Flatcar o Talos accanto a Ubuntu e Debian. Devi fornire tu il disco; questo è l'argomento della sezione successiva.

Installazione su un VPS noleggiato

Prima verificate due aspetti presso il provider: dovete disporre dell'accesso alla console fuori banda, tramite VNC o console seriale, e dovete poter avviare un sistema di ripristino. Senza una console, una macchina che non si riavvia diventa un ticket per l'assistenza invece di una correzione di cinque minuti.

Se il provider accetta immagini personalizzate, caricate l'immagine raw o qcow2 del fornitore. Il solo caricamento non vi fornisce però una macchina a cui possiate accedere. L'utente core di Fedora CoreOS non ha una password o una chiave SSH predefinita. Dovete quindi fornire una configurazione Ignition contenente la vostra chiave oppure, su una piattaforma cloud supportata da Afterburn, impostare una chiave tramite la funzione SSH key del provider. In alternativa, potete scrivere direttamente il disco dal sistema di ripristino. Flatcar include uno script autonomo specifico per questa operazione, eseguibile da qualsiasi sistema 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

Eseguite lo script dal sistema di ripristino, mai dal server che state sostituendo, perché durante l'esecuzione lo script ripartiziona il dispositivo di destinazione. Il dispositivo deve disporre di almeno 8 GB di spazio utilizzabile e l'ambiente di ripristino deve fornire bash, bzip2 o lbzip2, lsblk, wget, udevadm, gpg e gawk. Il file ignition.json deve contenere una chiave SSH. In caso contrario, il sistema installato non avrà alcun modo di consentirvi l'accesso.

Fedora CoreOS segue lo stesso modello e il relativo installer viene eseguito come 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

Prima di eseguire il comando, verificate il nome del dispositivo con lsblk. La scrittura sul dispositivo errato distrugge i dati presenti e non viene mostrata alcuna richiesta di conferma.

bootc offre l'unico percorso che evita la modalità di ripristino, perché converte direttamente un sistema Linux in esecuzione:

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

Prima di eseguire il comando, leggete la documentazione dell'immagine di base che state utilizzando e provatelo su un server che potete eliminare. Dopo il riavvio, la macchina eseguirà l'immagine e il set di pacchetti precedente non sarà più disponibile.

Chi dovrebbe usare un server immutabile e chi no

Questa soluzione è adatta se i server sono trattati come risorse sostituibili. Si gestiscono molte macchine a partire da una sola ricetta. È adatta anche ai runner CI (continuous integration) che restano attivi per un'ora, ai nodi k3s o Kubernetes che vengono sostituiti invece di essere riparati e, in generale, a tutti i sistemi per i quali la risposta a un guasto è già «eliminalo e creane un altro». È utile anche quando occorre dimostrare a un auditor quale software è in esecuzione su una macchina, perché la risposta è il digest di un'immagine, non un elenco di pacchetti.

Questa soluzione non è adatta se hai un solo VPS gestito manualmente, con tre servizi installati, aggiungi i componenti quando servono e non disponi di una pipeline di build. La modalità basata sulle immagini non elimina il lavoro. Sposta il lavoro dal server al processo di build e, per farlo, richiede un registry e una pipeline. Se hai un ambiente in cui gestire questo lavoro, ottieni server identici e un rollback che consiste in un riavvio. Se non lo hai, aggiungi componenti a una macchina che funzionava già e rendi più difficile la gestione alle 2am.

La soluzione intermedia, meno complessa, continua a funzionare: una distribuzione normale con aggiornamenti di sicurezza automatici e una procedura di rebuild che hai effettivamente provato. La scelta della base è una decisione distinta, descritta in come scegliere quale sistema operativo eseguire sul VPS. La modalità basata sulle immagini è soltanto l'ultimo capitolo di una discussione molto più vecchia su come distribuire il software su una macchina; la storia delle distribuzioni Linux consiste in gran parte nella ripetizione di quella stessa discussione.

FAQ

Una distribuzione Linux immutabile è davvero immutabile?

No, e il nome può creare confusione. root può comunque scrivere sul disco. In pratica, /usr viene montato in sola lettura durante l'esecuzione e sostituito interamente dall'immagine successiva, mentre /etc e /var restano scrivibili e persistono tra gli aggiornamenti. Le modifiche apportate in /usr vengono rifiutate subito oppure eliminate al successivo aggiornamento. L'effetto pratico è quindi che le directory di sistema cambiano solo quando cambia l'immagine.

Posso eseguire Fedora CoreOS o Flatcar su un VPS che non li offre?

Di solito sì, se il provider fornisce un sistema di soccorso e l'accesso alla console. Avvia il sistema di soccorso, scrivi l'immagine del disco della distribuzione sul dispositivo a blocchi, quindi riavvia. Lo script flatcar-install di Flatcar esegue questa operazione da qualsiasi sistema Linux, mentre Fedora CoreOS fornisce coreos-installer come container, che puoi eseguire nello stesso modo. Entrambi richiedono un file Ignition contenente la tua chiave SSH, perché non è disponibile una richiesta della password al primo avvio come alternativa. Senza accesso alla console, non procedere: se la macchina non torna online, non avrai modo di intervenire.

Come installo un pacchetto su un server immutabile?

Devi aggiungerlo all'immagine e distribuire nuovamente il sistema. Con bootc, aggiungi una riga RUN dnf -y install ... al Containerfile, esegui una nuova build e un push, quindi esegui sudo bootc upgrade --apply sulla macchina. Su Fedora CoreOS puoi aggiungerlo tramite sudo rpm-ostree install e riavviare, ma il pacchetto verrà applicato nuovamente a ogni aggiornamento futuro. Su Flatcar e Talos non esiste un gestore di pacchetti, quindi la soluzione è usare un container. Per uno strumento di debug temporaneo su un host bootc, sudo bootc usr-overlay fornisce un /usr scrivibile, che scompare al successivo riavvio.

La modalità image risolve il problema di un VPS che non si avvia dopo un aggiornamento del kernel?

Trasforma il ripristino da un intervento tramite console di soccorso in un riavvio. L'immagine precedente, comprensiva di kernel e userspace, è ancora presente sul disco, quindi sudo bootc rollback o sudo rpm-ostree rollback -r ripristina quella versione. Talos e Flatcar fanno un passo ulteriore e annullano automaticamente l'aggiornamento se il nuovo slot non riesce ad avviarsi, perché una voce di avvio diventa quella predefinita solo dopo un avvio completato correttamente. Nulla di tutto questo impedisce un aggiornamento difettoso. Rende semplicemente rapido il suo annullamento.

Quale distribuzione immutabile dovrei scegliere per un server?

Scegli bootc se vuoi un server Linux general purpose da creare come un'immagine container e installare su una macchina già disponibile. Scegli Fedora CoreOS se vuoi lo stesso modello, con la build gestita dal sistema e gli aggiornamenti automatici già inclusi. Scegli Flatcar se vuoi un host container minimale con uno schema di aggiornamento A/B e senza un gestore di pacchetti disponibile per installazioni occasionali. Scegli Talos solo quando la macchina è un nodo Kubernetes, perché non dispone di una shell di login e non esegue altro.