Docker -containere er ment å bli behandlet som storfe, ikke kjæledyr. Dette betyr at deres opprettelse, konfigurasjon, styring og avhending bør automatiseres fra topp til bunn. Vi oppretter og konfigurerer ikke individuelle containere. Snarere skala vi horisontalt ved å snurre opp flere containere.

Horisontal skalering refererer til å snurre opp flere datamaskiner, jeg.E, VM -er, containere eller fysiske servere for å imøtekomme bølge i krav. Dette i motsetning til skalering 'vertikalt ', som vanligvis refererer til å erstatte en tregere maskin (med mindre minne og lagring) med en raskere 'større ' en.

Med containerne har skalering av begge slagene blitt veldig dynamisk. Du kan angi kvoter for spesifikke applikasjoner som angir mengden CPU, minne eller lagring som de kan ha tilgang til. Denne kvoten kan endres for å skalere opp eller ned etter behov. Tilsvarende kan du skalere horisontalt ved å spinne opp flere containere som vil imøtekomme en uptick i etterspørselen, og senere skalere ned ved å ødelegge overskuddet av containere du opprettet. Hvis du bruker Cloud Hosted Services som fakturerer deg etter timen (eller minutt), kan dette betydelig redusere hosting -regningene dine.

I denne artikkelen vil vi bare fokusere på horisontal skalering som ikke er så dynamisk som beskrivelsen ovenfor, men det er et godt utgangspunkt for noen som lærer det grunnleggende. Så la oss starte.

Skala via Docker-Compose CLI

Når du starter applikasjonsstabelen ved å sende komponeringsfilen din til CLI Docker-Compose Du kan bruke flagget -skala For å spesifisere skalerbarheten til en bestemt tjeneste som er spesifisert der inne.

For eksempel for min Docker-Compose-fil:

versjon: "3"
tjenester:
Web:
Bilde: "Nginx: siste"
Porter:
- "80-85: 80"
$ Docker -Compose Up -D -Skala nett = 5

Her kalles tjenesten web i YML -erklæringen, men det kan være hvilken som helst individuell komponent i distribusjonen din, i.E, web front-end, database, overvåking av demon osv. Den generelle syntaksen krever at du velger et av elementene under Services-delen på toppnivå. Avhengig av tjenesten din, kan det hende du må endre andre deler av skriptet. For eksempel er det gitt 80-85-utvalget av vertsporter for å imøtekomme 5 forekomster av Nginx-containere som alle lytter på sin interne port 80, men verten lytter på porter fra 80-85 og omdirigerer trafikk fra hver unike port til en av Nginx forekomster.

For å se hvilken beholder som får hvilket portnummer du kan bruke kommandoen:

$ docker ps -a
Container ID Image Command opprettet
d02e19d1b688 nginx: siste "nginx -g 'daemon of ..." for omtrent et minutt siden
34B4DD74352D Nginx: Siste "Nginx -g 'Daemon of ..." For omtrent et minutt siden
98549c0f3dcf nginx: Siste "nginx -g 'daemon of ..." for omtrent et minutt siden
Statusporter navn
Opp omtrent et minutt 0.0.0.0: 83-> 80/TCP Project_Web_1
Opp omtrent et minutt 0.0.0.0: 82-> 80/TCP Project_Web_3
Opp omtrent et minutt 0.0.0.0: 81-> 80/TCP Project_Web_2
..

For å skalere mer enn en tjeneste, må du nevne dem individuelt med skalaflagget og tallparameteren for å sikre at ønsket antall forekomster opprettes. Hvis du for eksempel har to forskjellige tjenester, må du gjøre noe slikt:

$ Docker -Compose Up -D -Skala Service1 = 5 -Skala Service2 = 6

Dette er den eneste måten å gjøre dette på, siden du ikke kan kjøre Docker -Compose Up -Sal -kommandoen to ganger en for hver tjeneste. Å gjøre det ville skalere den forrige tjenesten tilbake til en enkelt beholder.

Senere får vi se hvordan du kan angi skalaverdi for et gitt bilde, fra Docker-Compose.yml. I tilfelle det er et skala -alternativ satt i filen, vil CLI -ekvivalenten for skala -alternativet overstyre verdien i filen.

Skala

Dette alternativet ble lagt til i Docker-Compose File versjon 2.2 og kan teknisk brukes, selv om jeg ikke anbefaler å bruke den. Det er nevnt her for fullstendighets skyld.

For min docker-komponering.YML -fil:

versjon: "2.2 "
tjenester:
Web:
Bilde: "Nginx: siste"
Porter:
- "80-85: 80"
Skala: 3

Dette er et perfekt gyldig alternativ. Selv om det fungerer for Docker Engine 1.1. 3.0 og over.

Bruk kopier i produksjonen

I stedet for å bruke skala -kommandoen eller den utdaterte skalaverdien i komponeringsfilen din, bør du bruke replika -variabelen. Dette er et enkelt heltall assosiert med en gitt tjeneste og fungerer stort sett på samme måte som skalavariabelen gjør. Den avgjørende forskjellen er at Docker Swarm er eksplisitt ment for distribuert system.

Dette betyr at du kan ha applikasjonen din distribuert over flere noder VMer eller fysiske servere som kjører over flere forskjellige regioner og flere forskjellige datasentre. Dette lar deg virkelig dra nytte av mangfoldet av serviceforekomster som kjører.

Den lar deg skalere applikasjonen din opp og ned ved å endre en enkelt variabel, dessuten gir den større motstandskraft mot driftsstans. Hvis et datasenter er nede eller en nettverkskobling mislykkes, kan brukerne fortsatt få tilgang til applikasjonen fordi en annen forekomst kjører et annet sted. Hvis du sprer applikasjonsdistribusjonen din over flere geografiske regioner, e.G, EU, USA og Asia Pacific Det vil redusere latensen for brukerne som prøver å få tilgang til søknaden din fra nevnte region.

Konklusjon

Mens Docker-Compose skala er nyttig for små miljøer som en enkelt Docker-vert som kjører i produksjon. Det er også veldig nyttig for utviklere som kjører Docker på arbeidsstasjonen. Det kan hjelpe dem å teste hvordan appen skal skaleres i produksjonen, og under forskjellige omstendigheter. Bruke skala -kommando omgår bryet med å sette opp en ny Docker -sverm.

Hvis du har en Docker Swarm -forekomst i gang, kan du gjerne leke med kopier. Her er dokumentasjonen om den saken,