Dopo circa 6 mesi di discussioni interne e gestazioni, il team di Swarm ha finalmente rilasciato la sua nuova creatura: Docker Swarm Kit.
Docker Swarm è già uno dei protagonisti dell’ecosistema di Docker, uno strumento per orchestrare e gestire cluster di container anche di grandi dimensioni.
Tornando a Swarmkit, cos’è? Lo descriverei come un insieme di strumenti che potenziano Swarm. Prendendo in prestito alcuni concetti teorici da Mesos e integrandosi (compatibilità API) con Swarm, Kit andrà pian piano a sostituire Swarm. In pratica, invece che gli swarm agent, un cluster kit avrà in funzione su ogni nodo gli swarmkit agent.
Ma qual è quindi la differenza?
- Come Swarm, un cluster Swarmkit è molto più facile da capire e da gestire di un equivalente Kubernetes. Ma d’ora in avanti, con Kit il cluster si gestisce non più comandando il container swarm usando le API di Docker, ma con strumenti locali quali swarmd e swarmctl (modellati sull’esempio di containerd). Ciò limita al momento l’operatività alle sole socket UNIX locali, per connettersi all’Engine
- L’architettura di Kit ricorda più Mesos che non gli altri strumenti per l’orchestrazione, come Fleet o Kubernetes: si aggiungono i concetti di Master e di Worker, e quello di promozione da Worker a Master o di retrocessione da Master a Worker (per adesso manuale)
- Kit distribuisce non più tanto container, ma task. E più task si raggruppano in service. Per esempio, un service può essere MySQL, e i suoi task i vari container che eseguono uno per container mysqld.
- Con Kit, il concetto di replica master diventa più automatico: ciò significa che un numero dispari di master maggiore o uguale a 3 sarà obbligatorio (al momento no, ma personalmente penso che presto diventerà un requisito)
- Per elezioni e consenso, Kit usa l’algoritmo RAFT. Kit e RAFT sono implementati su due livelli distinti al momento, quindi indipendenti l’uno dall’altro – probabili estensioni e modularità venture.
- Le operazioni sul cluster sono sicure by default in automatico (per esempio autorizzazioni, crittografia point-to-point, TLS obbligatorio e protocolli di trasporto dati).
Questa è in sintesi l’architettura provvisoria di un cluster Swarmkit (lo schema è del mio amico Chanwit Kaewkasi, uno dei maintainer di Swarm, che lo ha appena rilasciato in CC):
Installare Swarmkit
Al momento Swarmkit sono alcuni binari che devono essere compilati. Per chi non è molto pratico con Golang ho scritto qualche veloce istruzione. Servono:
- Ambiente Go (io ho compilato con 1.6.2)
- Client git
Procedete così:
$ cd $GOPATH $ mkdir -p mkdir -p src/github.com/docker/ $ cd src/github.com/docker/ $ git clone https://github.com/docker/swarmkit.git $ cd swarmkit $ make binaries $ ls bin/ protoc-gen-gogoswarm swarm-bench swarmctl swarmd
Usare Swarmkit
Una volta a disposizione i binari, vi consiglio di dare un’occhiata all’esempio disponibile su https://github.com/docker/swarmkit che è già esplicativo e non necessita di ripetizioni. In pratica, viene mostrato come costruire uno Swarmkit locale e di come poi creare un servizio Redis, mostrando come si autoscala da 1 a 4 container.
Se volete fare un tentativo, ciò che vi serve è un Engine funzionante in locale (vedi punto 1 sopra). Perciò vi consiglio di provare direttamente su Linux, senza passare per Docker Machine.
L’infrastruttura IT del futuro
C’è grande movimento sui sistemi di orchestrazione dei container, ed è sicuramente uno degli argomenti più caldi del momento. Ad oggi abbiamo principalmente quattro protagonisti:
- Docker Swarm
- Kubernetes
- CoreOS Fleet
- Mesos (con Marathon o Aurora)
Dei quattro, la mia preferenza va a Swarm per vari motivi.
Su Swarm sto scrivendo qualcosa di interessante, quindi stay very tuned 😉
