OpenShift vs. Docker

Docker ha portato al trionfo della virtualizzazione basata su container. Il software è una tecnologia di base per creare ed eseguire contenitori di applicazioni. Docker è usato da singoli sviluppatori sui propri computer portatili, per esempio, per standardizzare i flussi di lavoro di sviluppo. OpenShift gioca all’altra estremità dello spettro di virtualizzazione, coprendo i requisiti operativi di un’intera organizzazione. La sua base è costituita da ambienti cloud pubblici e privati.

Le due tecnologie non sono affatto da considerarsi concorrenti diretti. Anzi, in passato OpenShift si basava indirettamente su Docker e ancora oggi utilizza il formato contenitore Docker. In questo articolo vi forniremo una panoramica dei due strumenti, andando poi ad approfondire i relativi punti di forza e di debolezza, nonché i rispettivi scenari di implementazione.

Nelle discussioni online o nei post dei blog capita spesso di imbattersi nella questione se sia meglio OpenShift o Docker come strumento per la virtualizzazione dei container. Anche se la domanda viene posta spesso, va ricordato che si tratta in realtà di tecnologie molto distanti tra loro. Sia OpenShift che Docker hanno la propria ragion d’essere e sono solitamente usati in modo complementare. Paragonare le tecnologie OpenShift e Docker è un po’ come chiedere: “è meglio spostarsi in automobile 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 dimensioni completamente diverse.

A differenza dei contenitori fisici, la funzione principale della loro controparte virtuale non è essere una tecnologia di trasporto. Serviamoci di un’analogia presa in prestito dalla biologia per capire meglio la questione. Infatti, i contenitori di applicazioni e le cellule hanno molto in comune: entrambi sono un’unità fondamentale di informazione incapsulata, sigillata esternamente, che diventa “viva”.

Nel mondo vivente, l’evoluzione ha avuto luogo da organismi unicellulari a organismi pluricellulari. Allo stesso modo, nel mondo virtuale, c’è stata un’evoluzione da singoli contenitori a reti orchestrate di contenitori interagenti. Le sfide associate alla multicellularità sono inoltre simili a quelle che sorgono dall’interazione di più contenitori.

Le cellule biologiche e i contenitori delle applicazioni devono comunicare tra loro. Devono riformarsi o morire a seconda delle necessità. Le risorse totali disponibili devono essere distribuite tra le singole unità. Tutto questo dovrebbe essere ben coordinato in modo che l’intero sistema possa reagire ai cambiamenti della domanda e rimanere stabile nel lungo periodo. Illustriamo la gamma di virtualizzazione dei container da Docker a OpenShift con la seguente panoramica:

Appare dunque evidente che alla domanda su quale sia la tecnologia migliore si può rispondere solo assumendo una prospettiva specifica. In definitiva, dipende fortemente dal punto di vista. Questo vale anche per il confronto tra OpenShift e Docker.

Docker ha reso popolare la virtualizzazione dei container e ha ampiamente soppiantato le macchine virtuali (VM) precedentemente dominanti. Il trionfo di container di applicazioni ha rivoluzionato il modo in cui le applicazioni sono costruite, impacchettate ed eseguite. Questo perché i container sono un’unità software standardizzata. Possono essere usati senza problemi ovunque sia disponibile un runtime di container corrispondente.

A differenza delle macchine virtuali precedentemente onnipresenti ma piuttosto complicate, i container risultano essere decisamente più leggeri. Su un solo host possono essere eseguiti decine o migliaia di container. Questo vantaggio intrinseco della virtualizzazione dei container ha portato alla diffusione delle architetture di microservizi distribuiti. Invece di costruire un’applicazione monolitica, l’ambito funzionale è suddiviso in singoli componenti. Ciascun componente è impacchettato come un servizio (“service”) in un proprio container. I container vengono avviati e i servizi comunicano tra loro attraverso la rete.

L’approccio microservizi è particolarmente pratico per lo sviluppo del software perché per ogni servizio permette di utilizzare le tecnologie più appropriate. Invece di essere legati a singoli linguaggi di programmazione e paradigmi, si può variare tra i diversi servizi. Man mano che arrivano nuove tecnologie risulta così più semplice implementare nuovamente i singoli servizi.

La capacità di clonare diversi container simili da un’immagine container ha come risultato la scalabilità del sistema complessivo. In caso di aumento della domanda, vengono avviati altri container e il rispettivo servizio scalato orizzontalmente. Questa operazione però richiede un sistema che si occupi di monitorare i container in esecuzione e, quando necessario, di terminarli o avviarne di nuovi. Inoltre, le richieste in arrivo devono essere distribuite ai singoli container.

La scalabilità fa sì che la complessità del sistema cresca notevolmente, in quanto diventano necessarie le seguenti azioni:

• Accogliere richieste tramite il load balancer
• Distribuire i compiti ai singoli container
• Monitorare 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 aggiornamenti, ecc.

A tutto ciò si aggiunge anche un enorme sovraccarico amministrativo. Ma non è finita qui. Bisogna anche considerare la manutenzione del sistema amministrativo stesso. Questo livello di controllo, che esegue tutti i punti di cui sopra, ha a sua volta necessità di manutenzione, monitoraggio e aggiornamenti. Dal lato dell’utente non è possibile permettersi alcun tipo di perdita di prestazione sensibile, mentre la sicurezza dell’intero sistema deve sempre essere garantita.

Per ultima cosa, ma non meno importante, vogliamo anche essere in grado di orchestrare i nostri cluster di container oltre i limiti dell’infrastruttura. A questo punto, la complessità del sistema è cresciuta a un livello tale da essere difficilmente gestibile da esseri umani. Pertanto, sono necessari strumenti speciali per aiutare le organizzazioni a far fronte a una simile complessità. Per rispondere a questa necessità sono nate alcune alternative a OpenShift.

Come già detto, OpenShift e Docker sono tecnologie molto distanti tra loro. Il confronto ha più senso se si include anche il software “Kubernetes”, noto anche come K8s. Il passaggio da Docker a K8s è paragonabile alla transizione da un organismo unicellulare a un organismo pluricellulare. E in modo simile, il passo da K8s a OpenShift è paragonabile al passaggio da un singolo organismo a un gruppo di esseri viventi. Partendo da queste premesse, torniamo a osservare le tecnologie in questione:

D’altronde, OpenShift è basato su K8s, che a sua volta era originariamente basato su Docker. Solo recentemente Docker e K8 si sono separati. Andiamo ad analizzare i due estremi opposti dello spettro, OpenShift e Docker, più in dettaglio qui sotto.

Docker è una tecnologia open source che può essere utilizzata per impacchettare le applicazioni in container o, meglio, eseguire container di applicazioni. Docker è usato per creare container di applicazioni portatili e autocontenuti 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 funzionalità di base della virtualizzazione dei container.
2. Docker Compose, che orchestra più contenitori come un unico gruppo.
3. Docker Swarm, che consente l’orchestrazione di cluster di container su più host.

Docker Engine a sua volta è costituito da tre componenti principali:

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’interfaccia a riga di comando (CLI), utilizzata come comando docker per comunicare con l’API Docker.

Docker Engine è stato creato inizialmente per Linux. Tuttavia, anche per Mac e Windows esiste un pacchetto facile da installare, il cosiddetto “Docker Desktop”. Quest’ultimo semplifica la configurazione e include un’interfaccia utente grafica. Oltre a ciò, sono incluse anche altre tecnologie derivate da Docker, come Docker Compose.

Docker si è affermato come lo standard per la virtualizzazione dei container negli ultimi dieci anni, pertanto non sorprende che sia compatibile con una grande varietà di sistemi operativi. Docker è relativamente facile da installare e da imparare a usare. Ciò che risulta particolarmente pratica è l’enorme gamma di immagini di container predefinite. Queste contengono ambienti software per lo sviluppo e la produzione e possono essere ottenute da registri pubblici di container. Rispetto a OpenShift, Docker è una tecnologia molto meno complessa.

I maggiori inconvenienti di Docker derivano dalla sua crescita organica nel corso degli anni. Ciò che è iniziato come virtualizzazione dei container si è evoluto oggi in una piattaforma monolitica che fa fin troppe cose contemporaneamente. Con Docker Swarm e Docker Compose, l’uso di Docker va ben oltre i suoi obiettivi originali. Rispetto agli approcci moderni, Docker è relativamente debole in termini di sicurezza e prestazioni.

Oggi, Docker è fortemente posizionato come strumento per lo sviluppo di software. Gli ambienti di sviluppo locali sono incapsulati come container insieme agli strumenti e ai flussi di lavoro utilizzati. Le immagini create in questo modo possono essere condivise tra gli sviluppatori e porre le basi per uno sviluppo standardizzato e riproducibile.

Inoltre, Docker serve come base per le tecnologie costruite sopra di esso. Gli strumenti di sviluppo, come DDEV e Lando, usano Docker per semplificare lo sviluppo locale, mentre le piattaforme, come Portainer e Mirantis (ex Docker Enterprise), mettono a disposizione potenti strumenti per l’orchestrazione dei container.

Come già accennato, OpenShift opera all’estremità superiore dello spettro dei container. OpenShift è usato per costruire applicazioni distribuite e scalabili e ambienti di sviluppo secondo il modello Platform as a Service (PaaS). Il software fornisce un ambiente di esecuzione completo in cui i contenitori sono distribuiti, eseguiti, gestiti e orchestrati. Gli strumenti integrati semplificano i moderni flussi di lavoro di sviluppo e distribuzione.

Una speciale distribuzione Kubernetes (K8s) è usata come base di OpenShift e può essere distribuita oltre i limiti del cloud e dell’infrastruttura, garantendo così un’esperienza utente consistente. La funzionalità di base di K8s è completata da caratteristiche di sicurezza e di monitoraggio e si basa su una gestione centralizzata dei criteri. Questo assicura alti standard di qualità in tutto l’ambito software di un’intera organizzazione.

In primo luogo, OpenShift è in grado di diminuire la complessità operativa associata all’amministrazione di cluster K8s autogestiti. Più cluster K8s possono essere gestiti contemporaneamente in modo centralizzato oltre i limiti delle infrastrutture cloud pubbliche e private. Seguendo l’approccio PaaS, gli sviluppatori dell’azienda possono richiedere automaticamente le risorse per i propri progetti tramite un’interfaccia web. Infine, strumenti e flussi di lavoro integrati per Continuous Integration e Continuous Delivery (CI/CD) completano la gamma di funzioni e riducono i tempi di consegna in maniera drastica.

OpenShift si basa su una speciale distribuzione K8s per orchestrare container e cluster. Originariamente, K8s era basato su Docker come runtime del contenitore. Nel frattempo, questa dipendenza è terminata; al suo posto, viene usata la “Container Runtime Interface” della Open Container Initiative (CRI-O). Questo comporta dei vantaggi in termini di sicurezza e prestazioni.

In generale, OpenShift convince con le sue misure di sicurezza integrate e con “Quay” mette a disposizione un registro di container appositamente protetto. L’autorizzazione e l’autenticazione end-to-end limitano l’accesso degli utenti alle singole aree del sistema. La possibilità di ospitare i singoli cluster in diverse regioni geografiche permette una migliore conformità in termini di protezione e sovranità dei dati.

OpenShift funziona solo su sistemi operativi speciali di Red Hat, come “Red Hat Enterprise Linux CoreOS” (RHCOS) e “Red Hat Enterprise Linux” (RHEL). L’installazione è estremamente lunga e laboriosa; per progetti di grandi dimensioni, l’installazione può richiedere fino a diverse settimane. A causa delle precauzioni di sicurezza più severe, non tutte le immagini dei container dei registri pubblici possono essere utilizzate.

Platform as a Service (PaaS), Software as a Service (SaaS) e Containers as a Service (CaaS) sono implementati sulla base di OpenShift. Il software è chiaramente rivolto alle grandi organizzazioni. OpenShift è troppo grande e troppo difficile da gestire per sviluppatori che lavorano in maniera autonoma.

Anche se è difficile effettuare un confronto diretto tra OpenShift e Docker, è possibile analizzarne le singole caratteristiche. Per ragioni di completezza, includiamo di nuovo Kubernetes (K8s) nel confronto: