Un’applicazione in container richiede un modello operativo adeguato. Docker Compose può bastare per un servizio di produzione dalla complessità contenuta. Kubernetes diventa interessante quando occorre distribuire le applicazioni su più macchine e gestirne sistematicamente il deployment. La scelta parte dai requisiti dell’applicazione.
Un’azienda gestisce un portale interno con interfaccia web, database ed elaborazioni in background. Dispone di una finestra di manutenzione, di un carico contenuto e di un amministratore responsabile. Un’altra azienda distribuisce nuove versioni di diversi servizi più volte alla settimana e deve rimanere raggiungibile anche durante la manutenzione programmata. Entrambe usano container, ma possono aver bisogno di modelli operativi diversi.
Docker, Compose e Kubernetes svolgono compiti diversi
Un runtime esegue i container. Docker Engine offre una piattaforma molto diffusa per questo scopo. Docker Compose descrive i servizi che compongono un’applicazione in un file YAML. Il file può riunire immagini, reti, volumi persistenti e configurazioni. Gli strumenti Compose creano e gestiscono l’applicazione sull’host Docker a cui si collegano.
Kubernetes gestisce invece lo stato desiderato dei workload in un cluster. Assegna i Pod ai nodi adatti e può sostituire le istanze gestite o aggiornarle gradualmente. Ogni nodo richiede comunque un runtime per container adeguato. I file Compose e le risorse Kubernetes descrivono il deployment in modi diversi: migrare richiede quindi più che rinominare un file.
Le dimensioni dell’azienda dicono poco su questa scelta. Un piccolo gruppo di sviluppo con release frequenti può trarre vantaggio dall’orchestrazione. Un’azienda molto più grande può gestire un singolo servizio applicativo supportato su un solo host ben mantenuto.
Docker Compose è previsto anche per la produzione
Docker documenta espressamente l’impiego di Compose in produzione, soprattutto su un singolo server. Le configurazioni di sviluppo e produzione possono essere separate oppure integrate per esigenze specifiche. Le politiche di riavvio, le porte pubblicate, i log e la procedura di aggiornamento devono essere adeguati all’ambiente di produzione.
Per un portale documentale interno può essere una soluzione chiara: un numero contenuto di servizi, versioni documentate, dati protetti e ripristino verificato. Il guasto dell’host richiede comunque un piano separato. Una politica di riavvio non sposta l’applicazione su un’altra macchina. Anche la ridondanza della virtualizzazione sottostante e il backup dell’applicazione appartengono a livelli distinti.
Conta anche il metodo di installazione supportato dal produttore del software. Un deployment Compose mantenuto ufficialmente può essere più utile per l’esercizio di un’installazione cluster realizzata in proprio senza un percorso di aggiornamento affidabile.
La matrice decisionale per l’esercizio
| Domanda | Docker Compose su un host | Kubernetes |
|---|---|---|
| Quanto è esteso l’ambiente? | Adatto a singole applicazioni con un numero contenuto di servizi. | Più workload e nodi possono essere gestiti mediante regole comuni della piattaforma. |
| Che cosa succede se un host si guasta? | Il ripristino o la ridondanza dell’infrastruttura vengono organizzati al di fuori di Compose. | La sostituzione su altri nodi è possibile se applicazione, capacità, controllo e accesso ai dati sono stati predisposti a questo scopo. |
| Come vengono distribuite le release? | I servizi interessati vengono sostituiti con una procedura documentata e, quando opportuno, automatizzata. | Le regole di deployment consentono rollout controllati. Le modifiche ai dati e i test funzionali devono comunque essere pianificati separatamente. |
| Dove sono conservati i dati aziendali? | In volumi o servizi esterni con procedure proprie di backup e ripristino. | In storage persistente o servizi esterni, la cui resilienza e protezione dei dati devono essere valutate. |
| Chi mantiene la piattaforma? | La responsabilità comprende host, runtime, immagini e applicazione. | Comprende inoltre il cluster, l’integrazione di rete, il collegamento allo storage e i relativi cicli di vita. |
| Come viene valutato lo stato del servizio? | Vengono monitorati host, servizi e processi aziendali. | Si monitorano anche lo stato del cluster e l’interazione tra i componenti della piattaforma: un Pod in esecuzione, da solo, non basta. |
| Che cosa supporta il fornitore? | Sono determinanti il metodo di installazione supportato e il suo percorso di aggiornamento. | Devono essere disponibili un deployment Kubernetes gestibile e un supporto adeguato del produttore. |
Quando Kubernetes offre un vantaggio concreto
Un motivo valido può essere la necessità di gestire in modo coerente molti deployment simili o di ripartire la capacità di calcolo disponibile tra più servizi. Anche aggiornamenti frequenti con regole di rollout chiare e responsabilità separate tra ambiti applicativi possono giustificarlo. Servono però un’applicazione in grado di funzionare con più istanze e competenze adeguate per gestire l’ulteriore lavoro sulla piattaforma.
Prima della scelta occorre chiarire se il fornitore gestisce il piano di controllo, quali componenti devono essere mantenuti internamente e quali compiti rimangono in caso di guasto. Un cluster gestito riduce determinate attività sulla piattaforma. Rimane la responsabilità per applicazione, autorizzazioni, dati e costi.
Un ostacolo tipico sono le ipotesi sui dati condivisi. L’applicazione aziendale può funzionare con più istanze attive? Dove scrive i file? Dove vengono conservate le sessioni? Un’attività in background può essere eseguita di nuovo senza conseguenze? Queste domande vanno risolte prima della migrazione. Un container tecnicamente raggiungibile non dimostra che gli ordini vengano elaborati correttamente.
L’impegno riguarda l’intero ciclo di vita
Per un confronto non bastano i soli costi del server o del cloud. Vanno considerati anche introduzione, documentazione, aggiornamenti, monitoraggio, backup e tempo dedicato agli incidenti. Kubernetes richiede inoltre conoscenze della piattaforma e coordinamento tra cluster, rete e storage. Un esercizio standardizzato può ridurre il lavoro ricorrente, ma prima occorre creare e mantenere quello standard.
Per il calcolo dei costi sono utili tre scenari: continuare a gestire correttamente l’applicazione esistente, uniformarla su Compose oppure introdurre una piattaforma Kubernetes. In ciascuno scenario si applicano gli stessi requisiti aziendali. Altrimenti si rischia di confrontare un semplice server singolo con un obiettivo di disponibilità molto superiore, senza rendere esplicita la differenza.
Come arrivare a una decisione solida
- Definire gli obiettivi operativi: descrivere interruzioni ammissibili, finestre di manutenzione, perdita di dati accettabile e modifiche previste.
- Verificare l’applicazione: rilevare installazioni supportate, funzionamento con più istanze, file, sessioni e interfacce esterne.
- Assegnare le responsabilità: individuare chi si occupa di manutenzione, segnalazioni, ripristino e sostituzioni in caso di assenza.
- Provare con un servizio: simulare un aggiornamento, un guasto e un ripristino nell’architettura prevista, documentando l’impegno necessario.
- Estendere solo in seguito: valutare altre applicazioni in base agli stessi criteri.
DAXS combina la valutazione dell’applicazione e delle sue interfacce con la pianificazione dell’infrastruttura e con un modello operativo adeguato. Per una prima valutazione bastano un servizio concreto, le sue dipendenze e gli obiettivi operativi richiesti. Il colloquio personale parte da questi elementi.
Fonti: Docker: il modello applicativo di Compose · Docker Compose in produzione · Kubernetes: componenti e responsabilità · Kubernetes: Deployment e rollout · Pianificare un ambiente Kubernetes di produzione
