Доцкер Цомпосе: од развоја до производње

Превод транскрипције подцаста припремљен у ишчекивању почетка курса "Линук администратор"

Доцкер Цомпосе је невероватан алат за креирање радног
окружење за стек који се користи у вашој апликацији. Омогућава вам да дефинишете
сваку компоненту ваше апликације, пратећи јасну и једноставну синтаксу у ИАМЛ-
фајлови.

Са појавом доцкер цомпосе в3 ове ИАМЛ датотеке се могу користити директно у производном окружењу када се ради са њима
кластер Доцкер Сварм.

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

• Интерполација променљивих: коришћење променљивих окружења за неке
  вредности које се мењају у свакој средини.
• Замена конфигурације: могућност дефинисања секунде (или било које
  још један следећи) доцкер-цомпосе фајл који ће променити нешто у вези
  прво, а доцкер цомпосе ће се побринути за спајање обе датотеке.

Разлике између развојних и производних датотека

Током развоја, највероватније ћете желети да проверите промене кода
реалном времену. Да бисте то урадили, обично се у њега монтира волумен са изворним кодом
контејнер који садржи време извођења за вашу апликацију. Али за производно окружење
Овај метод није погодан.

У производњи имате кластер са много чворова, а запремина је локална
у односу на чвор на коме је покренут ваш контејнер (или услуга), тако да не радите
можете монтирати изворни код без сложених операција које укључују
синхронизација кода, сигнали итд.

Уместо тога, обично желимо да направимо слику са одређеном верзијом вашег кода.
Уобичајено је да га означите одговарајућом ознаком (можете користити семантички
верзионисање или други систем по вашем нахођењу).

Цонфигуратион Оверриде

С обзиром на разлике и да се ваше зависности могу разликовати у сценаријима
развој и производња, јасно је да ће нам требати различите конфигурационе датотеке.

Доцкер цомпосе подржава спајање различитих датотека за састављање
добити коначну конфигурацију. Како ово функционише може се видети на примеру:

$ 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

Ова синтакса није баш згодна током развоја, када команда
мораће да се уради много пута.

Срећом, доцкер цомпосе аутоматски тражи посебну датотеку под називом
доцкер-цомпосе.оверриде.имл да надјача вредности доцкер-цомпосе.имл. Ако
преименујте другу датотеку, добићете исти резултат, само користећи оригиналну команду:

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

ја могу користити доцкер-цомпосе (доцкер-цомпосе уп)за покретање стека
развојни режим са уграђеним изворним кодом /пројекат/срц.

Могу да користим ове исте датотеке у производњи! И дефинитивно бих могао да користим
исти фајл доцкер-цомпосе.имл за инсценацију. Да проширим ово на
продукцију, само треба да направим и пошаљем слику са унапред дефинисаном ознаком
у фази ЦИ:

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

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

Сазнајте више о курсу "Линук администратор"

Извор: ввв.хабр.цом