🥇Docker Compose: od vývoje po produkci

Překlad transkripce podcastu byl připraven před zahájením kurzu „Linuxový administrátor“

Docker Compose je úžasný nástroj pro vytváření pracovní
prostředí pro stack používaný ve vaší aplikaci. Umožňuje vám definovat
každou komponentu vaší aplikace podle jasné a jednoduché syntaxe v YAML-
souboru.

S příchodem docker compose v3 tyto YAML soubory mohou být použity přímo v pracovní prostředí při práci s
klastrem Docker Swarm.

Ale znamená to, že můžete použít stejný docker-compose soubor v
procesu vývoje a v produkčním prostředí? Nebo použít tento soubor pro
staging? No, celkově - ano, ale pro takovou funkčnost potřebujeme následující:

Interpolace proměnných: použití proměnných prostředí pro některé
hodnoty, které se mění v každém prostředí.
Přepsání konfigurace: možnost určit druhý (nebo jakýkoliv
další následující) docker-compose soubor, který něco změní na prvním, a docker compose se postará o sloučení obou souborů.
Rozdíly mezi soubory pro vývoj a produkci

Během vývoje pravděpodobně chcete kontrolovat změny kódu v

reálném čase. K tomu se obvykle svazek se zdrojovým kódem montuje do
konteineru, kde se nachází runtime pro vaši aplikaci. Ale pro produkční prostředí
tento způsob nevyhovuje.
V produkci máte klastr s mnoha uzly, a svazek je místní ve

vztahu k uzlu, na kterém běží váš kontejner (nebo služba), takže nemůžete montovat zdrojový kód bez složitých operací, které zahrnují
synchronicitu kódu, signály atd.
Místo toho obvykle chceme vytvořit obraz s konkrétní verzí vašeho kódu.
Ten se obvykle označuje odpovídajícím tagem (můžete použít sémantické

verzování nebo jiný systém podle vašeho uvážení).
Přepsání konfigurace
Vzhledem k rozdílům a tomu, že vaše závislosti se mohou lišit ve scénářích

vývoje a produkce, je jasné, že budeme potřebovat různé konfigurační soubory.

Docker compose podporuje sloučení různých compose-souborů pro
získání konečné konfigurace. Jak to funguje, lze vidět na příkladu:

Docker Compose podporuje sloučení různých compose souborů pro
získání konečné konfigurace. Jak to funguje, můžete vidět na příkladu:

$ 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

Jak již bylo zmíněno, docker compose podporuje sloučení několika compose-
souborů, což umožňuje přepisovat různé parametry v druhém souboru. Napří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

Tento syntax není během vývoje příliš pohodlný, když je třeba příkaz
provádět několikrát.

Naštěstí docker compose automaticky hledá speciální soubor s názvem
docker-compose.override.yml pro přepsání hodnot docker-compose.yml. Pokud
přejmenovat druhý soubor, získáte stejný výsledek, pouze s pomocí původního pří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

Dobře, to si lépe zapamatuji.

Interpolace proměnných

Konfigurační soubory podporují interpolaci
proměnných a výchozí hodnoty. To znamená, že můžete udělat následující:

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

A pokud provádíte docker-compose build (nebo push) bez proměnné prostředí
$MY_SERVICE_VERSION, bude použita hodnota latest, ale pokud nastavíte
hodnotu proměnné prostředí před sestavením, bude použita při sestavení nebo push
do registru private.registry.mine.

Moje principi

Metody, které mi vyhovují, mohou být užitečné i pro vás. Řídím se těmito
jednoduchými pravidly:

Všechny mé stacky pro produkci, vývoj (nebo jiné prostředí) jsou definovány pomocí
souborů docker-compose.
Konfigurační soubory, které potřebujeme k pokrytí všech mých prostředí, se snaží
maximálně vyhnout duplikování.
Potřebuji jeden jednoduchý příkaz pro práci v každém prostředí.
Hlavní konfigurace je určena v souboru docker-compose.yml.
Proměnné prostředí se používají k určení tagů obrazů nebo jiných
proměnných, které se mohou měnit od prostředí k prostředí (staging, integrace,
produktivní).
Hodnoty proměnných pro produkci se používají jako výchozí hodnoty, čímž
minimalizujeme rizika při spuštění stacku v produkci bez
nastavené proměnné prostředí.
Pro spuštění služby v produkčním prostředí se používá příkaz docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name.
Pracovní prostředí se spouští pomocí příkazu docker-compose up -d.

Podívejme se na jednoduchý příklad.

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

Mohu použít docker-compose (docker-compose up), abych spustil stack v
režimu vývoje s původním kódem namontovaným v /project/src.

Tyto stejné soubory mohu použít i v produkci! A mohl bych použít přesně
stejný soubor docker-compose.yml pro staging. Pro nasazení do
produkce stačí sestavit a odeslat obraz s předdefinovaným tagem
ve fázi CI:

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

V produkci to lze spustit pomocí následujících příkazů:

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

A pokud chcete udělat to samé na stagingu, stačí jen definovat
potřebné proměnné prostředí pro práci v prostředí 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

Celkově jsme použili dva různé soubory docker-compose, které bez
duplikování konfigurací mohou být použity pro jakékoli vaše prostředí!

Zjistit více o kurzu „Linuxový administrátor“

Zdroj: habr.com