Sfida al Docker Corral

Docker è sicuramente una delle tecnologie maggiormente in voga in questi ultimi anni. Si tratta di un sistema intelligente per creare infrastrutture ad alte prestazioni attraverso l'uso dei container che condividono kernel ed hardware della macchina fisica, con un overhead simile a quello di un normale processo in esecuzione direttamente sulla macchina.

Questa sua caratteristica permette di avere un gran numero di container su uno stesso nodo fisico, cosa impensabile con il sistema classico di virtualizzazione ad hypervisor.

Approfondiamo un po'!

La tecnologia

Docker utilizza il kernel Linux (ma può essere eseguito anche su altre piattaforme con le dovute accortezze) ed alcune delle sue funzionalità, come cgroups e namespaces, per eseguire i processi in maniera isolata ed indipendente. Per quanto riguarda la parte tecnica, Docker da LXC per evolversi in maniera totalmente differente: infatti, mentre LXC mette a disposizione un sistema completo, come se fosse un sistema di virtualizzazione leggera, Docker prevede un'architettura a servizi attraverso cui eseguire una singola applicazione per container.

Il deploy di un container avviene utilizzando un sistema di immagini, a partire dalle quali è possibile creare tutta l'architettura di cui si ha bisogno; ogni file immagine è formato da più strati (solitamente si usano filesystem come overlay o aufs) così da poter effettuare modifiche senza dover ricostruire tutta l'immagine, ma solo ciò che differisce dall'immagine precedente. Questo stesso sistema a strati rende anche possibile effettuare in maniera molto semplice un rollback in caso di necessità. E non è poco.

Il mio approccio

Terminata la panoramica molto sommaria sulla tecnologia che è alla base di Docker, non è mia intenzione continuare a descrivere come si genera un'immagine o quali sono le strategie migliori dettate dall'esperienza: internet è una fonte molto più autorevole di me.

Quello di cui voglio parlare è del mio rapporto con questo tipo di tecnologia: per natura sono scettico e non sono facile ad entusiasmi, cerco di analizzare le varie mode tecnologiche qualche tempo dopo che sono alla ribalta. Un po' perché così la tecnologia stessa matura, un po' perché dopo qualche tempo che viene utilizzata, si riesce a fare anche un'analisi un pochino più profonda.

Ho approcciato a Docker nella seconda metà del 2016, per un progetto in azienda su cui ho dovuto dare il mio supporto: non è stato un inizio scoppiettante, anzi, tutt'altro. Mi è sembrata una tecnologia poco matura, con una curva di apprendimento abbastanza ripida se si ha l'esigenza di fare cose un po' più complesse di fare il pull di qualche immagine e avviare il proprio codice. Parlo di sistemi cluster o in alta affidabilità, che introducono una notevole complessità infrastrutturale e che l'ecosistema Docker all'epoca non digeriva bene. Almeno in configurazioni on premises. Sì, perché Docker, in fondo, è pensato per essere utilizzato sul proprio laptop per sviluppo e su infrastrutture grosse, come Amazon AWS o Google Compute Engine dove tutta una serie di componenti critiche, come sistemi database in alta affidabilità o storage ridondati, sono gestiti dal provider.

Nel tempo ho potuto dare a Docker una seconda occasione per fare una buona prima impressione: ne ho capito di più, ho scoperto cose, nel frattempo la tecnologia è maturata ed anche io ho appreso concetti e best-practices che mi hanno fatto apprezzare le sue qualità.

Ho iniziato con il leggere la documentazione ufficiale ed a crearmi le mie immagini per prendere confidenza con i Dockerfile e per capire a fondo i comandi basilari per interagire con i container. Quindi, ho iniziato ad affrontare il più semplice tool di deploy a disposizione nell'ecosistema Docker: Docker compose](https://docs.docker.com/compose/), che permette attraverso un file con sintassi YAML di definire e configurare tutti i container dell'infrastruttura. Docker compose è sicuramente comodo da usare e i file YAML sono facili da scrivere; con compose è possibile aggiornare facilmente l'infrastruttura riavviando solo i container modificati, gestisce correttamente i volumi copiando il contenuto dal vecchio al nuovo container, è possibile effettuare il deploy sia su host singoli, sia su cluster creati con Docker Swarm.

Ok, ma quindi, Docker è buono o no?

Docker è un prodotto molto interessante sia dal punto di vista sistemistico che da quello di uno sviluppatore: infatti, grazie alle sue caratteristiche, è possibile ricreare facilmente un ambiente di sviluppo del tutto identico a quello di produzione in pochissimi minuti avendo (oltre ad una connessione internet) esclusivamente i Dockerfile e il codice delle applicazioni. E se poi si usano tool di orchestrazione - come- il tutto è a disposizione con un solo comando, che si occupa di creare le immagini ed avviare i container. D'altro canto, c'è un effort iniziale di preparazione dell'infrastruttura che non è banale, soprattutto quando le dimensioni crescono e le immagini da creare sono molte e con particolari caratteristiche. Un altro punto a sfavore che ho notato è la mancanza di omogeneità nell'ecosistema Docker: esistono molte soluzioni per risolvere lo stesso problema e ciò porta ad una confusione forte per chi deve implementare l'infrastruttura.

Utilizzerei Docker per un nuovo progetto? Probabilmente sì.

Ho ancora molto da studiare? Certamente!

Al prossimo post!