Negli ultimi mesi abbiamo avuto l’occasione di parlare più volte dei container confrontandoli ad esempio con la virtualizzazione o ripercorrendone la storia dalle origini ad oggi. Tra le parole che sempre più spesso sono associate ai container troviamo anche “orchestrazione”. L’intenzione del post odierno è quella di spiegare cosa sia l’orchestrazione dei container presentando infine i più popolari strumenti per metterla in atto: Docker Swarm, Kubernetes, Mesos/Marathon.
Cosa significa orchestrazione dei container
Per diverso tempo il deploy di un’applicazione in produzione è rimasta una pratica complessa ed onerosa da portare a termine – anche per gli amministratori di sistema più esperti. Con l’arrivo sulla scena di soluzioni come Chef o Puppet la situazione è migliorata e si è assistito all’inizio dell’era “dell’integrazione e dei deploy continui”: tra i principali pregi di tali strumenti anche quello di gestire automaticamente vari aspetti inerenti le procedure citate sollevando, di fatto, gli addetti ai lavori dall’onere di supervisionare ed impostare ognuno di essi.
Le soluzioni pensate per orchestrare i container offrono dei vantaggi analoghi, sollevando gli utilizzatori dal compito di prestare ad esempio attenzione a quale particolare server ospiterà il container e come quest’ultimo sarà avviato, monitorato o terminato. Se per il momento la lotta per l’affermazione di un unico standard container sembra essere stata vinta da Docker, quella che concerne le soluzioni per l’orchestrazione è ancora in corso.
Soluzioni di orchestrazione
Come detto in apertura, gli strumenti di orchestrazione più popolari del momento sono Docker Swarm, Kubernetes, Mesos+Marathon. Sebbene ciascuno di essi possa svolgere il medesimo compito, le modalità con le quali portano a compimento le task differiscono tra loro. Ogni soluzione offre infatti uno specifico livello di astrazione, approccio operativo (come viene gestita l’orchestrazione e come si integra con gli altri servizi) rivelandosi consigliata a specifici casi di utilizzo (container, servizi, workload vari su scala ridotta o su vasta scala etc.). Va inoltre valutato se il framework può integrarsi/affiancarsi agevolmente al nostro approccio lavorativo o dobbiamo necessariamente adottare una “nuova filosofia operativa”.
Docker Swarm
Swarm è la proposta sviluppata dalla startup Docker che si adatta facilmente ad ambienti in cui già si lavora con container Docker. La soluzione è ideale per operazioni di testing o per il deploy di applicazioni su ristretta scala . “Swarm” è caratterizzato da una serie di componenti incaricati di svolgere specifici compiti, nel dettaglio:
- Manager. Si occupano di distribuire le task tra i vari cluster. Un manager si occupa di orchestrare i nodi worker che costituiscono lo swarm.
- Worker. Eseguono i container che sono stati assegnati da un manager.
- Servizi. Un’interfaccia per un particolare set di container docker in esecuzione.
- Task. Singoli container che eseguono immagini e comandi richiesti da un particolare servizio.
- Key-value store. Servizi (etcd, Consul, Zookeeper) che si occupano di archiviare lo stato dello swarm e fornire visibilità al servizio.
Kubernetes
E’ il progetto open source sviluppato da Google che adotta un approccio totalmente differente da Docker. Kubernetes è consigliato per cluster di medie-grandi dimensioni ed applicazioni complesse. Rispetto a Swarm, la curva di apprendimento è molto più ripida – ma coloro che ne apprenderanno il funzionamento saranno ripagati dalla flessibilità / modularità della soluzione e dalla possibilità di gestire anche deploy su larga scala. Un cluster Kubernetes è formato da:
- Master. Si occupa di gestire le chiamate delle API, assegnare workload e supervisionare la configurazione degli stati.
- Minion. I server che eseguono workload o altri elementi non localizzati nel Master.
- Pod. Unità computazionali costituite da uno o più container il cui deploy è stato effettuato sul medesimo host. Si occupano di eseguire task ed hanno un singolo IP.
- Servizi. Front end e load balancer dei pod, mettono a disposizione un floating IP per accedere ai pod che eseguono il servizio.
- Replication controller. Si occupano di supervisionare un determinato numero di copie dei pod richiesti.
- Label. Tag utilizzati per identificare pod, replication controller e servizi.
Mesos e Marathon
Mesos è un cluster manager che mette a disposizione di un framework delle risorse computazionali. Marathon è un framework specializzato nell’esecuzione di applicazioni, inclusi i container, su cluster Mesos. Entrambi sono stati pensati per gestire decine di migliaia di nodi e sono quindi adatti a lavorare su larga scala. Anche in questo caso gli strumenti e le API adoperate si rivelano differenti da quelli delle altre soluzioni obbligando gli utilizzatori a ripartire sostanzialmente da zero. Passiamo ora all’elenco degli elementi che costituiscono un cluster Mesos:
- Master. Zookeeper gestisce un quantitativo minimo di nodi master pari a 3 e garantisce alta disponibilità affidandosi ad un quorum tra questi nodi.
- Slave. Nodi che si occupano di eseguire le task inviate dal framework.
- Framework. E’ l’elemento che si occupa di gestire i vari workload ed al quale Mesos offre risorse computazionali.
A sua volta Marathon offre:
- Service discovery. Visibilità attraverso varie opzioni (servizio DNS dedicato etc.).
- Load balancing. Via HAProxy.
- Constraint Management. Per controllare in quale parte del cluster siano eseguiti determinati workload, per mantenere a disposizione un determinato set di risorse per questi ultimi ed altre mansioni.
- Applicazioni. I servizi in esecuzione – container o altri workload.
- REST API: effettua il deploy, la modifica e l’eliminazione dei workload.
Conclusione
Come abbiamo visto le tre soluzioni differiscono profondamente tra loro. In linea di massima è possibile dire che Swarm rappresenta la soluzione più alla mano per l’orchestrazione dei container Docker; Kubernetes è una soluzione interessante ma più orientata al deploy ed alla gestione di servizi; Mesos e Marathon sono indubbiamente adatti a casi di utilizzo che prevedono deploy su larga scala ma risultano più complessi da utilizzare.
