Docker Compose: van ontwikkeling tot produksie

Vertaling van die podcast-transkripsie voorberei in afwagting van die begin van die kursus "Linux Administrateur"

Docker Compose is 'n wonderlike hulpmiddel om 'n werkende
omgewing vir die stapel wat in jou toepassing gebruik word. Dit laat jou toe om te definieer
elke komponent van jou toepassing, volgens 'n duidelike en eenvoudige sintaksis in YAML-
lêers.

Met die koms van docker compose v3 hierdie YAML-lêers kan direk in die produksie-omgewing gebruik word wanneer daar gewerk word
cluster Docker -swerm.

Maar beteken dit dat jy dieselfde docker-compose-lêer kan gebruik in
ontwikkelingsproses en in die produksie-omgewing? Of gebruik dieselfde lêer vir
opvoering? Wel, in die algemeen, ja, maar vir hierdie funksionaliteit het ons die volgende nodig:

• Veranderlike interpolasie: gebruik omgewingsveranderlikes vir sommige
  waardes wat in elke omgewing verander.
• Konfigurasie ignoreer: vermoë om 'n tweede (of enige
  'n ander daaropvolgende) docker-compose-lêer wat iets aangaande
  eerstens, en docker compose sal sorg vir die samevoeging van beide lêers.

Verskille tussen ontwikkeling en produksie lêers

Tydens ontwikkeling sal jy heel waarskynlik kodeveranderings in wil nagaan
ware tyd. Om dit te doen, word gewoonlik die volume met die bronkode in gemonteer
houer wat looptyd vir jou toepassing bevat. Maar vir 'n produksie-omgewing
Hierdie metode is nie geskik nie.

In produksie het jy 'n groep met baie nodusse, en die volume is plaaslik
relatief tot die nodus waarop jou houer (of diens) loop, so jy doen dit nie
jy kan die bronkode monteer sonder komplekse bewerkings wat insluit
kode sinchronisasie, seine, ens.

In plaas daarvan wil ons gewoonlik 'n prent skep met 'n spesifieke weergawe van jou kode.
Dit is gebruiklik om dit met die toepaslike merker te merk (jy kan semanties gebruik
weergawe of 'n ander stelsel na u goeddunke).

Konfigurasie ignoreer

Gegewe die verskille en dat jou afhanklikhede in scenario's kan verskil
ontwikkeling en produksie, is dit duidelik dat ons verskillende konfigurasielêers sal benodig.

Docker compose ondersteun die samevoeging van verskillende opstellêers na
verkry die finale konfigurasie. Hoe dit werk, kan in die voorbeeld gesien word:

$ 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

Soos gesê, ondersteun docker compose die kombinasie van veelvuldige composes -
lêers, dit laat jou toe om verskeie parameters in die tweede lêer te ignoreer. Byvoorbeeld:

$ 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

Hierdie sintaksis is nie baie gerieflik tydens ontwikkeling, wanneer die opdrag
sal baie keer gedoen moet word.

Gelukkig soek docker compose outomaties na 'n spesiale lêer genaamd
docker-compose.override.yml waardes te ignoreer Docker-compose.yml. indien
hernoem die tweede lêer, jy kry dieselfde resultaat, net met die oorspronklike opdrag:

$ 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

Goed, dis makliker om te onthou.

Interpolasie van veranderlikes

Ondersteuning van konfigurasielêers interpolasie
veranderlikes en verstekwaardes. Dit wil sê, jy kan die volgende doen:

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

En as jy dit doen docker-compose bou (of druk) sonder omgewingsveranderlike
$MY_SERVICE_VERSION, sal die waarde gebruik word jongstemaar as jy stel
die waarde van die omgewingsveranderlike voor die bou, sal dit gebruik word wanneer jy bou of stoot
na die register private.register.myn.

My beginsels

Die benaderings wat vir my werk, kan ook vir jou werk. Ek volg hierdie
eenvoudige reëls:

• Al my stapels vir produksie, ontwikkeling (of ander omgewings) word deur gedefinieer
  docker-compose lêers
• Konfigurasielêers benodig om al my omgewings soveel as moontlik te dek
  vermy duplisering.
• Ek het een eenvoudige opdrag nodig om in elke omgewing te werk.
• Die hoofkonfigurasie word in die lêer gedefinieer Docker-compose.yml.
• Omgewingsveranderlikes word gebruik om beeldmerkers of ander te definieer
  veranderlikes wat van omgewing tot omgewing kan verskil (verstelling, integrasie,
  produksie).
• Die waardes van produksieveranderlikes word gebruik as waardes vir
  by verstek verminder dit die risiko's as die stapel sonder produksie bekendgestel word
  omgewingsveranderlike stel.
• Om 'n diens in 'n produksie-omgewing te begin, gebruik die opdrag docker-stapel ontplooi - komstel-lêer docker-compose.yml -met-register-bevoegdheid my-stapel-naam.
• Die werksomgewing word begin deur die opdrag te gebruik docker-opstel -d.

Kom ons kyk na 'n eenvoudige voorbeeld.

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

Ek kan gebruik docker-compose (docker-compose up)om die stapel in te hardloop
ontwikkelingsmodus met bronkode gemonteer in /projek/src.

Ek kan dieselfde lêers in produksie gebruik! En ek kan beslis gebruik
dieselfde lêer Docker-compose.yml vir opvoering. Om dit uit te brei na
produksie, moet ek net die prent bou en stuur met 'n voorafbepaalde merker
op die CI stadium:

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

In produksie kan dit uitgevoer word deur die volgende opdragte te gebruik:

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

En as jy dieselfde op die verhoog wil doen, moet jy net definieer
nodige omgewingsveranderlikes om in die opstelomgewing te werk:

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

As gevolg hiervan het ons twee verskillende docker-compose-lêers gebruik, wat sonder
Duplikaat konfigurasies kan gebruik word vir enige omgewing wat jy het!

Kom meer te wete oor die kursus "Linux Administrateur"

Bron: will.com