Docker Compose: nga zhvillimi në prodhim

Përkthimi i transkriptit të podkastit është përgatitur në prag të fillimit të kursit «Administrator Linux»

Docker Compose është një mjet fantastik për krijimin e një
mjedisi për stek, i përdorur në aplikacionin tuaj. Ai ju lejon të përcaktoni
çdo komponent të aplikacionit tuaj, duke ndjekur një sintaksë të qartë dhe të thjeshtë në skedarët YAML
Me shfaqjen 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 që mund të përdorni të njëjtin skedar docker-compose në Docker Swarm.

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

• vlera që ndryshojnë në çdo mjedis.
  Rivendosja e konfiguracionit: mundësia për të përcaktuar një skedar të dytë (ose çdo
• skedar tjetër të mëvonshëm) docker-compose që do të ndryshojë diçka në lidhje me
  të parin, dhe docker compose do të kujdeset për bashkimin e të dy skedarëve.
  Dallimet midis skedarëve për zhvillimin dhe prodhimin

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

Gjatë zhvillimit, me siguri do të dëshironi të kontrolloni ndryshimet e kodit në
në kohë reale. Për këtë, zakonisht, volumi me kodin burimor montoset në
kontenierin, ku ndodhet runtime për aplikacionin tuaj. Por për mjedisin prodhues
këto metoda nuk janë të përshtatshme.

Në prodhim keni një klasër me shumë nyje, dhe volumi është lokal në lidhje me nyjen
ku punon konteneri juaj (ose shërbimi), prandaj nuk mund
të montoni kodin burimor pa operacione të komplikuara që përfshijnë
sinkronizimin e kodit, sinjalet dhe tjerë.

Në vend të kësaj, zakonisht dëshirojmë të krijojmë një imazh me një version të caktuar të kodit tuaj.
Është e zakonshme ta shenoni me një etiketë përkatëse (mund të përdorni versionimin
semantik ose një sistem tjetër sipas dëshirës tuaj).

Rivendosja e konfiguracionit

Duke marrë parasysh dallimet dhe se varsitë tuaja mund të ndryshojnë në skenarët
e zhvillimit dhe prodhimit, është e qartë se na nevojiten skedarë të ndryshëm konfigurimi.

Docker compose mbështet bashkimin e skedarëve të ndryshëm compose për
të marrë konfigurimin përfundimtar. Si funksionon mund të shihet nga një shembull:

$ 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 e tha u tha, docker compose mbështet bashkimin e disa compose-
fileve, kjo lejon rinovimin 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 në procesin e zhvillimit, kur komanda
do t'i nevojitet të ekzekutohet shumë herë.

Fatmirësisht, docker compose automatikisht kërkon një skedar të veçantë me emrin
docker-compose.override.yml për të tejkaluar vlerat docker-compose.yml. Nëse
nëse e rinomin skedarin e dytë, do të marrësh të njëjtin rezultat, vetëm me komandën fillestare:

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Duke filluar composeconfigs_whale_1
Duke u lidhur me 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 doli me kod 0

Mirë, kështu është më e lehtë për ta mbajtur mend.

Interpolimi i variablave

Skedarët e konfigurimit mbështesin interpolimin
variablat dhe vlerat e paracaktuar. Pra, ju mund të bëni sa vijon:

shërbimet:
  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 shtytjes
në regjistër private.registry.mine.

Parimet e mia

Qasht që funksionojnë për mua, mund të jenë të dobishme edhe për ju. Unë ndjek këto
rregulla të thjeshta:

• Të gjitha steqet e mia për prodhimin, zhvillimin (ose ambiente të tjera) përcaktohen përmes
  skedarëve docker-compose.
• Skedarët e konfigurimit, të nevojshëm për të mbuluar të gjitha ambientet e mia, maksimalisht
  evitojnë shumëzimin.
• Më nevojitet një komandë e thjeshtë për të punuar në çdo ambient.
• Konfigurimi kryesor përcaktohet në skedarin docker-compose.yml.
• Variablat e ambientit përdoren për të përcaktuar etiketat e imazheve ose variablat e tjera
  që mund të ndryshojnë nga ambienti në ambient (stage, integrim,
  prodhim).
• Vlerat e variablave për prodhimin përdoren si vlera të parazgjedhura, kjo minimizon rreziqet në rastin e ekzekutimit të stekës në prodhim pa
  përcaktuar një variabël ambienti.
  Për të ekzekutuar shërbimin në ambientin e prodhimit përdoret komanda
• docker stack deploy — compose-file docker-compose.yml —with-registry-auth my-stack-name Ambienti i punës fillohet me ndihmën e 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 stekën nëmodusin e zhvillimit me kodin burimor të montuar për
modin e zhvillimit me kodin burimor të montuar në /project/src.

Mund të përdor të njëjtat skedarë në prodhim! Dhe mund të përdor saktësisht
të njëjtin skedar docker-compose.yml për skenë. Për ta vendosur këtë në
prodhim, thjesht duhet të mbledh dhe të dërgoj imazhin me një etiketë të paracaktuar
në hapin 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 komandat e 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ë skenë, thjesht duhet të përcaktoni
variablat e nevojshme të mjedisit për të punuar në ambientin e skenës:

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
dyfishimin e konfigurimeve mund të përdoren për çdo mjedis tuajin!

Mëso më shumë për kursin «Administrator Linux»

Burimi: habr.com