Innanzitutto, cosa c’era prima di Docker?
Rispondere a questa domanda senza generalizzare troppo è molto difficile.
Tuttavia, semplificando, possiamo racchiudere tutto in due macro-categorie: Macchine Fisiche e Macchine Virtuali.
Macchine Fisiche
Come tutte le soluzioni, presentano sia pro sia contro.
Dato che stiamo parlando do Docker, mi limito a esplicitare i problemi che hanno spinto a trovare una soluzione in tale direzione.
- Dimensionate con una stima, spesso difficile da eseguire
- Costi Elevati
- Difficoltà a scalare
- Difficoltà a replicare il codice in altre macchine
- Difficoltà di monitoraggio delle risorse in modo centralizzato
- Tempistiche d’intervento molto lunghe in caso di failure
I punti trovano riscontro in diversi aspetti. Il primo che mi viene in mente è un servizio con picchi di utenza e lunghi periodi di carico basso.
Con in sistema a macchine fisiche (Bare-Metal) l’unica soluzione è avere in dotazione l’infrastruttura necessaria alla gestione dell’intero carico. Pagando per la gestione della stessa ed il costo di mantenimento in servizio anche nei periodi in cui l’utilizzo è ridotto.
A questo aspetto si somma anche l’esattezza della stima di massimo carico che, se errata, rischia anche di rendere il costoso sistema inadeguato al carico.
Con Docker si può risolvere, attraverso i Command Line Tool, la problematica della decentralizzazione delle risorse. Vi è un sistema infatti che permette di vedere in modo centralizzato, lo stato di tutte le risorse in ogni momento.
E in caso di failure?
In un ambiente di questo tipo, un problema ad una macchina determina una procedura risolutiva piuttosto lunga. Innanzitutto capire di quale macchina si tratta. Poi dobbiamo ripristinare il suo ambiente e solo dopo possiamo tornare operativi.
Con Docker invece sarà sufficiente riavviare il container associando eventualmente la nuova risorsa. Qualora il problema si facesse più grave e coinvolgesse una macchina su cui sta girando Docker, basterà installare Docker su una nuova macchina ed il resto, dopo il deploy dell’infrastruttura, verrà da se.
Macchine Virtuali
Spesso utilizzate per spedire (delivery) delle applicazioni complete.
Di conseguenza, se volessimo trasportare l’approccio a microservizi alle macchine virtuali, dovremmo avere una macchina virtuale per ogni servizio.
Per ogni macchina virtuale dovrei gestire singolarmente sistema operativo, ram, disco, processori, visibilità di rete.
Non è sicuramente la miglior soluzione possibile.
Prendiamo ad esempio avere un server Apache con MySql e un reverse proxy NGINX. Una gestione a microservizi si macchine virtuali richiederebbe tre sistemi operativi, magari anche della stessa versione.
È proprio qui che emerge il reale vantaggio di utilizzare Docker.
Quello che succede è che vengono creati dei container. I container sono una sorta di sandbox, e dialogano con l’esterno con delle modalità che approfondiremo quando parleremo di Network e di apertura delle porte nei container.
Spesso utilizzare Docker o meno determina la possibilità o meno di realizzare un servizio con l’infrastruttura a disposizione o meno
—
Prosegui su: Container su Windows e Mac
Immagine: photoangel – it.freepik.com