Gli strumenti Docker

Il vasto eco­si­ste­ma Docker offre agli svi­lup­pa­to­ri e alle svi­lup­pa­tri­ci molte opzioni per la di­stri­bu­zio­ne delle ap­pli­ca­zio­ni, l’or­che­stra­zio­ne dei container e molto altro. Ti pre­sen­tia­mo gli strumenti Docker più im­por­tan­ti e ti forniamo una pa­no­ra­mi­ca dei progetti di terze parti più popolari, in cui vengono svi­lup­pa­ti strumenti Docker open source.

Gli strumenti e i com­po­nen­ti di Docker es­sen­zia­li

Og­gi­gior­no Docker è molto di più che una semplice piat­ta­for­ma per la gestione di software container. Per gestire il de­ploy­ment, ovvero la messa a di­spo­si­zio­ne di ap­pli­ca­zio­ni, at­tra­ver­so in­fra­strut­tu­re di­stri­bui­te e ambienti cloud in maniera più semplice, più veloce e più fles­si­bi­le, il team di sviluppo ha dotato il software centrale di diversi strumenti Docker. Oltre alle funzioni cluster e di or­che­stra­zio­ne, essi offrono un punto di incontro centrale, per quel che riguarda il mercato delle app, e uno strumento per la gestione delle risorse cloud.

Docker Engine

Quando gli utenti parlano di “Docker”, viene so­li­ta­men­te intesa un’ap­pli­ca­zio­ne open source di tipo client-server, la quale sta alla base della piat­ta­for­ma container. Tale ap­pli­ca­zio­ne viene chiamata “Docker Engine” nella ter­mi­no­lo­gia specifica di Docker. I com­po­nen­ti centrali di Docker Engine sono Docker Daemon, un’API REST e una CLI (Command Line Interface) come in­ter­fac­cia utente. Questa struttura ti consente di ri­chia­ma­re Docker Engine tramite i comandi dati dalla riga di comando e di gestire immagini, file di Docker e container dal terminale. Il client e il demone possono trovarsi su sistemi diversi. Nel nostro articolo di ap­pro­fon­di­men­to trovi una pa­no­ra­mi­ca dei comandi Docker più im­por­tan­ti.

Docker Hub

Con Docker Hub, il progetto open source mette a di­spo­si­zio­ne degli utenti un registry basato su cloud, tramite il quale è possibile scaricare, gestire in maniera cen­tra­liz­za­ta e con­di­vi­de­re con altri utenti le immagini di Docker. Gli utenti re­gi­stra­ti possono ar­chi­via­re le proprie immagini di Docker su re­po­si­to­ry pubblici o privati. Un tag integrato consente di creare più versioni delle immagini.

Oltre ai re­po­si­to­ry pubblici degli altri utenti di Docker, anche nell’hub hai a di­spo­si­zio­ne molte risorse, messe a di­spo­si­zio­ne in archivi ufficiali di immagini dal team di sviluppo di Docker e da altri progetti open source co­no­sciu­ti. Tra le immagini più scaricate si an­no­ve­ra­no il server web leggero NGINX, il database in-memory Redis, il toolkit di Unix BusyBox e la di­stri­bu­zio­ne Linux Ubuntu.

Tra le altre funzioni di Docker Hub rientrano le co­sid­det­te Or­ga­ni­za­tions, ovvero dei gruppi di lavoro, che per­met­to­no agli utenti della piat­ta­for­ma di mettere a di­spo­si­zio­ne i re­po­si­to­ry privati solo a de­ter­mi­na­te cerchie di persone. I permessi di accesso vengono gestiti in­ter­na­men­te tra team e gruppi di per­ti­nen­za.

Docker Swarm

Docker Engine dispone di funzioni native che per­met­to­no la gestione degli host di Docker in cluster, i co­sid­det­ti sciami (Swarms). Le funzioni di gestione dei cluster e di or­che­stra­zio­ne integrate in Docker Engine si basano sul toolbox Swarmkit.

Lo strumento di clu­ste­ring di Docker Swarm raggruppa una serie di host Docker in un singolo host virtuale e serve al fun­zio­na­men­to delle API REST di Docker. In questo modo ogni strumento di Docker che è in col­le­ga­men­to con Docker Daemon può affidarsi a Swarm ed essere regolato su un numero qualsiasi di host Docker. Gli utenti uti­liz­za­no le CLI di Docker Engine per creare gli sciami, con­trol­lar­ne il com­por­ta­men­to e di­stri­bui­re le ap­pli­ca­zio­ni nel cluster. Un software di or­che­stra­zio­ne ag­giun­ti­vo non è perciò ne­ces­sa­rio.

I Docker Engine che sono stati collegati ai cluster operano in modalità Swarm. Questa modalità è da attivare se crei un nuovo cluster o se desideri ag­giun­ge­re un host Docker a uno sciame già presente. I singoli host Docker in un cluster vengono definiti come “nodi”. I nodi di un cluster possono fun­zio­na­re come host virtuali sullo stesso sistema locale, più spesso ri­scon­tra­bi­le è tuttavia una struttura basata su cloud, presso la quale i singoli nodi dello sciame Docker vengono di­stri­bui­ti su diversi sistemi e in­fra­strut­tu­re.

Il software si basa su un’ar­chi­tet­tu­ra master-slave. Nel caso in cui dei compiti vengano suddivisi all’interno dello sciame, gli utenti inviano un co­sid­det­to Service al manager node, il quale funge da master del cluster. Questo master è re­spon­sa­bi­le per la pia­ni­fi­ca­zio­ne dei container nel cluster e serve come in­ter­fac­cia utente primaria per poter accedere alle risorse dello sciame.

Il manager node invia singole unità di lavoro, chiamate task, agli slave su­bor­di­na­ti, co­no­sciu­ti come “worker nodes” nella ter­mi­no­lo­gia di Docker.

• Services: i Services (servizi) sono strutture centrali all’interno dei cluster di Docker. Per Service si intende un gruppo di container, che si basa sulla stessa immagine. Un Service definisce i task che vengono eseguiti nel cluster. Gli utenti, che creano servizi, spe­ci­fi­ca­no all’interno di questi quale immagine e quale comando debbano essere uti­liz­za­ti. Inoltre, i Services offrono la pos­si­bi­li­tà di scalare le ap­pli­ca­zio­ni. Gli utenti della piat­ta­for­ma Docker de­fi­ni­sco­no in aggiunta il numero di container che devono essere avviati per un de­ter­mi­na­to servizio.
• Task: per poter di­stri­bui­re i Services in un cluster, questi ultimi vengono scomposti dai manager node in unità di lavoro singole, ovvero i già citati task. Ogni task raggruppa un container Docker, così come i comandi che vengono eseguiti all’interno di essi.

Nelle im­po­sta­zio­ni standard, oltre alle funzioni per la gestione dei cluster e per l’or­che­stra­zio­ne dei container, i manager node offrono anche fun­zio­na­li­tà worker node, ovvero limitano i compiti di un simile nodo master alla semplice gestione dei task.

Su ogni worker node viene eseguito un programma Agent. Tale programma accetta i task per poi con­se­gna­re al relativo master node un ag­gior­na­men­to sull’avan­za­men­to degli incarichi che sono stati trasmessi. Il seguente grafico mostra una rap­pre­sen­ta­zio­ne sche­ma­ti­ca di uno Swarm Docker.

Con l’im­ple­men­ta­zio­ne di uno sciame di Docker, gli utenti ricorrono so­li­ta­men­te alla Docker Machine.

Docker Compose

Docker Compose ti permette di collegare tra loro più container e di farlo eseguendo un solo comando. L’elemento di base di Compose è il file di controllo centrale basato sul lin­guag­gio di markup YAML. La sintassi di questi file di Compose as­so­mi­glia a quella del software open source Vagrant, uti­liz­za­to per la creazione e la fornitura delle macchine virtuali.

Nel file docker-compose.yml definisci il numero che pre­fe­ri­sci di software container, incluse le relative su­bor­di­na­zio­ni e relazioni tra di loro. Tali ap­pli­ca­zio­ni multi-container vengono gestite secondo lo stesso schema dei singoli container. Utilizza il comando docker-compose in com­bi­na­zio­ne con il sot­to­co­man­do de­si­de­ra­to per gestire l’intero ciclo di vita dell’ap­pli­ca­zio­ne.

Lo strumento di Docker è fa­cil­men­te in­te­gra­bi­le in un cluster basato su Swarm. In questo modo, con Compose, esegui fa­cil­men­te le ap­pli­ca­zio­ni multi-container create sia sui vari sistemi di­stri­bui­ti, sia su un singolo host di Docker.

Un’ulteriore funzione di Docker Compose è il mec­ca­ni­smo di re­go­la­zio­ne integrato. Uti­liz­zan­do la riga di comando, con lo strumento di or­che­stra­zio­ne definisci fa­cil­men­te quanti container desideri avviare per un de­ter­mi­na­to servizio.

Gli strumenti Docker svi­lup­pa­ti da fornitori esterni

Oltre agli sviluppi ottenuti dallo svi­lup­pa­to­re stesso, Docker Inc., si possono trovare diversi altri strumenti software e piat­ta­for­me di fornitori esterni, i quali mettono a di­spo­si­zio­ne le in­ter­fac­ce per Docker Engine o per la piat­ta­for­ma di container che pre­fe­ri­sci. Tra i progetti open source più co­no­sciu­ti dell’eco­si­ste­ma di Docker si an­no­ve­ra­no lo strumento per l’or­che­stra­zio­ne Ku­ber­ne­tes, lo strumento per la gestione dei cluster Shipyard, la soluzione multi-container per Docker Panamax, la piat­ta­for­ma di in­te­gra­zio­ne continua Drone, il sistema operativo cloud OpenStack e il sistema operativo per data center D2iQ DC/OS, che si basa sul gestore di cluster Mesos.

Ku­ber­ne­tes

Gli strumenti di or­che­stra­zio­ne di­spo­ni­bi­li in Docker, come Swarm e Compose, non sono stati sempre offerti dal team di sviluppo di Docker. Ormai da anni numerose aziende hanno iniziato a con­cen­tra­re i propri sforzi su strumenti fatti su misura, i quali do­vreb­be­ro sem­pli­fi­ca­re il compito di gestire la piat­ta­for­ma di container in grandi in­fra­strut­tu­re di­stri­bui­te. Tra le soluzioni più co­no­sciu­te di questo tipo vi è il progetto open source Ku­ber­ne­tes.

Con Ku­ber­ne­tes si ha a di­spo­si­zio­ne un gestore di cluster per le ap­pli­ca­zio­ni basate su container. Lo scopo di Ku­ber­ne­tes è quello di au­to­ma­tiz­za­re le ap­pli­ca­zio­ni nel cluster. Lo strumento di or­che­stra­zio­ne utilizza anche un’API REST, il programma a riga di comando e un’in­ter­fac­cia web grafica come in­ter­fac­ce di gestione, at­tra­ver­so le quali gli au­to­ma­ti­smi possono essere messi in moto e può essere richiesto il rapporto sulla si­tua­zio­ne attuale. Gli utenti uti­liz­za­no Ku­ber­ne­tes per i seguenti motivi:

• eseguire le ap­pli­ca­zio­ni basate su container in un cluster;
• con­fi­gu­ra­re e gestire le ap­pli­ca­zio­ni nei vari sistemi di­stri­bui­ti;
• regolare le ap­pli­ca­zio­ni;
• sfruttare al meglio la di­spo­ni­bi­li­tà degli hardware presenti.

Inoltre, Ku­ber­ne­tes raggruppa i container all’interno di una sezione logica, il co­sid­det­to Pod. I pod rap­pre­sen­ta­no le unità di base dei gestori di cluster, le quali possono essere suddivise in cluster tramite il processo di sche­du­ling.

Come per gli sciami di Docker, anche alla base di Ku­ber­ne­tes vi è un’ar­chi­tet­tu­ra master-slave. Un cluster si basa sia su un master Ku­ber­ne­tes sia su una grande quantità di slave, i co­sid­det­ti Ku­ber­ne­tes Node, anche chiamati Ku­ber­ne­tes Worker o Ku­ber­ne­tes Minion. Il master Ku­ber­ne­tes funge da livello di controllo centrale (in inglese “Control Plane”) all’interno del cluster e si compone di quattro com­po­nen­ti di base, i quali rendono possibile la gestione della co­mu­ni­ca­zio­ne nel cluster e la di­stri­bu­zio­ne dei compiti. Un master Ku­ber­ne­tes include anche un server API, una memoria di con­fi­gu­ra­zio­ne etcd, uno scheduler e un con­trol­ler manager.

• Server API: tutti gli au­to­ma­ti­smi nel cluster Ku­ber­ne­tes vengono messi in moto tramite le API REST su un server API. Questo funziona come in­ter­fac­cia di am­mi­ni­stra­zio­ne centrale all’interno del cluster.
• etcd: immagina la memoria di con­fi­gu­ra­zio­ne open source etcd come la memoria di un cluster Ku­ber­ne­tes. Il database coppia-valore (key-value store), svi­lup­pa­to da CoreOS spe­ci­fi­ca­men­te per i sistemi di­stri­bui­ti, archivia i dati di con­fi­gu­ra­zio­ne e li mette a di­spo­si­zio­ne di ogni nodo del cluster. At­tra­ver­so etcd è possibile gestire in ogni momento lo stato attuale del cluster.
• Scheduler: lo scheduler è re­spon­sa­bi­le per la di­stri­bu­zio­ne dei gruppi container (pod) all’interno del cluster. Inoltre, esso comunica a questi le risorse ne­ces­sa­rie di ogni pod e le equipara con le risorse di­spo­ni­bi­li dei singoli nodi.
• Con­trol­ler manager: il con­trol­ler manager è un servizio del master di Ku­ber­ne­tes che regola lo stato del cluster, esegue i compiti di routine e gestisce quindi l’or­che­stra­zio­ne. Il compito prin­ci­pa­le del con­trol­ler manager è quello di fare in modo che lo stato del cluster cor­ri­spon­da a quello dell’obiettivo pre­de­fi­ni­to.

Tutti i com­po­nen­ti del master di Ku­ber­ne­tes possono essere basati su uno stesso host o, nel caso di un cluster ad alta di­spo­ni­bi­li­tà, possono essere di­stri­bui­ti tra più host master.

Mentre il master di Ku­ber­ne­tes è re­spon­sa­bi­le dell’or­che­stra­zio­ne, i pod di­stri­bui­ti nel cluster vengono eseguiti sugli host di­pen­den­ti dal master, ovvero i nodi Ku­ber­ne­tes. Inoltre, su ogni nodo Ku­ber­ne­tes deve operare un container engine. Docker rap­pre­sen­ta lo standard a tutti gli effetti. Da un punto di vista teorico, Ku­ber­ne­tes non è vincolato ad alcun container engine specifico.

Oltre al container engine, i nodi Ku­ber­ne­tes com­pren­do­no anche i seguenti com­po­nen­ti:

• kubelet: kubelet è un agent che viene eseguito su ogni nodo Ku­ber­ne­tes e serve al controllo e alla gestione dei nodi. In quanto punto di contatto centrale di ogni nodo, kubelet è in contatto con il master Ku­ber­ne­tes e assicura che le in­for­ma­zio­ni siano inoltrate e ricevute dal livello di controllo.
• kube-proxy: su ogni nodo Ku­ber­ne­tes gira anche kube-proxy, un servizio proxy. Questo deve far sì che le richieste ai vari container, pro­ve­nien­ti dall’esterno, giungano a de­sti­na­zio­ne, e che agli utenti vengano messi a di­spo­si­zio­ne i servizi delle ap­pli­ca­zio­ni basate su container. Inoltre kube-proxy offre un load balancer ru­di­men­ta­le.

Il seguente grafico mostra una rap­pre­sen­ta­zio­ne sche­ma­ti­ca dell’ar­chi­tet­tu­ra master-slave, alla base della piat­ta­for­ma di or­che­stra­zio­ne Ku­ber­ne­tes:

Oltre alle fun­zio­na­li­tà centrali del progetto Ku­ber­ne­tes, puoi trovare numerosi altri strumenti ed esten­sio­ni che ti per­met­te­ran­no di dotare la piat­ta­for­ma di or­che­stra­zio­ne di funzioni ag­giun­ti­ve. Tra le più famose vi sono gli strumenti per il mo­ni­to­rag­gio e per la diagnosi degli errori Pro­me­theus, Weave Scope e sysdig, così come anche il gestore di pacchetti Helm. Inoltre esistono dei plugin per Apache Maven e Gradle, così come un’API Java per la con­fi­gu­ra­zio­ne di Ku­ber­ne­tes da remoto.

Shipyard

Shipyard è una delle soluzioni ge­stio­na­li basate su Swarm, svi­lup­pa­ta dalla community degli utenti di Docker. Permette di gestire le risorse Docker quali i container, le immagini, gli host e i registry privati tramite un’in­ter­fac­cia utente grafica. È di­spo­ni­bi­le come ap­pli­ca­zio­ne web dal browser.

Il software è com­pa­ti­bi­le al 100% con la Remote API di Docker e usa RethinkDB, il database NoSQL open source, come memoria di ar­chi­via­zio­ne per gli account utente, gli indirizzi e gli eventi.

Oltre alle funzioni di gestione dei cluster at­tra­ver­so l’in­ter­fac­cia web centrale, Shipyard mette a di­spo­si­zio­ne un’au­ten­ti­ca­zio­ne utente, così come anche la pos­si­bi­li­tà di con­trol­la­re gli accessi in base ai ruoli.

Il software si basa sul toolkit di gestione dei cluster Citadel e si compone so­stan­zial­men­te di tre com­po­nen­ti fon­da­men­ta­li: Con­trol­ler, API e UI.

• Shipyard Con­trol­ler: il con­trol­ler è il com­po­nen­te centrale dello strumento di gestione Shipyard. Il con­trol­ler in­te­ra­gi­sce con il database RethinkDB nell’ambito dell’ar­chi­via­zio­ne dei dati e permette di in­te­ra­gi­re con i singoli host all’interno di un cluster Docker e di gestire gli eventi.
• Shipyard API: l’API di Shipyard si basa su REST. Tutte le funzioni dello strumento di gestione vengono con­fi­gu­ra­te at­tra­ver­so questa API.
• Shipyard User Interface (UI): l’in­ter­fac­cia utente Shipyard è un’app di AngularJS che mette a di­spo­si­zio­ne degli utenti un’in­ter­fac­cia utente grafica per la gestione dei cluster di Docker di­ret­ta­men­te dal browser. Tutte le in­te­ra­zio­ni nell’in­ter­fac­cia utente avvengono tramite l’API di Shipyard.

Trovi ulteriori in­for­ma­zio­ni su Shipyard sul sito web ufficiale del progetto open source.

Panamax

Il team di sviluppo dello strumento Docker open source Panamax si è pre­fis­sa­to come obiettivo quello di sem­pli­fi­ca­re la fornitura delle app multi-container. Lo strumento gratuito offre agli utenti un’in­ter­fac­cia grafica tramite la quale è possibile svi­lup­pa­re, mettere a di­spo­si­zio­ne e di­stri­bui­re le ap­pli­ca­zio­ni complesse basate sui container Docker in maniera agile tramite drag and drop.

Panamax permette di ar­chi­via­re le complesse ap­pli­ca­zio­ni multi-container come co­sid­det­ti ap­pli­ca­tion template e quindi di di­stri­buir­le con un semplice clic all’interno delle ar­chi­tet­tu­re dei cluster. Tramite un mercato per le app, ospitato su GitHub, è possibile ar­chi­via­re nei re­po­si­to­ry Git i template delle app create au­to­no­ma­men­te e metterli a di­spo­si­zio­ne degli altri utenti.

I com­po­nen­ti di base dell’ar­chi­tet­tu­ra di Panamax sono sud­di­vi­si­bi­li in due gruppi: si distingue tra Panamax Local Client e un numero qualsiasi di co­sid­det­ti remote de­ploy­ment target.

Panamax Local Client è il com­po­nen­te centrale dello strumento Docker. Questo viene eseguito sul sistema locale e permette di creare ap­pli­ca­zio­ni complesse basate su container. Il local client si compone dei seguenti com­po­nen­ti:

• CoreOS: l’in­stal­la­zio­ne di Panamax Local Client prevede come sistema host CoreOS, il software container rivolto spe­cial­men­te alla di­stri­bu­zio­ne di Linux. Il client di Panamax viene eseguito come container Docker su CoreOS. Con Panamax, gli utenti hanno a di­spo­si­zio­ne diverse funzioni CoreOS e Docker. Tra queste vi sono Fleet e Jour­nalc­tl:

  • Fleet: invece di in­te­ra­gi­re di­ret­ta­men­te con Docker, il client di Panamax utilizza il cluster manager Fleet per or­che­stra­re i container. Fleet è un gestore di cluster che controlla systemd, il demone di Linux, all’interno dei cluster del computer.
  • Jour­nalc­tl: il client di Panamax utilizza Jour­nalc­tl per esaminare i messaggi di log del gestore di sistema Linux systemd dal co­sid­det­to Journal.

• Local Client Installer: il Local Client Installer contiene tutti i com­po­nen­ti necessari per in­stal­la­re il client di Panamax sul sistema locale.

• Panamax Local Agent: il com­po­nen­te centrale del local client è il local agent. Questo è connesso tramite l’API di Panamax con diversi altri com­po­nen­ti e funzioni. Inoltre, vi sono anche l’host locale di Docker, la Panamax UI, i registry esterni, così come i remote agent, che fanno af­fi­da­men­to sui de­ploy­ment target all’interno del cluster. Il local agent in­te­ra­gi­sce nel sistema locale con le seguenti in­ter­fac­ce di pro­gram­ma­zio­ne, tramite l’API di Panamax, in modo da scambiare in­for­ma­zio­ni con le ap­pli­ca­zio­ni in ese­cu­zio­ne:

  • Docker Remote API: tramite la Docker Remote API, Panamax cerca immagini sul sistema locale, ri­chia­man­do le in­for­ma­zio­ni di stato ri­guar­dan­ti i container in ese­cu­zio­ne.
  • etcd API: tramite l’API etcd vengono trasmessi i dati al demone di Fleet del CoreOS.
  • systemd-journal-gatewayd.services: Panamax utilizza systemd-journal-gatewayd.services per ri­chia­ma­re il Journal Output dei servizi in ese­cu­zio­ne.

Inoltre, l’API di Panamax rende possibile le in­te­ra­zio­ni con diverse API esterne.

• Docker Registry API: at­tra­ver­so la Docker Registry API, Panamax richiama i tag delle immagini dal registry di Docker.
• GitHub API: con la GitHub API si caricano i template di Panamax nel re­po­si­to­ry di GitHub.
• Kiss­Me­trics API: la Kiss­Me­trics API raccoglie i dati riguardo ai template eseguiti dagli utenti.
• Panamax UI: la Panamax UI serve come in­ter­fac­cia utente sul sistema locale e permette agli utenti di gestire lo strumento Docker tramite un’in­ter­fac­cia grafica. Tramite l’API di Panamax le im­mis­sio­ni degli utenti vengono inoltrate di­ret­ta­men­te al local agent. La Panamax UI si basa su CTL Base UI Kit, una libreria con com­po­nen­ti UI per i progetti web di Cen­tu­ry­Link.

Ogni nodo in un cluster Docker senza compiti di gestione viene chiamato Remote De­ploy­ment Target, secondo la ter­mi­no­lo­gia Panamax. I de­ploy­ment target sono composti di un host Docker, il quale è con­fi­gu­ra­to per la di­stri­bu­zio­ne dei template Panamax grazie ai seguenti com­po­nen­ti:

• De­ploy­ment Target Installer: De­ploy­ment Target Installer avvia un host Docker, inclusi il Panamax Remote Agent e l’Or­che­stra­tion Adapter (l’adat­ta­to­re di or­che­stra­zio­ne).
• Panamax Remote Agent: in­stal­lan­do Panamax Remote Agent, è possibile di­stri­bui­re le ap­pli­ca­zio­ni tra i Panamax client locali a un qualsiasi punto finale del cluster. Panamax Remote Agent viene eseguito all’interno del cluster come container Docker su ogni de­ploy­ment target.
• Panamax Or­che­stra­tion Adapter: nell’adat­ta­to­re di or­che­stra­zio­ne viene messa a di­spo­si­zio­ne, all’interno di un livello Adapter in­di­pen­den­te, la logica del programma di ogni strumento di or­che­stra­zio­ne di Panamax. In questo modo gli utenti hanno la pos­si­bi­li­tà di scegliere sempre esat­ta­men­te la tec­no­lo­gia di or­che­stra­zio­ne che pre­fe­ri­sco­no, con il supporto dell’ambiente relativo. Sia Ku­ber­ne­tes che Fleet pos­sie­do­no i ri­spet­ti­vi adat­ta­to­ri pre­con­fi­gu­ra­ti:
  • Panamax-Ku­ber­ne­tes-Adapter: Panamax Ku­ber­ne­tes Adapter, in com­bi­na­zio­ne con Panamax Remote Agent, permette di di­stri­bui­re i template Panamax tra i cluster Ku­ber­ne­tes.
  • Panamax-Fleet-Adapter: Panamax Fleet Adapter, in com­bi­na­zio­ne con Panamax Remote Agent, permette di di­stri­bui­re i template Panamax nei cluster con­trol­la­ti tramite il gestore di cluster di Fleet.

Il grafico seguente mostra la coo­pe­ra­zio­ne dei singoli com­po­nen­ti di Panamax all’interno di un cluster Docker:

Lo strumento di gestione di container Panamax, basato su CoreOS, offre agli utenti diversi standard tec­no­lo­gi­ci per l’or­che­stra­zio­ne dei container at­tra­ver­so un’in­ter­fac­cia utente grafica, così come la pos­si­bi­li­tà di gestire ap­pli­ca­zio­ni multi-container complesse nelle ar­chi­tet­tu­re cluster at­tra­ver­so il sistema che si pre­fe­ri­sce, come ad esempio quello del proprio notebook.

Con il Public Template Re­po­si­to­ry, Panamax mette a di­spo­si­zio­ne dei propri utenti, tramite GitHub, una libreria template pubblica con diverse risorse.

Drone

Drone è una piat­ta­for­ma di in­te­gra­zio­ne continua leggera e con pochi pre­re­qui­si­ti. Con lo strumento Docker, è possibile caricare au­to­ma­ti­ca­men­te l’ultima build da un re­po­si­to­ry Git come GitHub ed eseguirla in container Docker isolati a scopo di test. Hai la pos­si­bi­li­tà di eseguire un numero qualsiasi di test e farti inviare i messaggi di stato per e-mail. Per ogni test di un software viene creato un nuovo container basato su un’immagine dal registry pubblico di Docker. Così facendo, ogni immagine di Docker ac­ces­si­bi­le pub­bli­ca­men­te può essere uti­liz­za­ta come ambiente per il codice da testare.

Drone è integrato in Docker e supporta diversi linguaggi di pro­gram­ma­zio­ne, come PHP, Node.js, Ruby, Go e Python. L’unica con­di­zio­ne ne­ces­sa­ria per il fun­zio­na­men­to di Drone è la piat­ta­for­ma di container. Con Drone crei la tua piat­ta­for­ma di in­te­gra­zio­ne continua personale per tutti i sistemi sui quali è possibile in­stal­la­re Docker. Inoltre, supporta più re­po­si­to­ry di controllo delle versioni. Trovi una guida all’in­stal­la­zio­ne standard con l’in­te­gra­zio­ne di GitHub nella do­cu­men­ta­zio­ne del progetto open source, sul sito readme.drone.io.

Il controllo della piat­ta­for­ma di in­te­gra­zio­ne continua avviene tramite l’in­ter­fac­cia web. At­tra­ver­so tale in­ter­fac­cia carichi le build di­ret­ta­men­te dal re­po­si­to­ry Git de­si­de­ra­to, metti in col­le­ga­men­to le ap­pli­ca­zio­ni e avvii ciò che ne risulta in un ambiente di test pre­ce­den­te­men­te definito. Inoltre, per ogni test del software eseguito, viene definito un file .drone.yml, all’interno del quale viene stabilito quali ap­pli­ca­zio­ni debbano essere usate per la creazione dell’ap­pli­ca­zio­ne finale e come quest’ultima debba essere eseguita.

Con Drone viene messa a di­spo­si­zio­ne degli utenti una soluzione CI open source, che riunisce i punti di forza di prodotti al­ter­na­ti­vi come Travis e Jenkins in un’ap­pli­ca­zio­ne dall’in­ter­fac­cia utente user-friendly.

OpenStack

Quando si tratta dell’ar­chi­tet­tu­ra e della gestione di strutture cloud open source, allora il sistema operativo cloud open source OpenStack è la soluzione software che fa per te. Con OpenStack è possibile gestire risorse di calcolo, di memoria e di rete in un data center, gestirle da una dashboard e metterle a di­spo­si­zio­ne degli utenti finali tramite un’in­ter­fac­cia web.

Il sistema operativo cloud si basa su un’ar­chi­tet­tu­ra modulare, composta da più com­po­nen­ti:

• • Zun (servizio container): Zun è il servizio container di OpenStack che consente una facile di­stri­bu­zio­ne e gestione di ap­pli­ca­zio­ni con­tai­ne­riz­za­te nel cloud OpenStack. Il suo scopo è quello di con­sen­ti­re agli utenti di gestire i container tramite un’API REST senza dover gestire server o cluster. Zun richiede l’ese­cu­zio­ne di altri tre servizi OpenStack: Keystone, Neutron e kuryr-lib­net­work. Op­zio­nal­men­te, la fun­zio­na­li­tà di Zun può essere estesa da altri servizi OpenStack, come Cinder e Glance.
• Neutron (com­po­nen­te di rete): quello che un tempo era chiamato Quantum, è ora un com­po­nen­te di sistema portabile, scalabile, capace di sup­por­ta­re le API, e che serve al controllo della rete. Questo modulo mette a di­spo­si­zio­ne un’in­ter­fac­cia per le topologie di rete più complesse e supporta diversi plugin, grazie ai quali è possibile integrare funzioni di rete ampliate.
• kuryr-lib­net­work (driver Docker): kuryr-lib­net­work è un driver per Docker che funge da in­ter­fac­cia tra Docker e Neutron.
• Keystone (servizio di identità): con Keystone, gli utenti di OpenStack di­spon­go­no di un servizio di identità centrale. Il modulo funge da sistema di au­ten­ti­ca­zio­ne e da sistema dei permessi tra i singoli com­po­nen­ti di OpenStack. Gli accessi ai progetti nel cloud vengono regolati at­tra­ver­so i co­sid­det­ti tenant (mandante). Ogni tenant rap­pre­sen­ta un’unità utente. Per ogni unità utente si possono definire diversi accessi con permessi utente dif­fe­ren­ti.
• Cinder (blocchi di memoria): Cinder è il nome di un com­po­nen­te dell’ar­chi­tet­tu­ra OpenStack che fornisce una memoria a blocchi per­si­sten­te per il fun­zio­na­men­to delle macchine virtuali. Il modulo mette a di­spo­si­zio­ne la memoria virtuale tramite un’API self service. Così gli utenti possono usufruire delle risorse di memoria, senza che sia visibile su quale di­spo­si­ti­vo venga messa a di­spo­si­zio­ne la memoria.
• Glance (servizio di immagine): con il modulo Glance, OpenStack mette a di­spo­si­zio­ne un servizio tramite il quale puoi ar­chi­via­re e ri­chia­ma­re le immagini delle macchine virtuali.

Ulteriori in­for­ma­zio­ni sui com­po­nen­ti e sui servizi OpenStack sono di­spo­ni­bi­li nel nostro articolo di ap­pro­fon­di­men­to su OpenStack. Oltre a questo com­po­nen­te, l’ar­chi­tet­tu­ra OpenStack può essere ampliata con vari moduli opzionali. Maggiori in­for­ma­zio­ni in merito sono di­spo­ni­bi­li sul sito web di OpenStack.

D2iQ DC/OS

DC/OS (Di­stri­bu­ted Cloud Operating System) è un software open source, svi­lup­pa­to da D2iQ Inc. (prima Me­so­sphe­re), per la gestione dei sistemi di­stri­bui­ti. Il progetto si fonda sul gestore di cluster open source Apache Mesos e va inteso come sistema operativo per i data center. Il codice sorgente è a di­spo­si­zio­ne degli utenti su GitHub con la versione 2 della licenza Apache. Inoltre, gli svi­lup­pa­to­ri e le svi­lup­pa­tri­ci hanno promosso una versione del software per le imprese su d2iq.com. Trovi una do­cu­men­ta­zio­ne det­ta­glia­ta del progetto su dcos.io. Considera DC/OS come un tipo di di­stri­bu­zio­ne Mesos, che mette a tua di­spo­si­zio­ne tutte le funzioni del gestore di cluster at­tra­ver­so un’in­ter­fac­cia centrale e che amplia Mesos.

DC/OS utilizza il sistema kernel di­stri­bui­to della piat­ta­for­ma Mesos. Questo permette di mettere in con­nes­sio­ne le risorse di un intero data center e am­mi­ni­strar­le sotto forma di un sistema aggregato, come fossero un singolo server logico. In questo modo gestisci l’intero cluster con macchine virtuali o fisiche con la stessa sem­pli­ci­tà, con la quale uti­liz­ze­re­sti un singolo computer.

Il software sem­pli­fi­ca l’in­stal­la­zio­ne e la gestione delle ap­pli­ca­zio­ni di­stri­bui­te e au­to­ma­tiz­za i compiti quali la gestione delle risorse, lo sche­du­ling e la co­mu­ni­ca­zio­ne tra processi. La gestione di un cluster tramite D2iQ DC/OS, così come di tutti i servizi eseguiti, avviene in maniera centrale tramite un programma a riga di comando (CLI) o un’in­ter­fac­cia web (GUI).

DC/OS astrae le risorse del cluster e mette a di­spo­si­zio­ne i servizi come, ad esempio, Service Discovery o il gestore di pacchetti. I com­po­nen­ti del software operano in uno spazio protetto: lo spazio kernel. Di questo fanno parte i programmi Master e Agent della piat­ta­for­ma Mesos, re­spon­sa­bi­li per la ca­ta­lo­ga­zio­ne delle risorse, l’iso­la­men­to dei processi e le funzioni di sicurezza.

• Mesos Master: per Mesos Master si intende un processo master che gira su un nodo master nel cluster. Il compito di Mesos Master è quello di con­trol­la­re la gestione delle risorse e di or­che­stra­re i task, ovvero le unità di lavoro astratte, che vengono eseguite su di un nodo agent. Inoltre, Mesos Master di­stri­bui­sce le risorse ai servizi DC/OS re­gi­stra­ti e accetta i rapporti sulle risorse dai vari Mesos Agent.
• Mesos Agent: per Mesos Agent si intende un processo slave che gira sui nodi agent e che è re­spon­sa­bi­le per l’ese­cu­zio­ne dei task di­stri­bui­ti dal master. I vari Mesos Agent for­ni­sco­no re­go­lar­men­te rapporti a Mesos Master sulle risorse di­spo­ni­bi­li nel cluster, i quali suc­ces­si­va­men­te vengono inoltrati a uno scheduler, come Marathon, Chronos o Cassandra. Lo scheduler decide a sua volta quale task deve essere eseguito su un nodo specifico. I task vengono eseguiti in iso­la­men­to in un con­te­ni­to­re.

Tutti gli altri com­po­nen­ti di sistema, quali le ap­pli­ca­zio­ni che vengono eseguite dai Mesos Agent tramite Executor, vengono svolte nello User Space o spazio utente. Tra i com­po­nen­ti base di un’in­stal­la­zio­ne standard di DC/OS vi sono Admin Router, Mesos DNS, un DNS Proxy di­stri­bui­to, il load balancer Minuteman, lo scheduler Marathon, Apache ZooKeeper ed Exhibitor.

• Admin Router: Admin Router è un server web con con­fi­gu­ra­zio­ne specifica, basato su NGINX, il quale mette a di­spo­si­zio­ne i servizi DC/OS, così come le funzioni centrali di au­ten­ti­ca­zio­ne e di proxy.
• Mesos DNS: il com­po­nen­te di sistema Mesos DNS offre delle funzioni di Service Discovery, che per­met­to­no ai singoli servizi e alle singole ap­pli­ca­zio­ni nel cluster di iden­ti­fi­car­si a vicenda at­tra­ver­so un Domain Name System (DNS) centrale.
• DNS Proxy di­stri­bui­to: per DNS Proxy di­stri­bui­to si intende un DNS Di­spat­cher interno, ovvero un sistema di­stri­bu­to­re di nomi di dominio.
• Minuteman: il com­po­nen­te di sistema Minuteman funge da load balancer interno, che lavora sul livello di trasporto del modello di ri­fe­ri­men­to ISO/OSI (livello 4).
• DC/OS Marathon: Marathon è un com­po­nen­te centrale della piat­ta­for­ma Mesos, che funge da sistema init (simile a systemd) all’interno di D2iQ DC/OS. Marathon avvia e controlla i servizi DC/OS e le ap­pli­ca­zio­ni all’interno degli ambienti di cluster. Inoltre, offre al software la funzione di alta di­spo­ni­bi­li­tà, Service Discovery, load balancer, controlli dello stato di salute e un’in­ter­fac­cia grafica.
• Apache ZooKeeper: per Apache ZooKeeper si intende un com­po­nen­te software open source, che mette a di­spo­si­zio­ne funzioni di coor­di­na­zio­ne per il fun­zio­na­men­to e l’am­mi­ni­stra­zio­ne di ap­pli­ca­zio­ni nei sistemi di­stri­bui­ti. Nell’ambito di D2iQ DC/OS, Zookeeper viene uti­liz­za­to per la coor­di­na­zio­ne di tutti servizi di sistema in­stal­la­ti.
• Exhibitor: Exhibitor è un com­po­nen­te di sistema con il quale si può in­stal­la­re au­to­ma­ti­ca­men­te e con­fi­gu­ra­re ZooKeeper su ogni nodo master. Inoltre, esso mette a di­spo­si­zio­ne un’in­ter­fac­cia utente grafica per gli utenti di ZooKeeper.

Sulle risorse cluster aggregate tramite DC/OS è possibile eseguire con­tem­po­ra­nea­men­te diversi carichi di lavoro. In questo modo, il sistema operativo del cluster permette ad esempio una gestione parallela di sistemi di Big Data, di mi­cro­ser­vi­zi o di piat­ta­for­me container come Hadoop, Spark e Docker.

Con D2iQ Universe viene messo a di­spo­si­zio­ne per DC/OS un catalogo pubblico delle app. Tramite esso puoi in­stal­la­re ap­pli­ca­zio­ni come Spark, Cassandra, Chronos, Jenkins o Kafka in modo pratico e con un semplice clic, grazie all’in­ter­fac­cia grafica.

Strumenti Docker per la sicurezza

Anche se i processi in­cap­su­la­ti nei container girano sullo stesso kernel, Docker usa diverse tec­no­lo­gie di iso­la­zio­ne per pro­teg­ger­li gli uni dagli altri. Vengono uti­liz­za­te so­prat­tut­to le funzioni cardine del kernel di Linux, come cgroup e namespace.

Tuttavia, i container non offrono lo stesso grado di iso­la­men­to delle macchine virtuali. No­no­stan­te le tecniche di iso­la­men­to descritte, im­por­tan­ti sot­to­si­ste­mi del kernel, come cgroups e le in­ter­fac­ce del kernel nelle directory /sys e /proc, possono essere ac­ces­si­bi­li dai container. Anche il team di sviluppo di Docker ha ri­co­no­sciu­to i dubbi relativi alla sicurezza come freni per l’af­fer­ma­zio­ne della tec­no­lo­gia container sui sistemi pro­dut­ti­vi. Oltre alle tec­no­lo­gie di iso­la­men­to che stanno alla base del kernel di Linux, le nuove versioni di Docker Engine sup­por­ta­no perciò i framework AppArmor, SELinux e Seccomp, che fungono come una sorta di firewall per le risorse kernel.

• AppArmor: con AppArmor si re­go­la­men­ta­no i permessi di accesso dei container sul file system.
• SELinux: SELinux offre un complesso sistema di regole con il quale si può im­ple­men­ta­re il controllo sugli accessi alle risorse kernel.
• Seccomp: con Seccomp (Secure Computing Mode) viene sor­ve­glia­to il fun­zio­na­men­to di Sy­stem­calls.

Oltre a questi strumenti, Docker utilizza le co­sid­det­te Linux ca­pa­bi­li­ties (capacità Linux), che possono essere uti­liz­za­te per limitare i permessi di root con cui Docker Engine avvia i container.

Ulteriori pre­oc­cu­pa­zio­ni relative alla sicurezza dipendono dalle vul­ne­ra­bi­li­tà dei software in relazione ai com­po­nen­ti delle ap­pli­ca­zio­ni, i quali vengono diffusi at­tra­ver­so il registry di Docker. Poiché, teo­ri­ca­men­te, chiunque può creare immagini Docker e renderle pub­bli­ca­men­te ac­ces­si­bi­li alla community su Docker Hub, esiste il rischio di in­tro­dur­re codice dannoso nel proprio sistema come parte di un’immagine scaricata. Gli utenti di Docker do­vreb­be­ro quindi as­si­cu­rar­si che tutto il codice fornito in un’immagine per l’ese­cu­zio­ne di container provenga da una fonte af­fi­da­bi­le prima di di­stri­bui­re un’ap­pli­ca­zio­ne.

Docker offre un programma di cer­ti­fi­ca­zio­ne, che i fornitori di software possono uti­liz­za­re per far con­trol­la­re e cer­ti­fi­ca­re le loro immagini. In questo modo, Docker vuole rendere più facile per gli svi­lup­pa­to­ri e le svi­lup­pa­tri­ci costruire catene di ap­prov­vi­gio­na­men­to software sicure per i loro progetti.

Oltre ad aumentare la sicurezza per gli utenti, il programma intende offrire agli svi­lup­pa­to­ri e alle svi­lup­pa­tri­ci di software l’op­por­tu­ni­tà di dif­fe­ren­zia­re i propri progetti dalla mol­ti­tu­di­ne di risorse di­spo­ni­bi­li. Le immagini cer­ti­fi­ca­te ottengono, tra l’altro, una posizione più elevata nei risultati di ricerca di Docker Hub e sono con­tras­se­gna­te da un badge “Verified Publisher” (fornitore ve­ri­fi­ca­to).