🥇Docker Compose: nga zhvillimi në prodhim

Përkthimi i transkriptimit të podcast-it i përgatitur në pritje të fillimit të kursit "Administrator Linux"

Docker Compose është një mjet i mrekullueshëm për krijimin e një pune
mjedisi për pirgun e përdorur në aplikacionin tuaj. Kjo ju lejon të përcaktoni
çdo komponent të aplikacionit tuaj, duke ndjekur një sintaksë të qartë dhe të thjeshtë në YAML-
dosjet.

Me ardhjen e docker kompozoj v3 këta skedarë YAML mund të përdoren drejtpërdrejt në mjedisin e prodhimit kur punoni me të
grumbull Grumbulli i dokerëve.

Por a do të thotë kjo që ju mund të përdorni të njëjtin skedar docker-compose në
procesin e zhvillimit dhe në mjedisin e prodhimit? Ose përdorni të njëjtin skedar për
vënien në skenë? Epo, në përgjithësi, po, por për këtë funksionalitet na duhen sa vijon:

Interpolimi i variablave: përdorimi i variablave të mjedisit për disa
vlerat që ndryshojnë në çdo mjedis.
Anulimi i konfigurimit: aftësia për të përcaktuar një sekondë (ose ndonjë tjetër
një skedar tjetër i mëvonshëm) docker-compose që do të ndryshojë diçka në lidhje me
së pari, dhe docker compose do të kujdeset për bashkimin e të dy skedarëve.

Dallimet midis skedarëve të zhvillimit dhe prodhimit

Gjatë zhvillimit, me shumë mundësi do të dëshironi të kontrolloni ndryshimet e kodit
kohe reale. Për ta bërë këtë, zakonisht vendoset vëllimi me kodin burimor
kontejner që përmban kohën e funksionimit për aplikacionin tuaj. Por për një mjedis prodhimi
Kjo metodë nuk është e përshtatshme.

Në prodhim, ju keni një grup me shumë nyje, dhe vëllimi është lokal
në lidhje me nyjen në të cilën kontejneri (ose shërbimi) juaj po funksionon, kështu që ju nuk e bëni
ju mund të montoni kodin burim pa operacione komplekse që përfshijnë
sinkronizimi i kodeve, sinjalet, etj.

Në vend të kësaj, ne zakonisht duam të krijojmë një imazh me një version specifik të kodit tuaj.
Është zakon ta shënoni me etiketën e duhur (mund të përdorni semantike
versionimi ose një sistem tjetër sipas gjykimit tuaj).

Mbështetja e konfigurimit

Duke pasur parasysh dallimet dhe se varësitë tuaja mund të ndryshojnë në skenarë
zhvillim dhe prodhim, është e qartë se do të na duhen skedarë të ndryshëm konfigurimi.

Docker compose mbështet bashkimin e skedarëve të ndryshëm të kompozimit në
merrni konfigurimin përfundimtar. Si funksionon kjo 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  | < 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

Siç u tha, docker compose mbështet kombinimin e kompozimeve të shumta -
skedarë, kjo ju lejon të anashkaloni parametra 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  | < 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

Kjo sintaksë nuk është shumë e përshtatshme gjatë zhvillimit, kur komanda
do të duhet të bëhet shumë herë.

Për fat të mirë, docker compose kërkon automatikisht një skedar të veçantë të quajtur
docker-kompozoj.përmbys.yml për të kapërcyer vlerat prerës-compose.yml. nëse
riemërtoni skedarin e dytë, ju merrni të njëjtin rezultat, vetëm duke përdorur komandën origjinale:

$ 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

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

Interpolimi i variablave

Mbështetja e skedarëve të konfigurimit interpolimi
variablave dhe vlerat e paracaktuara. Kjo është, ju mund të bëni sa më poshtë:

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

Dhe nëse e bëni ndërtim docker-compose (ose shtytje) pa variabël mjedisi
$MY_SERVICE_VERSION, do të përdoret vlera funditpor nëse vendosni
vlera e ndryshores së mjedisit përpara ndërtimit, do të përdoret kur ndërtohet ose shtyhet
në regjistër private.regjistri.imja.

Parimet e mia

Qasjet që funksionojnë për mua mund të funksionojnë edhe për ju. Unë i ndjek këto
rregulla të thjeshta:

Të gjitha pirgjet e mia për prodhim, zhvillim (ose mjedise të tjera) përcaktohen përmes
docker-compose skedarë
Skedarët e konfigurimit të nevojshëm për të mbuluar të gjitha mjediset e mia, sa më shumë që të jetë e mundur
shmangni dyfishimin.
Më duhet një komandë e thjeshtë për të punuar në çdo mjedis.
Konfigurimi kryesor përcaktohet në skedar prerës-compose.yml.
Variablat e mjedisit përdoren për të përcaktuar etiketat e imazhit ose të tjera
variablat që mund të ndryshojnë nga mjedisi në mjedis (instalimi, integrimi,
prodhim).
Vlerat e variablave të prodhimit përdoren si vlera për
si parazgjedhje, kjo minimizon rreziqet nëse pirgja lëshohet në prodhim pa
vendos ndryshore mjedisore.
Për të nisur një shërbim në një mjedis prodhimi, përdorni komandën docker stack deploy - compose-file docker-compose.yml -with-registry-auth my-stack-name.
Mjedisi i punës fillon duke përdorur komandën docker-përbëjnë -d.

Le të shohim një shembull të thjeshtë.

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

mund të përdor docker-compose (docker-compose up)për të drejtuar pirgun brenda
modaliteti i zhvillimit me kodin burimor të montuar /projekt/src.

Unë mund të përdor të njëjtat skedarë në prodhim! Dhe unë mund ta përdor patjetër
i njëjti skedar prerës-compose.yml për vënien në skenë. Për ta zgjeruar këtë në
prodhimit, më duhet vetëm të ndërtoj dhe dërgoj imazhin me një etiketë të paracaktuar
në fazën 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 duke përdorur 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 doni të bëni të njëjtën gjë në skenë, thjesht duhet të përcaktoni
variablat e nevojshëm të mjedisit për të punuar në mjedisin 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
Konfigurimet dublikate mund të përdoren për çdo mjedis që keni!

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

Burimi: www.habr.com

Docker Compose: nga zhvillimi në prodhim

Dallimet midis skedarëve të zhvillimit dhe prodhimit

Mbështetja e konfigurimit

Interpolimi i variablave

Parimet e mia

Shto një koment Cancel përgjigje