Docker Compose: nga zhvillimi në prodhim

Përkthimi i transkriptit të podkastit është përgatitur para fillimit të kursit "Administrator Linux"

Docker Compose është një mjet fantastik për krijimin e një
mjedisi për stack-un që përdoret në aplikacionin tuaj. Ai ju lejon të definoni
secilin komponent të aplikacionit tuaj, duke ndjekur një sintaksë të qartë dhe të thjeshtë në skedaret YAML
Me daljen e.

docker compose v3 këto skedarë YAML mund të përdoren drejtpërdrejt në mjedisin e punës, kur punoni me klasterin
Por, a do të thotë kjo se mund të përdorni të njëjtin skedar docker-compose në Docker Swarm.

procesin e zhvillimit dhe në ambientin e prodhimit? Ose të përdorni të njëjtin skedar për
staging? Po, në përgjithësi, po, por për këtë funksionalitet na nevojitet e mëposhtme:
Interpolimi i variablave: përdorimi i variablave të mjedisit për disa

• vlera që ndryshojnë në secilin mjedis.
  Mattja e konfiguracionit: mundësia për të përcaktuar një skedar të dytë (ose të çdo
• skedari tjetër tjetër) docker-compose që do të ndryshojë diçka në lidhje me
  të parin, dhe docker compose do të kujdeset për kombinimin e të dy skedarëve.
  Dallimet midis skedareve për zhvillim dhe prodhim

Gjatë zhvillimit, me siguri do të doni të kontrolloni ndryshimet në kod në

kohë reale. Për këtë, zakonisht, volume-i me kodin burimor montohen në
kontejnerin ku ndodhet runtime-i për aplikacionin tuaj. Por për ambientin e prodhimit
kjo mënyrë nuk është e përshtatshme.
Në prodhim keni një klaster me shumë nyje, dhe volume-i është lokal në

raport me nyjen ku funksionon konteineri juaj (ose shërbimi), kështu që nuk
mund të montoni kodin burimor pa operacione të komplikuara që përfshijnë
sinkronizimin e kodit, sinjalet etj.
Në vend të kësaj, zakonisht duam të krijojmë një imazh me një version të caktuar të kodit tuaj.

Është zakon që ta shënoni me një tag përkatës (mund të përdorni versionim
semantik ose një sistem tjetër sipas zgjedhjes suaj).
Mattja e konfiguracionit

Duke marrë parasysh dallimet dhe se varësitë tuaja mund të jenë të ndryshme në skenarët

e zhvillimit dhe prodhimit, është e qartë se do të na duhen skedarë konfigurimi të ndryshëm.
Docker compose mbështet kombinimin e skedarëve të ndryshëm compose për

të marrë konfigurimin përfundimtar. Si funksionon kjo mund të shihet në shembullin:
për të marrë konfigurimin përfundimtar. Si funksionon mund të shihet në shembullin:

$ 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

Si u tha, docker compose mbështet bashkimin e disa compose-
fileve, kjo lejon tejkalimin e parametrave të ndryshëm në skedarin e dytë. Për shembull:

$ 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

Ky sintaks nuk është shumë i përshtatshëm gjatë zhvillimit, kur komanda
duhet të ekzekutohet shumë herë.

Fatmirësisht, docker compose automatikisht e kërkon një skedar të veçantë me emrin
docker-compose.override.yml për të tejkaluar vlerat docker-compose.yml. Nëse
ndërroni emrin e skedarit të dytë, do të merrni rezultatin e njëjtë, vetëm me komandën fillestare:

$ 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

Mirë, kështu është më e lehtë për t'u mbajtur mend.

Interpolimi i variablave

Skedarët e konfigurimit mbështesin interpolimin
variabile dhe vlerat e paracaktuara. Pra, mund të bëni ndryshe:

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

Dhe nëse ekzekutoni docker-compose build (ose push) pa variablën e mjedisit
$MY_SERVICE_VERSION, do të përdoret vlera latest, por nëse vendosni
vlerën e variablës së mjedisit para ndërtimit, ajo do të përdoret gjatë ndërtimit ose pushit
në regjistrin private.registry.mine.

Parimet e mia

Qasje të përshtatshme për mua mund të jenë të dobishme edhe për ju. Ndjek këto
rregulla të thjeshta:

• Të gjitha stekat e mia për prodhim, zhvillim (apo mjedise të tjera) përkufizohen përmes
  skedarëve docker-compose.
• Skedarët e konfigurimit, të nevojshëm për të mbuluar të gjitha mjediset e mia, maksimalisht
  shmangin riprodhimin.
• Më duhet një komandë e thjeshtë për të punuar në çdo mjedis.
• Konfigurimi kryesor përcaktohet në skedarin docker-compose.yml.
• Variablat e mjedisit përdoren për të përcaktuar etiketat e imazheve ose variabla të tjerë
  që mund të ndryshojnë nga mjedisi në mjedis (staging, integrim,
  prodhim).
• Vlerat e variablave për prodhimin përdoren si vlera të paracaktuara, kjo minimizon rreziqet në rast se ekipi është aktivizuar në prodhim pa
  të vendosur variablin e mjedisit.
  Për të nisur shërbimin në mjedisin e prodhimit përdoret komanda
• docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name Mjedisi i punës aktivizohet me anë të komandës.
• Le të shohim një shembull të thjeshtë. docker-compose up -d.

Mund të përdor

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

DHE

# 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) për të nisur stekun nëmodin e zhvillimit me kodin burimor të montuar në
Mund të përdor këta të njëjtë skedarë në prodhim! Dhe mund të përdorja saktësisht /project/src.

të njëjtin skedar
për staging. Për ta zhvendosur këtë në docker-compose.yml prodhim, më mjafton të ndërtoj dhe dërgoj imazhin me etiketën e paracaktuar
në fazën e CI:
export MY_SERVICE_VERSION=1.2.3 docker-compose -f docker-compose.yml build docker-compose -f docker-compose.yml push

Në prodhim, kjo mund të ekzekutohet me anë të komandave të mëposhtme:

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

Dhe nëse dëshironi të bëni të njëjtën gjë në staging, thjesht duhet të përcaktoni

variablat e nevojshme të mjedisit për të punuar në mjedisin e staging:
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

Si rezultat, ne përdorëm dy skedarë të ndryshëm docker-compose, të cilët pa

riprodhimin e konfigurimeve mund të përdoren për çdo mjedis tuajin!
Përkthimi i transkriptit të podcast-it është përgatitur në prag të nisjes së kursit "Administratori Linux"

Mësoni më shumë rreth kursit "Administrator Linux"

Burimi: habr.com