Con la 'rivoluzione' dei container le app sono cresciute molto di più che essere solo un database e un frontend. Le applicazioni sono suddivise in vari microservizi e in genere comunicano tra loro tramite un'API REST (in genere payload in formato JSON su HTTP). I contenitori Docker sono ideali per questo tipo di architettura. Puoi impacchettare il tuo 'microservizio' frontend in un contenitore Docker, il database va in un altro e così via e così via. Ogni servizio parla con un altro tramite un'API REST predefinita invece di essere un monolite scritto come un singolo pezzo di software.
Se hai bisogno di implementare una nuova funzionalità o una caratteristica, ad esempio un motore di analisi, puoi semplicemente scrivere un nuovo microservizio per quello e consumerebbe dati tramite l'API REST esposta dai vari microservizi della tua app web. E man mano che la tua funzionalità cresce nel tempo, anche questo elenco di microservizi crescerà con esso.
Non vuoi distribuire ogni singolo contenitore, configurarlo e quindi configurare tutto il resto per parlare anche con esso. Diventerà noioso anche con tre contenitori. Docker-Compose ti consente di automatizzare la distribuzione di più contenitori.
Docker-Compose è uno degli strumenti più semplici che ti aiuta a trasformare l'idea astratta di microservizi in un set funzionale di contenitori Docker.
Sistemi distribuiti
Ora che abbiamo suddiviso l'app Web in più contenitori, non ha molto senso tenerli tutti su un singolo server (peggio ancora su una singola macchina virtuale!) ed è qui che entrano in gioco servizi come Docker Swarm e Kubernetes.
Docker Swarm ti consente di eseguire più repliche della tua applicazione su più server. Se il tuo microservizio è scritto in modo da poter scalare 'orizzontalmente', puoi utilizzare Docker Swarm per distribuire la tua app Web in più data center e più regioni. Ciò offre resilienza contro il guasto di uno o più data center o collegamenti di rete. Ciò viene in genere eseguito utilizzando un sottocomando in Docker, ovvero Docker Stack.
Il Pila Docker il sottocomando si comporta in modo molto più simile al comando Docker-Compose e ciò può portare a idee sbagliate a qualcuno che utilizza una delle tecnologie.
Fonte di confusione
In termini di utilizzo e flusso di lavoro, entrambe le tecnologie funzionano in modo molto simile tra loro e questo crea confusione. Il modo in cui distribuisci la tua app utilizzando Docker Swarm o Docker-Compose è molto simile. Definisci la tua applicazione in un file YAML, questo file conterrà il nome dell'immagine, la configurazione per ogni immagine e anche la scala (numero di repliche) che ogni microservizio dovrà soddisfare nella distribuzione.
La differenza risiede principalmente nel backend, dove docker-compose distribuisce il container su un singolo host Docker, Docker Swarm lo distribuisce su più nodi. In parole povere, può ancora fare la maggior parte delle cose che può fare docker-compose, ma lo ridimensiona su più host Docker.
Somiglianze
Sia Docker Swarm che Docker-Compose hanno le seguenti somiglianze:
- Entrambi accettano definizioni formattate in YAML dello stack dell'applicazione.
- Entrambi sono pensati per gestire applicazioni multi-contenitore (microservizi)
- Entrambi hanno un parametro di scala che consente di eseguire più contenitori della stessa immagine consentendo al microservizio di ridimensionarsi orizzontalmente.
- Sono entrambi gestiti dalla stessa società, ovvero Docker, Inc.
differenze
Le poche differenze tra Docker Swarm e Docker-Compose:
- Docker Swarm viene utilizzato per ridimensionare la tua app Web su uno o più server. Dove, come Docker-compose, eseguirà semplicemente la tua app Web su un singolo host Docker.
- Ridimensionamento della tua app Web Docker Swarm offre un'elevata disponibilità e tolleranza ai guasti. Ridimensionare la tua app Web utilizzando Docker-Compose su un singolo host è utile solo per il test e lo sviluppo.
- Docker Swarm e i relativi sottocomandi come Docker Swarm e Docker Stack sono integrati nella stessa Docker CLI. Fanno tutti parte del binario Docker che chiami tramite il tuo terminale. Docker-Compose è un binario autonomo in sé e per sé.
Un caso d'uso per Docker-Compose
Come descritto sopra, sono entrambi strumenti completamente diversi e ognuno risolve un problema completamente diverso, quindi non è che uno sia un'alternativa per l'altro. Tuttavia, per dare ai nuovi arrivati un'idea di cosa sto parlando, ecco un caso d'uso per Docker Compose.
Supponiamo di voler ospitare autonomamente un blog WordPress su un singolo server. Configurarlo o mantenerlo non è qualcosa che vuoi fare, manualmente, quindi ciò che faresti invece è installare Docker e Docker-compose sul tuo VPS, creare un semplice file YAML che definisce tutti i vari aspetti del tuo stack WordPress, come di seguito, :
Nota: se stai utilizzando quanto segue per distribuire un sito WordPress, cambia tutte le password in qualcosa di sicuro. Meglio ancora, usa Docker Secrets per archiviare dati sensibili come le password, invece di averli in un semplice file di testo.
versione:'3'Servizi:
db:
immagine: mysql:5.7
volumi:
- db_data:/dove/libi/mysql
riavvia: sempre
ambiente:
MYSQL_ROOT_PASSWORD: un po' di wordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
dipende da:
- db
immagine: wordpress: più recente
porti:
-'8000: 80'
riavvia: sempre
ambiente:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpressPassword
WORDPRESS_DB_NAME: wordpress
volumi:
db_data:{}
Una volta creato il file e installati sia Docker che Docker-compose, tutto ciò che devi fare è eseguire:
$docker-componi-DE il tuo sito sarà attivo e funzionante. Se è disponibile un aggiornamento, esegui:
$docker-componi giùQuindi getta via le vecchie immagini Docker ed esegui il comando docker-compose up -d e le nuove immagini verranno automaticamente inserite. Poiché i dati persistenti sono archiviati in un volume Docker, il contenuto del tuo sito Web non andrà perso.
Quando usare Docker Swarm
Mentre Docker-compose è più uno strumento di automazione, Docker Swarm è pensato per applicazioni più impegnative. App Web con centinaia o migliaia di utenti o carichi di lavoro che devono essere ridimensionati parallelamente. Le aziende con un'ampia base di utenti e rigorosi requisiti SLA vorrebbero utilizzare un sistema distribuito come Docker Swarm. Se la tua app è in esecuzione su più server e più data center, le possibilità di tempi di inattività a causa di un controller di dominio o di un collegamento di rete interessati vengono notevolmente ridotte.
Detto questo, esito a raccomandare Docker Swarm per i casi d'uso di produzione perché le tecnologie concorrenti come Kubernetes sono probabilmente più adatte a questo compito. Kubernetes è supportato in modo nativo da molti provider cloud e funziona abbastanza bene con Docker Containers, quindi non devi nemmeno ricostruire la tua app per sfruttare Kubernetes.
Conclusione
Spero che questa divagazione su Docker e sui suoi progetti satellitari sia stata istruttiva e che tu sia più preparato per l'ecosistema docker.