🥇Docker Compose: от разработки до продакшена

Preklad transkripcie podcastu bol pripravený pred začiatkom kurzu „Administrátor Linuxu“

Docker Compose je úžasný nástroj na vytváranie pracovného
prostredia pre technológie používané vo vašej aplikácii. Umožňuje vám definovať
každú zložku vašej aplikácie, podľa jasnej a jednoduchej syntaxe v súboroch YAML
S príchodom.

docker compose v3 tieto YAML súbory môžu byť použité priamo v pracovnom prostredí pri práci s klastrom
Ale znamená to, že môžete použiť rovnaký docker-compose súbor v Docker Swarm.

procese vývoja a v produkčnom prostredí? Alebo použiť tento istý súbor pre
stage? Nuž, celkovo — áno, ale na takúto funkcionalitu potrebujeme nasledujúce:
Interpolácia premenných: používanie premenných prostredia pre niektoré

hodnoty, ktoré sa menia v každom prostredí.
Prepisovanie konfigurácie: možnosť definovať druhý (alebo akýkoľvek
ďalší nasledujúci) docker-compose súbor, ktorý niečo zmení vo vzťahu k
prvému, a docker compose sa postará o zlúčenie oboch súborov.
Rozdiely medzi súbormi pre vývoj a produkciu

Počas vývoja pravdepodobne budete chcieť sledovať zmeny kódu v

reálnom čase. Na to sa zvyčajne zdieľa zväzok s pôvodným kódom v
kontajneri, v ktorom sa nachádza runtime pre vašu aplikáciu. Ale pre produkčné prostredie
takýto prístup nie je vhodný.
V produkcii máte klaster s množstvom uzlov a zväzok je lokálny vo

vzťahu k uzlu, na ktorom beží váš kontajner (alebo služba), preto nemôžete
zdieľať pôvodný kód bez zložitých operácií, ktoré zahŕňajú
synchronizáciu kódu, signály atď.
Namiesto toho zvyčajne chceme vytvoriť obraz s konkrétnou verziou vášho kódu.

Praktikuje sa označovanie príslušným tagom (môžete použiť semantické
verzovanie alebo iný systém podľa vášho uváženia).
Prepisovanie konfigurácie

Zohľadňujúc rozdiely a to, že vaše závislosti sa môžu líšiť v scenároch

vývoja a produkcie, je jasné, že budeme potrebovať rôzne konfiguračné súbory.
Docker compose podporuje zlúčenie rôznych compose-súborov pre

získanie konečnej konfigurácie. Ako to funguje, môžeme vidieť na príklade:
получения окончательной конфигурации. Как это работает можно увидеть на примере:

$ 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

Ako bolo povedané, docker compose podporuje kombinovanie viacerých compose-
súborov, čo umožňuje predefinovať rôzne parametre v druhom súbore. Napríklad:

$ 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

Takýto syntax nie je veľmi pohodlný v priebehu vývoja, keď bude potrebné príkaz
vykonávať mnohokrát.

Našťastie, docker compose automaticky hľadá špeciálny súbor s názvom
docker-compose.override.yml na predefinovanie hodnôt docker-compose.yml. Ak
premenujte druhý súbor a výsledok bude rovnaký, len s pomocou pôvodného príkazu:

$ 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

Dobre, takto si to ľahšie pamätám.

Interpolácia premenných

Konfiguračné súbory podporujú interpoláciu
premenných a predvolené hodnoty. To znamená, že môžete urobiť nasledovné:

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

A ak vykonáte docker-compose build (alebo push) bez premennej prostredia
$MY_SERVICE_VERSION, použije sa hodnota latest, ale ak nastavíte
hodnotu premennej prostredia pred zostavením, bude použitá pri zostavení alebo push
do registra private.registry.mine.

Moje zásady

Prístupy, ktoré sú pre mňa pohodlné, môžu byť užitočné aj pre vás. Riadiť sa nimi
týmito jednoduchými pravidlami:

Všetky moje stacky pre produkciu, vývoj (alebo iné prostredia) sú definované prostredníctvom
súborov docker-compose.
Konfiguračné súbory, ktoré sú potrebné na pokrytie všetkých mojich prostredí, maximálne
minimalizujú duplicitu.
Potrebujem jeden jednoduchý príkaz pre prácu v každom prostredí.
Hlavná konfigurácia je definovaná v súbore docker-compose.yml.
Premenné prostredia sa používajú na definovanie značiek obrazov alebo iných
premenných, ktoré sa môžu líšiť od prostredia k prostrediu (staging, integrácia,
produkcia).
Hodnoty premenných pre produkciu sa používajú ako predvolené hodnoty, aby sa minimalizovali riziká v prípade spustenia stacku v produkcii bez
nastavenej premennej prostredia.
Na spustenie služby v produkčnom prostredí sa používa príkaz
docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name Pracovné prostredie sa spúšťa pomocou príkazu.
Pozrime sa na jednoduchý príklad. docker-compose up -d.

Môžem použiť

# 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) , aby som spustil stack vrežime vývoja so zdrojovým kódom pripojeným do
Môžem tieto isté súbory použiť aj na produkcii! A mohol by som použiť presne /project/src.

taký istý súbor
pre staging. Na nasadenie tohto na docker-compose.yml produkciu, stačí zostaviť a odoslať obraz s predom definovanou značkou
v rámci CI:
export MY_SERVICE_VERSION=1.2.3 docker-compose -f docker-compose.yml build docker-compose -f docker-compose.yml push

Na produkcii to môžem spustiť pomocou nasledujúcich príkazov:

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

A ak chcete to isté urobiť na stagingu, stačí definovať

potrebné premenné prostredia na prácu v prostredí staging:
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

Nakoniec sme použili dva rôzne docker-compose súbory, ktoré bez

duplicity konfigurácií môžu byť použité pre akékoľvek vaše prostredie!
Preklad transkripcie podcastu bol pripravený v predvečer začiatku kurzu „Administrátor Linux“

Zistiť viac o kurze „Administrátor Linuxu“

Zdroj: habr.com