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.

OpenShift e Docker: come confrontarli?

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:

Tecnologia Funzione Equivalente biologico
Docker Containerizzazione Cellule singole e semplici (ad esempio i batteri)
Docker Compose Orchestrazione di container Cellule singole e complesse (per esempio cellule di lievito)
Docker Swarm, K8s (Kubernetes) Orchestrazione di container / cluster Organismi multicellulari indipendenti
OpenShift Orchestrazione multi-cluster Gruppo di esseri viventi

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.

Dalla virtualizzazione dei container, passando per l’orchestrazione fino alla gestione multi-cluster

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.

OpenShift o Docker: cosa sta nel mezzo?

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:

Software Funzione Descrizione
Docker Containerizzazione Gestisce singoli container.
Docker Compose Orchestrazione di container Gestisce diversi container combinati tra loro.
Docker Swarm, K8s Orchestrazione di container / cluster Gestisce un gran numero di container su cluster di calcolo e li scala secondo necessità.
OpenShift Soluzione di gestione K8s Controlla più cluster K8s oltre i limiti del cloud. Compresi strumenti di sviluppo integrati, monitoraggio, CI/CD, ecc.

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: la tecnologia container di base

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.

Quali sono i vantaggi di Docker?

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.

Quali sono gli svantaggi di Docker?

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.

Per quali finalità d’uso è più adatto Docker?

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.

Consiglio

Imparate a usare i container sul vostro sistema con il nostro tutorial di Docker.

OpenShift: la potente piattaforma di applicazioni e sviluppo

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.

Quali sono i vantaggi di OpenShift?

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.

Quali sono gli svantaggi di OpenShift?

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.

Per quali finalità d’uso è più adatto OpenShift?

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.

OpenShift vs. Docker: il confronto diretto

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:

Proprietà OpenShift K8s Docker
Provenienza del software Oltre alle versioni aziendali offerte da Red Hat, OKD è un’edizione Community liberamente disponibile. La distribuzione ufficiale “Vanilla” K8s è rilasciata come progetto open source dalla “Cloud Native Computing Foundation” (CNCF). Il software è rilasciato dalla società Docker Inc. I componenti open source sottostanti sono sviluppati nel quadro del progetto “Moby”.
Modello di distribuzione Possibilità di implementazioni multi-cloud e ibride. Le implementazioni multi-cloud e di cloud ibridi sono una sfida. Implementazioni multi-cloud per Docker Swarm.
Piattaforme cloud supportate Come soluzione gestita, OpenShift funziona sulle piattaforme cloud AWS, Azure, Google Cloud e IBM Cloud. Essendo una soluzione autogestita, il software può essere eseguito praticamente su qualsiasi infrastruttura. Molte piattaforme cloud offrono l’hosting gestito di K8s. Molte piattaforme cloud offrono soluzioni Container as a Service (CaaS) dedicate.
Installazione Richiede un ambiente cluster o cloud per l’installazione. Incluso come componente di Docker, o integrato nelle soluzioni Managed K8s. Facile da installare su un singolo host.
Release Fino a tre release all’anno. Fino a quattro release all’anno. Diverse release dei singoli componenti Docker ogni anno.
Gestione degli aggiornamenti Aggiornamenti semplificati da Cluster Version Operator. Gli aggiornamenti continui permettono al sistema di essere aggiornato senza alcuna perdita di prestazioni. Possibili aggiornamenti continui per Docker Swarm.
Gestione dell’immagine del contenitore Il registro dei container Quay di Red Hat contiene immagini controllate per la vulnerabilità. Nessun registro container nativo. Tutti i registri pubblici, specialmente Docker Hub, possono essere utilizzati.
Utilizzo di template Oltre ai modelli propri di OpenShift, vengono utilizzati potenti “operators” per standardizzare il deployment e il funzionamento delle applicazioni. Le cosiddette “Helm Charts” forniscono un meccanismo flessibile per definire i cluster K8s. I contenitori individuali sono definiti tramite Dockerfile; un file YAML è usato per Docker Compose.
Gestione della rete Rete definita dal software (SDN) e rete overlay tramite Open vSwitch (OVS) Nessuna gestione nativa della rete. Networking multi-host con rete overlay.
Interfaccia web L’interfaccia web di OpenShift è considerata una delle migliori del settore. Nessuna interfaccia web nativa. Docker Desktop è un’applicazione GUI; varie interfacce web sono disponibili per l’installazione.
Pipeline CI/CD integrata Le versioni precedenti usavano lo standard industriale “Jenkins”; ora si usa “Tekton”. Nessuna pipeline CI/CD nativa; installazione tramite helm possibile. Può essere configurato per l’uso con GitHub Actions; Jenkins include un plugin per l’uso con Docker.
Funzioni di sicurezza Ampie funzioni di sicurezza. Le funzioni di sicurezza devono essere implementate per progetto. Funzioni di sicurezza di base.
Uso aziendale Utilizzato da più di duemila organizzazioni in tutto il mondo. Utilizzato da sempre più aziende; in parte come soluzione gestita o come componente di altri software. Componente fondamentale del moderno sviluppo del software.
Per offrirti una migliore esperienza di navigazione online questo sito web usa dei cookie, propri e di terze parti. Continuando a navigare sul sito acconsenti all’utilizzo dei cookie. Scopri di più sull’uso dei cookie e sulla possibilità di modificarne le impostazioni o negare il consenso.
Page top