ProHoster > Blog > Uprava > Docker Compose: od razvoja do proizvodnje

Docker Compose: od razvoja do proizvodnje

Prevod transkripcije podcasta pripravljen v pričakovanju začetka tečaja "Linux Administrator"

Docker Compose: od razvoja do proizvodnje

Docker Compose je neverjetno orodje za ustvarjanje delujočega
okolje za sklad, uporabljen v vaši aplikaciji. Omogoča vam definiranje
vsako komponento vaše aplikacije, ki sledi jasni in preprosti sintaksi YAML-
datoteke.

S prihodom leta docker compose v3 te datoteke YAML je mogoče uporabiti neposredno v produkcijskem okolju, ko delate z njimi
grozd Docker roj.

Toda ali to pomeni, da lahko uporabite isto datoteko docker-compose v
razvojnem procesu in v proizvodnem okolju? Ali pa uporabite isto datoteko za
uprizoritev? No, na splošno ja, vendar za to funkcionalnost potrebujemo naslednje:

  • Interpolacija spremenljivk: uporaba spremenljivk okolja za nekatere
    vrednote, ki se spreminjajo v vsakem okolju.
  • Preglasitev konfiguracije: možnost definiranja drugega (ali katerega koli
    še eno naslednjo) docker-compose datoteko, ki bo nekaj spremenila glede
    najprej, docker compose pa bo poskrbel za združitev obeh datotek.

Razlike med razvojnimi in produkcijskimi datotekami

Med razvojem boste najverjetneje želeli preveriti spremembe kode
v realnem času. Če želite to narediti, je običajno nameščen nosilec z izvorno kodo
vsebnik, ki vsebuje čas izvajanja za vašo aplikacijo. Ampak za proizvodno okolje
Ta metoda ni primerna.

V proizvodnji imate gručo s številnimi vozlišči, obseg pa je lokalni
glede na vozlišče, na katerem se izvaja vaš vsebnik (ali storitev), tako da ne
lahko namestite izvorno kodo brez zapletenih operacij, ki vključujejo
kodna sinhronizacija, signali itd.

Namesto tega običajno želimo ustvariti sliko z določeno različico vaše kode.
Običajno ga označite z ustrezno oznako (lahko uporabite semantično
različic ali drug sistem po vaši presoji).

Preglasitev konfiguracije

Glede na razlike in da se vaše odvisnosti lahko razlikujejo v scenarijih
razvoj in proizvodnjo, je jasno, da bomo potrebovali različne konfiguracijske datoteke.

Docker compose podpira združevanje različnih datotek za sestavljanje v
dobite končno konfiguracijo. Kako to deluje, je razvidno iz primera:

$ 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

Kot rečeno, docker compose podpira kombiniranje več sestavljanj -
datoteke, vam to omogoča preglasitev različnih parametrov v drugi datoteki. Na primer:

$ 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

Ta sintaksa ni zelo priročna med razvojem, ko ukaz
bo treba opraviti večkrat.

Na srečo docker compose samodejno poišče posebno datoteko, imenovano
docker-compose.override.yml za preglasitev vrednosti docker-compose.yml. Če
preimenujte drugo datoteko, dobite enak rezultat, le z uporabo izvirnega ukaza:

$ 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

V redu, to si je lažje zapomniti.

Interpolacija spremenljivk

Podpora za konfiguracijske datoteke interpolacija
spremenljivke in privzete vrednosti. To pomeni, da lahko storite naslednje:

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

In če to storite docker-compose build (ali push) brez spremenljivke okolja
$MY_SERVICE_VERSION, bo uporabljena vrednost Zadnjiče pa nastavite
vrednost spremenljivke okolja pred gradnjo, bo uporabljena pri gradnji ali potiskanju
v register private.registry.mine.

Moja načela

Pristopi, ki delujejo zame, bodo morda delovali tudi pri vas. Sledim tem
preprosta pravila:

  • Vsi moji skladi za proizvodnjo, razvoj (ali druga okolja) so definirani prek
    docker-compose datoteke
  • Konfiguracijske datoteke, potrebne za pokrivanje vseh mojih okolij, kolikor je le mogoče
    izogibajte se podvajanju.
  • Za delo v vsakem okolju potrebujem en preprost ukaz.
  • Glavna konfiguracija je definirana v datoteki docker-compose.yml.
  • Spremenljivke okolja se uporabljajo za definiranje oznak slik ali drugega
    spremenljivke, ki se lahko razlikujejo od okolja do okolja (uprizoritev, integracija,
    proizvodnja).
  • Vrednosti proizvodnih spremenljivk se uporabljajo kot vrednosti za
    privzeto to zmanjša tveganja, če je sklad zagnan v produkciji brez
    nastavite spremenljivko okolja.
  • Za zagon storitve v produkcijskem okolju uporabite ukaz docker stack deploy - compose-file docker-compose.yml -with-registry-auth my-stack-name.
  • Delovno okolje se zažene z ukazom docker-compose up -d.

Poglejmo preprost primer.

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

Lahko uporabim docker-compose (docker-compose up)za zagon sklada
razvojni način z nameščeno izvorno kodo /projekt/src.

Te iste datoteke lahko uporabim v proizvodnji! In zagotovo bi lahko uporabil
isto datoteko docker-compose.yml za uprizoritev. Da bi to razširili na
proizvodnje, moram samo zgraditi in poslati sliko z vnaprej določeno oznako
na stopnji CI:

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

V proizvodnji je to mogoče zagnati z naslednjimi ukazi:

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

In če želite isto narediti na odru, se morate samo definirati
potrebne spremenljivke okolja za delo v uprizoritvenem okolju:

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

Posledično smo uporabili dve različni datoteki za sestavljanje dockerja, ki brez
Podvojene konfiguracije je mogoče uporabiti za katero koli okolje, ki ga imate!

Izvedite več o tečaju "Linux Administrator"

Vir: www.habr.com

Dodaj komentar