Med behållaren 'revolution' har appar vuxit mycket mer än att bara vara en databas och en frontend. Program delas upp i olika mikrotjänster och de kommunicerar vanligtvis med varandra via ett REST API (vanligtvis JSON -formaterad nyttolast via HTTP). Dockerbehållare är idealiska för denna typ av arkitektur. Du kan packa din frontend -mikroservice i en Docker -behållare, databasen går in i en annan osv. Och så vidare. Varje tjänst pratar med en annan över ett fördefinierat REST API istället för att vara en monolit som är skriven som en enda mjukvara.
Om du behöver implementera en ny funktionalitet eller en funktion, t.ex. en analysmotor, kan du helt enkelt skriva en ny mikrotjänst för det och det skulle konsumera data via REST API som exponeras av de olika mikrotjänsterna i din webbapp. Och i takt med att din funktionalitet växer över tiden kommer denna lista med mikrotjänster att växa tillsammans med den också.
Du vill inte distribuera varje enskild behållare, konfigurera den och sedan konfigurera allt annat för att prata med den också. Det blir tråkigt med till och med tre behållare. Med Docker-Compose kan du automatisera distributionen av flera behållare.
Docker-Compose är ett av de enklaste verktygen som hjälper dig att omvandla den abstrakta idén om mikrotjänster till en funktionell uppsättning Docker-behållare.
Distribuerade system
Nu när vi har delat upp webbappen i flera behållare är det meningslöst att ha dem alla på en enda server (ännu värre på en enda virtuell maskin!) Det är där tjänster som Docker Swarm och Kubernetes spelar in.
Med Docker Swarm kan du köra flera kopior av din applikation på flera servrar. Om din mikrotjänst är skriven på ett sätt som kan skala 'horisontellt' kan du använda Docker Swarm för att distribuera din webbapp över flera datacenter och flera regioner. Detta ger motståndskraft mot att ett eller flera datacenter eller nätverkslänkar misslyckas. Detta görs vanligtvis med ett underkommando i Docker, det vill säga Docker Stack.
De Docker Stack underkommando beter sig mycket mer som Docker-Compose-kommandot och det kan leda till missuppfattningar för någon som använder någon av teknikerna.
Källa till förvirring
När det gäller användning och arbetsflöde fungerar båda teknikerna mycket lika varandra, och detta orsakar förvirring. Sättet du distribuerar din app med antingen Docker Swarm eller Docker-Compose är väldigt lika. Du definierar din applikation i en YAML -fil, den här filen innehåller bildnamnet, konfigurationen för varje bild och även skalan (antal repliker) som varje mikrotjänst måste uppfylla vid distributionen.
Skillnaden ligger mestadels i backend, där docker-compose distribuerar behållare på en enda Docker-värd, Docker Swarm distribuerar den över flera noder. Löst sett kan den fortfarande göra de flesta saker som docker-komponera kan men den skalar den över flera Docker-värdar.
Likheter
Både Docker Swarm och Docker-Compose har följande likheter:
- De tar båda YAML -formaterade definitioner av din applikationsbunt.
- De är båda avsedda att hantera applikationer med flera behållare (mikrotjänster)
- De har båda en skalparameter som låter dig köra flera behållare med samma bild så att din mikrotjänst kan skala horisontellt.
- De underhålls båda av samma företag, dvs Docker, Inc.
Skillnader
De få skillnaderna mellan Docker Swarm och Docker-Compose:
- Docker Swarm används för att skala din webbapp över en eller flera servrar. Var som Docker-compose helt enkelt kommer att köra din webbapp på en enda Docker-värd.
- Skalning av din webbapp Docker Swarm erbjuder allvarlig hög tillgänglighet och feltolerans. Att skala din webbapp med Docker-Compose på en enda värd är bara användbart för testning och utveckling.
- Docker Swarm och relaterade underkommandon som Docker Swarm och Docker Stack är inbyggda i själva Docker CLI. De är alla en del av Docker -binären som du ringer via din terminal. Docker-Compose är fristående binär i sig.
Ett användningsfall för Docker-Compose
Som beskrivits ovan är de båda helt olika verktyg och var och en löser ett helt annat problem så det är inte som att det ena är ett alternativ för det andra. För att ge nya användare en känsla av vad jag pratar om, här är ett användningsfall för Docker Compose.
Antag att du själv vill vara värd för en WordPress-blogg på en enda server. Att konfigurera eller behålla det är inget du vill göra manuellt, så det du istället skulle göra är att installera Docker och Docker-komponera på din VPS, skapa en enkel YAML-fil som definierar alla olika aspekter av din WordPress-stack, som nedan, :
Obs! Om du använder nedanstående för att distribuera en WordPress -webbplats, vänligen ändra alla lösenord till något säkert. Ännu bättre, använd Docker Secrets för att lagra känslig data som lösenord, istället för att ha den i en vanlig textfil.
version:'3'tjänster:
db:
bild: mysql:5.7
volymer:
- db_data:/var/lib/mysql
starta om: alltid
miljö:
MYSQL_ROOT_PASSWORD: någonstans
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
beror på:
- db
image: wordpress: senaste
hamnar:
-'8000: 80'
starta om: alltid
miljö:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpressPassword
WORDPRESS_DB_NAME: wordpress
volymer:
db_data:{}
När filen har skapats och både Docker och Docker-compose är installerade är allt du behöver göra att köra:
$docker-komponera upp-dOch din webbplats kommer att vara igång. Om det finns en uppdatering, kör sedan:
$docker-komponera nerKasta sedan bort de gamla Docker -bilderna och kör kommandot docker -compose up -d och nya bilder kommer automatiskt att dras in. Eftersom du har den ihållande data lagrad i en Docker -volym går inte din webbplats innehåll förlorad.
När ska man använda Docker Swarm
Medan Docker-compose är mer ett automatiseringsverktyg, är Docker Swarm avsett för mer krävande applikationer. Webbappar med hundratals eller tusentals användare eller arbetsbelastning som måste skalas parallellt. Företag med stor användarbas och strikta SLA -krav skulle vilja använda ett distribuerat system som Docker Swarm. Om din app körs över flera servrar och flera datacenter minskar risken för stillestånd på grund av en påverkad DC- eller nätverkslänk avsevärt.
Med det sagt tvekar jag att rekommendera Docker Swarm för produktionsanvändningsfall eftersom konkurrerande teknik som Kubernetes utan tvekan passar bättre för denna uppgift. Kubernetes stöds inbyggt i många molnleverantörer och det fungerar ganska bra med Docker Containers så att du inte ens behöver bygga om din app för att dra nytta av Kubernetes.
Slutsats
Jag hoppas att denna vandring på Docker och dess satellitprojekt var informativ och att du är mer förberedd på dockarens ekosystem.