Nettapper og mikroservices

Med containerens 'Revolution' har appene vokst mye mer enn å bare være en database og en frontend. Programmer er delt inn i forskjellige mikroservices, og de kommuniserer typisk med hverandre via et REST API (typisk JSON formatert nyttelast over HTTP). Docker -containere er ideelle for denne typen arkitektur. Du kan pakke frontend 'Microservice' til en Docker -beholder, databasen går inn i en annen, og så videre og så videre. Hver tjenestespråk med en annen over et forhåndsdefinert REST API i stedet for å være en monolit skrevet som et enkelt programvare.

Hvis du trenger å implementere en ny funksjonalitet eller en funksjon, e.G, en analysemotor, kan du ganske enkelt skrive en ny mikroservice for det, og den vil konsumere data via REST API utsatt av de forskjellige mikroservicene i webappen din. Og etter hvert som funksjonaliteten din vokser over tid, vil denne listen over mikroservices også vokse sammen med den.

Du vil ikke distribuere hver enkelt beholder, konfigurere den og konfigurere alt annet for å snakke med den også. Som vil bli kjedelig med til og med tre containere. Docker-Compose lar deg automatisere distribusjonen av flere containere.

Docker-Compose er et av de enkleste verktøyene som hjelper deg å forvandle den abstrakte ideen om mikroservices til et funksjonelt sett med Docker-beholderen.

Distribuerte systemer

Nå som vi har delt opp webappen i flere containere, er det lite fornuftig å holde dem alle på en enkelt server (verre fremdeles 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 applikasjonen din på flere servere. Hvis mikroservice er skrevet på en måte som den kan skalere 'horisontalt', kan du bruke Docker Swarm til å distribuere webappen din på flere datasentre og flere regioner. Dette gir motstandskraft mot svikt i ett eller flere datasentre eller nettverkslenker. Dette gjøres vanligvis ved hjelp av en underkommando i Docker, det vil si Docker Stack.

De Docker Stack Subcommand oppfører seg mye mer som Docker-Compose-kommandoen, og det kan føre til misoppfatninger til noen som bruker en av teknologiene.

Kilde til forvirring

Når det gjelder bruk og arbeidsflyt, fungerer begge teknologiene veldig lik hverandre, og dette forårsaker forvirring. Måten du distribuerer appen din ved å bruke enten Docker Swarm eller Docker-Compose på er veldig lik. Du definerer applikasjonen din i en YAML -fil, denne filen vil inneholde bildetavnet, konfigurasjonen for hvert bilde og også skalaen (antall kopier) som hver mikroservice vil være nødvendig for å oppfylle i distribusjonen.

Forskjellen ligger stort sett i backend, der Docker-Compose distribuerer container på en enkelt Docker-vert, Docker Swarm distribuerer den over flere noder. Løst sett kan det fortsatt gjøre det meste som Docker-Compose kan, men det skalerer det på tvers av flere Docker-verter.

Likheter

Både Docker Swarm og Docker-Compose har følgende likheter:

1. De tar begge YAML -formaterte definisjoner av applikasjonsstabelen din.
2. De er begge ment å håndtere applikasjoner med flere container (mikroservices)
3. De har begge en skalaparameter som lar deg kjøre flere containere med det samme bildet slik at mikroservice skal skalere horisontalt.
4. De blir begge vedlikeholdt av samme selskap, jeg.E, Docker, Inc.

Forskjeller

De få forskjellene mellom Docker Swarm og Docker-Compose:

1. Docker Swarm brukes til å skalere webappen din på en eller flere servere. Hvor som Docker-Compose ganske enkelt vil kjøre webappen din på en enkelt Docker-vert.
2. Skalering av webappen din Docker Swarm tilbyr alvorlig høy tilgjengelighet og feiltoleranse. Å skalere webappen din ved hjelp av Docker-komponering på en enkelt vert er bare nyttig for testing og utvikling.
3. 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æren som du ringer via terminalen din. Docker-Compose er frittstående binær i seg selv.

En brukssak for Docker-komponering

Som beskrevet ovenfor er de begge helt forskjellige verktøy, og hver løser et helt annet problem, så det er ikke som en er et alternativ for den andre. For å gi nye komere en følelse av hva jeg snakker om, er her en brukssak for Docker Compose.

Anta at du vil selv host en WordPress-blogg på en enkelt server. Sette den opp eller vedlikeholde det ikke noe du vil gjøre, manuelt, så det du vil gjøre i stedet er å installere Docker og Docker-komponering på VP-ene dine, oppretter en enkel YAML-fil som definerer alle de forskjellige aspektene i WordPress-stack, som nedenfor, :

Merk: Hvis du bruker nedenfor for å distribuere et WordPress -nettsted, kan du endre alle passordene til noe sikkert. Bedre ennå, bruk Docker -hemmeligheter for å lagre sensitive data som passord, i stedet for å ha dem i en vanlig tekstfil.

Versjon: '3'
tjenester:
DB:
Bilde: MySQL: 5.7
Volum:
- db_data:/var/lib/mysql
Start på nytt: Alltid
miljø:
Mysql_root_password: SomewordPress
Mysql_database: WordPress
Mysql_user: WordPress
Mysql_password: wordpress
WordPress:
kommer an på:
- db
Bilde: 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
Volum:
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 -compose up -d

Og nettstedet ditt vil være i gang. Hvis det er en oppdatering, så kjør:

$ Docker-Compose Down

Kast deretter de gamle Docker -bildene og kjør Docker -Compose Up -D -kommandoen, og nye bilder blir automatisk trukket inn. Siden du har de vedvarende dataene lagret i et Docker -volum, vil ikke nettstedets innhold gå 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 parallelly. Bedrifter med store brukerbase og strenge SLA -krav vil ønske å bruke et distribuert system som Docker Swarm. Hvis appen din kjører over flere servere og flere datasentre, blir sjansene for driftsstans på grunn av en berørt DC eller nettverkslenke betydelig redusert.

Når det er sagt, nøler jeg med å anbefale Docker Swarm for tilfeller av produksjonsbruk 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 -containere, slik at du ikke en gang trenger å gjenoppbygge appen din for å dra nytte av Kubernetes.

Konklusjon

Jeg håper at dette ruslet på Docker og dens satellittprosjekter var informativt og at du er mer forberedt på Docker -økosystemet.