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

Превод на транскрипцијата на подкаст подготвена во пресрет на почетокот на курсот „Администратор на Линукс“

Docker Compose е неверојатна алатка за создавање на работна
околина за стекот што се користи во вашата апликација. Тоа ви овозможува да дефинирате
секоја компонента од вашата апликација, следејќи јасна и едноставна синтакса во YAML-
датотеки.

Со доаѓањето на docker compose v3 овие YAML-датотеки може да се користат директно во производствената средина при работа со
Грозд Докер рој.

Но, дали ова значи дека можете да ја користите истата датотека со докер-компонирање во
процес на развој и во производствената средина? Или користете ја истата датотека за
инсценирање? Па, во принцип, да, но за оваа функционалност ни треба следново:

• Интерполација на променлива: користење на променливи на околината за некои
  вредности кои се менуваат во секоја средина.
• Отфрлање на конфигурацијата: способност да се дефинира втора (или која било
  уште една следна) датотека 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 поддржува комбинирање на повеќе композиции -
датотеки, ова ви овозможува да отфрлите различни параметри во втората датотека. На пример:

$ 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 да ги отфрли вредностите 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  | < 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, вредноста ќе се користи најновитено ако поставите
вредноста на променливата на животната средина пред изградбата, ќе се користи при градење или притискање
до регистарот приватен.регистар.мој.

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

Пристапите што функционираат за мене може да работат и за вас. Јас ги следам овие
едноставни правила:

• Сите мои купови за производство, развој (или други средини) се дефинирани преку
  докер-компонира датотеки
• Потребни се датотеки за конфигурација за да ги покријат сите мои средини, колку што е можно повеќе
  избегнувајте дуплирање.
• Ми треба една едноставна команда за работа во секоја средина.
• Главната конфигурација е дефинирана во датотеката docker-compose.yml.
• Променливите на животната средина се користат за дефинирање на ознаки на слики или други
  променливи кои може да варираат од средина до средина (поставување, интеграција,
  производство).
• Вредностите на производствените променливи се користат како вредности за
  по дифолт, ова ги минимизира ризиците доколку оџакот се лансира во производство без
  постави променлива на околината.
• За да започнете услуга во производствена средина, користете ја командата docker stack deploy - compose-file docker-compose.yml -with-registry-auth my-stack-name.
• Работната средина се стартува со помош на командата докер-компонирај -Д.

Ајде да погледнеме едноставен пример.

# 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)за да го вклучите магацинот
режим на развој со монтиран изворен код /проект/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

Како резултат на тоа, користевме две различни датотеки со докер-компонирање, кои без
Дупликатните конфигурации може да се користат за која било средина што ја имате!

Дознајте повеќе за курсот „Администратор на Линукс“

Извор: www.habr.com