🥇Docker Compose: od razvoja do produkcije

Prevajanje transkripcije podkasta je pripravljeno ob začetku tečaja "Administrator Linuxa"

Docker Compose je neverjetno orodje za ustvarjanje delovnega
okolja za sklad, ki se uporablja v vaši aplikaciji. Omogoča vam opredelitev
vsakega komponenta vaše aplikacije, skladno s jasno in preprosto sintakso v YAML-
datotekah.

S pojavom docker compose v3 te YAML datoteke se lahko uporabljajo neposredno v delovnem okolju, pri delu z
grozdom Docker Swarm.

Ali to pomeni, da lahko uporabite isto datoteko docker-compose v
procesu razvoja in v produkcijskem okolju? Ali uporabite to datoteko za
staging? Na splošno da, vendar za to funkcionalnost potrebujemo naslednje:

Interpolacijo spremenljivk: uporaba okolijskih spremenljivk za nekatere
vrednosti, ki se razlikujejo v vsakem okolju.
Presejanje konfiguracije: možnost opredelitve druge (ali katerikoli
nadaljnji) datoteke docker-compose, ki bo spremenila nekaj v povezavi s
prvo, in docker compose bo poskrbel za združitev obeh datotek.

Razlike med datotekami za razvoj in produkcijo

Med razvojem boste verjetno želeli preverjati spremembe kode v
realnem času. Običajno se za to v kontejner, ki vsebuje runtime za vašo aplikacijo, montira
katalog z izvorno kodo. Vendar ta način ni primeren za produkcijsko okolje.
V produkciji imate grozd z več vozlišči, katalog pa je lokalno do

vozlišča, na katerem deluje vaš kontejner (ali storitev), zato ne
morete montirati izvorno kodo brez zapletenih operacij, ki vključujejo
sinhronizacijo kode, signale itd.
Namesto tega običajno želimo ustvariti sliko z določeno različico vaše kode.

Navadno se označi z ustrezno oznako (lahko se uporabi semantično
verzioniranje ali drug sistem po vaši izbiri).
Presejanje konfiguracije

Ob upoštevanju razlik in dejstva, da se vaše odvisnosti lahko razlikujejo v scenarijih

razvoja in produkcije, je jasno, da bomo potrebovali različne konfiguracijske datoteke.
Docker compose podpira združevanje različnih compose-datotek za

pridobitev končne konfiguracije. Kako to deluje, lahko vidite na primeru:
получения окончательной конфигурации. Как это работает можно увидеть на примере:

$ 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

для переопределения значений.
Переименовав второй файл, вы получите тот же результат, только с помощью изначальной команды: $ 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 docker-compose.yml. Если
Хорошо, так запомнить проще.

Интерполяция переменных.

Файлы конфигурации поддерживают

интерполяцию

и значения по умолчанию. То есть вы можете сделать следующее: services: my-service: build: context: . image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest} ...
spremenljivkah И если вы выполняете

docker-compose build (или push)

без переменной окружения $MY_SERVICE_VERSION , будет использовано значение
, но если вы установитезначение переменной окружения до сборки, оно будет использовано при сборке или пуше latestв регистр
private.registry.mine
Мои принципы private.registry.mine.

Мои принципы

Pristopi, ki so zame udobni, so lahko koristni tudi za vas. Sledim tem
enostavnim pravilom:

Vse moje tehnologije za produkcijo, razvoj (ali druge okolja) so opredeljene preko
datotek docker-compose.
Konfiguracijske datoteke, potrebne za pokritje vseh mojih okolij, kar se da
izogibajo podvajanju.
Potrebujem enostavno ukazno vrstico za delovanje v vsakem okolju.
Osnovna konfiguracija je definirana v datoteki docker-compose.yml.
Spremenljivke okolja se uporabljajo za določanje oznak slik ali drugih
spremenljivk, ki se lahko spreminjajo od okolja do okolja (staging, integracija,
produkcija).
Vrednosti spremenljivk za produkcijo se uporabljajo kot privzete vrednosti, kar
mini imira tveganja v primeru zagonja sklada v produkciji brez
določene spremenljivke okolja.
Za zagon storitve v produkcijskem okolju se uporablja ukaz docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name.
Delovno okolje se zažene z ukazom docker-compose up -d.

Poglejmo en preprost primer.

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

Lahko uporabim docker-compose (docker-compose up), da zagnem sklad v
razvojnem načinu s izvorno kodo, ki je priključena v /project/src.

Te iste datoteke lahko uporabim tudi v produkciji! In lahko bi uporabil točno
isto datoteko docker-compose.yml za staging. Da to razporedim na
produkcijo, moram le zgraditi in poslati sliko s predhodno opredeljeno oznako
v fazi CI:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

V produkciji to lahko zaženem s spodnjimi ukazi:

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

In če želite storiti enako na stagi, morate le določiti
potrebne spremenljivke okolja za delo v staging okolju:

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

Na koncu smo uporabili dve različni datoteki docker-compose, ki brez
podvajanja konfiguracij lahko uporabimo za katero koli vaše okolje!

Več o tečaju "Administrator Linuxa"

Izvor: habr.com