Docker, servizi all’interno di un container
Docker è un progetto open-source che gestisce le applicazioni isolandole l’una dall’altra (consentendo di automatizzare il deployment delle stesse all’interno di contenitori software) e che permette la replica di un ambiente di test/produzione da locale a remoto o viceversa.
Le macchine virtuali di Docker vengono chiamate container e al loro interno si può inserire qualsiasi cosa: un sistema operativo, una lista di applicazioni o anche un singolo servizio.
Il funzionamento di queste macchine virtuali è estremamente flessibile ed applicabile a qualsiasi livello.
Docker può essere usato sia in ambienti cloud che virtuali; una singola applicazione funziona ugualmente in diversi contesti e ambienti con la stessa metodologia.
Nella foto seguente, ad esempio, viene mostrata la coesistenza di Docker tra Microsoft Azure altri provider e il proprio datacenter
Perché Docker e a cosa serve
Docker risolve eventuali incompatibilità tra il lavoro dello sviluppatore che crea l’applicazione e il sistemista o l’azienda che deve preparare l’ambiente.
Grazie a Docker, lo sviluppatore crea con pochi comandi il suo container all’interno del quale svilupperà l’applicazione che successivamente verrà consegnata al sistemista per il deploy nell’architettura di produzione.
Docker è principalmente composto da 3 elementi:
- container
- immagine
- Dockerfile
Il container rappresenta l’ambiente di isolamento. Ha un proprio filesystem suo, propri processi, proprie interface rete etc. Possiamo pensare ad una combinazione tra un’immagine e un processo, o meglio ancora ad un mini sistema operativo completamente isolato, con propri processi e servizi.
L’immagine rappresenta un template di sola lettura che descrive l’ambiente, un sistema di base dal quale partire (si può immaginare come una iso di Ubuntu ad esempio).
Viene costruita attraverso la compilazione di un Dockerfile e definisce il comportamento predefinito di un ambiente.
Il Dockerfile è un file di testo che contiene tutte le istruzioni necessarie per costruire un’immagine; l’esecuzione di queste, che vengono lanciate in modalità sequenziale, avviene azionando/attivando il comando “run” da terminale.
Nella foto che segue sono evidenziati i vari livelli applicativi in un ambiente che grazie a Docker isola tre diverse applicazioni condividendo una parte di librerie, lo stesso Host OS e lo stesso Server.
Pro e Contro
I principali vantaggi che possono derivare dall’utilizzo di questa tecnologia sono l’isolamento dei processi ad un costo davvero ridotto rispetto alle soluzioni alternative, l’ampia compatibilità degli ambienti creati su multiple piattaforme e sistemi, il basso impatto sulle performance rispetto alle classiche soluzioni di virtualizzazione e infine i tantissimi contributi della comunità che si sta dimostrando sempre più attiva e interessata a questa tecnologia.
Di contro essendo una tecnologia nuova e in continuo sviluppo, Docker mostra ancora aree di immaturità e in continua evoluzione; questo in termini gestionali implica che una pianificazione di investimento iniziale in una infrastruttura del genere potrebbe essere disatteso e diventare continuativo a causa dei necessari frequenti aggiornamenti all’ecosistema.
Andrebbe migliorato anche il livello di sicurezza in determinati casi e in particolari setup.
Esempio di implementazione
Se dovessimo mettere in produzione un’applicazione chiamata “mia app”, escludendo una soluzione di tipo PaaS (Product as a Service), il modo tradizionale per realizzare l’operazione sarebbe:
- Aggiungere una macchina virtuale
- Configurare la macchina virtuale installando i pacchetti necessari per far girare l’applicazione
- Pubblicare il codice sorgente dell’applicazione
- Testarla in tutti i modi possibili
Se invece volessimo replicare questa app in un’altra macchina virtuale ma con una configurazione diversa, abbiamo due modalità:
- Riutilizzare la macchina virtuale esistente e aggiungere un nuovo virtualhost (ad esempio)
- Creare un’altra macchina virtuale e ripetere gli step sopra descritti con la configurazione modificata
Il metodo più pulito sarebbe il secondo, ma anche il più lento e costoso.
Se invece utilizzassimo Docker, la messa in produzione della nostra app risulterebbe sicuramente più economica e veloce. Infatti una volta creato il container con tutto quello che serve, basterebbe cambiare la configurazione che vogliamo e potremmo lanciare con un semplice comando la nostra app in uno o diversi container.
Differenze tra Virtual Server e Container
Nell’immagine che segue si può notare la differenza tra la gestione di una o più applicazioni su una tradizionale macchina virtuale rispetto ad un Container Docker
La gestione diventa molto più semplice e allo stesso tempo meno costosa e coinvolge meno risorse.
Gestione Docker
Su internet ci sono già diversi sistemi che permettono la gestione ed il monitoraggio dei containers con Docker.
A nostro avviso, essendo una tecnologia così nuova e in rapida evoluzione, non esiste ancora un sistema completo perfettamente funzionante tale da essere considerato stabile o pronto all’uso in produzione o per effettuare i deploy massivi.
La comunità internazionale si sta muovendo nella giusta direzione e nei prossimi mesi siamo sicuri avremo modo di veder nascere molte nuove soluzioni Docker basate sulle infrastrutture e software di diversi player tra i quali neen.
Alcuni link opensource di sistemi di gestione e monitoraggio containers:
https://github.com/centurylinklabs/panamax-ui
https://github.com/shipyard/shipyard
www.flynn.io
https://github.com/GoogleCloudPlatform/kubernetes
https://github.com/opdemand/deis
https://github.com/progrium/dokku
https://github.com/coreos
https://github.com/orchardup/fig
https://github.com/hashicorp/serf
https://github.com/drone/drone
Considerazioni finali
Noi neeners siamo entusiasti di questa tecnologia per la semplicità di gestione e per l’innovazione che porterà all’interno dei servizi hosting.
L’abbiamo utilizzato per ogni progetto di R&D che potesse beneficiare di questo approccio.
Allo stesso tempo pensiamo che come per tutti i nuovi software serva un attento monitoraggio della sicurezza e dell’evoluzione del sistema prima di poterlo considerare perfettamente stabile e funzionale a ospitare applicazioni impegnative e critiche.
neen stà lavorando attivamente ad un prodotto stabile che speriamo di lanciare entro il primo trimestre del 2015