Un servizio self-hosted che non viene mai aggiornato accumula vulnerabilità; uno aggiornato alla cieca prima o poi si rompe. Tra questi due estremi c'è un metodo semplice, che chiede pochi minuti alla settimana e riduce quasi a zero le brutte sorprese del sabato mattina. Lo descrivo così come lo applico, con gli strumenti più diffusi nel mondo dei container.
Perché «latest» è una cattiva idea
Molti file di composizione d'esempio usano il tag latest. Sembra comodo, ma significa che ogni volta che si scarica l'immagine si può ottenere una versione molto diversa da quella di ieri, compresi cambiamenti incompatibili. Peggio ancora, se qualcosa si rompe non si sa con certezza da quale versione si è partiti.
La soluzione è fissare la versione in modo esplicito:
services:
app:
image: esempio/app:2.4.1
Così l'aggiornamento diventa una decisione consapevole: si cambia il numero, si legge cosa cambia, si applica. Alcuni progetti offrono anche tag intermedi (per esempio 2.4 o 2) che ricevono solo correzioni o solo versioni compatibili; possono essere un buon compromesso, purché si sappia cosa promette il progetto.
Leggere le note di rilascio
Prima di cambiare versione, leggo le note di rilascio di tutte le versioni intermedie, non solo dell'ultima. Le informazioni che cerco sono sempre le stesse:
- Breaking changes: variabili rinominate, cartelle spostate, opzioni rimosse.
- Migrazioni del database: se l'aggiornamento modifica lo schema, il ritorno alla versione precedente può non essere possibile.
- Passaggi obbligati: alcuni progetti non permettono di saltare versioni principali. Nextcloud, per esempio, va aggiornato una versione principale alla volta.
- Dipendenze: a volte cambia la versione richiesta del database o di un servizio collegato.
Se le note segnalano interventi manuali, li annoto e li eseguo in ordine. Se non sono chiare, aspetto qualche giorno: spesso le segnalazioni degli altri utenti chiariscono eventuali problemi.
Il backup prima di ogni salto
Un aggiornamento che modifica il database è l'unico momento in cui un backup recente diventa davvero indispensabile. La procedura che seguo:
- Fermo il servizio, così il database non sta scrivendo.
- Copio la cartella dei dati o esporto un dump del database.
- Annoto la versione attuale dell'immagine.
- Cambio la versione nel file di composizione e riavvio.
- Controllo i log e provo le funzioni principali.
Se qualcosa va storto, torno indietro ripristinando i dati e la versione annotata. È questo il motivo per cui conviene fermare il servizio prima della copia: tornare alla versione vecchia con un database già migrato dalla nuova di solito non funziona.
I database hanno regole proprie
Il servizio applicativo e il suo database vanno trattati in modo diverso. Aggiornare l'applicazione è frequente; aggiornare la versione principale di PostgreSQL, invece, richiede un'esportazione e un'importazione dei dati oppure uno strumento di migrazione dedicato, perché i file su disco non sono compatibili tra versioni principali. Per questo, quando un progetto lo consente, lascio il database sulla versione indicata nella documentazione e lo aggiorno solo quando il progetto lo richiede.
Farsi avvisare invece di controllare a mano
Controllare a mano decine di progetti è noioso e si finisce per smettere. Meglio affidarsi a strumenti che segnalano quando esce una nuova versione:
| Approccio | Cosa fa | Quando usarlo |
|---|---|---|
| Notifica (es. Diun) | Avvisa quando un'immagine ha una nuova versione | Servizi importanti, aggiornati a mano |
| Aggiornamento automatico | Scarica e riavvia da solo | Servizi poco critici e senza database |
| Abbonamento ai rilasci | Avvisi dal repository del progetto | Progetti giovani o con molti cambiamenti |
| Proposte automatiche (es. Renovate) | Propone modifiche ai file di composizione in un repository | Chi tiene la configurazione sotto Git |
Personalmente accetto l'aggiornamento automatico solo per servizi senza dati preziosi; per tutto il resto preferisco una notifica e qualche minuto di lettura.
Un ritmo sostenibile
Il metodo funziona se diventa un'abitudine. Un ritmo realistico per una casa:
- Ogni settimana: aggiornamenti del sistema operativo dell'host e delle correzioni di sicurezza.
- Ogni due settimane o al mese: revisione delle notifiche e aggiornamento dei servizi applicativi.
- Subito: quando un progetto segnala una vulnerabilità grave, soprattutto se il servizio è raggiungibile da fuori.
Tenere un piccolo registro (data, servizio, versione di partenza e di arrivo, eventuali problemi) aiuta a ricostruire cosa è successo se un difetto emerge settimane dopo.
In sintesi
- Fissare le versioni trasforma ogni aggiornamento in una scelta consapevole.
- Le note di rilascio vanno lette per tutte le versioni intermedie.
- Prima di un aggiornamento che tocca il database: servizio fermo e backup.
- Le versioni principali dei database seguono regole di migrazione proprie.
- Notifiche e un ritmo regolare evitano sia l'abbandono sia gli aggiornamenti alla cieca.
