🥇Docker Compose: fra utvikling til produksjon

Oversettelse av podkasttranskripsjonen er forberedt i forkant av kursstart «Linux-administrator»

Docker Compose er et fantastisk verktøy for å opprette et arbeidsmiljø
for stakken som brukes i applikasjonen din. Det lar deg definere
hver komponent av applikasjonen din, ved å følge en klar og enkel syntaks i YAML-
filer.

Med lanseringen av docker compose v3 kan disse YAML-filene brukes direkte i produksjonsmiljøet, når man jobber med
klynger Docker Swarm.

Men betyr det at du kan bruke den samme docker-compose-filen i
utviklingsprosessen og i produksjonsmiljøet? Eller bruke den samme filen til
staging? Generelt sett — ja, men for denne funksjonaliteten trenger vi det følgende:

Variabel interpolering: bruk av miljøvariabler for enkelte
verdier som endres i hvert miljø.
Overriding av konfigurasjoner: muligheten til å definere en andre (eller hvilken som helst
annen påfølgende) docker-compose-fil, som endrer noe i forhold til
den første, og docker compose vil ta seg av sammenslåing av begge filene.

Forskjeller mellom filer for utvikling og produksjon

Under utvikling vil du sannsynligvis ønske å sjekke endringer i koden i
sanntid. For dette monteres vanligvis volumet med kildekoden i
containeren der kjøringen for applikasjonen din befinner seg. Men for produksjonsmiljøet
er ikke denne metoden egnet.

I produksjon har du en klynge med mange noder, og volumet er lokalt i
forhold til noden som containeren (eller tjenesten) går på, så du kan ikke
montere kildekoden uten kompliserte operasjoner som involverer
kode-synkronisering, signaler osv.

I stedet ønsker vi vanligvis å opprette et bilde med en spesifikk versjon av koden din.
Det er vanlig å merke det med en passende tag (du kan bruke semantisk
versjonering eller et annet system etter eget valg).

Overriding av konfigurasjoner

Gitt forskjellene, og at avhengighetene dine kan variere i scenarier
for utvikling og produksjon, er det klart at vi trenger forskjellige konfigurasjonsfiler.

Docker compose støtter sammenslåing av forskjellige compose-filer for
å oppnå en endelig konfigurasjon. Hvordan dette fungerer kan sees 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 ble sagt, støtter docker compose sammenslåing av flere compose-filer,
dette gjør det mulig å overstyre ulike parametre i den andre filen. 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 syntaksen er ikke veldig praktisk under utviklingsprosessen, når man må
kjøre kommandoen mange ganger.

Heldigvis leter docker compose automatisk etter en spesialfil med navnet
docker-compose.override.yml for å overstyre verdier. docker-compose.yml. Hvis
man gir det andre filnavnet nytt navn, får man samme resultat med den originale kommandoen:

$ 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

Bra, så er det lettere å huske.

Variabelinterpolasjon

Konfigurasjonsfilene støtter interpolasjon
variabler og standardverdier. Så du kan gjøre følgende:

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

Og hvis du kjører docker-compose build (eller push) uten miljøvariabelen
$MY_SERVICE_VERSION, vil standardverdien latest, men hvis du setter
verdien av miljøvariabelen før byggingen, vil den bli brukt under bygging eller pushing
til registeret private.registry.mine.

Mine prinsipper

Metodene som er behagelige for meg, kan også være nyttige for deg. Jeg følger disse
enkelte reglene:

Alle mine stakker for produksjon, utvikling (eller andre miljøer) defineres gjennom
docker-compose-filer.
Konfigurasjonsfilene som er nødvendige for å dekke alle mine miljøer, unngår så mye som mulig
duplisering.
Jeg trenger én enkel kommando for å jobbe i hvert miljø.
Hovedkonfigurasjonen defineres i filen docker-compose.yml.
Miljøvariabler brukes til å definere bildeetiketter eller andre
variabler som kan variere fra miljø til miljø (staging, integrasjon,
produksjon).
Verdiene for produksjon brukes som standardverdier, noe som minimerer risikoene ved å kjøre stakken i produksjon uten
den angitte miljøvariabelen.
For å starte tjenesten i produksjonsmiljøet brukes kommandoen
docker stack deploy — compose-file docker-compose.yml —with-registry-auth my-stack-name Arbeidsmiljøet startes ved hjelp av kommandoen.
La oss se på et enkelt eksempel. docker-compose up -d.

Jeg kan bruke

# 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 å starte stakken iutviklingsmodus med kildekoden montert i
Jeg kan bruke disse samme filene på produksjon! Og jeg kunne brukt nøyaktig /project/src.

den samme filen
for staging. For å deployere dette til docker-compose.yml produksjon, trenger jeg bare å bygge og sende bildet med en forhåndsdefinert etikett
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 produksjon 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 gjøre det samme på staging, er det bare å definere

de nødvendige miljøvariablene for å arbeide 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

Som et resultat har vi brukt to forskjellige docker-compose-filer, som uten

duplisering av konfigurasjoner kan brukes for hvilket som helst av dine miljøer!
Teori og praksis for bruk av ClickHouse i virkelige applikasjoner. Alexander Zaitsev (2018)

Lær mer om kurset «Linux-administrator»

Kilde: habr.com