ProHoster > Blog > Stjórnsýsla > Docker Compose: frá þróun til framleiðslu

Docker Compose: frá þróun til framleiðslu

Þýðing á podcast umritun unnin í aðdraganda upphafs námskeiðs "Linux stjórnandi"

Docker Compose: frá þróun til framleiðslu

Docker Compose er ótrúlegt tól til að búa til vinnu
umhverfi fyrir stafla sem notaður er í forritinu þínu. Það gerir þér kleift að skilgreina
hvern hluta forritsins þíns, eftir skýrri og einföldum setningafræði YAML-
skrár.

Með tilkomu docker compose v3 þessar YAML skrár er hægt að nota beint í framleiðsluumhverfi þegar unnið er með
þyrping Docker Sveimur.

En þýðir þetta að þú getur notað sömu docker-compose skrána í
þróunarferli og í framleiðsluumhverfi? Eða notaðu sömu skrána fyrir
sviðsetning? Jæja, almennt séð, já, en fyrir þessa virkni þurfum við eftirfarandi:

  • Variable interpolation: að nota umhverfisbreytur fyrir suma
    gildi sem breytast í hverju umhverfi.
  • Hnekkt stillingar: geta til að skilgreina sekúndu (eða hvaða
    önnur síðari) docker-compose skrá sem mun breyta einhverju varðandi
    fyrst, og docker compose mun sjá um að sameina báðar skrárnar.

Mismunur á þróunar- og framleiðsluskrám

Meðan á þróun stendur muntu líklegast vilja athuga kóðabreytingar í
alvöru tími. Til að gera þetta er venjulega hljóðstyrkurinn með frumkóðann settur inn
ílát sem inniheldur keyrslutíma fyrir forritið þitt. En fyrir framleiðsluumhverfi
Þessi aðferð hentar ekki.

Í framleiðslu ertu með þyrping með mörgum hnútum og rúmmálið er staðbundið
miðað við hnútinn sem ílátið þitt (eða þjónustan) er í gangi á, svo þú gerir það ekki
þú getur tengt frumkóðann án flókinna aðgerða sem innihalda
kóða samstillingu, merki o.fl.

Þess í stað viljum við venjulega búa til mynd með ákveðinni útgáfu af kóðanum þínum.
Venjulegt er að merkja það með viðeigandi merki (þú getur notað merkingarfræði
útgáfu eða annað kerfi að eigin vali).

Hnekkt stillingar

Miðað við muninn og að ósjálfstæði þín geta verið mismunandi í atburðarás
þróun og framleiðslu, það er ljóst að við munum þurfa mismunandi stillingarskrár.

Docker compose styður sameiningu mismunandi textaskráa við
fáðu endanlega uppsetningu. Hvernig þetta virkar má sjá í dæminu:

$ 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

Eins og sagt er, styður docker compose að sameina margar tónsmíðar -
skrár, gerir þetta þér kleift að hnekkja ýmsum breytum í annarri skránni. Til dæmis:

$ 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

Þessi setningafræði er ekki mjög þægileg meðan á þróun stendur, þegar skipunin
þarf að gera oft.

Sem betur fer leitar docker compose sjálfkrafa að sérstakri skrá sem kallast
docker-compose.override.yml að hnekkja gildum Docker-compose.yml. Ef
endurnefna seinni skrána, þú færð sömu niðurstöðu, aðeins með því að nota upprunalegu skipunina:

$ 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

Allt í lagi, það er auðveldara að muna það.

Interpolation af breytum

Stuðningur við stillingarskrár innskot
breytum og sjálfgefin gildi. Það er, þú getur gert eftirfarandi:

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

Og ef þú gerir það docker-compose smíða (eða ýta) án umhverfisbreytu
$MY_SERVICE_VERSION, gildið verður notað Nýjastaen ef þú stillir
gildi umhverfisbreytunnar fyrir byggingu, hún verður notuð þegar byggt er eða ýtt
til skrárinnar einka.skrár.minn.

Meginreglur mínar

Aðferðirnar sem virka fyrir mig gætu virkað fyrir þig líka. Ég fylgist með þessum
einfaldar reglur:

  • Allir staflar mínir fyrir framleiðslu, þróun (eða annað umhverfi) eru skilgreindir í gegnum
    docker-compose skrár
  • Stillingarskrár sem þarf til að ná yfir allt umhverfi mitt, eins mikið og mögulegt er
    forðast tvíverknað.
  • Ég þarf eina einfalda skipun til að vinna í hverju umhverfi.
  • Aðalstillingin er skilgreind í skránni Docker-compose.yml.
  • Umhverfisbreytur eru notaðar til að skilgreina myndmerki eða annað
    breytur sem geta verið mismunandi eftir umhverfi (sviðsetning, samþætting,
    framleiðslu).
  • Gildi framleiðslubreyta eru notuð sem gildi fyrir
    sjálfgefið, þetta lágmarkar áhættuna ef stafla er sett í framleiðslu án
    stilltu umhverfisbreytu.
  • Til að hefja þjónustu í framleiðsluumhverfi skaltu nota skipunina docker stack deploy - semja-skrá docker-compose.yml -with-registry-auth my-stack-name.
  • Vinnuumhverfið er ræst með því að nota skipunina Docker-compose upp -d.

Við skulum líta á einfalt dæmi.

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

Ég get notað docker-compose (docker-compose up)til að keyra bunkann í
þróunarhamur með frumkóða festur í /verkefni/src.

Ég get notað þessar sömu skrár í framleiðslu! Og ég gæti svo sannarlega notað
sama skrá Docker-compose.yml til sviðsetningar. Til að útvíkka þetta til
framleiðslu, ég þarf bara að smíða og senda myndina með fyrirfram skilgreindu tagi
á CI stigi:

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

Í framleiðslu er hægt að keyra þetta með eftirfarandi skipunum:

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

Og ef þú vilt gera það sama á sviðinu þarftu bara að skilgreina
nauðsynlegar umhverfisbreytur til að vinna í sviðsetningarumhverfinu:

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

Fyrir vikið notuðum við tvær mismunandi docker-compose skrár, sem án
Hægt er að nota tvíteknar stillingar fyrir hvaða umhverfi sem þú hefur!

Kynntu þér námskeiðið nánar "Linux stjórnandi"

Heimild: www.habr.com

Bæta við athugasemd