ProHoster > Блог > администрация > Docker Compose: от разработка до производство

Docker Compose: от разработка до производство

Превод на транскрипцията на подкаста, изготвен в очакване на началото на курса Администратор Linux»

Docker Compose: от разработка до производство

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

С появата на docker compose v3 тези YAML файлове могат да се използват директно в производствената среда, когато се работи с
клъстер Докер рояк.

Но означава ли това, че можете да използвате същия файл за съставяне на docker в
процес на разработка и производствена среда? Или използвайте същия файл за
постановка? Е, като цяло, да, но за такава функционалност се нуждаем от следното:

  • Интерполация на променливи: използване на променливи на средата за някои
    ценности, които се променят във всяка среда.
  • Отмяна на конфигурацията: възможност за дефиниране на втори (или който и да е
    друг последващ) docker-compose файл, който ще промени нещо относно
    първият, а docker compose ще се погрижи за сливането на двата файла.

Разлики между развойни и производствени файлове

По време на разработката най-вероятно ще искате да проверите за промени в кода
режим в реално време. За да направите това, обикновено се монтира томът с изходния код
контейнер, който съдържа времето за изпълнение на вашето приложение. Но за производствена среда
този начин не е подходящ.

В производството имате клъстер с множество възли и обемът е локален
спрямо хоста, на който работи вашият контейнер (или услуга), така че не го правите
можете да монтирате изходния код без сложни операции, които включват
кодова синхронизация, сигнали и др.

Вместо това обикновено искаме да създадем изображение с конкретна версия на вашия код.
Обичайно е да го маркирате със съответния етикет (можете да използвате семантичен
версия или друга система по ваш избор).

Отмяна на конфигурацията

Като се имат предвид разликите и че вашите зависимости може да се различават в сценариите
разработка и производство, ясно е, че ще имаме нужда от различни конфигурационни файлове.

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

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

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

  • Всички мои стекове за производство, разработка (или други среди) са дефинирани чрез
    докер композиране на файлове.
  • Конфигурационните файлове, необходими за покриване на всички мои среди, макс.
    избягвайте дублиране.
  • Имам нужда от една проста команда, за да работя във всяка среда.
  • Основната конфигурация е дефинирана във файла докер-compose.yml.
  • Променливите на средата се използват за дефиниране на етикети на изображения или други
    променливи, които могат да се променят от среда в среда (постановка, интеграция,
    производство).
  • Стойностите на променливите за производство се използват като стойности от
    по подразбиране това минимизира рисковете, ако стартирате стека в производство без
    задайте променлива на средата.
  • За да стартирате услуга в производствена среда, използвайте командата разгръщане на докер стек - композиране на файл.
  • Работната среда се стартира с командата докер-компилиране нагоре -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)за да стартирате стека
режим на разработка с монтиран изходен код /проект/срц.

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

Източник: www.habr.com

Купете надежден хостинг за сайтове с DDoS защита, VPS VDS сървъри 🔥 Купете надежден уеб хостинг със защита от DDoS атаки, VPS VDS сървъри | ProHoster