Distribuzioni Linux immutabili per server: pro e contro

Che cos'è una distribuzione Linux immutabile

Una distribuzione Linux immutabile fornisce il sistema operativo come un'unica immagine. Per questo si sostituisce il sistema invece di applicare patch direttamente all'installazione in uso. Su un sistema attivo non vengono riscritti i file sotto /usr tramite apt upgrade. Si crea o si scarica una nuova immagine. La macchina la prepara accanto a quella in esecuzione. Al riavvio successivo cambia l'immagine attiva. L'immagine precedente resta sul disco. Per annullare un aggiornamento problematico basta riavviare.

Il termine "immutabile" è impreciso. Nulla impedisce fisicamente a root di scrivere sul disco. Questi sistemi montano le directory di sistema in sola lettura e ne affidano la gestione all'immagine. I dati persistenti risiedono in /var. La configurazione specifica della macchina 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 gestore di pacchetti che lo modifica. La modalità a immagine consiste in una fase di build eseguita altrove, che produce un artefatto, e in un server il cui unico compito è avviare l'artefatto indicato. Tutto ciò che segue deriva da questa differenza fondamentale.

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. Un make install eseguito in fretta durante una sera impegnativa. Un repository di terze parti aggiunto per installare un pacchetto. Un file di configurazione modificato durante un’interruzione del servizio e mai ripristinato nel sistema di gestione della configurazione. Questo fenomeno si chiama deriva della configurazione e spiega perché ricreare “lo stesso” server partendo dagli appunti produce spesso una macchina che si comporta in modo diverso. Gli appunti descrivono l’intento. Il disco contiene la realtà.

La modalità immagine elimina il punto in cui si accumula la deriva. /usr è di sola lettura durante l’esecuzione, quindi un’installazione manuale fallisce immediatamente oppure viene registrata come un livello che puoi elencare 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 checklist di manutenzione ordinaria di un server Linux affronta con disciplina, ma qui viene gestito dal filesystem.

Il rollback consiste in un riavvio. Questo è l'intero principio.

Il problema che questo modello è progettato per gestire è quello già documentato: un VPS che non si avvia dopo un aggiornamento del kernel. In modalità pacchetto, il ripristino avviene dalla console di emergenza del provider. Si monta il disco, si esegue chroot e si rimuove manualmente un pacchetto del kernel. Questa procedura funziona perché il bootloader conserva i kernel precedenti, ma solo il kernel viene sottoposto al 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 per annullarle insieme.

In modalità immagine, l'unità è l'intero sistema. Su un host bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback ripristina l'ordine del bootloader assegnando nuovamente la priorità alla voce di avvio precedente, cioè all'immagine in esecuzione un'ora prima, con kernel e spazio utente inclusi. Non viene scaricato né ricostruito nulla, perché la vecchia immagine è ancora sul disco.

Fedora CoreOS esegue la stessa operazione, ma con nomi diversi:

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

Prima si arresta Zincati. Zincati è l'agent che mantiene una macchina Fedora CoreOS sulla release più recente. Se resta in esecuzione, preparerà l'aggiornamento appena annullato. -r riavvia il sistema quando il rollback è stato preparato. Per impedire che una deployment considerata affidabile venga rimossa dal garbage collector:

sudo ostree admin pin 0
rpm-ostree status

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

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. Verificare quale slot è in uso e se è stato contrassegnato come valido:

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

Uno slot in esecuzione e integro stampa una riga contenente priority=1 tries=0 successful=1. L'assenza di una riga corrispondente indica che lo slot corrente non è mai stato confermato. Questo è lo stato in cui si trova una macchina tra un aggiornamento e il primo avvio completato correttamente.

Che cosa sostituisce «installare un pacchetto»: 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

Creare e pubblicare l'immagine 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

Poi, sul server:

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

bootc upgrade interroga l'origine dell'immagine e accoda la nuova immagine per il prossimo avvio. --check indica se è disponibile un aggiornamento e non modifica nulla. --apply riavvia il server usando la nuova immagine. bootc switch registry.example.com/edge/web:next imposta il server in modo che utilizzi un'immagine diversa, mantenendo /etc e /var. Questo consente di spostare un server tra diversi stream di immagini senza reinstallarlo.

Per gli aggiornamenti automatici, abilitare il timer fornito dal progetto:

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

Questa è la soluzione in modalità immagine per gli aggiornamenti automatici su Ubuntu e per dnf-automatic su Rocky e Alma. La differenza riguarda ciò che viene installato. Un timer in modalità pacchetto applica le versioni disponibili nel repository quella notte, quindi l'insieme risultante è leggermente diverso su ogni macchina. Un timer in modalità immagine applica un unico artefatto già avviato altrove.

Da questo Containerfile derivano due regole di compilazione. I dati scrivibili devono trovarsi sotto /var, quindi il software che richiede di scrivere nella propria directory di installazione deve usare un collegamento simbolico oppure una direttiva BindPaths= di systemd aggiunta in fase di compilazione. Anche /etc viene unito a tre vie durante l'aggiornamento. Di conseguenza, un file mai modificato riceve la nuova versione presente nell'immagine, mentre un file modificato localmente viene mantenuto.

Quando serve uno strumento su un server in esecuzione per una sola sessione di debug:

sudo bootc usr-overlay
sudo dnf -y install strace

Questo aggiunge un overlay scrivibile temporaneo su /usr, che viene eliminato al riavvio successivo. Serve per analizzare un problema, non per risolverlo. In questo modo non è possibile modificare il kernel e tutto ciò che viene installato scompare al riavvio, come previsto.

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 soltanto al primo avvio. Questo è il punto che spesso causa problemi a chi proviene da cloud-init. Se la configurazione non contiene una chiave SSH, la macchina si avvia senza un metodo di accesso 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 dell’array di tabelle. 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, assumendo quindi la responsabilità della pianificazione delle patch.

Il layering dei pacchetti è disponibile come soluzione alternativa:

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

Questo comando crea un nuovo deployment con il pacchetto aggiunto. La modifica diventa effettiva soltanto dopo il riavvio. Il costo si presenta in seguito. L’insieme dei pacchetti aggiunti viene riapplicato sopra ogni nuova immagine di base. Di conseguenza, se il pacchetto non è più disponibile nel repository il giorno di un aggiornamento, l’aggiornamento non va a buon fine. La documentazione ufficiale 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 gestore di pacchetti

Flatcar è il proseguimento di CoreOS Container Linux e l'opzione più rigorosa tra quelle general-purpose. Non esiste alcun gestore di pacchetti su cui ripiegare. Tutto ciò che si esegue è un container. Il provisioning usa Ignition, come in Fedora CoreOS. Gli aggiornamenti utilizzano le due partizioni A/B /usr descritte sopra, gestite da update_engine, mentre locksmithd stabilisce quando eseguire il riavvio.

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 manca soltanto il riavvio. La strategia di riavvio predefinita è reboot con un ritardo di cinque minuti, quindi un singolo VPS di produzione si riavvia secondo la pianificazione prevista, salvo diversa indicazione. Imposta 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 te il riavvio. 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, così 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 chiarisce meglio il proprio scopo. Esegue i nodi Kubernetes. Non sono disponibili un demone SSH, una shell o un accesso alla console. Ogni operazione consiste in una chiamata API gRPC eseguita con talosctl dalla workstation, utilizzando una configurazione della macchina mantenuta in git.

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

Sostituisci il tag con la release a cui stai passando. L'aggiornamento utilizza uno schema A-B che conserva il kernel e l'immagine del sistema operativo precedenti. Se il nuovo sistema non si avvia, Talos esegue automaticamente il rollback senza intervento manuale. Il debugging segue un approccio diverso perché non è disponibile una shell: usa talosctl logs e talosctl dmesg invece di journalctl direttamente sul nodo.

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 è possibile che "qualcuno acceda a un nodo e modifichi qualcosa".

Cosa cede realmente chi utilizza un VPS

Installazioni ad hoc su un sistema in esecuzione. Questo è il punto 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 a livelli 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 è contenuto. Configurarla da zero richiede invece lavoro e un registry raggiungibile dai server: si tratta di un altro servizio da gestire o di un altro costo da sostenere.

Moduli del kernel. Il kernel proviene dall'immagine, quindi un modulo compilato per il kernel in esecuzione non sopravvive al successivo aggiornamento. 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 quell'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. Verificalo prima di impegnarti, perché una flotta che non puoi monitorare è peggiore di una flotta che presenta 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.

Installare uno di questi sistemi su un VPS preso in affitto

Prima verificate due aspetti presso il provider: dovete avere accesso alla console out-of-band, tramite VNC o console seriale, e dovete poter avviare un sistema di ripristino. Senza una console, una macchina che non torna operativa richiede l'intervento del supporto invece di una correzione di cinque minuti.

Se il provider accetta immagini personalizzate, caricate l'immagine raw o qcow2 del fornitore e avete finito. In caso contrario, dovete scrivere direttamente il disco dal sistema di ripristino. Flatcar fornisce uno script autonomo specifico per questo scopo, 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 avere 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, altrimenti 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

Controllate il nome del dispositivo con lsblk prima di eseguire il comando. La scrittura sul dispositivo errato distrugge i dati presenti e non viene visualizzato alcun prompt di conferma.

bootc offre l'unico percorso che evita la modalità di ripristino, perché converte in-place 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 utilizzata 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 intercambiabili. Molte macchine create a partire dalla stessa ricetta. Runner CI (integrazione continua) che restano attivi per un’ora. Nodi k3s o Kubernetes che vengono sostituiti invece di essere riparati. In generale, quando la risposta a un server guasto è già «eliminalo e creane un altro». È utile anche quando devi dimostrare a un auditor che cosa è in esecuzione su una macchina, perché la risposta è il digest di un’immagine, non un elenco di pacchetti.

Non è adatta se hai un unico VPS gestito manualmente, con tre servizi, installi i componenti quando servono e non hai una pipeline di build. La modalità basata su immagini non elimina il lavoro. Sposta il lavoro dal server alla build e, per farlo, richiede un registry e una pipeline. Se hai un ambiente in cui eseguire questo lavoro, ottieni server identici e un rollback che consiste in un riavvio. Se non ce l’hai, aggiungi componenti a una macchina che funzionava già e rendi più complessa la gestione alle 2am.

Il compromesso tradizionale continua a funzionare: una distribuzione normale con aggiornamenti automatici di sicurezza, oltre a una procedura di ricostruzione che hai già verificato. La scelta della base è una decisione separata, descritta in scegliere quale sistema operativo usare sul VPS. La modalità basata su immagini è soltanto l’ultima fase di una discussione molto più vecchia su come distribuire il software su una macchina, e la storia delle distribuzioni Linux consiste in gran parte nella ripetizione di quella discussione.

FAQ

Una distribuzione Linux immutabile è davvero immutabile?

No, e il nome può creare confusione. root può ancora 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 è 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 mette a disposizione un sistema di rescue e l'accesso alla console. Avvia il sistema di rescue, scrivi l'immagine 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 distribuisce 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. Senza accesso alla console, non tentare l'operazione: se la macchina non torna online, non avrai modo di intervenire.

Come installo un pacchetto su un server immutabile?

Devi aggiungerlo all'immagine e ridistribuirla. Con bootc, nel Containerfile aggiungi una riga RUN dnf -y install ..., esegui una nuova build e un push, quindi esegui sudo bootc upgrade --apply sulla macchina. Su Fedora CoreOS puoi aggiungere il pacchetto con sudo rpm-ostree install e riavviare, ma il pacchetto verrà applicato nuovamente a ogni aggiornamento futuro. Su Flatcar e Talos non esiste un package manager, 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à immagine risolve il problema di un VPS che non si avvia dopo un aggiornamento del kernel?

Trasforma il ripristino da un'operazione nella console di rescue in un semplice riavvio. L'immagine precedente, con kernel e userspace, è ancora sul disco, quindi sudo bootc rollback o sudo rpm-ostree rollback -r ti riporta a quella versione. Talos e Flatcar fanno un passo ulteriore e annullano automaticamente l'aggiornamento quando il nuovo slot non si avvia, perché una voce di avvio diventa predefinita solo dopo un avvio riuscito. Nulla di tutto questo impedisce un aggiornamento problematico. Rende semplicemente rapido il ripristino della versione precedente.

Quale distribuzione immutabile dovrei scegliere per un server?

Scegli bootc se vuoi un server Linux general purpose che costruisci come un'immagine container e che puoi installare su una macchina già disponibile. Scegli Fedora CoreOS se vuoi lo stesso modello con la build gestita automaticamente e gli aggiornamenti automatici disponibili fin dall'inizio. Scegli Flatcar se vuoi un host container minimale con uno schema di aggiornamento A/B e senza un package manager da utilizzare. Scegli Talos solo quando la macchina è un nodo Kubernetes, perché non dispone di una shell e non esegue altri workload.