Container: quando, se e perché serve il backup

A prima vista può sembrare che non sia necessario eseguire il backup dei container, ma a un esame più attento le operazioni di backup servono per proteggerli da eventi catastrofici e per altre eventualità meno disastrose. Ci sono infatti dei percorsi che si possono intraprendere per assicurarsi che le parti più critiche di un’infrastruttura container siano protette dalle cose peggiori che potrebbero accadere al vostro data center.

Nozioni di base sui container

I container sono un altro tipo di virtualizzazione e Docker è la piattaforma container più popolare. I container sono un ambiente specializzato in cui è possibile eseguire una particolare applicazione. Un modo di pensarli è come macchine virtuali leggere. Laddove ogni VM in un server hypervisor contiene un’intera copia di un sistema operativo, i container condividono il sistema operativo sottostante e ciascuno di essi contiene solo le librerie necessarie dall’applicazione che verrà eseguita in quel container. Di conseguenza, molti container su un singolo nodo (una macchina fisica o virtuale che esegue un sistema operativo e l’ambiente di runtime del container) occupano molte meno risorse rispetto allo stesso numero di macchine virtuali.

Un’altra differenza tra VM e container è che laddove le aziende tendono a eseguire simultaneamente molte applicazioni in una singola VM, i container sono in genere progettati per servire un singolo componente dell’applicazione che di solito esegue una singola attività come la registrazione o il monitoraggio. Se è necessario che più componenti dell’applicazione interagiscano, ognuno verrà eseguito nel proprio container e comunicherà attraverso la rete. Ciò consente il ridimensionamento individuale di ciascuna applicazione e fornisce un certo isolamento tra le applicazioni.

Laddove le macchine virtuali sono progettate per funzionare all’interno di un particolare hypervisor in esecuzione su un determinato set di hardware, i container sono molto più “portatili”, visto che sono progettati per funzionare praticamente su qualsiasi sistema Linux e possono anche funzionare su Windows se è stato installato il software appropriato. Infine, i container sono progettati per essere molto più temporanei delle macchine virtuali. Laddove una tipica VM può funzionare per mesi o addirittura anni, il 95% di tutti i container rimane operativo per meno di una settimana, secondo un recente sondaggio du Sysdig.

L’esecuzione di molti container in un ambiente di produzione richiede l’orchestrazione ed è qui che entra in gioco Kubernetes (spesso scritto K8), che raggruppa i container in pod, altri container che raggiungono un unico scopo. I container in un pod possono comunicare facilmente tra loro e possono condividere l’archiviazione montando un volume condiviso.

Container e backup

Storicamente i backup sono stati eseguiti inserendo un agente in un server di cui era necessario eseguire il backup. La virtualizzazione ha interrotto quel modello a favore di un altro modello in cui l’agente viene eseguito a livello di hypervisor ed esegue il backup delle macchine virtuali come immagini. I container non offrono nessuna di queste opzioni.

Sebbene in teoria si possa collocare un agente all’interno di un’immagine del container, questo è considerato un passaggio molto discutibile per molte ragioni e quindi nessuno lo fa. Inoltre, al momento non è possibile eseguire un agente a livello di runtime del container, che è analogo al livello dell’hypervisor. Infine, l’idea di eseguire il backup dei container sembra piuttosto estranea a molti che li usano. Pensateci; la maggior parte dei container opera (come già detto) per meno di una settimana.

Perché è necessario eseguire il backup dei container

In un certo senso, non è necessario eseguire il backup dello stato corrente di un tipico container, anche perché nella maggior parte di essi non sono memorizzati dei dati. È solo un’altra istanza in esecuzione di una determinata immagine di un container che è già stata salvata tramite un’altra operazione.

Molti sostenitori del container sottolineano che l’alta disponibilità è integrata in ogni parte dell’infrastruttura del container. Kubernetes, ad esempio, viene sempre eseguito in un cluster. I container vengono sempre “generati e uccisi” secondo necessità. Sfortunatamente, molti confondono questa elevata disponibilità con la possibilità di riprendersi da un disastro.

Chiedete a qualcuno come replicare l’intero ambiente Kubernetes e Docker se qualcosa dovesse eliminare l’intero cluster, i nodi e lo storage persistente associato. Sì, ci sono ragioni per cui è necessario eseguire il backup di Kubernetes, Docker e delle applicazioni associate. Lo è innanzitutto per riprendersi dalle catastrofi. Cosa fate se succede il peggio? In secondo luogo, lo è per replicare l’ambiente come quando si passa da un ambiente di test/sviluppo alla produzione o dalla produzione allo staging prima di un aggiornamento. E, terzo motivo, un backup è necessario per migrare più facilmente un cluster Kubernetes.

Di cosa avreste bisogno in caso di disastro?

Ci sono diverse cose che dovreste replicare per un intero ambiente in caso di disastro.

• Immagini container: un’immagine container è un file statico che contiene tutto il codice eseguibile necessario per l’esecuzione di un container. Queste immagini non cambiano; sono ciò che viene utilizzato per eseguire un determinato container. Se è necessario apportare modifiche alle librerie e al codice per un determinato container, verrà creata una nuova immagine per quel container. Le immagini devono essere protette in qualche modo, spesso usando un repository. A sua volta, tale archivio dovrebbe essere protetto dalle catastrofi.
• Storage collegato, database: i container spesso creano dati che sopravvivono alla vita del container stesso. A tale scopo, montate un volume tramite NFS e scrivete i dati su quel volume.
• Volumi persistenti: i pod di Kubernetes utilizzano sempre più spazio di archiviazione persistente. È consigliabile eseguire il backup anche di tali dati se sono preziosi per l’azienda.
• Deployment: un deployment è un concept Kubernetes di un insieme di pod che svolgono una particolare funzione. I deployment vengono archiviati come file YAML di cui è necessario eseguire il backup.
• Kubernetes etcd: il database centrale di Kubernetes è etcd e deve essere sottoposto a backup. È relativamente piccolo e Kubernetes fornisce strumenti per scaricare il suo contenuto in un file di cui è possibile eseguire il backup.
• Prometheus: Prometheus viene spesso utilizzato per monitorare K8 e Docker. È necessario eseguire anche il backup della sua configurazione.
• Risorse di Kubernetes: poiché gli sviluppatori creano risorse in K8, è necessario eseguire il backup di tali risorse con il gruppo e la versione corretti.

Per cosa non dovrebbe essere necessario il backup?

Non è necessario eseguire il backup di tutto.

1. Esecuzione di contenitori stateless: un container in esecuzione è temporaneo. È stato generato da un’immagine (di cui è necessario eseguire il backup), ma non è necessario eseguire il backup dell’istanza in esecuzione del container. Tutti i dati creati dovrebbero probabilmente essere sottoposti a backup, ma se è necessario eseguire il backup del container stesso, qualcosa non va. Se un container contiene effettivamente dati, anziché archiviarli su un volume esterno, è necessario eseguire il backup, ma ciò dovrebbe essere molto raro.
2. Pod: poiché i pod sono semplicemente gruppi di container in esecuzione, non è necessario eseguirne il backup.

Ogni entità sopra menzionata offre uno strumento nativo che può essere utilizzato per eseguire il backup di tale entità nella memoria locale o remota. Ci sono anche utility commerciali che iniziano ad arrivare sul mercato e che funzionano in vari modi. Il prossimo articolo tratterà in dettaglio questi vari metodi, incluso come usarli per ripristinare le varie parti del vostro ambiente Kubernetes e Docker.