OpenShift vs. Docker

Docker ha portato al trionfo della vir­tua­liz­za­zio­ne basata su container. Il software è una tec­no­lo­gia di base per creare ed eseguire con­te­ni­to­ri di ap­pli­ca­zio­ni. Docker è usato da singoli svi­lup­pa­to­ri sui propri computer portatili, per esempio, per stan­dar­diz­za­re i flussi di lavoro di sviluppo. OpenShift gioca all’altra estremità dello spettro di vir­tua­liz­za­zio­ne, coprendo i requisiti operativi di un’intera or­ga­niz­za­zio­ne. La sua base è co­sti­tui­ta da ambienti cloud pubblici e privati.

Le due tec­no­lo­gie non sono affatto da con­si­de­rar­si con­cor­ren­ti diretti. Anzi, in passato OpenShift si basava in­di­ret­ta­men­te su Docker e ancora oggi utilizza il formato con­te­ni­to­re Docker. In questo articolo vi forniremo una pa­no­ra­mi­ca dei due strumenti, andando poi ad ap­pro­fon­di­re i relativi punti di forza e di debolezza, nonché i ri­spet­ti­vi scenari di im­ple­men­ta­zio­ne.

Nelle di­scus­sio­ni online o nei post dei blog capita spesso di im­bat­ter­si nella questione se sia meglio OpenShift o Docker come strumento per la vir­tua­liz­za­zio­ne dei container. Anche se la domanda viene posta spesso, va ricordato che si tratta in realtà di tec­no­lo­gie molto distanti tra loro. Sia OpenShift che Docker hanno la propria ragion d’essere e sono so­li­ta­men­te usati in modo com­ple­men­ta­re. Pa­ra­go­na­re le tec­no­lo­gie OpenShift e Docker è un po’ come chiedere: “è meglio spostarsi in au­to­mo­bi­le o con i trasporti pubblici?”. In linea di principio, entrambi hanno un compito simile: spostare persone e merci da un luogo all’altro; entrambi sono forniti di ruote, ma si parla di di­men­sio­ni com­ple­ta­men­te diverse.

A dif­fe­ren­za dei con­te­ni­to­ri fisici, la funzione prin­ci­pa­le della loro con­tro­par­te virtuale non è essere una tec­no­lo­gia di trasporto. Ser­via­mo­ci di un’analogia presa in prestito dalla biologia per capire meglio la questione. Infatti, i con­te­ni­to­ri di ap­pli­ca­zio­ni e le cellule hanno molto in comune: entrambi sono un’unità fon­da­men­ta­le di in­for­ma­zio­ne in­cap­su­la­ta, sigillata ester­na­men­te, che diventa “viva”.

Nel mondo vivente, l’evo­lu­zio­ne ha avuto luogo da organismi uni­cel­lu­la­ri a organismi plu­ri­cel­lu­la­ri. Allo stesso modo, nel mondo virtuale, c’è stata un’evo­lu­zio­ne da singoli con­te­ni­to­ri a reti or­che­stra­te di con­te­ni­to­ri in­te­ra­gen­ti. Le sfide associate alla mul­ti­cel­lu­la­ri­tà sono inoltre simili a quelle che sorgono dall’in­te­ra­zio­ne di più con­te­ni­to­ri.

Le cellule bio­lo­gi­che e i con­te­ni­to­ri delle ap­pli­ca­zio­ni devono co­mu­ni­ca­re tra loro. Devono ri­for­mar­si o morire a seconda delle necessità. Le risorse totali di­spo­ni­bi­li devono essere di­stri­bui­te tra le singole unità. Tutto questo dovrebbe essere ben coor­di­na­to in modo che l’intero sistema possa reagire ai cam­bia­men­ti della domanda e rimanere stabile nel lungo periodo. Il­lu­stria­mo la gamma di vir­tua­liz­za­zio­ne dei container da Docker a OpenShift con la seguente pa­no­ra­mi­ca:

Appare dunque evidente che alla domanda su quale sia la tec­no­lo­gia migliore si può ri­spon­de­re solo assumendo una pro­spet­ti­va specifica. In de­fi­ni­ti­va, dipende for­te­men­te dal punto di vista. Questo vale anche per il confronto tra OpenShift e Docker.

Docker ha reso popolare la vir­tua­liz­za­zio­ne dei container e ha am­pia­men­te sop­pian­ta­to le macchine virtuali (VM) pre­ce­den­te­men­te dominanti. Il trionfo di container di ap­pli­ca­zio­ni ha ri­vo­lu­zio­na­to il modo in cui le ap­pli­ca­zio­ni sono costruite, im­pac­chet­ta­te ed eseguite. Questo perché i container sono un’unità software stan­dar­diz­za­ta. Possono essere usati senza problemi ovunque sia di­spo­ni­bi­le un runtime di container cor­ri­spon­den­te.

A dif­fe­ren­za delle macchine virtuali pre­ce­den­te­men­te on­ni­pre­sen­ti ma piuttosto com­pli­ca­te, i container risultano essere de­ci­sa­men­te più leggeri. Su un solo host possono essere eseguiti decine o migliaia di container. Questo vantaggio in­trin­se­co della vir­tua­liz­za­zio­ne dei container ha portato alla dif­fu­sio­ne delle ar­chi­tet­tu­re di mi­cro­ser­vi­zi di­stri­bui­ti. Invece di costruire un’ap­pli­ca­zio­ne mo­no­li­ti­ca, l’ambito fun­zio­na­le è suddiviso in singoli com­po­nen­ti. Ciascun com­po­nen­te è im­pac­chet­ta­to come un servizio (“service”) in un proprio container. I container vengono avviati e i servizi co­mu­ni­ca­no tra loro at­tra­ver­so la rete.

L’approccio mi­cro­ser­vi­zi è par­ti­co­lar­men­te pratico per lo sviluppo del software perché per ogni servizio permette di uti­liz­za­re le tec­no­lo­gie più ap­pro­pria­te. Invece di essere legati a singoli linguaggi di pro­gram­ma­zio­ne e paradigmi, si può variare tra i diversi servizi. Man mano che arrivano nuove tec­no­lo­gie risulta così più semplice im­ple­men­ta­re nuo­va­men­te i singoli servizi.

La capacità di clonare diversi container simili da un’immagine container ha come risultato la sca­la­bi­li­tà del sistema com­ples­si­vo. In caso di aumento della domanda, vengono avviati altri container e il ri­spet­ti­vo servizio scalato oriz­zon­tal­men­te. Questa ope­ra­zio­ne però richiede un sistema che si occupi di mo­ni­to­ra­re i container in ese­cu­zio­ne e, quando ne­ces­sa­rio, di ter­mi­nar­li o avviarne di nuovi. Inoltre, le richieste in arrivo devono essere di­stri­bui­te ai singoli container.

La sca­la­bi­li­tà fa sì che la com­ples­si­tà del sistema cresca no­te­vol­men­te, in quanto diventano ne­ces­sa­rie le seguenti azioni:

• Ac­co­glie­re richieste tramite il load balancer
• Di­stri­bui­re i compiti ai singoli container
• Mo­ni­to­ra­re lo stato delle istanze del container
• Terminare e avviare nuove istanze
• Stabilire una rete di container
• Gestire i container o le immagini per mezzo di ag­gior­na­men­ti, ecc.

A tutto ciò si aggiunge anche un enorme so­vrac­ca­ri­co am­mi­ni­stra­ti­vo. Ma non è finita qui. Bisogna anche con­si­de­ra­re la ma­nu­ten­zio­ne del sistema am­mi­ni­stra­ti­vo stesso. Questo livello di controllo, che esegue tutti i punti di cui sopra, ha a sua volta necessità di ma­nu­ten­zio­ne, mo­ni­to­rag­gio e ag­gior­na­men­ti. Dal lato dell’utente non è possibile per­met­ter­si alcun tipo di perdita di pre­sta­zio­ne sensibile, mentre la sicurezza dell’intero sistema deve sempre essere garantita.

Per ultima cosa, ma non meno im­por­tan­te, vogliamo anche essere in grado di or­che­stra­re i nostri cluster di container oltre i limiti dell’in­fra­strut­tu­ra. A questo punto, la com­ples­si­tà del sistema è cresciuta a un livello tale da essere dif­fi­cil­men­te gestibile da esseri umani. Pertanto, sono necessari strumenti speciali per aiutare le or­ga­niz­za­zio­ni a far fronte a una simile com­ples­si­tà. Per ri­spon­de­re a questa necessità sono nate alcune al­ter­na­ti­ve a OpenShift.

Come già detto, OpenShift e Docker sono tec­no­lo­gie molto distanti tra loro. Il confronto ha più senso se si include anche il software “Ku­ber­ne­tes”, noto anche come K8s. Il passaggio da Docker a K8s è pa­ra­go­na­bi­le alla tran­si­zio­ne da un organismo uni­cel­lu­la­re a un organismo plu­ri­cel­lu­la­re. E in modo simile, il passo da K8s a OpenShift è pa­ra­go­na­bi­le al passaggio da un singolo organismo a un gruppo di esseri viventi. Partendo da queste premesse, torniamo a osservare le tec­no­lo­gie in questione:

D’altronde, OpenShift è basato su K8s, che a sua volta era ori­gi­na­ria­men­te basato su Docker. Solo re­cen­te­men­te Docker e K8 si sono separati. Andiamo ad ana­liz­za­re i due estremi opposti dello spettro, OpenShift e Docker, più in dettaglio qui sotto.

Docker è una tec­no­lo­gia open source che può essere uti­liz­za­ta per im­pac­chet­ta­re le ap­pli­ca­zio­ni in container o, meglio, eseguire container di ap­pli­ca­zio­ni. Docker è usato per creare container di ap­pli­ca­zio­ni portatili e au­to­con­te­nu­ti che possono essere eseguiti in ambiente cloud o su hardware locale. Il software proviene dall’omonima società Docker Inc. Oltre alla versione open source gratuita, l’azienda offre vari prodotti a pagamento.

Ad oggi, Docker è tre strumenti in uno:

1. Docker Engine, che fornisce le fun­zio­na­li­tà di base della vir­tua­liz­za­zio­ne dei container.
2. Docker Compose, che orchestra più con­te­ni­to­ri come un unico gruppo.
3. Docker Swarm, che consente l’or­che­stra­zio­ne di cluster di container su più host.

Docker Engine a sua volta è co­sti­tui­to da tre com­po­nen­ti prin­ci­pa­li:

1. Docker Daemon, che gira come dockerd sull’host.
2. L’API Docker fornita dal Docker Deamon e che indirizza e controlla Docker Daemon.
3. L’in­ter­fac­cia a riga di comando (CLI), uti­liz­za­ta come comando docker per co­mu­ni­ca­re con l’API Docker.

Docker Engine è stato creato ini­zial­men­te per Linux. Tuttavia, anche per Mac e Windows esiste un pacchetto facile da in­stal­la­re, il co­sid­det­to “Docker Desktop”. Quest’ultimo sem­pli­fi­ca la con­fi­gu­ra­zio­ne e include un’in­ter­fac­cia utente grafica. Oltre a ciò, sono incluse anche altre tec­no­lo­gie derivate da Docker, come Docker Compose.

Docker si è affermato come lo standard per la vir­tua­liz­za­zio­ne dei container negli ultimi dieci anni, pertanto non sorprende che sia com­pa­ti­bi­le con una grande varietà di sistemi operativi. Docker è re­la­ti­va­men­te facile da in­stal­la­re e da imparare a usare. Ciò che risulta par­ti­co­lar­men­te pratica è l’enorme gamma di immagini di container pre­de­fi­ni­te. Queste con­ten­go­no ambienti software per lo sviluppo e la pro­du­zio­ne e possono essere ottenute da registri pubblici di container. Rispetto a OpenShift, Docker è una tec­no­lo­gia molto meno complessa.

I maggiori in­con­ve­nien­ti di Docker derivano dalla sua crescita organica nel corso degli anni. Ciò che è iniziato come vir­tua­liz­za­zio­ne dei container si è evoluto oggi in una piat­ta­for­ma mo­no­li­ti­ca che fa fin troppe cose con­tem­po­ra­nea­men­te. Con Docker Swarm e Docker Compose, l’uso di Docker va ben oltre i suoi obiettivi originali. Rispetto agli approcci moderni, Docker è re­la­ti­va­men­te debole in termini di sicurezza e pre­sta­zio­ni.

Oggi, Docker è for­te­men­te po­si­zio­na­to come strumento per lo sviluppo di software. Gli ambienti di sviluppo locali sono in­cap­su­la­ti come container insieme agli strumenti e ai flussi di lavoro uti­liz­za­ti. Le immagini create in questo modo possono essere condivise tra gli svi­lup­pa­to­ri e porre le basi per uno sviluppo stan­dar­diz­za­to e ri­pro­du­ci­bi­le.

Inoltre, Docker serve come base per le tec­no­lo­gie costruite sopra di esso. Gli strumenti di sviluppo, come DDEV e Lando, usano Docker per sem­pli­fi­ca­re lo sviluppo locale, mentre le piat­ta­for­me, come Portainer e Mirantis (ex Docker En­ter­pri­se), mettono a di­spo­si­zio­ne potenti strumenti per l’or­che­stra­zio­ne dei container.

Come già accennato, OpenShift opera all’estremità superiore dello spettro dei container. OpenShift è usato per costruire ap­pli­ca­zio­ni di­stri­bui­te e scalabili e ambienti di sviluppo secondo il modello Platform as a Service (PaaS). Il software fornisce un ambiente di ese­cu­zio­ne completo in cui i con­te­ni­to­ri sono di­stri­bui­ti, eseguiti, gestiti e or­che­stra­ti. Gli strumenti integrati sem­pli­fi­ca­no i moderni flussi di lavoro di sviluppo e di­stri­bu­zio­ne.

Una speciale di­stri­bu­zio­ne Ku­ber­ne­tes (K8s) è usata come base di OpenShift e può essere di­stri­bui­ta oltre i limiti del cloud e dell’in­fra­strut­tu­ra, ga­ran­ten­do così un’espe­rien­za utente con­si­sten­te. La fun­zio­na­li­tà di base di K8s è com­ple­ta­ta da ca­rat­te­ri­sti­che di sicurezza e di mo­ni­to­rag­gio e si basa su una gestione cen­tra­liz­za­ta dei criteri. Questo assicura alti standard di qualità in tutto l’ambito software di un’intera or­ga­niz­za­zio­ne.

In primo luogo, OpenShift è in grado di diminuire la com­ples­si­tà operativa associata all’am­mi­ni­stra­zio­ne di cluster K8s au­to­ge­sti­ti. Più cluster K8s possono essere gestiti con­tem­po­ra­nea­men­te in modo cen­tra­liz­za­to oltre i limiti delle in­fra­strut­tu­re cloud pubbliche e private. Seguendo l’approccio PaaS, gli svi­lup­pa­to­ri dell’azienda possono ri­chie­de­re au­to­ma­ti­ca­men­te le risorse per i propri progetti tramite un’in­ter­fac­cia web. Infine, strumenti e flussi di lavoro integrati per Con­ti­nuous In­te­gra­tion e Con­ti­nuous Delivery (CI/CD) com­ple­ta­no la gamma di funzioni e riducono i tempi di consegna in maniera drastica.

OpenShift si basa su una speciale di­stri­bu­zio­ne K8s per or­che­stra­re container e cluster. Ori­gi­na­ria­men­te, K8s era basato su Docker come runtime del con­te­ni­to­re. Nel frattempo, questa di­pen­den­za è terminata; al suo posto, viene usata la “Container Runtime Interface” della Open Container Ini­tia­ti­ve (CRI-O). Questo comporta dei vantaggi in termini di sicurezza e pre­sta­zio­ni.

In generale, OpenShift convince con le sue misure di sicurezza integrate e con “Quay” mette a di­spo­si­zio­ne un registro di container ap­po­si­ta­men­te protetto. L’au­to­riz­za­zio­ne e l’au­ten­ti­ca­zio­ne end-to-end limitano l’accesso degli utenti alle singole aree del sistema. La pos­si­bi­li­tà di ospitare i singoli cluster in diverse regioni geo­gra­fi­che permette una migliore con­for­mi­tà in termini di pro­te­zio­ne e sovranità dei dati.

OpenShift funziona solo su sistemi operativi speciali di Red Hat, come “Red Hat En­ter­pri­se Linux CoreOS” (RHCOS) e “Red Hat En­ter­pri­se Linux” (RHEL). L’in­stal­la­zio­ne è estre­ma­men­te lunga e laboriosa; per progetti di grandi di­men­sio­ni, l’in­stal­la­zio­ne può ri­chie­de­re fino a diverse settimane. A causa delle pre­cau­zio­ni di sicurezza più severe, non tutte le immagini dei container dei registri pubblici possono essere uti­liz­za­te.

Platform as a Service (PaaS), Software as a Service (SaaS) e Con­tai­ners as a Service (CaaS) sono im­ple­men­ta­ti sulla base di OpenShift. Il software è chia­ra­men­te rivolto alle grandi or­ga­niz­za­zio­ni. OpenShift è troppo grande e troppo difficile da gestire per svi­lup­pa­to­ri che lavorano in maniera autonoma.

Anche se è difficile ef­fet­tua­re un confronto diretto tra OpenShift e Docker, è possibile ana­liz­zar­ne le singole ca­rat­te­ri­sti­che. Per ragioni di com­ple­tez­za, in­clu­dia­mo di nuovo Ku­ber­ne­tes (K8s) nel confronto: