Il futuro di Docker – parte seconda

15 luglio 2015

Fabrizio Soppelsa

- RHCE, Autore di Linux&C, Autore di Linux Journal

Non è facile tirare le somme della DockerCon15, tante le novità e gli annunci. Questo è un breve riepilogo di ciò che ho captato – tenendo conto che ero reduce da un intenso hackathon. Ventiquattro ore estenuanti, ma che mi hanno dato tante soddisfazioni, tra cui nuove amicizie e il terzo posto nella classifica finale.

In un post precedente buttato giù nel mezzo della maratona, avevo scritto a caldo alcune mie impressioni ed idee. Non tutto si è rivelato esatto, ma qualcosina…

Open container format

Per smorzare la competizione con RKT di CoreOS, Docker insieme agli altri player del mercato container, come CoreOS appunto, ma anche RedHat, Rancher Labs, Google, Amazon, hanno iniziato a definire un formato standardizzato per i container, creando una coalizione sotto l’egida della Linux Software Foundation per lanciare l’Open Container Project. In pratica, viene creato lo standard dei container, sia per le immagini che a runtime (e durante la DockerCon15 è stato presentato RunC), il che dovrebbe rendere possibile creare un container in un ecosistema – per esempio in Docker – e portarlo senza sforzo in un altro ecosistema – per esempio CoreOS.

Networking

Tallone d’achille delle release fino alle 1.6, finalmente si inizia a intravedere la luce grazie a libnetwork, inclusa direttamente in 1.7+. Pur considerate ancora experimental, alcune delle nuove funzionalità presto disponibili consentiranno (un po’ come accade con Neutron in OpenStack) di creare reti di qualsiasi topologia, assegnar loro container e pubblicare servizi sulla rete rendendoli disponibili a un uso futuro direttamente con il comando docker:

docker network create mynet
docker service publish mysql.mynet
docker run -t -i --publish-service mysql.mynet mysql55

Orchestration

Parecchie le novità nei tre progetti di orchestration. Attendendo la riscrittura completa di Compose in Go, sono stati aggiunti la possibilità di ricreare solo i container che hanno effettivamente subito modifiche e un nuovo sistema di tagging (un po’ come in Google Kubernetes). Swarm ora conta l’integrazione con Mesos, il multitenancy oltre che molti miglioramenti in stabilità. Machine introduce la novità di poter istanziare macchine direttamente via Swarm, un comodo (finalmente!) comando scp per copiare file tra macchine e, come dettomi dal CEO di Rancher Labs, probabilmente presto RancherOS diventerà l’immagine di default per i deployment Machine remoti – incluso OpenStack.

Plugin

Se è vero che molti miglioramenti sono stati introdotti in libnetwork e in Docker stesso, da adesso si può ulteriormente estendere Docker con i plugin (che non sono altro che container). I plugin, che mi ricordano molto i driver di OpenStack sia per il networking che per lo storage – come Cisco, NetApp – consentiranno agli utenti di aggiungere funzionalità di terze parti al core. Per esempio, quando viene lanciato un container con -v, si potrà specificare il plugin da usare per importarne automaticamente le funzioni. Ci si aspetta di poter fare cose del genere:

docker run -t -i -v /data --volume-driver=netapp cirros /bin/sh

Production ready

Docker è pronto ai sistemi di produzione e allo scaling massivo. Ci sono tanti modi di mettere in piedi un’infrastruttura su Docker con software open source adesso. Per esempio con il Project Orca, che mira a fornire uno stack completo tutto campo (Engine, Swarm, Compose, Machine libnetwork, UI, configurazione). Oppure AtomicOS, direttamente da Red Hat, o CoreOS che è già disponibile su DigitalOcean. Oppure Rancher, che è già pronto per il deployment su RancherOS, un sistema operativo minimale dove tutto è containerizzato. Per passare a Docker su IaaS, si può pensare a  Magnum, un progetto di fattura Rackspace incubato in Stackforge. Oppure direttamente a integrare Docker in Nova su OpenStack, o usare Docker tramite Kubernetes nell’application catalog di OpenStack, Murano.