docker
adv

Come visto, il mondo della virtualizzazione negli ultimi anni sta vedendo un nuovo protagonista, i container. Docker è uno dei tool di containerizzazione più noti, vediamo come funziona.

 

Container

Un container, come detto in precedenza, è un pacchetto contenente un’applicazione da eseguire, corredata da tutte le sue dipendenze e dal filesystem. Esso interagisce con un sistema host sfruttandone le risorse. L’host è una macchina reale che può eseguire una o più istanze di una o più applicazioni.

Docker

Tra i sistemi per la gestione dei container spicca Docker, un’applicazione nata per Linux ma che trova una versione per tutte le maggiori piattaforme consentendo, così, la piena portabilità del container realizzato e garantendo la funzionalità indipendentemente da sistema operativo, librerie e versione di pacchetti installati sul sistema che andrà ad eseguirlo.

Architettura Docker

Docker è un sistema “client-server” dove ambo gli attori possono essere installati sulla stessa macchina. Essi comunicano in HTTP tramite API RESTful, quindi sfruttando i webservice, su un canale rappresentato da una socket Unix. È possibile anche aprire questa socket all’esterno per consentire la connessione al server locale da parte di client esterni, con implicazioni sulla sicurezza.

Nella sua forma standard, Docker offre un client in command line interface, cioè a riga di comando. Esso ha la funzione di inviare i comandi al daemon (server) che, di fatto, gestisce i container, e di interpretare la risposta restituendola in un formato leggibile per l’utente finale.

Immagini e container

La logica di Docker si basa su layer sovrapposti. L’immagine di partenza è un layer read-only. Eseguendola con il comando run si ottiene un container che sarà, dunque, un’istanza della prima. L’immagine può essere eseguita più volte, dunque i container la condivideranno. Si possono apportare modifiche diverse a ciascun container ma il tutto si annullerà alla sua rimozione shutdown, quando verrà rieseguito a partire dall’immagine non ci saranno più. Per far si che le modifiche siano permanenti il container dev’essere trasformato in una nuova immagine eseguendo un commit.

Ad esempio, da una singola immagine di un webserver si possono eseguire 2 container: far girare 2 distinti webserver, apportare modifiche differenti e confrontarli e fare il commit del solo webserver che si desidera mantenere.

Un container non copia l’immagine ma la sfrutta: vengono copiati solo i dati modificati, in questo modo si avranno più container con meno utilizzo di memoria. Questa tecnica è chiamata copy on write.

La combinazione di questi layer read-only e read-write è chiamata UFS (Union File System) . Il concetto è vecchio per Unix.

HUB

I container possono essere creati in più modi, partendo dal filesystem di un sistema reale, di una virtual machine, oppure partendo da immagini già esistenti. Tali immagini possono essere reperite facilmente su Docker HUB, un portale che fornisce pacchetti per ogni esigenza, a partire da sistemi operativi minimali su cui cucire un prodotto per le proprie esigenze per arrivare agli applicativi già pacchettizzati, solo da utilizzare.

Microservice

Le best practice suggeriscono che i container seguano l’ottica dei microservice: ciascun container va costruito in maniera minimale, con lo stretto indispensabile ed orientato ad un’unica funzione. Ciò consente una migliore gestione del troubleshooting e di realizzare prodotti più veloci e con minore occupazione di memoria, consentendo alla macchina host di ospitare quanti più container possibili.