„Docker Compose“: nuo kūrimo iki gamybos

Podcast'o transkripcijos, parengtos laukiant kurso pradžios, vertimas "Linux administratorius"

„Docker Compose“ yra puikus įrankis darbui sukurti
jūsų programoje naudojamo kamino aplinka. Tai leidžia apibrėžti
kiekvieną programos komponentą, vadovaudamiesi aiškia ir paprasta sintaksė YAML-
failus.

Atsiradus Docker Compose v3 šiuos YAML failus galima naudoti tiesiogiai gamybinėje aplinkoje dirbant su
klasteris Dockerio spiečius.

Bet ar tai reiškia, kad galite naudoti tą patį „Docker“ kūrimo failą
kūrimo procese ir gamybos aplinkoje? Arba naudokite tą patį failą
pastatymas? Na, apskritai, taip, bet šiai funkcijai mums reikia šių dalykų:

• Kintamųjų interpoliacija: kai kuriems naudojant aplinkos kintamuosius
  vertybes, kurios keičiasi kiekvienoje aplinkoje.
• Konfigūracijos nepaisymas: galimybė apibrėžti sekundę (arba bet kurią
  kitas paskesnis) docker-compose failas, kuris kažką pakeis
  pirma, o docker compose pasirūpins abiejų failų sujungimu.

Kūrimo ir gamybos failų skirtumai

Kurdami greičiausiai norėsite patikrinti kodo pakeitimus
realiu laiku. Norėdami tai padaryti, paprastai įmontuojamas tomas su šaltinio kodu
konteineris, kuriame yra jūsų programos vykdymo laikas. Bet gamybos aplinkai
Šis metodas netinka.

Gamyboje turite klasterį su daugybe mazgų, o apimtis yra vietinė
palyginti su mazgu, kuriame veikia jūsų sudėtinis rodinys (arba paslauga), todėl to nedarote
galite prijungti šaltinio kodą be sudėtingų operacijų, kurios apima
kodų sinchronizavimas, signalai ir kt.

Vietoj to dažniausiai norime sukurti vaizdą su konkrečia jūsų kodo versija.
Įprasta jį pažymėti atitinkama žyma (galite naudoti semantinę
versijų kūrimas arba kita jūsų nuožiūra sistema).

Konfigūracijos nepaisymas

Atsižvelgiant į skirtumus ir į tai, kad jūsų priklausomybės gali skirtis pagal scenarijus
kūrimas ir gamyba, aišku, kad mums reikės skirtingų konfigūracijos failų.

„Docker Compose“ palaiko skirtingų kūrimo failų sujungimą
gauti galutinę konfigūraciją. Kaip tai veikia, galima pamatyti pavyzdyje:

$ 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

Kaip minėta, „Docker“ komponavimo atramos, derinančios kelias kompozicijas -
failus, tai leidžia nepaisyti įvairių parametrų antrajame faile. Pavyzdžiui:

$ 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

Ši sintaksė nėra labai patogi kūrimo metu, kai komanda
reikės daryti daug kartų.

Laimei, „Docker Compose“ automatiškai ieško specialaus failo, vadinamo
docker-compose.override.yml nepaisyti vertybių docker-compose.yml. Jei
pervardykite antrąjį failą, gausite tą patį rezultatą, tik naudodami pradinę komandą:

$ 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

Gerai, tai lengviau atsiminti.

Kintamųjų interpoliacija

Konfigūracijos failų palaikymas interpoliacija
kintamieji ir numatytosios reikšmės. Tai yra, galite atlikti šiuos veiksmus:

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

O jei darai statyti (arba stumti) be aplinkos kintamojo
$MY_SERVICE_VERSION, bus naudojama vertė naujausiasbet jei nustatysite
aplinkos kintamojo vertė prieš statant, jis bus naudojamas statant ar stumiant
į registrą privatus.registras.mano.

Mano principai

Man tinkantys metodai gali būti naudingi ir jums. Aš vadovaujuosi šiais
paprastos taisyklės:

• Visos mano gamybos, kūrimo (ar kitos aplinkos) krūvos yra apibrėžtos
  docker-komponuoti failus
• Konfigūracijos failai, reikalingi, kad apimtų visas mano aplinkas, kiek įmanoma
  vengti dubliavimosi.
• Man reikia vienos paprastos komandos, kad galėčiau dirbti kiekvienoje aplinkoje.
• Pagrindinė konfigūracija yra apibrėžta faile docker-compose.yml.
• Aplinkos kintamieji naudojami vaizdų žymoms ar kt
  kintamieji, kurie gali skirtis įvairiose aplinkose (pastatymas, integravimas,
  gamyba).
• Gamybos kintamųjų reikšmės naudojamos kaip reikšmės
  pagal numatytuosius nustatymus tai sumažina riziką, jei dėklas pradedamas gaminti be
  nustatyti aplinkos kintamąjį.
• Norėdami pradėti paslaugą gamybos aplinkoje, naudokite komandą docker stack deploy - sukurti failą docker-compose.yml -with-registry-auth my-stack-name.
• Darbo aplinka paleidžiama naudojant komandą docker-sudaryti -d.

Pažiūrėkime į paprastą pavyzdį.

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

Galiu naudoti docker-sudaryti (dokeris-komponuoti)kad įstumtumėte krūvą
kūrimo režimas su įmontuotu šaltinio kodu /projektas/src.

Tuos pačius failus galiu naudoti gamyboje! Ir tikrai galėčiau pasinaudoti
tas pats failas docker-compose.yml pastatymui. Norėdami tai išplėsti iki
gamyba, man tereikia sukurti ir išsiųsti vaizdą su iš anksto nustatyta žyma
CI etape:

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

Gamyboje tai galima paleisti naudojant šias komandas:

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

O jei nori tą patį daryti scenoje, tereikia apsibrėžti
būtini aplinkos kintamieji darbui sustojimo aplinkoje:

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

Dėl to naudojome du skirtingus dokerio kūrimo failus, kurių be
Pasikartojančios konfigūracijos gali būti naudojamos bet kurioje jūsų aplinkoje!

Sužinokite daugiau apie kursą "Linux administratorius"

Šaltinis: www.habr.com