Recentemente è stata rilasciata una nuova versione della piattaforma di gestione dei container Docker. Questo ha portato all’aggiornamento di tutti i componenti del progetto: l’Engine è stato portato alla versione 1.11, Swarm è ora alla 1.2, ed infine Compose e Machine sono stati aggiornati rispettivamente alla 1.7 ed alla 0.7. E’ stata inoltra ufficializzata la Beta 10 di Docker Mac/Windows, ovvero il set di librerie che permettono di sfruttare le estensioni di virtualizzazione native dei relativi OS per far girare un core linux per Docker stesso.

Tutto questo, però, non è altro che la punta dell’iceberg e gli aggiornamenti più grossi non sono visibili dall’utente.

Per prima cosa è stato pesantemente rivisto l’Engine, rendendolo il primo runtime compliant alla Open Container Initiative (OCI, ne abbiamo già parlato in un precedente articolo).
Nello specifico, l’Engine adesso è costruito sopra runC e containerd.

runC è un tool che fa una cosa, ed una cosa soltanto: esegue un container. E proprio perché fa solo questa cosa, la fa molto bene! Storicamente il Docker Engine funzionava utilizzando direttamente gli strumenti di LXC, per gestire i container su Linux; successivamente si sono spostati su “libcontainer”, una libreria che permettesse di interfacciarsi direttamente con le feature del kernel necessarie all’esecuzione di container (come i namespace ed i cgroups).
In breve, runC è un piccolo tool da riga di comando che permette l’esecuzione di un container tramite libcontainer, indipendentemente dall’Engine che si sta utilizzando: prende un container conforme OCI e lo esegue. Solomon Hykes ha scritto un’interessante post a riguardo, se volete approfondire.

containerd è un demone che utilizza runC (o una qualsiasi alternativa, purché conforme OCI) per gestire i container ed espone le sue funzionalità tramite gRPC. In pratica, fornisce un’interfaccia CRUD (Create Read Update Delete) per la gestione specifica dei container, a differenza del Docker Engine che permette di gestire anche immagini, volumi, network, etc.

Come si combinano queste cose insieme? Il tutto è facilmente comprensibile con questo schema:

Lato utente, le interfacce sono identiche a prima, quello che cambia è come l’Engine arriva a lavorare sul kernel, il tutto a favore della standardizzazione.

Altri cambiamenti, non minori, sono stati fatti, ad esempio, per quanto riguarda il networking. Se la release 1.10 aveva aggiunto la presenza di un DNS integrato, permettendo ad ogni container di associare nomi ed alias di rete ad indirizzi IP, nel nuovo Engine 1.11, il DNS restituisce tutti i record relativi allo stesso alias di rete.
Questo significa che nel caso andassimo a creare diversi container con lo stesso alias avremmo, senza bisogno di altre configurazioni, un bilanciamento round robin ed un sistema di failover dei container.

Sono presenti novità anche in Compose, il tool utilizzato per creare “applicazioni” come strutture di diversi container, volumi e reti; le novità portano in Compose alcune funzionalità comode dell’engine, quale la possibilità di monitorare i log dell’intera “applicazione” o di eseguire comandi sui suoi container.

L’aggiornamento di Swarm, il sistema di clustering degli Engine Docker, rimuove dallo stato “experimental” la possibilità di ri-schedulare i container, facendo si che questi possano ripartire automaticamente in caso di fallimento di un nodo.

Insomma, tante tantissime novità da esplorare e, soprattutto, una chiara direzione verso la standardizzazione, che non può che renderci entisiasti.

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.