I container sono una forma di virtualizzazione del sistema operativo che negli anni ha rivoluzionato il mondo IT e del Cloud Computing, e anche noi del Team CloudFire, con il tempo, abbiamo maturato competenze e conoscenze in merito.
Questo articolo vi illustra quali sono stati i passaggi adottati in generale, e in primis da CloudFire, dagli albori fino a raggiungere l’approccio e gli strumenti utilizziamo ora in termini di container.
Un passo indietro
Per definizione un container è una unità eseguibile di software in cui viene impacchettato un determinato codice applicativo, insieme alle sue librerie e dipendenze, con modalità comuni in modo da poter essere avviato ovunque. Può essere utilizzato per eseguire qualsiasi cosa, da microservizi o processi software, ad un’applicazione più grande.
Negli anni l’utilizzo dei container e la loro distribuzione sono cambiati e, sicuramente, la loro globale approvazione ha avuto come protagonista il cambio di paradigma che ha coinvolto direttamente l’uso degli applicativi, il quale permette ora di raggiungere efficienza e velocità nella loro distribuzione.
L’ingresso della virtualizzazione ha portato ad una divisione del server fisici in vari ambienti, ognuno dei quali ha la capacità di sfruttare un sistema operativo differente. Ciò significa che, tale approccio, porta ad un beneficio già di per sé innovativo: la possibilità di ospitare più applicazioni su un unico server fisico. Tuttavia, il limite che permane in questa soluzione è che l'avvio di una nuova istanza applicativa comporta anche l'avvio di un sistema operativo completo, e di conseguenza un dispendio di tempo e risorse.
Attraverso la containerizzazione invece, diventa possibile effettuare l'esecuzione di più istanze applicative sul medesimo sistema operativo, ottimizzando così l'utilizzo delle risorse e il tempo di avvio. Per natura infatti i container rappresentano una immagine sterile e fissa che permette di essere eseguita in qualsiasi ambiente senza particolari dipendenze dal sistema operativo ospitante.
Differenze tra VM e Container
Spesso la tecnologia dei container viene confusa con quella delle macchine virtuali o di virtualizzazione dei server, e sebbene ci sia qualche somiglianza alla base, portano a risultati differenti.
- Minor impatto sulle risorse occupate:
Le macchine virtuali, eseguite dall’hypervisor su ciascuna VM, devono per forza includere il proprio sistema operativo, risorse, library e file dell’applicazione. Tutto ciò comporta una grande quantità di risorse di sistema e, in caso di più VM eseguite sullo stesso server, si rischia un sovraccarico del sistema. Al contrario invece, ogni container, che condivide il medesimo sistema operativo host o kernell di sistema, è innanzitutto di dimensioni più ridotte, solitamente solo megabyte e quindi richiede solo pochi secondi per l’avvio, rispetto ai gigabyte e a minuti tipici di una VM. - Maggior portabilità, facilità di distribuzione e resilienza dell’applicazione:
Un altro vantaggio legato al mondo dei container, apprezzato soprattutto dagli sviluppatori stessi, è il corretto funzionamento dell’applicativo indipendentemente dall’ambiente che lo ospita o dalle caratteristiche stesse. Infatti, il rischio di utilizzare più fonti, library e repository per scrivere e strutturare una determinata applicazione, aumenta la possibilità che risulti incompatibile in ambienti differenti. Ecco, attraverso i container questo problema non sussiste proprio. - Maggior resilienza dell’applicazione e supporto:
I team DevOps attraverso i container sanno che le applicazioni funzioneranno sempre e allo stesso modo indipendentemente dall’ambiente in cui sono distribuite per cui possono creare, testare e distribuire su più ambienti mantenendo continuità; - Maggiore efficienza e rapidità nei processi di distribuzione , patch o ridimensionamento:
A differenza dell'approccio tradizionale con le VM, dove era richiesta l'installazione di prerequisiti quali librerie e altri software di supporto, una volta che l'immagine del container è pubblicata dallo sviluppatore, l'operatore è in grado di eseguirla in pochi semplici passaggi. Per quanto riguarda il patching inoltre, è reso ancora più semplice in quanto l'installazione di una nuova versione comporta solo il download della nuova immagine. Mentre relativamente al ridimensionamento, scalare l'applicazione significa eseguire più istanze dello stesso container e quindi risulta facile sia lo scale up che lo scale down dell'applicazione.
Dov'è la sfida? Da Docker, passando per Kubernetes fino a Rancher
Ad ogni innovazione tecnologica, e soprattutto rivoluzionaria come i container, nascono nuove sfide da affrontare.
In passato la containerizzazione delle applicazioni era riconducibile ad un pubblico di nicchia in quanto le competenze richieste erano elevate. Per questo motivo nasce Docker: software opensource che permette di eseguire, implementare e distribuire container e applicazioni in modo semplice ed efficiente automatizzando processi ripetitivi e banali attraverso semplici comandi.
Inizialmente tante aziende, compresa CloudFire, hanno iniziato ad adottare Docker in modo massiccio ospitando i container in vari ambienti quali VM o server fisici. Questo ha portato tuttavia ad un proliferare di applicazioni, rendendo difficile l'ottimizzazione delle risorse e il controllo sul contenuto eseguito all'interno dei container e sulle interazioni con altre applicazioni/container. Ciononostante, con tempo ed esperienza, abbiamo raggiunto alcune considerazioni e applicato le seguenti linee guida:
- Strutturare correttamente la comunicazione tra container;
- Tenere traccia di come i container vengono eseguiti, possibilmente definendo su file le configurazioni necessarie;
- Monitorare lo stato di ciascun container ed avere meccanismi automatici di riparazione in caso di problemi.
Per rispondere a tutte queste esigenze si è reso necessario l'adozione di un orchestratore di container: Kubernetes.
Kubernetes è il software opensource che armonizza il deployment e la gestione dell’intero ciclo di vita del container, garantendo scalabilità e resilienza automatizzata di ciascun container e di conseguenza dell’applicazione in esso contenuta. Viste le funzionalità e potenzialità innegabili, Kubernetes diventa e rimane tutt’ora lo standard de facto.
Come per i container, anche per utilizzare Kubernetes è necessario avere un' approfondita conoscenza e competenza in materia, e tuttavia rimane difficile da implementare e mantenere anche per esperti Cloud Architect.
Per questo motivo si adottano soluzioni di tipo managed, tra cui Rancher, uno stack software completo che semplifica il deployment e la creazione di nuovi cluster. Lo stesso Rancher è un’applicazione che gira all’interno di container, e la sua installazione è semplice tanto quanto eseguire un container.
Una volta dato il comando, e il container di Rancher è in esecuzione, basterà navigare all'indirizzo IP della macchina che ospita il container e seguire le istruzioni indicate.
Una volta eseguito il login in Rancher, sarà possibile creare un nuovo cluster. Ciò che occorre è: definire il nome del cluster, selezionare le macchine ospite ed infine scegliere il CNI - Container Network Interface.
Mai più senza Rancher
In conclusione, in CloudFire scegliamo ed utilizziamo Rancher perché:
- permette di agire in più modi🎨 dalla creazione al deploy di cluster K8s🛞 sia per test interni che per produzione, e soprattutto per la loro gestione. In questo modo tutti i setup vengono gestiti centralmente eliminando completamente errori di configurazione offrendo un' unica dashboard ai vari operatori mantenendo la personalizzazione di ciascun cluster;
- 🛡️ sotto l'aspetto della security, Rancher agevola la configurazione del Role Based Acces Control (RBAC) e permette reportistiche mirate sul suo utilizzo;
- relativamente a Monitoring ⚠️& Alerting🚨, con Rancher avvii rapidamente un sistema di monitoraggio e alerting basato su Prometheus e Grafana senza alcuna competenza specifica;
- Infine, per chi si è affidato a noi per la gestione di cluster Kubernetes, installati in precedenza utilizzando altri sistemi, abbiamo realizzato progetti di interconnessione 🖇con l'interfaccia Rancher senza alcuna migrazione applicativa.
