Docker Compose: fra udvikling til produktion

Oversættelse af transskriptionen af ​​podcasten udarbejdet i forventning om kursets start "Linux-administrator"

Docker Compose er et fantastisk værktøj til at skabe desktop
miljø for den stak, der bruges i din applikation. Det giver dig mulighed for at definere
hver komponent i din applikation, efter en klar og enkel syntaks i YAML-
filer.

Med fremkomsten af docker compose v3 disse YAML-filer kan bruges direkte i produktionsmiljøet, når der arbejdes med
klynge Docker sværm.

Men betyder det, at du kan bruge den samme docker-compose-fil i
udviklingsproces og produktionsmiljø? Eller brug den samme fil til
iscenesættelse? Nå, generelt, ja, men for sådan funktionalitet har vi brug for følgende:

• Variabel interpolation: brug af miljøvariabler for nogle
  værdier, der ændrer sig i hvert miljø.
• Konfigurationstilsidesættelse: evnen til at definere et sekund (eller en hvilken som helst
  en anden opfølgning) docker-compose fil, der vil ændre noget vedr
  den første, og docker compose sørger for at flette begge filer.

Forskelle mellem udviklings- og produktionsfiler

Under udviklingen vil du højst sandsynligt gerne tjekke for kodeændringer i
realtidstilstand. For at gøre dette er volumen med kildekoden normalt monteret i
en container, der indeholder runtime for din applikation. Men for et produktionsmiljø
denne måde er ikke egnet.

I produktionen har du en multi-node klynge, og volumen er lokal
i forhold til den vært, din container (eller tjeneste) kører på, så det gør du ikke
du kan montere kildekoden uden komplekse operationer, som omfatter
kodesynkronisering, signaler mv.

I stedet vil vi normalt lave et billede med en bestemt version af din kode.
Det er sædvanligt at markere det med det passende tag (du kan bruge semantik
versionering eller et andet system efter eget valg).

Konfigurationstilsidesættelse

I betragtning af forskellene og at dine afhængigheder kan variere i scenarier
udvikling og produktion, er det klart, at vi får brug for forskellige konfigurationsfiler.

Docker compose understøtter fletning af forskellige skrivefiler til
få den endelige konfiguration. Hvordan det virker kan ses i et eksempel:

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Som sagt understøtter docker compose fletning af flere compose-
filer, giver dette dig mulighed for at tilsidesætte forskellige muligheder i den anden fil. For eksempel:

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Denne syntaks er ikke særlig praktisk i udviklingsprocessen, når kommandoen
skal gøres flere gange.

Heldigvis leder docker compose automatisk efter en speciel fil med navnet
docker-compose.override.yml at tilsidesætte værdier havnearbeider-compose.yml. hvis
omdøb den anden fil, du vil få det samme resultat, kun ved at bruge den originale kommando:

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Okay, det er nemmere at huske.

Variabel interpolation

Understøttelse af konfigurationsfiler interpolation
variabler og standardværdier. Det vil sige, du kan gøre følgende:

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

Og hvis du gør det docker-compose build (eller push) uden miljøvariabel
$MY_SERVICE_VERSION, vil værdien blive brugt senestemen hvis du indstiller
værdien af ​​miljøvariablen før bygningen, vil den blive brugt, når du bygger eller skubber
at registrere private.registry.mine.

Mine principper

Tilgange, der er praktiske for mig, kan være nyttige for dig. Jeg følger dette
simple regler:

• Alle mine stakke til produktion, udvikling (eller andre miljøer) er defineret igennem
  docker-compose filer.
• De nødvendige konfigurationsfiler til at dække alle mine miljøer, max.
  undgå dobbeltarbejde.
• Jeg har brug for en simpel kommando for at fungere i alle miljøer.
• Hovedkonfigurationen er defineret i filen havnearbeider-compose.yml.
• Miljøvariabler bruges til at definere billedtags eller andet
  variabler, der kan ændre sig fra miljø til miljø (iscenesættelse, integration,
  produktion).
• Værdierne af variabler til produktion bruges som værdier af
  som standard minimerer dette risiciene, hvis du kører stakken i produktion uden
  sæt miljøvariabel.
• For at starte en tjeneste i et produktionsmiljø skal du bruge kommandoen docker stack deploy - compose-fil docker-compose.yml - with-registry-auth mit-stak-navn.
• Arbejdsmiljøet startes med kommandoen docker-compose -d.

Lad os se på et simpelt eksempel.

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

И

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

jeg kan bruge docker-compose (docker-compose up)at køre stakken på
udviklingstilstand med kildekode monteret i /project/src.

Jeg kan bruge de samme filer i produktionen! Og jeg kunne bruge præcis
samme fil havnearbeider-compose.yml til iscenesættelse. For at udvide dette til
produktion, skal jeg bare bygge og sende billedet med et foruddefineret tag
på CI-stadiet:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

I produktionen kan dette køres med følgende kommandoer:

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Og hvis du vil gøre det samme på scenen, skal du bare definere
nødvendige miljøvariabler for at arbejde i iscenesættelsesmiljøet:

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Som et resultat brugte vi to forskellige docker-compose-filer, som uden
duplikerede konfigurationer kan bruges til alle dine miljøer!

Lær mere om kurset "Linux-administrator"

Kilde: www.habr.com