Container orchestration, come semplificare la gestione delle applicazioni
Guida all’orchestrazione container: strumenti, vantaggi e criteri di scelta
La container orchestration è il processo automatico di gestione o pianificazione del lavoro di singoli container, per applicazioni basate su microservizi all’interno di più cluster. Queste operazioni possono essere eseguite in un numero elevato di varianti di ambiente, modalità e approccio ai microservizi.
Parlando di container, il nome di riferimento nei container è senz’altro Docker, un approccio di virtualizzazione basato su Linux. I container sono impostati per svolgere il lavoro in un’architettura a più container, denominata cluster di container.
Parlando di container, tra i runtime più diffusi troviamo Docker, un approccio di virtualizzazione basato su Linux, e containerd, oggi runtime standard adottato nativamente da Kubernetes. I container sono impostati per svolgere il lavoro in un’architettura container a più nodi, denominata cluster di container.
Le principali piattaforme di container orchestration
Le piattaforme di container orchestration ampiamente distribuite si basano su versioni open source come Kubernetes, Docker Swarm o la versione commerciale di Red Hat OpenShift.
Kubernetes è di fatto la più nota piattaforma open source per l’orchestrazione container, ma la gestione dei cluster Kubernetes richiede molto overhead. Per questo i principali cloud provider offrono servizi gestiti: tra questi, Azure Kubernetes Service (AKS) e Azure Container Apps di Microsoft, Amazon Elastic Container Service (ECS) e Google Kubernetes Engine (GKE).
Bisogna quindi prestare attenzione alle caratteristiche specifiche delle varie soluzioni, che in genere non sono interscambiabili, anzi presentano molte differenze le une dalle altre. Le piattaforme di gestione dei container possono includere funzionalità di orchestrazione, ma molte soluzioni funzionano come complemento alla piattaforma di gestione.
I benefici della container orchestration
Il software di container orchestration consente agli sviluppatori di distribuire i container all’interno delle applicazioni. Le aziende li usano per aumentare la scalabilità e la funzionalità delle applicazioni aggiungendo container e collegando informazioni su repository e reti.
Ciascuna scelta va ponderata in funzione degli obiettivi immediati e a medio termine che l’IT architect si propone di raggiungere: una scelta troppo orientata sul risultato immediato potrebbe rendere più farraginosi gli sviluppi futuri.
Questi strumenti infatti intervengono grandemente nel lavoro degli amministratori IT che oggi si trovano a dover automatizzare il processo di esecuzione di istanze, host provisioning e collegamento. Nel dettaglio, le piattaforme di orchestrazione consentono di:
- automatizzare il deployment, il provisioning e il collegamento dei container
- identificare container non funzionanti e ripristinarli automaticamente
- configurare le applicazioni e ottimizzare l’uso delle risorse
- migliorare la sicurezza impostando requisiti di accesso e mantenendo i componenti isolati
- estendere il ciclo di vita delle applicazioni complesse riutilizzando i processi di deploy
Scegliere l’orchestratore più adatto all’azienda
Il modo più immediato di semplificare la gestione delle applicazioni è scegliere il tool più adeguato. Esistono molte soluzioni che rientrano nella stessa categoria, ma non coprono le stesse fasi allo stesso modo. Abbiamo già citato Docker Swarm, Kubernetes, Red Hat OpenShift e le soluzioni cloud dei principali provider.
Altri software di orchestrazione dei container sono Apache Mesos e IBM Cloud Kubernetes Service (IKS), un framework integrato che semplifica lo sviluppo e il deployment. Tutte le soluzioni più diffuse aderiscono allo standard Open Container Initiative (OCI), che garantisce interoperabilità tra runtime e strumenti diversi.
Conclusioni
L’adozione del modello open source mette a disposizione un numero elevato di soluzioni che a prima vista sembrano molto simili. Una prima, importante valutazione da fare è il costo reale di implementazione e manutenzione in un periodo di medio termine, ad esempio nei primi tre anni di implementazione dell’orchestrazione.
Inoltre, le differenze nei processi e nella matrice di compatibilità – si pensi ai microservizi – rischiano di diventare colli di bottiglia in un futuro molto vicino. Nella scelta, va dato un peso rilevante alla sicurezza: non partire direttamente con la security by design, se non proprio con un approccio DevSecOps, potrebbe essere motivo di rallentamenti quando si presume di aver completato la prima fase di sviluppo.