Docker Compose: от разработка до продукция

Преводът на транскрипцията на подкаста е подготвен в навечерието на старта на курса "Администратор Linux"

Docker Compose е удивителен инструмент за създаване на работна
среда за стека, използван във вашето приложение. Той ви позволява да дефинирате
всеки компонент на вашето приложение, следвайки ясна и проста синтаксис в YAML-файлове
С появата на.

docker compose v3 тези YAML-файлове могат да се използват директно в работната среда, при работа с клъстер
Docker Swarm Но означава ли това, че можете да използвате същия 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  | 
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  | 
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 за преопределение на стойности. docker-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  | 
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, ще бъде използвана стойността latest, но ако зададете
стойността на променливата на околната среда преди компилиране, тя ще бъде използвана при компилиране или изпращане
в регистъра private.registry.mine.

Моите принципи

Подходите, които са удобни за мен, може да се окажат полезни и за вас. Следвам тези
простички правила:

• Всичките ми стекове за продукция, разработка (или други среди) се определят чрез
  файлове docker-compose.
• Конфигурационните файлове, които са необходими за обхващане на всички моите среди, максимално
  избягват дублирането.
• Нуждая се от една проста команда за работа във всяка среда.
• Основната конфигурация е определена във файла docker-compose.yml.
• Променливите за средата се използват за определяне на таговете на образите или други
  променливи, които могат да се променят от среда на среда (стейджинг, интеграция,
  продукция).
• Стойностите на променливите за продукция се използват като стойности по
  подразбиране, това минимизира рисковете при стартиране на стека в продукция без
  установената променлива на средата.
• За стартиране на услугата в продукционна среда се използва командата docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name.
• Работната среда се стартира с помощта на командата docker-compose up -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.

Мога да използвам тези същите файлове в продукция! И бих могъл да използвам точно
такъв файл docker-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