🥇Docker Compose: fra udvikling til produktion

Oversættelsen af podcasttransskriptionen er forberedt i takt med starten af kurset «Linux Administrator»

Docker Compose er et fantastisk værktøj til at oprette et arbejdsmiljø
for stakken, der bruges i din applikation. Det giver dig mulighed for at definere
hver komponent i din applikation ved at følge en klar og enkel syntaks i YAML-
filer.

Med fremkomsten af docker compose v3 kan disse YAML-filer anvendes direkte i produktionsmiljøet, når man arbejder med
klynger Docker Swarm.

Men betyder det, at du kan bruge den samme docker-compose-fil i
udviklingsprocessen og i produktionsmiljøet? Eller bruge den samme fil til
staging? Så generelt — ja, men for at opnå denne funktionalitet har vi brug for følgende:

Interpolering af variabler: brug af miljøvariabler til nogle
værdier, der ændrer sig i hvert miljø.
Overskrivning af konfigurationer: muligheden for at definere en anden (eller enhver
anden efterfølgende) docker-compose-fil, som vil ændre noget i forhold til
den første, og docker compose vil tage sig af sammenlægningen af begge filer.

Forskelle mellem filer for udvikling og produktion

Under udviklingen vil du sandsynligvis gerne se ændringer i koden i
real-time. Til dette monteres normalt volumenet med kildekoden i
den container, hvor din applikations runtime befinder sig. Men til produktionsmiljøet
er denne metode ikke passende.

I produktionen har du en klynge med mange noder, og volumenet er lokalt i forhold til
den node, hvor din container (eller tjeneste) kører, så du kan ikke
montere kildekoden uden komplicerede operationer, der involverer
kode-synkronisering, signaler osv.

I stedet vil vi typisk gerne oprette et billede med en specifik version af din kode.
Det er almindeligt at mærke det med en passende tag (man kan bruge semantisk
versionering eller et andet system efter eget valg).

Overskrivning af konfigurationer

I betragtning af forskellene og at dine afhængigheder kan variere mellem
udviklings- og produktionsscenarier, er det klart, at vi har brug for forskellige

konfigurationsfiler.
Docker compose understøtter sammenlægning af forskellige compose-filer for at opnå det endelige konfiguration. Hvordan dette fungerer, kan ses i eksemplet:

$ 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  | 
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 det blev nævnt, understøtter docker compose sammenfletning af flere compose-filer,
hvilket gør det muligt at overskrive forskellige parametre 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  | 
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 under udviklingen, når kommandoen
skal udføres mange gange.

Heldigvis leder docker compose automatisk efter en speciel fil med navnet
docker-compose.override.yml til overskrivning af værdier docker-compose.yml. Hvis
du omdøber den anden fil, får du det samme resultat, bare ved hjælp af den oprindelige 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  | 
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

Det er lettere at huske på denne måde.

Variabelinterpolation

Konfigurationsfiler understøtter interpolation
af variabler og standardværdier. Det betyder, at 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 kører docker-compose build (eller push) uden miljøvariablen
$MY_SERVICE_VERSION, vil standardværdien blive brugt, latest, men hvis du sætter værdien af miljøvariablen inden bygningen, vil den blive brugt under bygningen eller pushen
til registret
private.registry.mine Mine principper.

Mine principper

Metoder, der er bekvemme for mig, kan også være nyttige for dig. Jeg følger disse
enkle regler:

Alle mine stakke til produktion, udvikling (eller andre miljøer) defineres gennem
docker-compose-filer.
Konfigurationsfilerne, der er nødvendige for at dække alle mine miljøer, undgår i videst muligt omfang
duplikering.
Jeg har brug for én enkel kommando til at arbejde i hvert miljø.
Den primære konfiguration defineres i filen docker-compose.yml.
Miljøvariabler bruges til at definere billedtags eller andre
variabler, der kan ændre sig fra miljø til miljø (staging, integration,
produktion).
Værdierne for variablerne til produktion bruges som standardværdier, hvilket minimerer risici i tilfælde af, at stakken startes i produktion uden
en defineret miljøvariabel.
For at starte tjenesten i et produktionsmiljø bruges kommandoen
docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name Arbejdsmiljøet startes med kommandoen.
Lad os se på et simpelt eksempel. docker-compose up -d.

Jeg kan bruge

# 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
...

docker-compose (docker-compose up) , for at starte stakken iudviklingsmodus med kildekoden monteret i
Jeg kan bruge de samme filer på produktion! Og jeg kunne bruge præcis /project/src.

samme fil
til staging. For at deployere dette til docker-compose.yml produktion skal jeg bare bygge og sende billedet med den foruddefinerede tag
i CI-fasen:
export MY_SERVICE_VERSION=1.2.3 docker-compose -f docker-compose.yml build docker-compose -f docker-compose.yml push

I produktion kan dette startes 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å staging, skal du blot definere

de nødvendige miljøvariabler for at arbejde i staging-miljø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

I alt har vi anvendt to forskellige docker-compose-filer, der uden

duplikering af konfigurationer kan bruges til ethvert af dine miljøer!
Pi-KVM — et åbent IP-KVM-projekt på Raspberry Pi

Lær mere om kurset «Linux Administrator»

Kilde: habr.com