Med beholderen 'revolusjon' har apper vokst mye mer enn å bare være en database og en frontend. Applikasjoner er delt inn i forskjellige mikrotjenester, og de kommuniserer vanligvis med hverandre via et REST API (vanligvis JSON -formatert nyttelast over HTTP). Dockerbeholdere er ideelle for denne typen arkitektur. Du kan pakke frontend ‘mikroservice’ inn i en Docker -beholder, databasen går inn i en annen, og så videre og så videre. Hver tjeneste snakker med en annen over et forhåndsdefinert REST API i stedet for å være en monolit skrevet som en enkelt programvare.
Hvis du trenger å implementere en ny funksjonalitet eller en funksjon, for eksempel en analysemotor, kan du ganske enkelt skrive en ny mikrotjeneste for det, og det ville forbruke data via REST API som ble avslørt av de forskjellige mikrotjenestene i nettappen din. Og ettersom funksjonaliteten din vokser over tid, vil denne listen over mikrotjenester vokse sammen med den også.
Du vil ikke distribuere hver enkelt beholder, konfigurere den og deretter konfigurere alt annet for å snakke med den også. Det vil bli kjedelig med tre beholdere. Med Docker-Compose kan du automatisere distribusjonen av flere beholdere.
Docker-Compose er et av de enkleste verktøyene som hjelper deg med å transformere den abstrakte ideen om mikroservices til et funksjonelt sett med Docker-beholder.
Distribuerte systemer
Nå som vi har delt nettappen i flere beholdere, er det lite fornuftig å beholde dem alle på en enkelt server (enda verre på en enkelt virtuell maskin!) Det er der tjenester som Docker Swarm og Kubernetes spiller inn.
Docker Swarm lar deg kjøre flere kopier av appen din på tvers av flere servere. Hvis mikrotjenesten din er skrevet på en måte som kan skaleres ‘horisontalt’, kan du bruke Docker Swarm til å distribuere nettappen din på tvers av flere datasentre og flere regioner. Dette gir motstandskraft mot svikt i ett eller flere datasentre eller nettverkskoblinger. Dette gjøres vanligvis med en underkommando i Docker, det vil si Docker Stack.
De Docker Stack underkommando oppfører seg mye mer som Docker-Compose-kommandoen, og det kan føre til misforståelser for noen som bruker noen av teknologiene.
Forvirringskilde
Når det gjelder bruk og arbeidsflyt, fungerer begge teknologiene veldig likt hverandre, og dette forårsaker forvirring. Måten du distribuerer appen din på enten Docker Swarm eller Docker-Compose er veldig lik. Du definerer søknaden din i en YAML -fil, denne filen vil inneholde bildenavnet, konfigurasjonen for hvert bilde og også skalaen (antall replikaer) som hver mikrotjeneste må oppfylle ved distribusjon.
Forskjellen ligger stort sett i backend, der docker-compose distribuerer container på en enkelt Docker-vert, Docker Swarm distribuerer den på tvers av flere noder. Løst sett kan den fremdeles gjøre det meste som docker-komponere kan, men den skalerer den over flere Docker-verter.
Likheter
Både Docker Swarm og Docker-Compose har følgende likheter:
- De tar begge YAML -formaterte definisjoner av applikasjonsbunken.
- De er begge ment å håndtere applikasjoner med flere beholdere (mikrotjenester)
- De har begge en skalaparameter som lar deg kjøre flere beholdere med det samme bildet, slik at din mikrotjeneste kan skalere horisontalt.
- De vedlikeholdes begge av det samme selskapet, dvs. Docker, Inc.
Forskjeller
De få forskjellene mellom Docker Swarm og Docker-Compose:
- Docker Swarm brukes til å skalere nettappen din over en eller flere servere. Hvor som Docker-compose ganske enkelt vil kjøre nettappen din på en enkelt Docker-vert.
- Skalering av nettappen din Docker Swarm tilbyr alvorlig høy tilgjengelighet og feiltoleranse. Skalering av nettappen din ved hjelp av Docker-Compose på en enkelt vert er bare nyttig for testing og utvikling.
- Docker Swarm og relaterte underkommandoer som Docker Swarm og Docker Stack er innebygd i selve Docker CLI. De er alle en del av Docker -binæret som du ringer via terminalen din. Docker-Compose er frittstående binær i seg selv.
En brukstilfelle for Docker-Compose
Som beskrevet ovenfor er de begge helt forskjellige verktøy, og hver løser et helt annet problem, så det er ikke som om det ene er et alternativ for det andre. For å gi nybegynnere en følelse av hva jeg snakker om, her er en brukstilfelle for Docker Compose.
Anta at du vil være vert for en WordPress-blogg på en enkelt server. Å sette opp eller vedlikeholde det er ikke noe du vil gjøre manuelt, så det du ville gjort i stedet er å installere Docker og Docker-komponere på din VPS, lage en enkel YAML-fil som definerer alle de forskjellige aspektene av WordPress-stakken din, som nedenfor, :
Merk: Hvis du bruker det nedenfor for å distribuere et WordPress -nettsted, må du endre alle passordene til noe sikkert. Enda bedre, bruk Docker Secrets til å lagre sensitive data som passord, i stedet for å ha dem i en ren tekstfil.
versjon:'3'tjenester:
db:
bilde: mysql:5.7
bind:
- db_data:/hvor/lib/mysql
start på nytt: alltid
miljø:
MYSQL_ROOT_PASSWORD: noeordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
kommer an på:
- db
image: wordpress: siste
porter:
-'8000: 80'
start på nytt: alltid
miljø:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpressPassword
WORDPRESS_DB_NAME: wordpress
bind:
db_data:{}
Når filen er opprettet og både Docker og Docker-compose er installert, er alt du trenger å gjøre å kjøre:
$docker-komponer opp-dOg nettstedet ditt vil være i gang. Hvis det er en oppdatering, kjør du:
$docker-komponer nedKast deretter de gamle Docker -bildene og kjør kommandoen docker -compose up -d, og nye bilder blir automatisk trukket inn. Siden du har de vedvarende dataene lagret i et Docker -volum, går ikke nettstedets innhold tapt.
Når skal du bruke Docker Swarm
Mens Docker-compose er mer et automatiseringsverktøy, er Docker Swarm ment for mer krevende applikasjoner. Nettapper med hundrevis eller tusenvis av brukere eller arbeidsmengde som må skaleres parallelt. Bedrifter med stor brukerbase og strenge SLA -krav vil bruke et distribuert system som Docker Swarm. Hvis appen din kjører på tvers av flere servere og flere datasentre, reduseres sjansene for nedetid på grunn av en berørt DC- eller nettverkskobling betydelig.
Når det er sagt, nøler jeg med å anbefale Docker Swarm for produksjonsbrukstilfeller fordi konkurrerende teknologier som Kubernetes uten tvil er mer passende for denne oppgaven. Kubernetes støttes innfødt på tvers av mange skyleverandører, og det fungerer ganske bra med Docker Containers, slik at du ikke engang trenger å bygge om appen din for å dra nytte av Kubernetes.
Konklusjon
Jeg håper at denne vandringen på Docker og dens satellittprosjekter var informativ, og at du er mer forberedt på docker -økosystemet.