Docker Compose: od vývoje po výrobu

Překlad přepisu podcastu připraveného v očekávání začátku kurzu "Správce Linuxu"

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

S příchodem docker compose v3 tyto soubory YAML lze při práci používat přímo v produkčním prostředí
shluk Docker roj.

Znamená to však, že můžete použít stejný soubor docker-compose v
vývojový proces a výrobní prostředí? Nebo použijte stejný soubor pro
inscenace? Obecně ano, ale pro takovou funkci potřebujeme následující:

• Interpolace proměnných: použití proměnných prostředí pro některé
  hodnoty, které se v každém prostředí mění.
• Přepsání konfigurace: možnost definovat sekundu (nebo jakoukoli
  další následný) soubor docker-compose, který něco změní
  první a docker compose se postará o sloučení obou souborů.

Rozdíly mezi vývojovými a produkčními soubory

Během vývoje budete s největší pravděpodobností chtít zkontrolovat změny kódu v
režim v reálném čase. K tomu je obvykle připojen svazek se zdrojovým kódem
kontejner, který obsahuje běhové prostředí vaší aplikace. Ale pro produkční prostředí
tento způsob není vhodný.

V produkci máte víceuzlový cluster a svazek je lokální
vzhledem k hostiteli, na kterém váš kontejner (nebo služba) běží, takže ne
můžete připojit zdrojový kód bez složitých operací, které zahrnují
synchronizace kódu, signály atd.

Místo toho obvykle chceme vytvořit obrázek s konkrétní verzí vašeho kódu.
Je obvyklé jej označit příslušnou značkou (můžete použít sémantický
verzování nebo jiný systém dle vašeho výběru).

Přepsání konfigurace

Vzhledem k rozdílům a tomu, že se vaše závislosti mohou ve scénářích lišit
vývoje a výroby, je jasné, že budeme potřebovat různé konfigurační soubory.

Docker compose podporuje slučování různých souborů pro psaní
získat konečnou konfiguraci. Jak to funguje, je 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  | < 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

Jak již bylo řečeno, docker compose podporuje sloučení několika
soubory, to vám umožní přepsat různé možnosti ve 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  | < 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

Tato syntaxe není příliš vhodná v procesu vývoje, kdy příkaz
je třeba provést vícekrát.

Naštěstí docker compose automaticky hledá speciální soubor s názvem
docker-compose.override.yml přepsat hodnoty docker-compose.yml. Pokud
přejmenujte druhý soubor, získáte stejný výsledek, pouze 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  | < 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

Dobře, to se pamatuje snadněji.

Variabilní interpolace

Podpora konfiguračních souborů interpolace
proměnné a výchozí hodnoty. To znamená, že můžete provést následující:

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

A pokud ano sestavení docker-compose (nebo push) bez proměnné prostředí
$MY_SERVICE_VERSION, bude použita hodnota posledníale pokud nastavíte
hodnota proměnné prostředí před sestavením, bude použita při sestavování nebo tlačení
zaregistrovat se soukromý.registr.moje.

Moje zásady

Pro vás mohou být užitečné přístupy, které jsou pro mě pohodlné. Řídím se tímto
jednoduchá pravidla:

• Všechny mé zásobníky pro produkci, vývoj (nebo jiná prostředí) jsou definovány prostřednictvím
  docker-compose soubory.
• Konfigurační soubory potřebné k pokrytí všech mých prostředí, max.
  vyhnout se duplicitě.
• Potřebuji jeden jednoduchý příkaz pro práci v každém prostředí.
• Hlavní konfigurace je definována v souboru docker-compose.yml.
• Proměnné prostředí se používají k definování značek obrázků nebo jiných
  proměnné, které se mohou měnit z prostředí do prostředí (staging, integrace,
  Výroba).
• Hodnoty proměnných pro výrobu se používají jako hodnoty podle
  ve výchozím nastavení to minimalizuje rizika, pokud zásobník spustíte v produkci bez
  nastavit proměnnou prostředí.
• Chcete-li spustit službu v produkčním prostředí, použijte příkaz nasazení zásobníku dockeru - skládání-souboru docker-compose.yml - s-registry-auth můj-název zásobníku.
• Pracovní prostředí se spustí příkazem docker-složte nahoru -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
...

můžu použít docker-compose (docker-compose up)spustit zásobník na
vývojový režim s nainstalovaným zdrojovým kódem /projekt/src.

Mohu použít stejné soubory ve výrobě! A přesně bych mohl použít
stejný soubor docker-compose.yml pro inscenaci. Chcete-li to rozšířit
výroba, potřebuji pouze sestavit a odeslat obrázek 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 totéž udělat na pódiu, stačí definovat
potřebné proměnné prostředí pro práci v pracovním prostředí:

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

V důsledku toho jsme použili dva různé soubory docker-compose, které bez
duplicitní konfigurace lze použít pro kterékoli z vašich prostředí!

Zjistěte více o kurzu "Správce Linuxu"

Zdroj: www.habr.com