ProHoster > Blog > Bestjoer > Docker Compose: fan ûntwikkeling oant produksje

Docker Compose: fan ûntwikkeling oant produksje

Oersetting fan 'e podcast-transkripsje taret yn ôfwachting fan it begjin fan' e kursus "Linux behearder"

Docker Compose: fan ûntwikkeling oant produksje

Docker Compose is in geweldig ark foar it meitsjen fan in wurkjende
omjouwing foar de stapel brûkt yn jo applikaasje. It lit jo definiearje
elke komponint fan jo applikaasje, nei in dúdlike en ienfâldige syntaksis yn YAML-
triemmen.

Mei de komst fan docker komponearje v3 dizze YAML-bestannen kinne direkt brûkt wurde yn 'e produksjeomjouwing as jo wurkje mei
kluster Docker swarm.

Mar betsjut dit dat jo itselde docker-compose-bestân kinne brûke yn
ûntwikkelingsproses en yn 'e produksjeomjouwing? Of brûk itselde bestân foar
staging? No, yn 't algemien, ja, mar foar dizze funksjonaliteit hawwe wy it folgjende nedich:

  • Fariabele ynterpolaasje: mei help fan omjouwingsfariabelen foar guon
    wearden dy't feroarje yn elke omjouwing.
  • Konfiguraasje oerskriuwe: mooglikheid om in twadde (of elke
    in oare folgjende) docker-compose-bestân dat wat sil feroarje oangeande
    earst, en docker compose sil soargje foar it gearfoegjen fan beide bestannen.

Ferskillen tusken ûntwikkeling en produksje triemmen

Tidens ûntwikkeling sille jo wierskynlik koadewizigingen wolle kontrolearje yn
echte tiid. Om dit te dwaan, wurdt normaal it folume mei de boarnekoade ynstalleare
kontener dy't runtime foar jo applikaasje befettet. Mar foar in produksjeomjouwing
Dizze metoade is net geskikt.

Yn produksje hawwe jo in kluster mei in protte knopen, en it folume is lokaal
relatyf oan it knooppunt wêrop jo kontener (of tsjinst) rint, dus jo dogge it net
jo kinne de boarnekoade mount sûnder komplekse operaasjes dy't omfetsje
koade syngronisaasje, sinjalen, etc.

Ynstee wolle wy normaal in ôfbylding meitsje mei in spesifike ferzje fan jo koade.
It is gewoanlik om it te markearjen mei de passende tag (jo kinne semantyk brûke
ferzje of in oar systeem nei jo goedtinken).

Konfiguraasje oerskriuwe

Sjoen de ferskillen en dat jo ôfhinklikens kinne ferskille yn senario's
ûntwikkeling en produksje, it is dúdlik dat wy sille nedich ferskillende konfiguraasje triemmen.

Docker compose stipet it gearfoegjen fan ferskate compose-bestannen nei
krije de definitive konfiguraasje. Hoe't dit wurket kin sjoen wurde yn it foarbyld:

$ 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

Lykas sein, stipet docker compose it kombinearjen fan meardere komposysjes -
bestannen, dit kinne jo ferskate parameters yn 'e twadde triem oerskriuwe. Bygelyks:

$ 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

Dizze syntaksis is net hiel handich tidens ûntwikkeling, doe't it kommando
sil in protte kearen dien wurde moatte.

Gelokkich siket docker compose automatysk nei in spesjaal bestân neamd
docker-compose.override.yml wearden te oerskriuwen docker-compose.yml. As
omneame it twadde bestân, jo krije itselde resultaat, allinich mei it orizjinele kommando:

$ 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

Okee, dat is makliker te ûnthâlden.

Ynterpolaasje fan fariabelen

Stipe foar konfiguraasjebestannen ynterpolaasje
fariabelen en standertwearden. Dat is, jo kinne it folgjende dwaan:

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

En as jo dogge docker-compose build (of push) sûnder omjouwingsfariabele
$MY_SERVICE_VERSION, sil de wearde brûkt wurde lêstemar as jo ynstelle
de wearde fan 'e omjouwingsfariabele foar it bouwen, it sil brûkt wurde by it bouwen of triuwen
oan it register private.registry.mine.

Myn prinsipes

De oanpakken dy't foar my wurkje kinne ek foar jo wurkje. Ik folgje dizze
ienfâldige regels:

  • Al myn stapels foar produksje, ûntwikkeling (of oare omjouwings) wurde definiearre troch
    docker-compose triemmen
  • Konfiguraasjebestannen nedich om al myn omjouwings safolle mooglik te dekken
    foarkomme duplikaasje.
  • Ik haw ien ienfâldich kommando nedich om yn elke omjouwing te wurkjen.
  • De wichtichste konfiguraasje wurdt definiearre yn de triem docker-compose.yml.
  • Omjouwingsfariabelen wurde brûkt om ôfbyldingstags of oare te definiearjen
    fariabelen dy't ferskille kinne fan omjouwing ta omjouwing (staging, yntegraasje,
    produksje).
  • De wearden fan produksjefariabelen wurde brûkt as wearden foar
    standert, dit minimizes de risiko 's as de steapel wurdt lansearre yn produksje sûnder
    set omjouwingsfariabele.
  • Om in tsjinst te begjinnen yn in produksjeomjouwing, brûk it kommando docker stack deploy - compose-bestân docker-compose.yml -with-registry-auth my-stack-name.
  • De wurkomjouwing wurdt begon mei it kommando Docker-komponearje oant -d.

Litte wy nei in ienfâldich foarbyld sjen.

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

Ik kin brûke docker-komponearje (docker-komponearje)om de stapel yn te rinnen
ûntwikkelingsmodus mei boarnekoade monteard yn /projekt/src.

Ik kin dizze deselde bestannen brûke yn produksje! En ik koe perfoarst brûke
deselde triem docker-compose.yml foar staging. Om dit út te wreidzjen nei
produksje, Ik moat gewoan bouwe en stjoer de ôfbylding mei in foarôf definiearre tag
op it CI-stadium:

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

Yn produksje kin dit wurde útfierd mei de folgjende kommando's:

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

En as jo itselde dwaan wolle op it poadium, moatte jo gewoan definiearje
needsaaklike omjouwingsfariabelen foar wurkjen yn 'e staging-omjouwing:

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 gefolch hawwe wy twa ferskillende docker-compose-bestannen brûkt, dy't sûnder
Dûbele konfiguraasjes kinne brûkt wurde foar elke omjouwing dy't jo hawwe!

Learje mear oer de kursus "Linux behearder"

Boarne: www.habr.com

Add a comment