Come funzionano gli aggiornamenti e il rollback nelle distribuzioni Linux Atomic
Le distribuzioni Linux Atomic o Immutable introducono un modo diverso di gestire il sistema operativo rispetto alle distribuzioni Linux tradizionali.
Come abbiamo visto nella nostra guida introduttiva alle distribuzioni Atomic e Immutable, il sistema non viene considerato semplicemente come un insieme di pacchetti installati e aggiornati uno alla volta. La parte fondamentale del sistema operativo viene invece trattata come un’immagine o una versione coerente che può essere sostituita con una nuova versione.
Questo approccio diventa particolarmente interessante quando parliamo di aggiornamenti e rollback.
Su una distribuzione tradizionale, un aggiornamento modifica direttamente il sistema installato. Su un sistema Atomic, invece, l’aggiornamento prepara normalmente una nuova versione del sistema, lasciando quella attualmente in uso disponibile fino al riavvio.
È proprio questo meccanismo che permette di aggiornare con maggiore tranquillità e, se necessario, tornare indietro.
Un aggiornamento Atomic non modifica semplicemente il sistema che stai usando
Immaginiamo di avere un computer con una distribuzione Atomic perfettamente funzionante.
Il sistema attualmente avviato rappresenta una determinata versione del sistema operativo. Quando viene trovato un aggiornamento, il sistema può preparare una nuova deployment, cioè una nuova versione del filesystem del sistema operativo pronta per essere utilizzata.
Con tecnologie come OSTree, le diverse versioni del sistema possono essere mantenute come deployment distinti. Il contenuto principale del sistema viene trattato in maniera immutabile e le versioni condividono efficientemente i dati sottostanti, evitando di dover duplicare inutilmente tutto il filesystem.
Il concetto importante è quindi questo:
l’aggiornamento prepara il prossimo sistema, non trasforma improvvisamente quello che stai utilizzando in un sistema diverso.
Nel caso di sistemi Fedora basati su rpm-ostree, per esempio, il comando:
rpm-ostree upgradeprepara una nuova deployment e la rende quella predefinita per il successivo avvio. L’aggiornamento viene quindi applicato effettivamente al riavvio.
Questo comportamento è molto diverso da quello a cui siamo abituati con un classico:
sudo apt upgradesu una distribuzione Debian o Ubuntu tradizionale.
Non significa che su un sistema Atomic ogni aggiornamento richieda necessariamente di interrompere immediatamente il proprio lavoro. Al contrario, una delle idee alla base di questo modello è proprio quella di poter preparare il nuovo stato del sistema e applicarlo in modo controllato.
Che cosa significa realmente “deployment”
Il termine può sembrare complicato, ma il concetto è abbastanza semplice.
Possiamo immaginare il sistema come una serie di versioni:
Deployment A
↓
sistema attualmente in uso
Deployment B
↓
aggiornamento appena preparatoDopo il riavvio:
Deployment B
↓
sistema attualmente in uso
Deployment A
↓
versione precedenteLa versione precedente non viene necessariamente eliminata immediatamente.
Ed è proprio qui che entra in gioco una delle caratteristiche più interessanti delle distribuzioni Atomic: il rollback.
OSTree è progettato per gestire più deployment e per effettuare transizioni atomiche tra di essi. L’idea è che il sistema debba avviarsi nella versione precedente oppure nella nuova versione, evitando di lasciare il sistema operativo in uno stato intermedio causato da un aggiornamento interrotto.
Prima di aggiornare possiamo controllare lo stato del sistema
Su un sistema Fedora Atomic che utilizza rpm-ostree, uno dei comandi più utili è:
rpm-ostree statusQuesto comando mostra le deployment disponibili e indica quale di esse è attualmente avviata.
È un comando che vale la pena conoscere perché permette di capire immediatamente quale versione del sistema stiamo utilizzando e quale altra versione è disponibile per il boot. La documentazione di rpm-ostree indica infatti status come uno dei comandi fondamentali per amministrare questi sistemi.
In una situazione reale potremmo quindi partire da “rpm-ostree status”, controllare lo stato corrente e successivamente verificare la disponibilità di aggiornamenti.
Il comando:
rpm-ostree upgradeprepara quindi la nuova deployment.
A questo punto il sistema continua normalmente a funzionare con la versione attuale. Per applicare il nuovo stato sarà necessario riavviare:
systemctl rebootoppure utilizzare il normale comando di riavvio dell’ambiente desktop.
Dopo il riavvio possiamo nuovamente controllare con il comando “rpm-ostree status” e verificare quale deployment è stata avviata.
E se dopo l’aggiornamento qualcosa non funziona?
È qui che il modello Atomic diventa particolarmente interessante.
Supponiamo che il nuovo aggiornamento abbia introdotto un problema. Potrebbe trattarsi di un driver, di un componente del desktop, di un’interazione inattesa con un’applicazione o semplicemente di un comportamento che vogliamo verificare prima di continuare a utilizzare quella versione.
In una distribuzione tradizionale potremmo dover individuare i pacchetti coinvolti e cercare di correggere manualmente la situazione.
In un sistema Atomic possiamo invece utilizzare la deployment precedente.
Su un sistema basato su rpm-ostree il comando è:
rpm-ostree rollbackIl comando cambia la deployment predefinita, impostando come successiva versione da avviare quella precedente. Sarà poi necessario riavviare il sistema per utilizzarla.
Il flusso diventa quindi molto semplice:
Aggiornamento
↓
Nuova deployment
↓
Riavvio
↓
Qualcosa non funziona
↓
rpm-ostree rollback
↓
Riavvio
↓
Versione precedenteNon stiamo reinstallando Linux e non stiamo cercando di ricostruire manualmente il sistema.
Stiamo semplicemente dicendo al sistema di tornare a utilizzare una deployment precedente.
Il rollback non è un backup
Questo è un punto molto importante.
Rollback e backup non sono la stessa cosa.
Il rollback riguarda principalmente la versione del sistema operativo. I dati personali, i documenti, le configurazioni e i dati delle applicazioni seguono invece le regole previste dalla specifica distribuzione e dalla posizione in cui sono memorizzati.
OSTree, ad esempio, considera separatamente componenti come /usr, /etc e /var; /var contiene lo stato persistente del sistema e non viene semplicemente sostituito come il contenuto immutabile del sistema operativo.
Per questo motivo non dobbiamo pensare:
“Ho il rollback, quindi non ho bisogno dei backup.”
È un errore.
Il rollback è una rete di sicurezza per gli aggiornamenti del sistema.
Un backup serve invece a proteggere i dati da cancellazioni accidentali, guasti hardware, corruzione, errori dell’utente o altri eventi.
Sono due strumenti diversi e complementari.
Perché questo approccio rende gli aggiornamenti più tranquilli?
Il vantaggio principale non è semplicemente la possibilità di tornare indietro.
È il fatto che la nuova versione viene preparata separatamente da quella attualmente in uso.
Il modello di OSTree è progettato proprio per effettuare transizioni atomiche tra sistemi avviabili. Se durante la preparazione dell’aggiornamento qualcosa va storto, l’obiettivo è mantenere disponibile la deployment precedente anziché lasciare il sistema in uno stato parzialmente aggiornato.
Questo cambia anche il modo in cui possiamo affrontare mentalmente gli aggiornamenti.
Su una distribuzione tradizionale possiamo avere una situazione concettualmente simile a:
Sistema attuale
↓
aggiornamento dei pacchetti
↓
modifica del sistemaCon un modello Atomic possiamo invece pensare:
Sistema attuale
│
├── continua a funzionare
│
└── prepara nuova versione
↓
nuova deployment
↓
reboot
↓
nuova versione attivaLa differenza è sottile ma fondamentale.
Cosa succede alle personalizzazioni?
Questo non significa che una distribuzione Atomic sia completamente “congelata”.
Le tecnologie utilizzate dalle diverse distribuzioni permettono di gestire applicazioni, pacchetti aggiuntivi e personalizzazioni secondo modalità differenti.
Nel caso di rpm-ostree, per esempio, esiste il package layering, che consente di aggiungere determinati pacchetti al sistema base creando una nuova configurazione del sistema. Anche queste operazioni vengono integrate nel modello delle deployment.
Questo è uno dei motivi per cui è importante non pensare alle distribuzioni Immutable come a sistemi nei quali “non si può modificare nulla”.
Il concetto corretto è piuttosto:
il sistema base viene gestito in modo controllato e versionato, mentre applicazioni e personalizzazioni vengono gestite attraverso meccanismi compatibili con questo modello.
È un cambio di paradigma, non una semplice limitazione.
Non tutte le Atomic sono identiche
C’è però una precisazione importante.
“Atomic” e “Immutable” descrivono un modello generale, non un unico sistema operativo con gli stessi comandi ovunque.
Fedora Silverblue e le altre Fedora Atomic Desktops possono utilizzare rpm-ostree, mentre altri sistemi image-based possono utilizzare strumenti differenti. Anche il mondo OSTree si sta evolvendo e oggi esistono approcci basati su tecnologie come bootc, dedicate alla gestione di sistemi operativi a partire da immagini containerizzate.
Per questo non dobbiamo trasformare il comando “rpm-ostree upgrade”
in una regola universale per tutte le distribuzioni Immutable.
È un esempio concreto relativo all’ecosistema rpm-ostree.
Il principio generale, invece, rimane:
una nuova versione del sistema viene preparata, resa disponibile per il boot e, quando necessario, possiamo tornare a una versione precedente.
Un nuovo modo di pensare agli aggiornamenti
A questo punto possiamo capire meglio perché il termine “Atomic” non sia soltanto una trovata commerciale.
L’idea è trasformare l’aggiornamento del sistema operativo da una serie di modifiche effettuate direttamente sul sistema in una transizione controllata tra versioni coerenti del sistema.
Il risultato è particolarmente interessante per chi utilizza Linux come workstation, macchina di sviluppo, computer di laboratorio o sistema destinato a essere aggiornato frequentemente.
E soprattutto cambia il rapporto con il classico timore:
“E se questo aggiornamento rompe qualcosa?”
Con un sistema Atomic la risposta diventa molto più rassicurante:
“Prima vediamo la nuova versione. Se qualcosa non va, possiamo tornare alla precedente.”
Naturalmente non significa che gli aggiornamenti siano impossibili da sbagliare o che il rollback risolva ogni problema. Ma avere una deployment precedente pronta all’avvio rende l’intero processo molto più prevedibile e offre un’importante possibilità di recupero.
In sintesi
Il funzionamento può essere riassunto così:
SISTEMA ATTUALE
│
▼
rpm-ostree upgrade
│
▼
NUOVA DEPLOYMENT
│
▼
REBOOT
│
▼
NUOVO SISTEMA
│
┌──────┴──────┐
│ │
tutto OK problema
│ │
▼ ▼
continua rollback
│
▼
VERSIONE PRECEDENTEIl punto fondamentale da portare con noi è quindi semplice: una distribuzione Atomic non rende gli aggiornamenti privi di rischi, ma cambia radicalmente il modo in cui il sistema gestisce il rischio.
Ed è proprio questa filosofia che rende interessanti tecnologie come OSTree e rpm-ostree e che approfondiremo nei prossimi articoli della serie.
LICENZA E CONDIZIONI D’USO
Questo How-to è rilasciato sotto licenza Creative Commons Attribution-NonCommercial 3.0 Italy.
CONTATTI DELL’AUTORE
Marco Ciammella marco@orvietolinux.it
Orvieto Linux User Group info@orvietolinux.it
