Docker Compose: arendusest tootmiseni

Kursuse alguse ootuses koostatud podcasti transkriptsiooni tõlge "Linuxi administraator"

Docker Compose on suurepärane tööriist töölaua loomiseks
keskkond teie rakenduses kasutatava virna jaoks. See võimaldab teil määratleda
iga teie rakenduse komponent, järgides selget ja lihtsat süntaksit YAML-
failid.

Koos tulekuga Docker Compose v3 neid YAML-faile saab nendega töötamisel kasutada otse tootmiskeskkonnas
klaster Dockeri sülem.

Kuid kas see tähendab, et saate kasutada sama dokkeri koostamise faili
arendusprotsess ja tootmiskeskkond? Või kasutage sama faili
lavastus? Noh, üldiselt jah, kuid sellise funktsiooni jaoks vajame järgmist:

• Muutujate interpoleerimine: mõne jaoks keskkonnamuutujate kasutamine
  väärtused, mis igas keskkonnas muutuvad.
• Konfiguratsiooni alistamine: võimalus määratleda sekund (või mis tahes
  teine ​​järeltegevus) docker-compose fail, mis muudab midagi
  esimene ja docker compose hoolitseb mõlema faili ühendamise eest.

Erinevused arendus- ja tootmisfailide vahel

Tõenäoliselt soovite arenduse ajal kontrollida koodimuudatusi
reaalajas režiim. Tavaliselt ühendatakse selleks lähtekoodiga helitugevus
konteiner, mis sisaldab teie rakenduse käitusaega. Aga tootmiskeskkonna jaoks
see viis ei sobi.

Tootmises on teil mitmesõlmeline klaster ja maht on kohalik
võrreldes hostiga, millel teie konteiner (või teenus) töötab, nii et te seda ei tee
saate lähtekoodi ühendada ilma keerukate toiminguteta, mis hõlmavad
koodide sünkroniseerimine, signaalid jne.

Selle asemel tahame tavaliselt luua pildi teie koodi konkreetse versiooniga.
See on tavaks märgistada vastava sildiga (võite kasutada semantikat
versioonimine või mõni muu teie valitud süsteem).

Konfiguratsiooni alistamine

Arvestades erinevusi ja seda, et teie sõltuvused võivad stsenaariumides erineda
on selge, et vajame erinevaid konfiguratsioonifaile.

Dockeri koostamine toetab erinevate koostamisfailide liitmist
saada lõplik konfiguratsioon. Kuidas see toimib, saab näha järgmises näites:

$ 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

Nagu öeldud, toetab dockeri koostamine mitme koostamise ühendamist.
failid, see võimaldab teil alistada erinevad valikud teises failis. Näiteks:

$ 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

See süntaks ei ole arendusprotsessis väga mugav, kui käsk
tuleb teha mitu korda.

Õnneks otsib dockeri koostamine automaatselt spetsiaalse faili nimega
docker-compose.override.yml väärtusi alistama docker-compose.yml. Kui
nimetage teine ​​fail ümber, saate sama tulemuse, kasutades ainult algset käsku:

$ 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

Olgu, seda on lihtsam meeles pidada.

Muutujate interpolatsioon

Konfiguratsioonifailide tugi interpoleerimine
muutujad ja vaikeväärtused. See tähendab, et saate teha järgmist.

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

Ja kui teete dokkija koostamine (või lükkamine) ilma keskkonnamuutujata
$MY_SERVICE_VERSION, kasutatakse väärtust hiljemaltaga kui seate
keskkonnamuutuja väärtus enne ehitamist, seda kasutatakse ehitamisel või lükkamisel
registreerida privaatne.register.mine.

Minu põhimõtted

Mulle sobivad lähenemisviisid võivad teile kasulikud olla. Ma järgin seda
lihtsad reeglid:

• Kõik minu tootmis-, arendus- (või muude keskkondade) virnad on määratletud läbi
  docker-koostefailid.
• Kõikide minu keskkondade katmiseks vajalikud konfiguratsioonifailid, max.
  vältida dubleerimist.
• Mul on igas keskkonnas töötamiseks vaja ühte lihtsat käsku.
• Põhikonfiguratsioon on failis määratletud docker-compose.yml.
• Keskkonnamuutujaid kasutatakse pildimärgendite või muu määratlemiseks
  muutujad, mis võivad keskkonnast keskkonda muutuda (lavastamine, integreerimine,
  tootmine).
• Tootmise muutujate väärtusi kasutatakse väärtustena
  vaikimisi minimeerib see riske, kui käivitate virna tootmises ilma
  määrata keskkonnamuutuja.
• Teenuse käivitamiseks tootmiskeskkonnas kasutage käsku dockeri pinu juurutamine - koosta-fail docker-compose.yml - koos-registri-auth minu-pinu-nimi.
• Töökeskkond käivitatakse käsuga docker-compose-d.

Vaatame lihtsat näidet.

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

Ma võin kasutada dokkija koostama (dokkija koostama)virna käivitamiseks
arendusrežiim, millesse on paigaldatud lähtekood /projekt/src.

Saan samu faile tootmises kasutada! Ja ma saaksin täpselt kasutada
sama faili docker-compose.yml lavastamiseks. Selle laiendamiseks
tootmist, pean lihtsalt pildi koos eelmääratletud sildiga koostama ja saatma
CI etapis:

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

Tootmises saab seda käivitada järgmiste käskudega:

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

Ja kui sa tahad sama teha laval, pead lihtsalt defineerima
lavastuskeskkonnas töötamiseks vajalikud keskkonnamuutujad:

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

Selle tulemusel kasutasime kahte erinevat dokkeri koostamise faili, mis ilma
dubleerivaid konfiguratsioone saab kasutada kõigis teie keskkondades!

Lisateavet kursuse kohta "Linuxi administraator"

Allikas: www.habr.com