ProHoster > Blog > Adminisztráció > Docker Compose: a fejlesztéstől a gyártásig

Docker Compose: a fejlesztéstől a gyártásig

A tanfolyam kezdetére készült podcast-átirat fordítása "Linux rendszergazda"

Docker Compose: a fejlesztéstől a gyártásig

A Docker Compose egy csodálatos eszköz a munka létrehozásához
környezetet az alkalmazásban használt veremhez. Lehetővé teszi a definiálást
az alkalmazás minden egyes összetevője világos és egyszerű szintaxist követve YAML-
fájlokat.

Adventjével docker compose v3 ezek a YAML fájlok közvetlenül használhatók az éles környezetben, amikor velük dolgozik
fürt Docker Raj.

De ez azt jelenti, hogy ugyanazt a docker-compose fájlt használhatja
fejlesztési folyamatban és a gyártási környezetben? Vagy használja ugyanazt a fájlt
színrevitel? Nos, általában igen, de ehhez a funkcióhoz a következőkre van szükségünk:

  • Változó interpoláció: környezeti változók használata bizonyos esetekben
    az egyes környezetben változó értékeket.
  • Konfiguráció felülbírálása: lehetőség egy második (vagy bármely más) meghatározására
    egy másik későbbi) docker-compose fájl, amely valamit megváltoztat
    először, és a docker compose gondoskodik a két fájl egyesítéséről.

A fejlesztési és a gyártási fájlok közötti különbségek

A fejlesztés során valószínűleg ellenőrizni fogja a kódmódosításokat
valós idő. Ehhez általában a forráskódot tartalmazó kötetet kell beilleszteni
tároló, amely az alkalmazás futási idejét tartalmazza. De termelési környezetre
Ez a módszer nem megfelelő.

A termelésben van egy fürt sok csomóponttal, és a kötet helyi
ahhoz a csomóponthoz képest, amelyen a tároló (vagy szolgáltatás) fut, tehát nem
felcsatolhatja a forráskódot olyan bonyolult műveletek nélkül, amelyek magukban foglalják
kódszinkronizálás, jelek stb.

Ehelyett általában egy képet szeretnénk létrehozni a kód egy adott verziójával.
Szokásos a megfelelő címkével jelölni (használhat szemantikát
verziószámítás vagy más rendszer az Ön belátása szerint).

Konfiguráció felülbírálása

Tekintettel a különbségekre és arra, hogy a függőségei forgatókönyvenként eltérőek lehetnek
fejlesztés és gyártás, egyértelmű, hogy különböző konfigurációs fájlokra lesz szükségünk.

A Docker Compose támogatja a különböző szerkesztési fájlok összevonását
megkapja a végső konfigurációt. Hogy ez hogyan működik, az a példán látható:

$ 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

Mint mondtam, a docker kompozíció támogatja több kompozíció kombinálását -
fájlokat, ez lehetővé teszi a különböző paraméterek felülbírálását a második fájlban. Például:

$ 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

Ez a szintaxis nem túl kényelmes a fejlesztés során, amikor a parancsot
sokszor meg kell majd tenni.

Szerencsére a docker compose automatikusan megkeres egy speciális nevű fájlt
docker-compose.override.yml értékek felülbírálásához dokkoló-compose.yml... Ha
nevezze át a második fájlt, ugyanazt az eredményt kapja, csak az eredeti paranccsal:

$ 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

Oké, ezt könnyebb megjegyezni.

Változók interpolációja

Konfigurációs fájlok támogatása interpoláció
változók és alapértelmezett értékeket. Vagyis a következőket teheti:

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

És ha igen docker-compose build (vagy push) környezeti változó nélkül
$MY_SERVICE_VERSION, az érték kerül felhasználásra legutolsóde ha beállítod
a környezeti változó értéke az építés előtt, akkor ez építéskor vagy tolásakor kerül felhasználásra
a nyilvántartásba privát.nyilvántartó.enyém.

Az elveim

Azok a megközelítések, amelyek nálam működnek, neked is beváltak. ezeket követem
egyszerű szabályok:

  • Az összes termelési, fejlesztési (vagy más környezeti) verem ezen keresztül van meghatározva
    docker-compose fájlokat
  • A konfigurációs fájlok szükségesek ahhoz, hogy a lehető legnagyobb mértékben lefedjék az összes környezetemet
    kerülje a párhuzamosságot.
  • Minden környezetben egy egyszerű parancsra van szükségem.
  • A fő konfiguráció a fájlban van meghatározva dokkoló-compose.yml.
  • A környezeti változók képcímkék vagy egyéb definiálására szolgálnak
    változók, amelyek környezetenként változhatnak (staging, integration,
    Termelés).
  • A termelési változók értékei értékként használatosak
    alapértelmezés szerint ez minimálisra csökkenti a kockázatokat, ha a verem anélkül indul élesben
    környezeti változó beállítása.
  • A szolgáltatás éles környezetben történő indításához használja a parancsot docker verem telepítése - compose-file docker-compose.yml -with-registry-auth my-stack-name.
  • A munkakörnyezet a paranccsal indul el docker-compose -d.

Nézzünk egy egyszerű példát.

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

tudom használni dokkoló-kompozíció (docker-kompozíció)hogy befusson a verem
fejlesztési mód a forráskóddal /projekt/src.

Ugyanezeket a fájlokat használhatom a termelésben is! És biztosan hasznát vehetném
ugyanaz a fájl dokkoló-compose.yml színrevitelére. Ennek kiterjesztéséhez
gyártás, csak meg kell építenem és elküldenem a képet egy előre meghatározott címkével
CI szakaszban:

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

Éles környezetben ez a következő parancsokkal futtatható:

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

És ha ugyanezt a színpadon is meg akarja tenni, akkor csak definiálnia kell
a színpadi környezetben végzett munkához szükséges környezeti változók:

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

Ennek eredményeként két különböző docker-compose fájlt használtunk, amelyek nélkül
A duplikált konfigurációk bármilyen környezetben használhatók!

Tudjon meg többet a tanfolyamról "Linux rendszergazda"

Forrás: will.com

Hozzászólás