Gli strumenti Docker

Il vasto ecosistema Docker offre agli sviluppatori e alle sviluppatrici molte opzioni per la distribuzione delle applicazioni, l’orchestrazione dei container e molto altro. Ti presentiamo gli strumenti Docker più importanti e ti forniamo una panoramica dei progetti di terze parti più popolari, in cui vengono sviluppati strumenti Docker open source.

Gli strumenti e i componenti di Docker essenziali

Oggigiorno Docker è molto di più che una semplice piattaforma per la gestione di software container. Per gestire il deployment, ovvero la messa a disposizione di applicazioni, attraverso infrastrutture distribuite e ambienti cloud in maniera più semplice, più veloce e più flessibile, il team di sviluppo ha dotato il software centrale di diversi strumenti Docker. Oltre alle funzioni cluster e di orchestrazione, 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 solitamente intesa un’applicazione open source di tipo client-server, la quale sta alla base della piattaforma container. Tale applicazione viene chiamata “Docker Engine” nella terminologia specifica di Docker. I componenti centrali di Docker Engine sono Docker Daemon, un’API REST e una CLI (Command Line Interface) come interfaccia utente. Questa struttura ti consente di richiamare 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 approfondimento trovi una panoramica dei comandi Docker più importanti.

Docker Hub

Con Docker Hub, il progetto open source mette a disposizione degli utenti un registry basato su cloud, tramite il quale è possibile scaricare, gestire in maniera centralizzata e condividere con altri utenti le immagini di Docker. Gli utenti registrati possono archiviare le proprie immagini di Docker su repository pubblici o privati. Un tag integrato consente di creare più versioni delle immagini.

Oltre ai repository pubblici degli altri utenti di Docker, anche nell’hub hai a disposizione molte risorse, messe a disposizione in archivi ufficiali di immagini dal team di sviluppo di Docker e da altri progetti open source conosciuti. Tra le immagini più scaricate si annoverano il server web leggero NGINX, il database in-memory Redis, il toolkit di Unix BusyBox e la distribuzione Linux Ubuntu.

Tra le altre funzioni di Docker Hub rientrano le cosiddette Organizations, ovvero dei gruppi di lavoro, che permettono agli utenti della piattaforma di mettere a disposizione i repository privati solo a determinate cerchie di persone. I permessi di accesso vengono gestiti internamente tra team e gruppi di pertinenza.

Docker Swarm

Docker Engine dispone di funzioni native che permettono la gestione degli host di Docker in cluster, i cosiddetti sciami (Swarms). Le funzioni di gestione dei cluster e di orchestrazione integrate in Docker Engine si basano sul toolbox Swarmkit.

Lo strumento di clustering di Docker Swarm raggruppa una serie di host Docker in un singolo host virtuale e serve al funzionamento delle API REST di Docker. In questo modo ogni strumento di Docker che è in collegamento con Docker Daemon può affidarsi a Swarm ed essere regolato su un numero qualsiasi di host Docker. Gli utenti utilizzano le CLI di Docker Engine per creare gli sciami, controllarne il comportamento e distribuire le applicazioni nel cluster. Un software di orchestrazione aggiuntivo non è perciò necessario.

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 aggiungere 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 funzionare come host virtuali sullo stesso sistema locale, più spesso riscontrabile è tuttavia una struttura basata su cloud, presso la quale i singoli nodi dello sciame Docker vengono distribuiti su diversi sistemi e infrastrutture.

Il software si basa su un’architettura master-slave. Nel caso in cui dei compiti vengano suddivisi all’interno dello sciame, gli utenti inviano un cosiddetto Service al manager node, il quale funge da master del cluster. Questo master è responsabile per la pianificazione dei container nel cluster e serve come interfaccia utente primaria per poter accedere alle risorse dello sciame.

Il manager node invia singole unità di lavoro, chiamate task, agli slave subordinati, conosciuti come “worker nodes” nella terminologia 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, specificano all’interno di questi quale immagine e quale comando debbano essere utilizzati. Inoltre, i Services offrono la possibilità di scalare le applicazioni. Gli utenti della piattaforma Docker definiscono in aggiunta il numero di container che devono essere avviati per un determinato servizio.
• Task: per poter distribuire 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 impostazioni standard, oltre alle funzioni per la gestione dei cluster e per l’orchestrazione dei container, i manager node offrono anche funzionalità 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 consegnare al relativo master node un aggiornamento sull’avanzamento degli incarichi che sono stati trasmessi. Il seguente grafico mostra una rappresentazione schematica di uno Swarm Docker.

Con l’implementazione di uno sciame di Docker, gli utenti ricorrono solitamente 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 linguaggio di markup YAML. La sintassi di questi file di Compose assomiglia a quella del software open source Vagrant, utilizzato per la creazione e la fornitura delle macchine virtuali.

Nel file docker-compose.yml definisci il numero che preferisci di software container, incluse le relative subordinazioni e relazioni tra di loro. Tali applicazioni multi-container vengono gestite secondo lo stesso schema dei singoli container. Utilizza il comando docker-compose in combinazione con il sottocomando desiderato per gestire l’intero ciclo di vita dell’applicazione.

Lo strumento di Docker è facilmente integrabile in un cluster basato su Swarm. In questo modo, con Compose, esegui facilmente le applicazioni multi-container create sia sui vari sistemi distribuiti, sia su un singolo host di Docker.

Un’ulteriore funzione di Docker Compose è il meccanismo di regolazione integrato. Utilizzando la riga di comando, con lo strumento di orchestrazione definisci facilmente quanti container desideri avviare per un determinato servizio.

Gli strumenti Docker sviluppati da fornitori esterni

Oltre agli sviluppi ottenuti dallo sviluppatore stesso, Docker Inc., si possono trovare diversi altri strumenti software e piattaforme di fornitori esterni, i quali mettono a disposizione le interfacce per Docker Engine o per la piattaforma di container che preferisci. Tra i progetti open source più conosciuti dell’ecosistema di Docker si annoverano lo strumento per l’orchestrazione Kubernetes, lo strumento per la gestione dei cluster Shipyard, la soluzione multi-container per Docker Panamax, la piattaforma di integrazione 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.

Kubernetes

Gli strumenti di orchestrazione disponibili 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 concentrare i propri sforzi su strumenti fatti su misura, i quali dovrebbero semplificare il compito di gestire la piattaforma di container in grandi infrastrutture distribuite. Tra le soluzioni più conosciute di questo tipo vi è il progetto open source Kubernetes.

Con Kubernetes si ha a disposizione un gestore di cluster per le applicazioni basate su container. Lo scopo di Kubernetes è quello di automatizzare le applicazioni nel cluster. Lo strumento di orchestrazione utilizza anche un’API REST, il programma a riga di comando e un’interfaccia web grafica come interfacce di gestione, attraverso le quali gli automatismi possono essere messi in moto e può essere richiesto il rapporto sulla situazione attuale. Gli utenti utilizzano Kubernetes per i seguenti motivi:

• eseguire le applicazioni basate su container in un cluster;
• configurare e gestire le applicazioni nei vari sistemi distribuiti;
• regolare le applicazioni;
• sfruttare al meglio la disponibilità degli hardware presenti.

Inoltre, Kubernetes raggruppa i container all’interno di una sezione logica, il cosiddetto Pod. I pod rappresentano le unità di base dei gestori di cluster, le quali possono essere suddivise in cluster tramite il processo di scheduling.

Come per gli sciami di Docker, anche alla base di Kubernetes vi è un’architettura master-slave. Un cluster si basa sia su un master Kubernetes sia su una grande quantità di slave, i cosiddetti Kubernetes Node, anche chiamati Kubernetes Worker o Kubernetes Minion. Il master Kubernetes funge da livello di controllo centrale (in inglese “Control Plane”) all’interno del cluster e si compone di quattro componenti di base, i quali rendono possibile la gestione della comunicazione nel cluster e la distribuzione dei compiti. Un master Kubernetes include anche un server API, una memoria di configurazione etcd, uno scheduler e un controller manager.

• Server API: tutti gli automatismi nel cluster Kubernetes vengono messi in moto tramite le API REST su un server API. Questo funziona come interfaccia di amministrazione centrale all’interno del cluster.
• etcd: immagina la memoria di configurazione open source etcd come la memoria di un cluster Kubernetes. Il database coppia-valore (key-value store), sviluppato da CoreOS specificamente per i sistemi distribuiti, archivia i dati di configurazione e li mette a disposizione di ogni nodo del cluster. Attraverso etcd è possibile gestire in ogni momento lo stato attuale del cluster.
• Scheduler: lo scheduler è responsabile per la distribuzione dei gruppi container (pod) all’interno del cluster. Inoltre, esso comunica a questi le risorse necessarie di ogni pod e le equipara con le risorse disponibili dei singoli nodi.
• Controller manager: il controller manager è un servizio del master di Kubernetes che regola lo stato del cluster, esegue i compiti di routine e gestisce quindi l’orchestrazione. Il compito principale del controller manager è quello di fare in modo che lo stato del cluster corrisponda a quello dell’obiettivo predefinito.

Tutti i componenti del master di Kubernetes possono essere basati su uno stesso host o, nel caso di un cluster ad alta disponibilità, possono essere distribuiti tra più host master.

Mentre il master di Kubernetes è responsabile dell’orchestrazione, i pod distribuiti nel cluster vengono eseguiti sugli host dipendenti dal master, ovvero i nodi Kubernetes. Inoltre, su ogni nodo Kubernetes deve operare un container engine. Docker rappresenta lo standard a tutti gli effetti. Da un punto di vista teorico, Kubernetes non è vincolato ad alcun container engine specifico.

Oltre al container engine, i nodi Kubernetes comprendono anche i seguenti componenti:

• kubelet: kubelet è un agent che viene eseguito su ogni nodo Kubernetes e serve al controllo e alla gestione dei nodi. In quanto punto di contatto centrale di ogni nodo, kubelet è in contatto con il master Kubernetes e assicura che le informazioni siano inoltrate e ricevute dal livello di controllo.
• kube-proxy: su ogni nodo Kubernetes gira anche kube-proxy, un servizio proxy. Questo deve far sì che le richieste ai vari container, provenienti dall’esterno, giungano a destinazione, e che agli utenti vengano messi a disposizione i servizi delle applicazioni basate su container. Inoltre kube-proxy offre un load balancer rudimentale.

Il seguente grafico mostra una rappresentazione schematica dell’architettura master-slave, alla base della piattaforma di orchestrazione Kubernetes:

Oltre alle funzionalità centrali del progetto Kubernetes, puoi trovare numerosi altri strumenti ed estensioni che ti permetteranno di dotare la piattaforma di orchestrazione di funzioni aggiuntive. Tra le più famose vi sono gli strumenti per il monitoraggio e per la diagnosi degli errori Prometheus, 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 configurazione di Kubernetes da remoto.

Shipyard

Shipyard è una delle soluzioni gestionali basate su Swarm, sviluppata 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’interfaccia utente grafica. È disponibile come applicazione web dal browser.

Il software è compatibile al 100% con la Remote API di Docker e usa RethinkDB, il database NoSQL open source, come memoria di archiviazione per gli account utente, gli indirizzi e gli eventi.

Oltre alle funzioni di gestione dei cluster attraverso l’interfaccia web centrale, Shipyard mette a disposizione un’autenticazione utente, così come anche la possibilità di controllare gli accessi in base ai ruoli.

Il software si basa sul toolkit di gestione dei cluster Citadel e si compone sostanzialmente di tre componenti fondamentali: Controller, API e UI.

• Shipyard Controller: il controller è il componente centrale dello strumento di gestione Shipyard. Il controller interagisce con il database RethinkDB nell’ambito dell’archiviazione dei dati e permette di interagire 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 configurate attraverso questa API.
• Shipyard User Interface (UI): l’interfaccia utente Shipyard è un’app di AngularJS che mette a disposizione degli utenti un’interfaccia utente grafica per la gestione dei cluster di Docker direttamente dal browser. Tutte le interazioni nell’interfaccia utente avvengono tramite l’API di Shipyard.

Trovi ulteriori informazioni su Shipyard sul sito web ufficiale del progetto open source.

Panamax

Il team di sviluppo dello strumento Docker open source Panamax si è prefissato come obiettivo quello di semplificare la fornitura delle app multi-container. Lo strumento gratuito offre agli utenti un’interfaccia grafica tramite la quale è possibile sviluppare, mettere a disposizione e distribuire le applicazioni complesse basate sui container Docker in maniera agile tramite drag and drop.

Panamax permette di archiviare le complesse applicazioni multi-container come cosiddetti application template e quindi di distribuirle con un semplice clic all’interno delle architetture dei cluster. Tramite un mercato per le app, ospitato su GitHub, è possibile archiviare nei repository Git i template delle app create autonomamente e metterli a disposizione degli altri utenti.

I componenti di base dell’architettura di Panamax sono suddivisibili in due gruppi: si distingue tra Panamax Local Client e un numero qualsiasi di cosiddetti remote deployment target.

Panamax Local Client è il componente centrale dello strumento Docker. Questo viene eseguito sul sistema locale e permette di creare applicazioni complesse basate su container. Il local client si compone dei seguenti componenti:

• CoreOS: l’installazione di Panamax Local Client prevede come sistema host CoreOS, il software container rivolto specialmente alla distribuzione di Linux. Il client di Panamax viene eseguito come container Docker su CoreOS. Con Panamax, gli utenti hanno a disposizione diverse funzioni CoreOS e Docker. Tra queste vi sono Fleet e Journalctl:

  • Fleet: invece di interagire direttamente con Docker, il client di Panamax utilizza il cluster manager Fleet per orchestrare i container. Fleet è un gestore di cluster che controlla systemd, il demone di Linux, all’interno dei cluster del computer.
  • Journalctl: il client di Panamax utilizza Journalctl per esaminare i messaggi di log del gestore di sistema Linux systemd dal cosiddetto Journal.

• Local Client Installer: il Local Client Installer contiene tutti i componenti necessari per installare il client di Panamax sul sistema locale.

• Panamax Local Agent: il componente centrale del local client è il local agent. Questo è connesso tramite l’API di Panamax con diversi altri componenti e funzioni. Inoltre, vi sono anche l’host locale di Docker, la Panamax UI, i registry esterni, così come i remote agent, che fanno affidamento sui deployment target all’interno del cluster. Il local agent interagisce nel sistema locale con le seguenti interfacce di programmazione, tramite l’API di Panamax, in modo da scambiare informazioni con le applicazioni in esecuzione:

  • Docker Remote API: tramite la Docker Remote API, Panamax cerca immagini sul sistema locale, richiamando le informazioni di stato riguardanti i container in esecuzione.
  • 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 richiamare il Journal Output dei servizi in esecuzione.

Inoltre, l’API di Panamax rende possibile le interazioni con diverse API esterne.

• Docker Registry API: attraverso 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 repository di GitHub.
• KissMetrics API: la KissMetrics API raccoglie i dati riguardo ai template eseguiti dagli utenti.
• Panamax UI: la Panamax UI serve come interfaccia utente sul sistema locale e permette agli utenti di gestire lo strumento Docker tramite un’interfaccia grafica. Tramite l’API di Panamax le immissioni degli utenti vengono inoltrate direttamente al local agent. La Panamax UI si basa su CTL Base UI Kit, una libreria con componenti UI per i progetti web di CenturyLink.

Ogni nodo in un cluster Docker senza compiti di gestione viene chiamato Remote Deployment Target, secondo la terminologia Panamax. I deployment target sono composti di un host Docker, il quale è configurato per la distribuzione dei template Panamax grazie ai seguenti componenti:

• Deployment Target Installer: Deployment Target Installer avvia un host Docker, inclusi il Panamax Remote Agent e l’Orchestration Adapter (l’adattatore di orchestrazione).
• Panamax Remote Agent: installando Panamax Remote Agent, è possibile distribuire le applicazioni 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 deployment target.
• Panamax Orchestration Adapter: nell’adattatore di orchestrazione viene messa a disposizione, all’interno di un livello Adapter indipendente, la logica del programma di ogni strumento di orchestrazione di Panamax. In questo modo gli utenti hanno la possibilità di scegliere sempre esattamente la tecnologia di orchestrazione che preferiscono, con il supporto dell’ambiente relativo. Sia Kubernetes che Fleet possiedono i rispettivi adattatori preconfigurati:
  • Panamax-Kubernetes-Adapter: Panamax Kubernetes Adapter, in combinazione con Panamax Remote Agent, permette di distribuire i template Panamax tra i cluster Kubernetes.
  • Panamax-Fleet-Adapter: Panamax Fleet Adapter, in combinazione con Panamax Remote Agent, permette di distribuire i template Panamax nei cluster controllati tramite il gestore di cluster di Fleet.

Il grafico seguente mostra la cooperazione dei singoli componenti di Panamax all’interno di un cluster Docker:

Lo strumento di gestione di container Panamax, basato su CoreOS, offre agli utenti diversi standard tecnologici per l’orchestrazione dei container attraverso un’interfaccia utente grafica, così come la possibilità di gestire applicazioni multi-container complesse nelle architetture cluster attraverso il sistema che si preferisce, come ad esempio quello del proprio notebook.

Con il Public Template Repository, Panamax mette a disposizione dei propri utenti, tramite GitHub, una libreria template pubblica con diverse risorse.

Drone

Drone è una piattaforma di integrazione continua leggera e con pochi prerequisiti. Con lo strumento Docker, è possibile caricare automaticamente l’ultima build da un repository Git come GitHub ed eseguirla in container Docker isolati a scopo di test. Hai la possibilità 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 accessibile pubblicamente può essere utilizzata come ambiente per il codice da testare.

Drone è integrato in Docker e supporta diversi linguaggi di programmazione, come PHP, Node.js, Ruby, Go e Python. L’unica condizione necessaria per il funzionamento di Drone è la piattaforma di container. Con Drone crei la tua piattaforma di integrazione continua personale per tutti i sistemi sui quali è possibile installare Docker. Inoltre, supporta più repository di controllo delle versioni. Trovi una guida all’installazione standard con l’integrazione di GitHub nella documentazione del progetto open source, sul sito readme.drone.io.

Il controllo della piattaforma di integrazione continua avviene tramite l’interfaccia web. Attraverso tale interfaccia carichi le build direttamente dal repository Git desiderato, metti in collegamento le applicazioni e avvii ciò che ne risulta in un ambiente di test precedentemente definito. Inoltre, per ogni test del software eseguito, viene definito un file .drone.yml, all’interno del quale viene stabilito quali applicazioni debbano essere usate per la creazione dell’applicazione finale e come quest’ultima debba essere eseguita.

Con Drone viene messa a disposizione degli utenti una soluzione CI open source, che riunisce i punti di forza di prodotti alternativi come Travis e Jenkins in un’applicazione dall’interfaccia utente user-friendly.

OpenStack

Quando si tratta dell’architettura 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 disposizione degli utenti finali tramite un’interfaccia web.

Il sistema operativo cloud si basa su un’architettura modulare, composta da più componenti:

• • Zun (servizio container): Zun è il servizio container di OpenStack che consente una facile distribuzione e gestione di applicazioni containerizzate nel cloud OpenStack. Il suo scopo è quello di consentire agli utenti di gestire i container tramite un’API REST senza dover gestire server o cluster. Zun richiede l’esecuzione di altri tre servizi OpenStack: Keystone, Neutron e kuryr-libnetwork. Opzionalmente, la funzionalità di Zun può essere estesa da altri servizi OpenStack, come Cinder e Glance.
• Neutron (componente di rete): quello che un tempo era chiamato Quantum, è ora un componente di sistema portabile, scalabile, capace di supportare le API, e che serve al controllo della rete. Questo modulo mette a disposizione un’interfaccia per le topologie di rete più complesse e supporta diversi plugin, grazie ai quali è possibile integrare funzioni di rete ampliate.
• kuryr-libnetwork (driver Docker): kuryr-libnetwork è un driver per Docker che funge da interfaccia tra Docker e Neutron.
• Keystone (servizio di identità): con Keystone, gli utenti di OpenStack dispongono di un servizio di identità centrale. Il modulo funge da sistema di autenticazione e da sistema dei permessi tra i singoli componenti di OpenStack. Gli accessi ai progetti nel cloud vengono regolati attraverso i cosiddetti tenant (mandante). Ogni tenant rappresenta un’unità utente. Per ogni unità utente si possono definire diversi accessi con permessi utente differenti.
• Cinder (blocchi di memoria): Cinder è il nome di un componente dell’architettura OpenStack che fornisce una memoria a blocchi persistente per il funzionamento delle macchine virtuali. Il modulo mette a disposizione la memoria virtuale tramite un’API self service. Così gli utenti possono usufruire delle risorse di memoria, senza che sia visibile su quale dispositivo venga messa a disposizione la memoria.
• Glance (servizio di immagine): con il modulo Glance, OpenStack mette a disposizione un servizio tramite il quale puoi archiviare e richiamare le immagini delle macchine virtuali.

Ulteriori informazioni sui componenti e sui servizi OpenStack sono disponibili nel nostro articolo di approfondimento su OpenStack. Oltre a questo componente, l’architettura OpenStack può essere ampliata con vari moduli opzionali. Maggiori informazioni in merito sono disponibili sul sito web di OpenStack.

D2iQ DC/OS

DC/OS (Distributed Cloud Operating System) è un software open source, sviluppato da D2iQ Inc. (prima Mesosphere), per la gestione dei sistemi distribuiti. 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 disposizione degli utenti su GitHub con la versione 2 della licenza Apache. Inoltre, gli sviluppatori e le sviluppatrici hanno promosso una versione del software per le imprese su d2iq.com. Trovi una documentazione dettagliata del progetto su dcos.io. Considera DC/OS come un tipo di distribuzione Mesos, che mette a tua disposizione tutte le funzioni del gestore di cluster attraverso un’interfaccia centrale e che amplia Mesos.

DC/OS utilizza il sistema kernel distribuito della piattaforma Mesos. Questo permette di mettere in connessione le risorse di un intero data center e amministrarle 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 semplicità, con la quale utilizzeresti un singolo computer.

Il software semplifica l’installazione e la gestione delle applicazioni distribuite e automatizza i compiti quali la gestione delle risorse, lo scheduling e la comunicazione 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’interfaccia web (GUI).

DC/OS astrae le risorse del cluster e mette a disposizione i servizi come, ad esempio, Service Discovery o il gestore di pacchetti. I componenti del software operano in uno spazio protetto: lo spazio kernel. Di questo fanno parte i programmi Master e Agent della piattaforma Mesos, responsabili per la catalogazione delle risorse, l’isolamento 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 controllare la gestione delle risorse e di orchestrare i task, ovvero le unità di lavoro astratte, che vengono eseguite su di un nodo agent. Inoltre, Mesos Master distribuisce le risorse ai servizi DC/OS registrati 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 è responsabile per l’esecuzione dei task distribuiti dal master. I vari Mesos Agent forniscono regolarmente rapporti a Mesos Master sulle risorse disponibili nel cluster, i quali successivamente 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 isolamento in un contenitore.

Tutti gli altri componenti di sistema, quali le applicazioni che vengono eseguite dai Mesos Agent tramite Executor, vengono svolte nello User Space o spazio utente. Tra i componenti base di un’installazione standard di DC/OS vi sono Admin Router, Mesos DNS, un DNS Proxy distribuito, il load balancer Minuteman, lo scheduler Marathon, Apache ZooKeeper ed Exhibitor.

• Admin Router: Admin Router è un server web con configurazione specifica, basato su NGINX, il quale mette a disposizione i servizi DC/OS, così come le funzioni centrali di autenticazione e di proxy.
• Mesos DNS: il componente di sistema Mesos DNS offre delle funzioni di Service Discovery, che permettono ai singoli servizi e alle singole applicazioni nel cluster di identificarsi a vicenda attraverso un Domain Name System (DNS) centrale.
• DNS Proxy distribuito: per DNS Proxy distribuito si intende un DNS Dispatcher interno, ovvero un sistema distributore di nomi di dominio.
• Minuteman: il componente di sistema Minuteman funge da load balancer interno, che lavora sul livello di trasporto del modello di riferimento ISO/OSI (livello 4).
• DC/OS Marathon: Marathon è un componente centrale della piattaforma 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 applicazioni all’interno degli ambienti di cluster. Inoltre, offre al software la funzione di alta disponibilità, Service Discovery, load balancer, controlli dello stato di salute e un’interfaccia grafica.
• Apache ZooKeeper: per Apache ZooKeeper si intende un componente software open source, che mette a disposizione funzioni di coordinazione per il funzionamento e l’amministrazione di applicazioni nei sistemi distribuiti. Nell’ambito di D2iQ DC/OS, Zookeeper viene utilizzato per la coordinazione di tutti servizi di sistema installati.
• Exhibitor: Exhibitor è un componente di sistema con il quale si può installare automaticamente e configurare ZooKeeper su ogni nodo master. Inoltre, esso mette a disposizione un’interfaccia utente grafica per gli utenti di ZooKeeper.

Sulle risorse cluster aggregate tramite DC/OS è possibile eseguire contemporaneamente diversi carichi di lavoro. In questo modo, il sistema operativo del cluster permette ad esempio una gestione parallela di sistemi di Big Data, di microservizi o di piattaforme container come Hadoop, Spark e Docker.

Con D2iQ Universe viene messo a disposizione per DC/OS un catalogo pubblico delle app. Tramite esso puoi installare applicazioni come Spark, Cassandra, Chronos, Jenkins o Kafka in modo pratico e con un semplice clic, grazie all’interfaccia grafica.

Strumenti Docker per la sicurezza

Anche se i processi incapsulati nei container girano sullo stesso kernel, Docker usa diverse tecnologie di isolazione per proteggerli gli uni dagli altri. Vengono utilizzate soprattutto le funzioni cardine del kernel di Linux, come cgroup e namespace.

Tuttavia, i container non offrono lo stesso grado di isolamento delle macchine virtuali. Nonostante le tecniche di isolamento descritte, importanti sottosistemi del kernel, come cgroups e le interfacce del kernel nelle directory /sys e /proc, possono essere accessibili dai container. Anche il team di sviluppo di Docker ha riconosciuto i dubbi relativi alla sicurezza come freni per l’affermazione della tecnologia container sui sistemi produttivi. Oltre alle tecnologie di isolamento che stanno alla base del kernel di Linux, le nuove versioni di Docker Engine supportano perciò i framework AppArmor, SELinux e Seccomp, che fungono come una sorta di firewall per le risorse kernel.

• AppArmor: con AppArmor si regolamentano i permessi di accesso dei container sul file system.
• SELinux: SELinux offre un complesso sistema di regole con il quale si può implementare il controllo sugli accessi alle risorse kernel.
• Seccomp: con Seccomp (Secure Computing Mode) viene sorvegliato il funzionamento di Systemcalls.

Oltre a questi strumenti, Docker utilizza le cosiddette Linux capabilities (capacità Linux), che possono essere utilizzate per limitare i permessi di root con cui Docker Engine avvia i container.

Ulteriori preoccupazioni relative alla sicurezza dipendono dalle vulnerabilità dei software in relazione ai componenti delle applicazioni, i quali vengono diffusi attraverso il registry di Docker. Poiché, teoricamente, chiunque può creare immagini Docker e renderle pubblicamente accessibili alla community su Docker Hub, esiste il rischio di introdurre codice dannoso nel proprio sistema come parte di un’immagine scaricata. Gli utenti di Docker dovrebbero quindi assicurarsi che tutto il codice fornito in un’immagine per l’esecuzione di container provenga da una fonte affidabile prima di distribuire un’applicazione.

Docker offre un programma di certificazione, che i fornitori di software possono utilizzare per far controllare e certificare le loro immagini. In questo modo, Docker vuole rendere più facile per gli sviluppatori e le sviluppatrici costruire catene di approvvigionamento software sicure per i loro progetti.

Oltre ad aumentare la sicurezza per gli utenti, il programma intende offrire agli sviluppatori e alle sviluppatrici di software l’opportunità di differenziare i propri progetti dalla moltitudine di risorse disponibili. Le immagini certificate ottengono, tra l’altro, una posizione più elevata nei risultati di ricerca di Docker Hub e sono contrassegnate da un badge “Verified Publisher” (fornitore verificato).