Med containeren 'revolution' er apps vokset meget mere end bare at være en database og en frontend. Applikationer er opdelt i forskellige mikrotjenester, og de kommunikerer typisk med hinanden via en REST API (typisk JSON -formateret nyttelast over HTTP). Docker -containere er ideelle til denne slags arkitektur. Du kan pakke din frontend 'mikroservice' i en Docker -container, databasen går ind i en anden osv. Og så videre. Hver service taler med en anden over et foruddefineret REST API i stedet for at være en monolit skrevet som et enkelt stykke software.
Hvis du har brug for at implementere en ny funktionalitet eller en funktion, f.eks. En analysemotor, kan du simpelthen skrive en ny mikrotjeneste til det, og det ville forbruge data via REST API, der blev afsløret af de forskellige mikrotjenester i din webapp. Og efterhånden som din funktionalitet vokser med tiden, vokser denne liste over mikroservices også med den.
Du vil ikke implementere hver enkelt container, konfigurere den og derefter konfigurere alt andet til også at tale med den. Det bliver kedeligt med selv tre containere. Docker-Compose lader dig automatisere implementeringen af flere containere.
Docker-Compose er et af de enkleste værktøjer, der hjælper dig med at omdanne den abstrakte idé om mikroservices til et funktionelt sæt Docker-containere.
Distribuerede systemer
Nu hvor vi har delt webapp'en op i flere containere, giver det ingen mening at beholde dem alle på en enkelt server (endnu værre på en enkelt virtuel maskine!), Det er her tjenester som Docker Swarm og Kubernetes spiller ind.
Docker Swarm giver dig mulighed for at køre flere kopier af din applikation på tværs af flere servere. Hvis din mikroservice er skrevet på en måde, så den kan skaleres 'vandret', kan du bruge Docker Swarm til at implementere din webapp på tværs af flere datacentre og flere regioner. Dette giver modstandsdygtighed over for fejl i et eller flere datacentre eller netværksforbindelser. Dette gøres typisk ved hjælp af en underkommando i Docker, det vil sige Docker Stack.
Det Docker Stack underkommando opfører sig meget mere som Docker-Compose-kommandoen, og det kan føre til misforståelser for nogen, der bruger en af teknologierne.
Kilde til forvirring
Med hensyn til brug og arbejdsgang fungerer begge teknologier meget ens, og det skaber forvirring. Den måde, du implementerer din app på enten Docker Swarm eller Docker-Compose, ligner meget. Du definerer din applikation i en YAML -fil, denne fil vil indeholde billednavnet, konfigurationen for hvert billede og også skalaen (antal replikaer), som hver mikroservice skal opfylde ved implementering.
Forskellen ligger mest i backend, hvor docker-compose distribuerer container på en enkelt Docker-vært, Docker Swarm anvender den på tværs af flere noder. Løst sagt kan den stadig gøre de fleste ting, som docker-komponere kan, men den skalerer den på tværs af flere Docker-værter.
Ligheder
Både Docker Swarm og Docker-Compose har følgende ligheder:
- De tager begge YAML -formaterede definitioner af din applikationsstak.
- De er begge beregnet til at håndtere applikationer med flere containere (mikroservices)
- De har begge en skala -parameter, der giver dig mulighed for at køre flere beholdere af det samme billede, så din mikroservice kan skaleres vandret.
- De vedligeholdes begge af det samme firma, dvs. Docker, Inc.
Forskelle
De få forskelle mellem Docker Swarm og Docker-Compose:
- Docker Swarm bruges til at skalere din webapp på tværs af en eller flere servere. Hvor som Docker-compose simpelthen vil køre din webapp på en enkelt Docker-vært.
- Skalering af din webapp Docker Swarm tilbyder alvorlig høj tilgængelighed og fejltolerance. Skalering af din webapp ved hjælp af Docker-Compose på en enkelt vært er kun nyttig til test og udvikling.
- Docker Swarm og relaterede underkommandoer som Docker Swarm og Docker Stack er indbygget i selve Docker CLI. De er alle en del af Docker -binæret, som du kalder via din terminal. Docker-Compose er selvstændig binær i sig selv.
En brugssag til Docker-Compose
Som beskrevet ovenfor er de begge helt forskellige værktøjer, og hver løser et helt andet problem, så det er ikke sådan, at det ene er et alternativ til det andet. For at give nytilkomne en fornemmelse af, hvad jeg taler om, er der her en brugssag til Docker Compose.
Antag, at du selv vil være vært for en WordPress-blog på en enkelt server. Opsætning eller vedligeholdelse af det er ikke noget, du vil gøre manuelt, så hvad du i stedet ville gøre er at installere Docker og Docker-komponere på din VPS, oprette en simpel YAML-fil, der definerer alle de forskellige aspekter af din WordPress-stak, som nedenfor, :
Bemærk: Hvis du bruger nedenstående til at implementere et WordPress -websted, skal du ændre alle adgangskoder til noget sikkert. Endnu bedre, brug Docker Secrets til at gemme følsomme data som adgangskoder i stedet for at have dem i en almindelig tekstfil.
version:'3'tjenester:
db:
billede: mysql:5.7
bind:
- db_data:/hvor/lib/mysql
genstart: altid
miljø:
MYSQL_ROOT_PASSWORD: et eller andet tryk
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
afhænger af:
- db
billede: wordpress: nyeste
havne:
-'8000: 80'
genstart: altid
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 oprettet, og både Docker og Docker-compose er installeret, er alt du skal gøre at køre:
$docker-komponer op-dOg dit websted vil være i gang. Hvis der er en opdatering, skal du køre:
$docker-komponer nedSmid derefter de gamle Docker -billeder væk, og kør kommandoen docker -compose up -d, og nye billeder vil automatisk blive trukket ind. Da du har de vedvarende data gemt i en Docker Volume, går dit websteds indhold ikke tabt.
Hvornår skal man bruge Docker Swarm
Mens Docker-compose mere er et automatiseringsværktøj, er Docker Swarm beregnet til mere krævende applikationer. Webapps med hundredvis eller tusinder af brugere eller arbejdsbyrde, der skal skaleres parallelt. Virksomheder med stor brugerbase og strenge SLA -krav vil gerne bruge et distribueret system som Docker Swarm. Hvis din app kører på tværs af flere servere og flere datacentre, reduceres chancerne for nedetid på grund af et påvirket DC- eller netværkslink betydeligt.
Når det er sagt, tøver jeg med at anbefale Docker Swarm til produktionsanvendelser, fordi konkurrerende teknologier som Kubernetes uden tvivl er mere passende til denne opgave. Kubernetes understøttes indbygget på tværs af mange cloud -udbydere, og det fungerer ganske godt med Docker Containers, så du ikke engang behøver at genopbygge din app for at drage fordel af Kubernetes.
Konklusion
Jeg håber, at denne vandring på Docker og dens satellitprojekter var informativ, og at du er mere forberedt på docker -økosystemet.