డాకర్ కంపోజ్: అభివృద్ధి నుండి ఉత్పత్తి వరకు

పాడ్‌క్యాస్ట్ ట్రాన్స్‌క్రిప్షన్ యొక్క అనువాదం కోర్సు ప్రారంభానికి ముందే సిద్ధం చేయబడింది "Linux అడ్మినిస్ట్రేటర్"

డాకర్ కంపోజ్ అనేది పనిని సృష్టించడానికి అద్భుతమైన సాధనం
మీ అప్లికేషన్‌లో ఉపయోగించిన స్టాక్ కోసం పర్యావరణం. ఇది నిర్వచించడానికి మిమ్మల్ని అనుమతిస్తుంది
каждый компонент вашего приложения, следуя четкому и простому синтаксису в YAML-
файлах.

రావడంతో డాకర్ కంపోజ్ v3 ఈ YAML ఫైల్‌లు పని చేస్తున్నప్పుడు నేరుగా ఉత్పత్తి వాతావరణంలో ఉపయోగించబడతాయి
క్లస్టర్ డాకర్ సమూహం.

అయితే మీరు అదే డాకర్-కంపోజ్ ఫైల్‌ని ఉపయోగించవచ్చని దీని అర్థం
процессе разработки и в продакшен среде? Или использовать этот же файл для
స్టేజింగ్? బాగా, సాధారణంగా, అవును, కానీ ఈ కార్యాచరణ కోసం మనకు ఈ క్రిందివి అవసరం:

• వేరియబుల్ ఇంటర్‌పోలేషన్: కొందరికి ఎన్విరాన్‌మెంట్ వేరియబుల్స్ ఉపయోగించడం
  ప్రతి వాతావరణంలో మారే విలువలు.
• కాన్ఫిగరేషన్ ఓవర్‌రైడ్: సెకనును నిర్వచించగల సామర్థ్యం (లేదా ఏదైనా
  другой последующий) 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

చెప్పినట్లుగా, డాకర్ కంపోజ్ బహుళ కంపోజ్‌లను కలపడానికి మద్దతు ఇస్తుంది -
файлов, это позволяет переопределять различные параметры во втором файле. Например:

$ 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 автоматически ищет специальный файл с именем
డాకర్-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}
...

మరియు మీరు చేస్తే డాకర్-కంపోజ్ బిల్డ్ (లేదా పుష్) పర్యావరణ వేరియబుల్ లేకుండా
$MY_SERVICE_VERSION, విలువ ఉపయోగించబడుతుంది తాజాకానీ మీరు సెట్ చేస్తే
బిల్డ్‌కు ముందు ఎన్విరాన్‌మెంట్ వేరియబుల్ విలువ, అది నిర్మించేటప్పుడు లేదా నెట్టేటప్పుడు ఉపయోగించబడుతుంది
రిజిస్టర్‌కి private.registry.mine.

Мои принципы

నాకు పని చేసే విధానాలు మీ కోసం కూడా పని చేయవచ్చు. నేను వీటిని అనుసరిస్తున్నాను
простым правилам:

• Все мои стеки для продакшена, разработки (или других сред) определяются через
  డాకర్-కంపోజ్ ఫైల్స్
• కాన్ఫిగరేషన్ ఫైల్‌లు నా అన్ని పరిసరాలను వీలైనంత వరకు కవర్ చేయడానికి అవసరం
  నకిలీని నివారించండి.
• ప్రతి వాతావరణంలో పని చేయడానికి నాకు ఒక సాధారణ కమాండ్ అవసరం.
• ప్రధాన కాన్ఫిగరేషన్ ఫైల్‌లో నిర్వచించబడింది డాకర్-compose.yml.
• ఇమేజ్ ట్యాగ్‌లు లేదా ఇతర వాటిని నిర్వచించడానికి ఎన్విరాన్‌మెంట్ వేరియబుల్స్ ఉపయోగించబడతాయి
  переменных, которые могут меняться от среды к среде (стейджинг, интеграция,
  продакшен).
• ఉత్పత్తి వేరియబుల్స్ యొక్క విలువలు విలువలుగా ఉపయోగించబడతాయి
  умолчанию, это минимизирует риски в случае запуска стека в продакшене без
  ఎన్విరాన్మెంట్ వేరియబుల్ సెట్ చేయండి.
• Для запуска сервиса в продакшен-среде используется команда డాకర్ స్టాక్ విస్తరణ - కంపోజ్-ఫైల్ 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
...

నేను ఉపయోగించగలను డాకర్-కంపోజ్ (డాకర్-కంపోజ్ అప్), чтобы запустить стек в
режиме разработки с исходным кодом, смонтированным в /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

ఫలితంగా, మేము రెండు వేర్వేరు డాకర్-కంపోజ్ ఫైల్‌లను ఉపయోగించాము, అవి లేకుండా
నకిలీ కాన్ఫిగరేషన్‌లను మీరు కలిగి ఉన్న ఏ వాతావరణంలోనైనా ఉపయోగించవచ్చు!

కోర్సు గురించి మరింత తెలుసుకోండి "Linux అడ్మినిస్ట్రేటర్"

మూలం: www.habr.com