🥇Docker Compose: ад распрацоўкі да прадакшэну

Пераклад транскрыпцыі падкасьце падрыхтаваны напярэдадні старту курса "Адміністратар Linux"

Docker Compose - гэта дзіўная прылада для стварэння працоўнага
акружэння для стэка, які выкарыстоўваецца ў вашым дадатку. Ён дазваляе вам вызначаць
кожны кампанент вашага прыкладання, прытрымліваючыся дакладнаму і простаму сінтаксісу ў YAML-
файлах.

З з'яўленнем docker compose v3 гэтыя YAML-файлы могуць выкарыстоўвацца непасрэдна ў працоўным асяроддзі, пры працы з
кластарам Докерскі рой.

Але ці значыць гэта, што вы можаце выкарыстоўваць адзін і той жа docker-compose файл у
працэсе распрацоўкі і ў прадакшэн асяроддзі? Або выкарыстоўваць гэты ж файл для
стэйджынгу? Ну, у цэлым - так, але для такога функцыяналу нам неабходна наступнае:

Інтэрпаляцыя зменных: выкарыстанне зменных асяроддзя для некаторых
значэнняў, якія змяняюцца ў кожным асяроддзі.
Пераазначэнне канфігурацыі: магчымасць вызначыць другі (ці любы
іншы наступны) docker-compose файл, які нешта зменіць адносна
першага, і docker compose паклапоціцца аб зліцці абодвух файлаў.

Адрозненні паміж файламі для распрацоўкі і прадакшэну

Падчас распрацоўкі вы, хутчэй за ўсё, захочаце правяраць змены кода ў
рэжыме рэальнага часу. Для гэтага, як правіла, том з зыходным кодам мантуецца ў
кантэйнер, у якім знаходзіцца рантайм для вашага прыкладання. Але для прадакшн-асяроддзя
такі спосаб не падыходзіць.

У прадакшэне ў вас ёсць кластар з мноствам вузлоў, а тым з'яўляецца лакальным па
адносінах да вузла, на якім працуе ваш кантэйнер (або сэрвіс), таму вы не
можаце мантаваць зыходны код без складаных аперацый, якія ўключаюць у сябе
сінхранізацыю кода, сігналы і т. д.

Замест гэтага мы, звычайна, жадаем стварыць выяву з пэўнай версіяй вашага кода.
Яго прынята пазначаць адпаведным тэгам (можна выкарыстоўваць семантычнае
версіяванне або іншую сістэму на ваша меркаванне).

Пераазначэнне канфігурацыі

Улічваючы адрозненні і тое, што вашыя залежнасці могуць адрознівацца ў сцэнарах
распрацоўкі і прадакшэна, ясна, што нам спатрэбяцца розныя канфігурацыйныя файлы.

Docker compose падтрымлівае аб'яднанне розных compose-файлаў для
атрымання канчатковай канфігурацыі. Як гэта працуе можна ўбачыць на прыкладзе:

$ 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

Як было сказана, docker compose падтрымлівае аб'яднанне некалькіх compose-
файлаў, гэта дазваляе перавызначаць розныя параметры ў другім файле. Напрыклад:

$ 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

Такі сінтаксіс не вельмі зручны ў працэсе распрацоўкі, калі каманду
спатрэбіцца выконваць мноства разоў.

На шчасце, docker compose аўтаматычна шукае спецыяльны файл з імем
docker-compose.override.yml для пераазначэння значэнняў докер-compose.yml. Калі
перайменаваць другі файл, то атрымаецца той жа вынік, толькі з дапамогай першапачатковай каманды:

$ 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

Добра, так запомніць прасцей.

Інтэрпаляцыя зменных

Файлы канфігурацыі падтрымліваюць інтэрпаляцыю
зменных і значэння па змаўчанні. Гэта значыць, вы можаце зрабіць наступнае:

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

І калі вы выконваеце docker-compose build (або push) без зменнай асяроддзя
$MY_SERVICE_VERSION, будзе выкарыстана значэнне апошні, але калі вы ўсталюеце
значэнне зменнай асяроддзі да зборкі, яно будзе выкарыстана пры зборцы або пушы
у рэгістр private.registry.mine.

Мае прынцыпы

Падыходы, якія зручныя для мяне, могуць спатрэбіцца і вам. Я прытрымліваюся гэтым
простым правілам:

Усе мае стэкі для прадакшэна, распрацоўкі (або іншых асяроддзяў) вызначаюцца праз
файлы docker-compose.
Файлы канфігурацыі, неабходныя для ахопу ўсіх маіх асяроддзяў, максімальна
пазбягаюць дубліравання.
Мне патрэбна адна простая каманда для працы ў кожным асяроддзі.
Асноўная канфігурацыя вызначаецца ў файле докер-compose.yml.
Пераменныя асяроддзі выкарыстоўваюцца для вызначэння тэгаў выяў або іншых
зменных, якія могуць мяняцца ад асяроддзя да асяроддзя (стэйджынг, інтэграцыя,
прадакшэн).
Значэнні зменных для прадакшэну выкарыстоўваюцца ў якасці значэнняў па
змаўчанні, гэта мінімізуе рызыкі ў выпадку запуску стэка ў прадакшэне без
устаноўленай зменнай акружэння.
Для запуску сэрвісу ў прадакшэн-асяроддзі выкарыстоўваецца каманда docker stack deploy - compose-file docker-compose.yml -with-registry-auth my-stack-name.
Працоўнае асяроддзе запускаецца з дапамогай каманды докер-кампанаваць да -d.

Давайце паглядзім на просты прыклад.

# 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), Каб запусціць стэк у
рэжыме распрацоўкі з зыходным кодам, змантаваным у /project/src.

Я магу выкарыстоўваць гэтыя ж файлы на прадакшэне! І я мог бы выкарыстоўваць дакладна
такі ж файл докер-compose.yml для стэйджынгу. Каб разгарнуць гэта на
прадакшэн, мне проста трэба сабраць і адправіць вобраз з наканаваным тэгам
на этапе CI:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

На прадакшэне гэта можна запусціць з дапамогай наступных каманд:

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

І калі вы хочаце зрабіць тое ж самае на стэйджы, неабходна проста вызначыць
неабходныя зменныя асяроддзі для працы ў асяроддзі стэйджынгу:

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

У выніку мы выкарыстоўвалі два розных docker-compose файла, якія без
дубліравання канфігурацый могуць выкарыстоўвацца для любой вашай асяроддзя!

Даведацца падрабязней аб курсе "Адміністратар Linux"

Крыніца: habr.com

Docker Compose: ад распрацоўкі да прадакшэну

Адрозненні паміж файламі для распрацоўкі і прадакшэну

Пераазначэнне канфігурацыі

Інтэрпаляцыя зменных

Мае прынцыпы

Дадаць каментар Адмяніць адказ