L’ecosistema Docker: panoramica sui più popolari tool di Docker

Nel giro di pochi anni il nome “Docker” è praticamente diventato un sinonimo per la tecnologia container nell’ambito dei software. All’azienda è riuscito di ravvivare le funzioni centrali di Linux che servono come fondamenta per la virtualizzazione a livello di sistema operativo e, grazie ad uno standard multipiattaforma sviluppato autonomamente, a stabilirsi come alternativa per gli hardware di virtualizzazione capaci di supportare l’hypervisor.

Consiglio

Docker utilizza l’interfaccia LibContainer, sviluppata autonomamente, una combinazione tra un driver e una libreria, al fine di gestire le funzioni principali di Linux e di rendere disponibili una schiera di tecnologie di isolamento come namespaces, Control Groups, AppArmor, profili di sicurezza, interfacce di rete e regole firewall per la gestione dei software container. Questo software open source è la condizione necessaria per RunC e Daemon ContainerD (gli ambienti di runtime dei container di Docker), i quali si basano sugli standard delle norme industriali della Open Container Initiative (OCI), e che vengono sviluppati come progetti non appartenenti ad alcun provider specifico sotto licenza open source.

Docker vanta un basso livello di difficoltà iniziale, offre agli sviluppatori e agli amministratori, con i suoi servizi online quali Docker Hub o Docker Cloud, una soluzione completa perfettamente integrata per il collaudo del software e il funzionamento su varie piattaforme delle applicazioni basate su container. Chiaramente però il ruolo di ambiente di test non è sufficiente a racchiudere l’intera essenza della piattaforma container.

L’obiettivo del progetto del software open source è quello di rendere la tecnologia container lo standard per la messa a disposizione di applicazioni per sistemi produttivi. Naturalmente questa intenzione porta con sé numerose sfide, che il Docker Engine da solo non è in grado di superare. Tutto ciò riguarda la gestione delle app multi-container, l’orchestrazione di container in sistemi distribuiti e ambienti cloud, così come la scalabilità delle varie applicazioni basate su container.

Il progetto principale è stato affiancato col tempo da numerosi progetti satellite, che hanno apportato al motore di Docker, il Docker Engine, nuove e performanti funzioni per l’utilizzo produttivo. Inoltre è possibile trovare su base open source un ecosistema vibrante di tool e piattaforme esterne, che mettono a disposizione nuove interfacce per Docker, e che offrono agli utilizzatori di suddividere le app basate su container tra tre diverse infrastrutture: cloud, in un ambiente locale (on-premises) o in uno ibrido.

Vi illustriamo le estensioni maggiori per questa piattaforma e vi offriamo una panoramica sui progetti più popolari sviluppati su base open source da terze parti.

Le estensioni di Docker e i servizi online

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 provvisto il software centrale con diverse estensioni e servizi online. Oltre alle funzioni cluster e di orchestrazione, esse 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. Componenti centrali del Docker Engine sono il Docker Daemon, una REST API e una CLI (Command Line Interface) come interfaccia utente. Questa struttura vi consente di interpellare il Docker engine tramite i comandi dati dalla riga di comando e di gestire immagini, file di Docker e container dal terminale. 

Una descrizione dettagliata del Docker Engine la potete trovare nel nostro tutorial di Docker per principianti.

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. Il download di un’immagine Docker pubblica, chiamata pull nella terminologia di Docker, non richiede il possesso di un account utente. Un tag integrato consente di versioning delle immagini.

Oltre ai repository pubblici degli altri utenti di Docker, anche nell’hub avete a disposizione molte risorse, le quali sono state 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, l’in-memory database Redis, il toolkit di Unix BusyBox e la distribuzione Linux Ubuntu.

Un’ulteriore funzione del Docker Hub sono i cosiddetti Organization, 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 Machine

Docker Machine rende possibile il funzionamento e la gestione degli host di Docker praticamente su qualsiasi infrastruttura. Il tool automatizza l’implementazione di Docker e semplifica in modo decisivo la fornitura dei Docker Host.

Il team di sviluppo indica gli host virtuali, sui quali funziona il Docker Engine, con il nome di “Docker Host” o “Dockerized Host”. Mentre con qualsiasi distribuzione di Linux questi host sono nativi e possono quindi essere eseguiti senza problemi, con i sistemi operativi macOS e Windows l’utilizzo di Docker richiede precedentemente un livello di astrazione sotto forma di Docker Machine. Tuttavia questo è stato fondamentalmente modificato con il release della versione 1.12. Allo stato attuale le funzionalità multipiattaforma di Docker sono disponibili anche per Windows e macOS. Il campo d’applicazione di Docker Machine è perciò mutato, spostandosi verso il controllo remoto e la gestione dei Docker Host negli ambienti cloud.

Nel caso in cui in una singola rete o su delle infrastrutture cloud come Amazon Web Services (AWS) o DigitalOcean vengano eseguiti un gran numero di nodi Docker, prima o poi gli utenti si rimbatteranno nella Docker Machine. Il tool riduce la creazione di nuovi Docker Host a un semplice ordine a riga di comando, ovvero docker-machine create, e permette la gestione di vari nodi Docker dal terminale. La Docker Machine si prende carico della creazione di un SSL-PKI così come della distribuzione dei certificati necessari per l’autentificazione degli utenti. In combinazione con Docker Swarm il software serve a rendere disponibili i Docker Cluster.

La Docker Machine è solitamente utilizzata nei sistemi locali. Il Docker Tool crea in automatico nuovi host, installa il Docker Engine e configura il programma per la riga di comando, installato localmente, per l’accesso a distanza. Questo vi permette di comunicare con gli host all’interno del cloud, utilizzando il terminale del sistema locale, così da eseguire i comandi diDocker da remoto.

Docker Swarm

A partire dalla versione 1.12 il Docker Engine dispone di funzioni native che permettono la gestione dei Docker Host in cluster, i cosiddetti sciami (Swarms). Le funzioni di cluster management e di orchestrazione integrate nel Docker Engine si basano sul toolbox Swarmkit.  Versioni meno aggiornate della piattaforma mettono a disposizione il Docker Tool Swarm come applicazione standalone.

Consiglio

Per cluster si intende il collegamento di più Docker Host, i quali vengono hostati sull’infrastruttura fornita da un provider laaS esterno o nel proprio centro di elaborazione dati.

Lo strumento di clustering Swarm raggruppa una serie di Docker Host in un singolo host virtuale e serve al funzionamento delle REST API di Docker. In questo modo ogni tool di Docker che è in collegamento con Docker Daemon può affidarsi a Swarm ed essere regolato su qualsivoglia numero di Docker Host. Gli utenti utilizzano le CLI del Docker Engine per creare gli sciami, controllarne il comportamento, e suddividere 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 create un nuovo cluster o se volete aggiungere un Docker Host ad uno sciame già presente. I singoli Docker Host 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 suddivisi in 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 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, nominati “Worker nodes” nella terminologia di Docker.

  •  Services: i Service sono delle strutture centrali all’interno dei cluster di Docker. Per Service si intende un gruppo di container, che si basano sulla stessa immagine. Un Service definisce i task che vengono eseguiti nel cluster. Un utente, che crea un service, specifica all’interno di esso quale immagine e quale comando debbano essere utilizzati. Inoltre i service offrono la possibilità di scalare le applicazioni. Gli utenti della piattaforma Docker definiscono in aggiunta il numero di Docker container che devono essere avviati per un determinato servizio.
  • Task: per poter suddividere i Service in un cluster, questi ultimi vengono scomposti dai Manager node in unità di lavoro singole, ovvero i già citati task. Ogni task raggruppa un Docker container 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 le 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.

La seguente grafica mostra una rappresentazione schematica di un Docker Swarm.

Con l’implementazione di uno sciame di Docker, gli utenti ricorrono solitamente alla Docker Machine.

Docker Compose

Compose è la soluzione di Docker per le applicazioni multi-container. Originariamente Docker Compose fu sviluppato sotto il nome di fig dall’azienda di software Orchard, mentre oggi il semplice strumento per l’orchestrazione amplia il portfolio di Docker.

Docker Compose vi permette di collegare tra loro più container e di farlo eseguendo un solo comando. Il tool open source è implementato nel linguaggio di scripting Python. 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 l’approvvigionamento delle macchine virtuali.

Nel file docker-compose.yml definite il numero che preferite 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. Utilizzate il comando docker-compose in combinazione con il sottocomando desiderato per gestire l’intero ciclo di vita dell’applicazione.

Il tool di Docker è facilmente integrabile in un cluster basato su Swarm. In questo modo, con Compose, eseguite facilmente le applicazioni multi-container create sia sui vari sistemi sui quali le avete precedentemente distribuite, 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 definite senza problemi quanti container desiderate avviare per un determinato servizio.

Docker Cloud

A fine del 2015 Docker ha acquisito Tutum, il servizio di deployment e di amministrazione dei container, e lo ha adattato per il Docker Cloud. Mentre l’hub di Docker serve come piattaforma di archiviazione centrale per le immagini, il cloud di Docker mette a disposizione una piattaforma basata sul web con la quale potete creare, testare, controllare e suddividere i container di Docker tra diverse architetture.

Il Docker Cloud offre un’integrazione nativa con tutti i servizi di Docker e si contraddistingue per il supporto dei diversi provider cloud come Microsoft Azure, Amazon Web Services, DigitalOcean, IBM Softlayer, Packet.net o Google Container Engine. Inoltre gli utenti hanno la possibilità di collegare Docker Cloud con la propria infrastruttura.

È però necessario prestare attenzione poiché il Docker Cloud non mette a disposizione alcun servizio di hosting. Tutte le risorse per i nodi, i servizi e gli Stack, creati attraverso la piattaforma di deployment, devono essere messi a disposizione tramite l’utilizzo di fornitori esterni o sul proprio data center. 

Consiglio

per Stack si intende un’interconnessione di più servizi di Docker, che se messi assieme formano un’applicazione.

L’integrazione nativa al provider laaS (Infrastructure-as-a-Service) vi offre la possibilità di ripartire le applicazioni tra diverse piattaforme di hosting o di realizzare architetture ibride in combinazione con i nodi locali. La gestione dei nodi di Docker tramite diverse infrastrutture avviene centralmente attraverso un’interfaccia utente grafica, la Dashboard del Docker Cloud. Sempre tramite tale interfaccia vi collegate con un click al vostro data center o al provider esterno su cui appoggia il vostro hosting e create, in caso di necessità, i singoli nodi (Docker Nodes) o gli interi Cluster Node.

Consiglio

È bene sapere che non è possibile creare i Cluster Node sul Docker Cloud con più di un fornitore esterno.

La piattaforma di deployment offre anche delle interfacce per diversi Registry come il Docker Hub o le funzioni automatizzate Build e Test (ovvero “costruzione” e “controllo”), oltre alla capacità delle applicazioni di essere disponibili su più piattaforme e regolabili nel cloud. Il seguente video, realizzato dal team di sviluppo, offre una panoramica sulle funzionalità centrali e le possibilità di utilizzo del Docker Cloud:

Per tutelare la vostra privacy il video si caricherà dopo aver cliccato.

Il Docker Toolbox

A partire dal rilascio della versione 1.12 Docker è disponibile come applicazione nativa per desktop anche per i nuovi computer macOS e Windows. Gli utenti dei sistemi operativi più datati, invece, devono affidarsi al toolbox di Docker per riuscire ad installare la piattaforma di container.

Il Docker Toolbox è un installer che automatizza le impostazioni degli ambienti di Docker per le versioni non aggiornate dei sistemi operativi Windows e macOS.  Il software contiene le seguenti componenti:

  • Docker Engine
  • Docker Machine
  • Docker Compose
  • Oracle VirtualBox
  • Kitematic, un’interfaccia grafica (GUI) di Docker
  • Un’interfaccia a riga di comando configurata per Docker

Al centro del Docker Toolbox vi è il software open source Kitematic. Questo si integra nella Docker Machine così da rendere disponibile una macchina virtuale sulla base di Oracle VirtualBox per l’installazione della piattaforma di container. Gli utenti possono approfittare di un’interfaccia utente grafica messa a loro disposizione per il loro lavoro con Docker; tramite tale interfaccia possono creare, avviare e interrompere i container con un click del mouse. Un’interfaccia per il Docker Hub permette inoltre di ricercare nei registry direttamente dall’app su desktop e di scaricare le immagini.

Oltre alla GUI, è disponibile anche un’interfaccia a riga di comando preconfigurata. Tutte le modifiche che gli utenti apportano al momento dell’immissione, vengono attuate anche per le altre modalità. Gli utenti hanno dunque la possibilità, di passare da GUI a CLI, senza che nulla venga perso strada facendo, per eseguire e gestire i container. In aggiunta Kitematic offre le funzioni attraverso le quali è possibile assegnare automaticamente le porte, definire le variabili ambientali e configurare le unità (Volumes).

Anche se il toolbox di Docker viene definito come datato (legacy) nella documentazione di Docker, il software continua ad essere supportato esattamente come lo è sempre stato. Il team di sviluppo consiglia tuttavia l’utilizzo delle app desktop native Docker for WindowsDocker for Mac, a patto che vengano soddisfatti i requisiti di sistema.

Gli strumenti per Docker sviluppati da provider esterni

Oltre agli sviluppi ottenuti dallo sviluppatore stesso, Docker Inc., si possono trovare diversi altri strumenti software e piattaforme di provider esterni, i quali mettono a disposizione le interfacce per il Docker Engine o per la piattaforma di container che preferite. Tra i progetti open source più conosciuti dell’ecosistema di Docker si annoverano il tool per l’orchestrazione Kubernetes, il tool per il cluster management Shipyard, la soluzione multi-container per Docker Panamax, la piattaforma di integrazione continua Drone, il sistema operativo per cloud OpenStack e il sistema operativo per data center basato su Mesos, un programma di cluster manager, Mesosphere DC/OS.

Kubernetes

Gli strumenti d’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 tool fatti su misura, i quali dovrebbero semplificare il compito di gestire la piattaforma di container in grandi infrastrutture distribuite. Oltre ad Helios, la piattaforma di orchestrazione open source di Spotify, tra le soluzioni più conosciute di questo tipo vi è Kubernetes.

Con Kubernetes si ha un cluster manager per le applicazioni basate su container, il quale è stato sviluppato in gran parte da Google e che oggi si trova sotto il patrocinio della Cloud Native Computing Foundation (CNCF).

N.B.:

La Cloud Native Computing Foundation (CNCF) è un’organizzazione appartenente alla Linux Foundation (LF). Il motivo decisivo che ha portato alla fondazione dell’organizzazione nel 2015 è stata la cooperazione tra la Linux Foundation con Google; in tale occasione è stato infatti realizzato il progetto Kubernetes, successivamente donato al CNCF. L’obiettivo dell’organizzazione è quello di far avanzare a passo più spedito la tecnologia di container nei progetti open source. Ulteriori partecipanti oltre a quelli già elencati sono Docker, Twitter, Huawei, Intel, Cisco, IBM, Univa e VMware.

A partire da metà 2015 è stato dato il via libera all’utilizzo di Kubernetes 1.0per i sistemi produttivi e viene utilizzato ad esempio nell’ambito del Google Container Engine (GKE).

Lo scopo di Kubernetes è quello di automatizzare le applicazioni nel cluster. Lo strumento di orchestrazione utilizza anche una REST API, 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 distribuite sui vari 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 cluster manager, 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, o 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 di ripartire i 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 REST API su un server API. Questo funziona come interfaccia di amministrazione centrale all’interno del cluster.
  • etcd: potete immaginarvi la memoria di configurazione open source etcd come la memoria di un cluster Kubernetes. Il database Key-value, 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.

Tutte i componenti del master di Kubernetes possono essere basati su uno stesso host o, nel caso di un cluster HA (ovvero cluster high availability), possono essere distribuiti tra più master host.
 
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 posseggono anche i seguenti componenti:

  • kubelet: con kubelet si tratta di un agent che viene eseguito su ogni Kubernetes Node e che serve al controllo e alla gestione dei nodi. In quanto punto di contatto centrale di ogni nodo, kubelet è in connessione con il Kubernetes master e dispone perciò che le informazioni sul livello di controllo vengano inoltrate ad esso, e che esso stesso le riceva. L’agent a sua volta riceve dal Kubernetes master i comandi e i compiti, e sorveglia l’attuazione degli stessi da parte dei nodi relativi.
  • kube-proxy: oltre al container engine e all’agent kubelet, su ogni Kubernetes node gira anche kube-proxy, un proxy-service. Questi deve far sì che le richieste ai vari container, provenienti dall’esterno, giungano a destinazione, e che agli utenti vengano messi a disposizione i service delle applicazioni basate su container. Inoltre kube-proxy offre un load balancer rudimentale.

La seguente grafica mostra una rappresentazione schematica dell’architettura master-slave, che sta alla base della piattaforma d’orchestrazione Kubernetes:

A fianco delle funzionalità centrali del progetto Kubernetes potete trovare numerosi altri strumenti ed estensioni che vi permetteranno di dotare la piattaforma d’orchestrazione di funzioni aggiuntive. Tra le più famose vi sono i tool per il monitoraggio e per la diagnosi degli errori Prometheus, Weave Scope e sysdig, così come anche il gestore di pacchetti Kurbenetes Helm. Inoltre esistono dei plug-in 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. Shipyard 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, quindi dal browser, e proprio per questo si differenzia dall’applicazione per desktop Kitematic.

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 utenti, gli indirizzi e gli eventi.

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

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

  • Shipyard Controller: il controller è il componente centrale del management tool Shipyard. Il controller interagisce con il RethinkDB nell’ambito dell’archiviazione dei dati e permette di interagire con i singoli host all’interno di un Docker cluster e di gestire gli eventi.
  • Shipyard API: la Shipyard API è un’API basata su REST. Tutte le funzioni del management tool 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 sul browser. Tutte le interazioni nella user interface avvengono tramite la Shipyard API. 

Trovate ulteriori informazioni su Shipyard sulla pagina web ufficiale del progetto open source.     

Panamax

Gli sviluppatori del progetto software open source Panamax si sono prefissati come obiettivo quello di semplificare la messa a disposizione delle app multi-container. Il tool gratuito offre agli utenti un’interfaccia grafica tramite la quale è possibile sviluppare, mettere a disposizione e ripartire le applicazioni complesse basate sui container Docker in maniera agile tramite la funzione di Drag and Drop.

Panamax permette di archiviare le complesse applicazioni multi-container come cosiddetti application template e quindi di distribuirle con un semplice click all’interno delle architetture dei cluster. Tramite un luogo di interscambio integrato per le app, hostato su GitHub, è possibile archiviare nei Git repository i template delle app create autonomamente e metterli a disposizione degli altri utenti. Il video che segue qui sotto dimostra il concetto che sta alla base di Panamax all’insegna del motto “Docker Management for Humans”:

Per tutelare la vostra privacy il video si caricherà dopo aver cliccato.

Panamax viene offerto da CenturyLink come software open source con la licenza Apache 2. Le 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 del Docker tool. Questa viene eseguita 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 di host CoreOS, il software container rivolto specialmente alla distribuzione di Linux. Il team di sviluppo consiglia agli utenti di installare CoreOS sul sistema locale tramite l’utilizzo di Vagrant e di Oracle Vitualbox. L’installazione sul sistema locale di Panamax si compone di una struttura software come la seguente: la base è rappresentata da un computer locale, su cui è installato un sistema operativo qualsiasi. Sullo stesso computer gli utenti installano CoreOS con l’aiuto del software di virtualizzazione VirtualBox. Successivamente il client di Panamax viene eseguito come Docker container su CoreOS. Il software venne sviluppato specificamente per l’agile distribuzione Linux. 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 cluster manager che gestisce 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 Linux System Manager 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 diverse altre componenti e funzioni. Inoltre, tra le altre vi sono 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 appunto con le seguenti interfacce di programmazione, tramite la Panamax API, 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 la etcd API 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 la Panamax API 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 Panamax Template 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 Docker tramite un’interfaccia grafica. Tramite la Panamax API le immissioni degli utenti vengono inoltrate direttamente al local agent. La Panamax UI si basa sul CTL Base UI Kit, una libreria con componenti UI per i progetti web di CenturyLink. 

Ogni nodo in un Docker Cluster senza compiti di management viene chiamato Remote Deployment Target, secondo la terminologia Panamax. I Deployment Target sono composti di un Docker Host, il quale è configurato per il Deployment dei Panamax Template grazie ai seguenti componenti:

  • Deployment Target Installer: il Deployment Target Installer avvia un Docker Host, inclusi il Panamax Remote Agent e l’Orchestration Adapter.
  • Panamax Remote Agent: ·         installando il Panamax Remote Agent, è possibile distribuire le applicazioni tra i Panamax client locali a qualsivoglia punto finale del cluster. Il Panamax Remote Agent viene eseguito all’interno del cluster come Docker Container su ogni Deployment Target.
  • Panamax Orchestration Adapter: ·         nell’Orchestration Adapter 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 adapter preconfigurati:

    • Panamax Kubernetes Adapter: o il Panamax Kubernetes Adapter, in combinazione con il Panamax Remote Agent, permette di distribuire i Panamax Templates tra i Kubernetes Cluster.

    • Panamax Fleet Adapter: il Panamax Fleet Adapter, in combinazione con Panamax Remote Agent, permette di distribuire i Panamax Template nei cluster controllati tramite il Cluster Manager di Fleet.

La grafica seguente mostra la cooperazione delle singole componenti di Panamax all’interno di un Docker Cluster:

Il Container Management Tool di 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. Utilizzate il tool Drone scritto in linguaggio di programmazione Go per caricare Build (i livelli di sviluppo singoli di un nuovo software) automaticamente dai Git repository come GitHub, GitLab o Bitbucket e lasciarli funzionare a fini di prova in container Docker isolati. Avete la possibilità di eseguire qualsiasi numero vogliate di Test Suite e farvi 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.

N.B.:

Con “Continuous Integration” si intende quel processo di sviluppo del software, presso il quale, ad intervalli regolari (solitamente almeno una volta al giorno), vengono messe in connessione i componenti software di nuovo sviluppo ed eseguite all’interno di ambienti di test. Tali componenti prendono il nome di Build, dall’inglese to build = “costruire”. Le applicazioni complesse vengono spesso sviluppate in team di grandi dimensioni. L’integrazione continua è una strategia che serve a riconoscere anzitempo gli errori di integrazione, che sorgono dalla cooperazione di diversi sviluppatori, e a porvi rimedio. Drone offre la possibilità agli sviluppatori software di realizzare svariati ambienti di test con l’aiuto dei Docker Container.    

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 create la vostra piattaforma di integrazione continua personale per  tutti i sistemi sui quali è possibile installare Docker. Inoltre supporta piùVersion Control Repository. Potete trovare 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 caricate le build direttamente dal Git repository desiderato, mettete in collegamento le applicazioni e avviate ciò che ne risulta in un ambiente di test precedentemente definito. Inoltre, per ogni test 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.

Nel video seguente Brad Rydzewski, uno degli sviluppatori di Drone, fornisce un’idea di quello che è la piattaforma di integrazione continua open source:

Per tutelare la vostra privacy il video si caricherà dopo aver cliccato.

A detta dello sviluppatore, con Drone viene messo 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 OpenStack è la soluzione software di cui avete bisogno. Il sistema operativo cloud  open source è venuto alla luce nel 2010 da una cooperazione del provider statunitense Rackspace con l’agenzia governativa di astronautica NASA.

Il progetto software libero, pubblicato con licenza Apache, è supportato da aziende come AT&T, SUSE, Canonical, HP, Interl Red Hat e IBM.

Con OpenStack è possibile gestire risorse di calcolo, risorse di memoria e risorse di rete in un data center tramite una dashboard e mettere queste a disposizione degli utenti finali tramite un’interfaccia web.

Il sistema operativo Cloud si basa su di un’architettura modulare, composta da sei componenti centrali:

  • Nova (componente centrale di calcolo): la componente di calcolo principale (Compute) di OpenStack prende il nome di “Nova” e rappresenta praticamente il cervello dell’architettura software. Nova è responsabile della gestione di tutte le istanze di calcolo del sistema e permette agli utenti di avviare macchine virtuali (VMs) sulla base di immagini, di metterle a disposizione nell’ambiente cloud e di amministrarle nei vari cluster. Le VMs si lasciano ridistribuire tra tutti i nodi che si desidera. In quanto sistema di Cloud Computing Fabric Controller (unità di controllo per le reti di computer), Nova è la componente di base per i servizi IaaS presenti su OpenStack. Nova supporta diverse tecnologie Hypervisor e di virtualizzazione così come architetture Bare Metal, presso le quali le VMs fanno direttamente affidamento sull’hardware. Di regola vengono utilizzati: KWM, VMware, Xen, Hyper-V o LXC, una tecnologia container di Linux.
  • Neutron (componente di rete): quello che un tempo era chiamato Quantum, è 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 plug-in, grazie ai quali potete integrare delle funzioni di rete ampliate.
  • Cinder (blocchi di memoria): sotto il nome di Cinder vi è la componente dell’architettura di OpenStack che si occupa di offrire continuamente ed in maniera permanente dei blocchi di memoria per la gestione 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.
  • Keystone (Identity Service): con Keystone, gli utenti di OpenStack dispongono di un Identity Service centrale. Il modulo funge da sistema di autentificazione e da sistema dei permessi tra le singole componenti di OpenStack. Gli accessi ai progetti nel cloud vengono regolati attraverso i cosiddetti tenant. Ogni tenant rappresenta un’unità utente. Per ogni unità utente si possono definire diversi accessi con permessi utente differenti.
  • Glance (Image Service): con il modulo Glance, OpenStack mette a disposizione un servizio tramite il quale potete archiviare e richiamare le immagini delle macchine virtuali. La componente di calcolo Nova utilizza le immagini messe a disposizione tramite Glance come modello per creare le istanze delle macchine virtuali.
  • Swift (sistema di Object Storage): il modulo di OpenStack Swift viene utilizzato dalla componente di calcolo Nova per archiviare gli oggetti di dati e anche per richiamarli in un secondo momento attraverso la REST API. Swift si differenzia attraverso una struttura ridondante e regolabile, e una tolleranza agli errori elevata.

A partire dal release di Havanna nel 2013, il componente centrale Nova offre un driver Hypervisor per il Docker Engine. Esso inserisce un client HTTP all’interno della struttura di OpenStack, il quale permette di comunicare con la Docker API interna, attraverso un socket di Unix.

Il driver di Docker per Nova permette di richiamare le immagini archiviate attraverso Glance e di caricarle direttamente nel file system di Docker. Inoltre è possibile esportare le immagini dalla piattaforma di container attraverso il comando standard docker save e riporle in Glance. Una guida passo per passo su come integrare Docker nella propria architettura OpenStack già esistente può essere trovata su OpenStack-Wiki.

Inoltre la OpenStack Foundation offre un workshop di 90 minuti su YouTube per imparare a integrare Docker:

Per tutelare la vostra privacy il video si caricherà dopo aver cliccato.

L’architettura OpenStack è ampliabile tramite diversi moduli opzionali: 

  • Horizon (Dashboard): la dashboard di OpenStack prende il nome di “Horizon” e offre agli utenti un’interfaccia utente grafica basata su web, tramite la quale si possono gestire altre componenti come Nova o Neutron.
  • Heat (Orchestrazione): il modulo opzionale Heat mette a disposizione un servizio, attraverso il quale è possibile orchestrare, attraverso i template, le applicazioni cloud formate da più componenti. Heat offre perciò una REST API nativa e il formato per template HOT. In alternativa viene supportato il formato per template AWS-Cloud-Formation, insieme alla relativa API query.
  • Ceilometer (Servizi telemetrici): Ceilometer mette a disposizione per OpenStack un servizio centrale di telemetria, con il quale è possibile raccogliere i dati e usarli per la fatturazione dei clienti, il resource tracking, e per le funzionalità di allarme a supporto di tutte le componenti di OpenStack.
  • Trove (Database-as-a-Service): Trove è un componente Database-as-a-Service (DbaaS), con il quale si possono mettere a disposizione database relazionali e non relazionali.
  • Zaqar (Messaging): il modulo opzionale Zaqar, una volta conosciuto con il nome Marconi, rende OpenStack un servizio multi-tenant di messaggistica su cloud per sviluppatori web. Il software offre una REST API, attraverso la quale gli sviluppatori possono inviare messaggi tra i diversi componenti di una Mobile App o di una SaaS App.
  • Designate (Servizio DNS ): Designate offre un DNS-as-a-Service per OpenStack. Il management dei Domain Record avviene tramite una REST API. Anche questo modulo è multi-tenant e utilizza le funzioni di autentificazione tramite l’integrazione di Keystone.
  • Barbican (gestione delle chiavi): il modulo Barbican mette a disposizione di OpenStack una REST API attraverso la quale è possibile archiviare in totale sicurezza, gestire e riutilizzare, quando necessario, password, chiavi e certificati vari.
  • Sahara (Elastic Map Reduce): la componente opzionale Sahara mette gli utenti nella condizione di creare e gestire Hadoop Cluster attraverso OpenStack.
  • Ironic (driver Bare Metal): il modulo aggiuntivo Ironic è un fork del driver baremetal del componente di calcolo Nova che offre agli utenti di OpenStack la possibilità di utilizzare macchine bare metal invece di macchine virtuali.
  • Murano (catalogo delle applicazioni): Murano offre agli sviluppatori e agli amministratori di cloud la possibilità di gestire le applicazioni in un catalogo consultabile e ordinato per categorie.
  • Manila (Shared File System): Manila è un modulo aggiuntivo per OpenStack, che serve ad ampliare l’architettura del sistema operativo del cloud con un file system comune e distribuito.
  • Magnum (API per il servizio di container): una componente aggiuntiva importante è Magnum, un’API Service, che rende disponibili, sotto forma di componenti OpenStack, gli strumenti per l’orchestrazione dei container, quali Docker Swarm, Kubernetes o Apache Mesos.

OpenStack si è affermato come uno dei sistemi operativi principali per la configurazione e la gestione di strutture cloud open source, proprio per via della sua ampliabilità modulare. OpenStack rappresenta per gli utenti Docker una piattaforma dalle prestazioni performanti grazie al driver di Docker per Nova, con il quale è possibile eseguire e gestire i container in maniera professionale all’interno di sistemi complessi e distribuiti.

Mesosphere DC/OS

DC/OS (Data Center Operating System) è un software open source sviluppato da Mesosphere, per la gestione dei sistemi distribuiti. Il progetto si fonda sul cluster manager open source Apache Mesos e va inteso come sistema operativo per idata center. Il codice sorgente è a disposizione degli utenti su GitHub  con la versione 2 della licenza Apache. Inoltre gli sviluppatori hanno promosso una versione del software per le imprese su mesosphere.com. Trovate una documentazione dettagliata del progetto su tware dcos.io.

Considerate DC/OS come un tipo di distribuzione Mesos che mette a vostra disposizione tutte le funzioni del cluster manager attraverso un’interfaccia centrale e che amplia Mesos attraverso varie componenti in un’infrastruttura più vasta, la quale facilita chiaramente la gestione delle applicazioni sui sistemi distribuiti, nel cloud o negli ambienti on-premises. Il seguente video realizzato dal team di sviluppo contiene una breve dimostrazione di quali sono le funzioni principali di DC/OS:

Per tutelare la vostra privacy il video si caricherà dopo aver cliccato.

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 gestite l’intero cluster con macchine virtuali o fisiche con la stessa semplicità, con la quale utilizzereste un singolo computer.

Il software semplifica l’installazione e la gestione delle applicazioni riparite e automatizza le mansioni quali la gestione delle risorse, lo scheduling e la comunicazione tra processi. La gestione di un cluster tramite Mesosphere 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, per 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 del 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 Mesos Agent forniscono regolarmente rapporti al Mesos Master sulle risorse disponibili nel cluster, i quali successivamente vengono inoltrati ad uno scheduler, come Marathon, Chronos o Cassandra. Lo scheduler decide a sua volta quale task deve essere eseguito su un nodo specifico. Per eseguire un task, il Mesos Agent inizia un cosiddetto processo Executor, il quale viene eseguito e gestito isolatamente all’interno di un container. La separazione dei processi avviene a scelta tra gli Universal Container Runtime di Mesos o la piattaforma di container Docker.

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

  • Admin Router: l’Admin Router è un web server con configurazione specifica, basato su NGINX, il quale mette a disposizione i servizi DC/OS così come le funzioni centrali di autentificazione 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.
  • Distributed DNS Proxy: per Distributed DNS Proxy 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 Mesosphere DC/OS. Marathon lancia e controlla i servizi DC/OS e le applicazioni all’interno degli ambienti di cluster. Inoltre offre al software la funzione di high availability, Service Discovery, load balancer, health checks e un’interfaccia grafica.
  • Apache ZooKeeper: per Apache ZooKeeper [Maggiori informazioni su ZooKeeper su zookeeper.apache.org] (https://zookeeper.apache.org/) 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 Mesosphere 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 Exhibitor 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 Microservice o di piattaforme container come Hadoop, Spark e Docker.

Con Mesosphere Universe viene messo a disposizione per DC/OS un catalogo pubblico delle app. Tramite di esso potete installare applicazioni come Spark, Cassandra, Chronos, Jenkins o Kafka in totale comodità e con un semplice click grazie all’interfaccia grafica utente.

Docker Container come componente di una piattaforma di infrastruttura digitale

Docker è riuscito a rivoluzionare dalle fondamenta l’intera branca dell’IT. Dando un’occhiata alle statistiche del progetto open source, risulta difficile credere che il primo rilascio della piattaforma di container risalga a quattro anni prima, ovvero al 13 Marzo 2013.

Gli utenti di Docker hanno scaricato fino ad oggi più di 8 miliardi di immagini per container, e il numero delle varie Docker app a disposizione nel registry si aggira attorno al mezzo milione. L’intero progetto può contare su una community di sviluppatori di circa 3.000 collaboratori. Attualmente l’ecosistema Docker raccoglie un numero pressoché incalcolabile di strumenti, estensioni e piattaforme software, che rendono il lavoro con i container di Docker ancora più efficiente. Stando alle stime ufficiali, la tecnologia container sviluppata da Docker sarebbe al momento installata in più di 100.000 progetti realizzati da terze parti. Ma su cosa esattamente si fonda il successo della piattaforma Docker e dei suoi progetti satellite?

In tempi in cui sempre più utenti approfittano della tecnologia cloud, un’applicazione che può contare su di essa aumenta di certo il proprio valore in termini di connessione e di diffusione. Difatti questo trend rispecchia il modo in cui al giorno d’oggi i software vengono sviluppati, testati ed eseguiti. Le infrastrutture cloud offrono una possibilità interessante per le aziende, poiché esse permettono un’amministrazione centrale delle risorse IT e la possibilità di accedervi da praticamente ovunque. Concetti quali l’Infrastructure-as-a-Service (IaaS) rendono i processi aziendali indipendenti dalle proprie risorse hardware, ovvero dalla vicinanza alla propria sala server, ed offrono il massimo grado di flessibilità e scalabilità in base alle proprie esigenze.

Inoltre i data center gestiti in modo professionale dai provider, offrono strategie riguardanti la sicurezza in caso di irraggiungibilità, un’alta disponibilità e garantiscono la continuità del business, tutte opzioni altrimenti irrealistiche per la realizzazione nei locali a disposizione delle piccole e medie imprese. È per questo motivo che la veloce tecnologia di virtualizzazione colpisce nel segno: poiché essa permette di trasmettere le applicazioni con overhead minimali in formato portatile e multipiattaforma, e con un’istruzione a riga di comando, di distribuirle tra le infrastrutture cloud e gli ambienti ibridi.

La tecnologia offerta da Docker partecipa come poche altre al trend “Digital Infrastructure Platform”, ovvero piattaforme la cui infrastruttura è un servizio basato su cloud. L’ecosistema Docker permette infatti di scomporre le applicazioni nei cosiddetti Microservice, i quali possono essere distribuiti tra i diversi nodi di un cluster attraverso le interfacce API. Il vantaggio che si assicurano le aziende in questo modo non è solo quello relativo all’agilità e alla flessibilità, bensì anche alla stabilità.

Le app multi-container, con i loro processi eseguiti su diversi host di un sistema distribuito, sono scalabili orizzontalmente e possono essere gestite senza il rischio di instabilità grazie all’utilizzo delle ridondanze. L’ampia indipendenza nei container dei microservice a ciclo chiuso serve inoltre a fare in modo che gli aggiornamenti e le patch facciano riferimento solamente a singole parti di un’applicazione e che non mettano mai dunque a repentaglio l’applicazione stessa, nella sua interezza. Gli errori di un software che possono insorgere saranno dunque risolvibili con maggiore facilità.

Anche passando da un’infrastruttura tradizionale a una piattaforma di infrastruttura digitale, la tecnologia di container può offrire funzioni essenziali: soprattutto la possibilità di raccogliere le applicazioni in un container trasferibile, incluse tutte le loro subordinazioni, e di distribuirle tra le varie piattaforme (Deployment), aiuta gli amministratori a trasferire i vecchi sistemi, quali possono essere ad esempio le applicazioni legacy, da un Static IT ad un Dynamic IT.    

Consiglio

Per via dell’aumento della popolarità delle infrastrutture basate su cloud, gli ambienti IT si suddividono in due sezioni fondamentali: lo Static IT (che sta per IT statico) riguarda le applicazioni aziendali e di back end, gestite su infrastrutture classiche in ambienti on-premises o su un cloud privato. Dovessero dunque le aziende dotarsi di applicazioni e sistemi nuovi, allora questi vengono implementati sempre più spesso direttamente su piattaforme infrastrutturali di public cloud, in modo da garantire il massimo grado possibile in materia di scalabilità, flessibilità e indipendenza in relazione al luogo. Proprio per questo si è affermato il concetto di Dynamic IT (o IT dinamico).

Inoltre l’utilizzo di una piattaforma di container come Docker, offre la possibilità di ottimizzare le applicazioni in merito alla velocità, alle prestazioni e al change management, ovvero in relazione alla gestione nel caso in cui si decida di apportare dei cambiamenti. Rimangono tuttavia delle riserve relative alla sicurezza della tecnologia container.

Deployment

L’installazione del Container Engine prevede che la applicazioni basate su container siano eseguibili su qualsiasi sistema. I container infatti non contengono solo il codice dell’applicazione stessa ma anche tutti i file binari e le librerie necessarie per tutto il tempo di esecuzione. Questo semplifica soprattutto il Deployment, ovvero la distribuzione del software tra diversi sistemi e questo non vale solo per le nuove applicazioni sviluppate. La tecnologia di container può essere utilizzata efficacemente anche quando si tratta di trasferire le applicazioni legacy su cloud, ovvero in quei casi in cui l’utilizzo nelle mansioni giornaliere delle vecchie applicazioni obsolete risulti comunque irrinunciabile.

Nella maggior parte dei casi, le componenti software datate sono difficilmente integrabili nelle infrastrutture cloud per via della loro dipendenza dai sistemi operativi, framework o classi ben precise. Qui un Container Engine come Docker può offrire un livello di astrazione, che compensa la dipendenza dal codice, senza che gli amministratori debbano tenere in conto l’overhead di un sistema operativo virtuale.

Velocità e performance

Comparando la tecnologia di container, che sta alla base della piattaforma Docker, con una classica virtualizzazione di un hardware tramite VM, si riscontrano chiaramente delle differenze in merito alla velocità e alla performance.

Essendo che nei container le applicazioni a ciclo chiuso fanno affidamento direttamente al kernel del sistema di host, con questo tipo di virtualizzazione non è necessario avviare alcun sistema ospitante separato. Con Docker, invece di un Hypervisor, viene utilizzato un Container Engine leggero, riducendo in questo modo non solo il tempo per il boot di una macchina virtuale, ma anche le risorse necessarie per il sistema operativo aggiuntivo.

Per questo motivo le container app disporranno di una velocità maggiore e di un risparmio di risorse maggiore rispetto alle applicazioni basate su macchine virtuali. Questo permette chiaramente agli amministratori di avviare più container su uno stesso sistema di host, di quanti potrebbero effettivamente essere accolti da un sistema ospitante su una piattaforma hardware comparabile. Se ad esempio su un server si trovano dalle 10 alle 100 macchine, in un container il numero salirà a 1.000.

In aggiunta i container contenenti solamente i file binari e le librerie, oltre chiaramente al codice dell’applicazione, necessiteranno di uno spazio di archiviazione significativamente minore rispetto ad una macchina virtuale che include l’applicazione ed il sistema operativo.

DevOps e Change Management

La digitalizzazione e il trend dell’utilizzo di Internet hanno velocizzato in maniera decisiva il ciclo di vita delle applicazioni. Non solo gli aggiornamenti, le patch e i bugfix devono essere messi a disposizione nel minor tempo possibile. Anche il rilascio delle nuove versioni dei software si susseguono con intervalli sempre più brevi.

Il deployment degli aggiornamenti mette sviluppatori e amministratori di fronte a delle sfide. Mentre i produttori di software desiderano fornire ai propri clienti nuove funzioni di un’applicazione nel minor tempo possibile, gli amministratori invece sono intimoriti dal rischio di instabilità che ogni modifica all’infrastruttura IT e alle componenti software implementate portano con sé. Le strategie che servono a risolvere tali difficoltà vengono sviluppate sotto il nome di DevOps. L’impulso venne dato nel 2009 dai DevOpsDays, durante i quali gli approcci per il miglioramento dei processi nell’ambito della cooperazione dello sviluppo (Development) e delle operazioni informatiche (Operations) ebbero luogo per la prima volta nell’ambito di una conferenza internazionale.

L’obiettivo di DevOps è quello di migliorare la qualità delle nuove versioni dei software e di velocizzare lo sviluppo, la distribuzione e l’implementazione di tutte le parti interessate attraverso una cooperazione efficace ed avvicinarsi ad un’automatizzazione di ampia portata. Tra i compiti DevOps automatizzabili vi sono i processi build del repository, l’analisi statica e dinamica dei codici, così come i test relativi ai moduli, all’integrazione, ai sistemi e alla performance. Al centro dell’approccio di DevOps vi sono fino ad oggi le considerazioni relative alla Continuous Integration (CI) e alla Continuous Delivery (CD), due campi di applicazione centrali per la piattaforma Docker.

Consiglio

Per Continuous Delivery (“Distribuzione Continua”) si intende un approccio atto all’ottimizzazione della distribuzione dei software tramite l’utilizzo di diverse tecnologie, processi e strumenti, semplicemente premendo un tasto. Al centro di essa vi è l’automatizzazione della cosiddetta Deployment pipeline.

Docker offre delle possibilità di integrazione per i tool CI/CD affermati come Jenkins, Travis o Drone e permette inoltre di caricare i codici direttamente dal Docker Hub o dalle varie repository per il controllo delle versioni come GitHub, GitLab e Bitbucket. Perciò la piattaforma di container rappresenta una base per il worflow di DevOps, tramite la quale gli sviluppatori possono creare congiuntamente nuove componenti per le applicazioni ed eseguirle negli ambienti di test che ritengono più congrui.

Inoltre Docker supporta ambienti on-premises, cloud e virtuali, così come diversi sistemi operativi e distribuzioni. Tra i vantaggi centrali di un’architettura CI/CD basata su Docker vi è il fatto che le aziende non saranno più rallentate dalle inconsistenze dei vari ambienti IT.

Sicurezza

Anche se i processi a ciclo unico girano sullo stesso kernel, Docker usa una sfilza di tecnologie di isolazione per proteggere le une dalle altre. Il focus è soprattutto sulle funzioni cardine del kernel di Linux come Cgroup e Namespace. Ogni container riceve un proprio nome host, un proprio ID del processo e una propria interfaccia di rete. Inoltre ogni container vede solo la porzione del file system ad esso assegnata. La suddivisione delle risorse di sistema come lo spazio di archiviazione, la CPU e la banda larga, avviene attraverso un meccanismo Cgroup, il quale serve a far sì che ogni container si arroghi solamente il contingente che gli spetta.

Tuttavia ai container non viene offerto lo stesso grado di isolamento realizzabile con le macchine virtuali. Nel caso in cui un cyber criminale riesca a mettere le mani su di una macchina virtuale, avrà ben poca possibilità di interagire con il kernel del sistema host che ne sta alla base. I container invece, in quanto istanze a ciclo unico di un kernel di host comune, offrono all’hacker ben più libertà.

Sebbene le tecnologie di isolamento descritte sono raggiungibili dai container, tramite importanti sottosistemi kernel, come Cgroups e componenti kernel nelle directory /sys e /proc, queste offrono agli aggressori la possibilità di aggirare le funzioni di sicurezza dell’host. Inoltre tutti i container girano su un sistema host con lo stesso namespace utente. Ciò ha come conseguenza che un container a cui viene assegnato l’accesso di root, lo mantiene poi anche durante l’interazione con il kernel dell’host. Gli amministratori dovrebbero quindi fare attenzione che i container vengano avviati esclusivamente con permessi limitati.

Anche il demone di Docker, responsabile per l’amministrazione dei container sul sistema host, dispone dei permessi di root. Un utente che ha accesso a Docker Daemon ottiene automaticamente accesso a tutte le directory sulle quali il demone può fare affidamento, così come la possibilità di comunicare attraverso una REST API, usando il protocollo HTTP. La documentazione di Docker consiglia perciò di garantire l’accesso al demone solamente agli utenti degni di fiducia.

Anche il team di sviluppo di Docker ha riconosciuto i sopracitati dubbi relativi alla sicurezza come freni per l’affermazione della tecnologia container sui sistemi produttivi. A fianco delle tecnologie di isolamento che stanno alla base del kernel di Linux, le nuove versioni del 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.

Inoltre Docker utilizza le cosiddette Linux Capabilities, attraverso le quali si possono limitare i permessi di root, con i quali viene avviato il container del Docker Engine.

Ulteriori preoccupazioni relative alla sicurezza dipendono dalle vulnerabilità dei software in relazione alle componenti delle applicazioni, le quali vengono diffuse attraverso il registry di Docker. Essendo che teoricamente ognuno può creare delle Docker Image e metterle a disposizione nell’hub di Docker di pubblico accesso per gli appartenenti alla community, vi è il pericolo di importare un codice dannoso sul proprio sistema durante il download di un’immagine. Per questo motivo, prima del deployment di un’applicazione, gli utenti di Docker dovrebbero assicurarsi che l’intero codice che viene messo a disposizione in un’immagine per la distribuzione di container, provenga da una fonte attendibile.

A questo scopo Docker offre a partire dal 2017 un programma di certificazione [Pagina del blogpost relativo su blog.docker.com] (https://blog.docker.com/2017/03/announcing-docker-certified/) nell’ambito dell’edizione enterprise (“Enterprise Edition” o anche “EE”), attraverso il quale i provider di infrastrutture, container e plug-in, possono testare e contrassegnare come affidabili i propri software. Per ottenere un certificato, è necessario rispettare i seguenti requisiti:

  • Certified Infrastructure: gli sviluppatori del software, che vorrebbero mettere le componenti infrastrutturali certificate a disposizione per l’ecosistema di Docker, devono dimostrare tramite il test corrispondente che il loro prodotto sia stato ottimizzato per poter lavorare con la piattaforma Docker.
  • Certified Container: viene assegnato il certificato ufficiale di Docker ad un container solo nel caso in cui sia stato creato conformemente alle Best Practices raccomandate per Docker e se supera tutti i relativi controlli: test del software, controllo delle vulnerabilità, controllo qualità.
  • Plug-in: un plug-in per Docker EE si può dotare di un certificato Docker, se è stato creato conformemente alle Best Practices raccomandate per Docker e se supera tutti i relativi controlli: gli API Compliance Test e il controllo delle vulnerabilità.

Oltre all’aumento della sicurezza per gli utenti, i certificati Docker offrono agli sviluppatori dei vari software una possibilità per far risaltare il proprio progetto tra l’enorme quantità di risorse già disponibili.

Conclusione: quanto è sicuro il futuro di Docker?

Docker è una realtà in crescita. Anche in Italia trova una diffusione di portata sempre maggiore. La tecnologia di Docker è un’alternativa che fa risparmiare risorse rispetto ai classici hardware per la virtualizzazione, adatta soprattutto per le aziende che devono mettere a disposizione un’applicazione web interattiva o che devono gestire una grande mole di dati. Nella branca dell’e-commerce ci si aspetta una richiesta crescente nei prossimi anni. Per i global player, quali sono eBay e Amazon, i container appartengono già alle tecnologie standard, mentre i piccoli commercianti online seguiranno la loro scia.

Attualmente l’ancora giovane software per le aziende Docker si è aggiudicato in pochi anni il posto di leader del mercato tecnologico nel ramo della operating system level virtualization, grazie soprattutto al concetto open source e agli sforzi in materia di standardizzazione. Chiaramente la concorrenza nel settore dei container non sta a guardare. Ad approfittare dell’aspra concorrenza tra i provider di soluzioni container e di strumenti di amministrazione, saranno tutti coloro che usufruiscono della velocità di innovazione.

A rallentare in passato sono stati invece i dubbi concernenti la sicurezza che si sono chiaramente ripercossi sulla diffusione della tecnologia di container. La sfida centrale per gli sviluppatori delle tecnologie di virtualizzazione basate su container è il miglioramento dei processi di isolamento all’interno del kernel di Linux; un settore nel quale già in passato grazie ai progetti come SELinux, AppArmor o Seccomp sono stati ottenuti dei risultati.

Considerando il tasso di accettazione per i container, è chiaro che la operation system level virtualization si imporrà alla lunga come alternativa alle macchine virtuali. Specialmente il progetto Docker e il suo ecosistema in rapida crescita offrono alle aziende una base sicura in chiave futura per la gestione dei software container nello sviluppo e nel mondo degli affari.


Abbiamo una proposta per te:
Web hosting a partire da 1 €/mese!

Dominio gratis
Certificato SSL Wildcard incluso
Assistenza clienti 24/7
A partire da 1 €/mese IVA escl. per un anno,
poi 8 €/ mese IVA escl.