Docker Compose: arendusest tootmiseni

Podcaste transkriptsiooni tõlge on valmistatud kursuse alguse eelõhtul. „Linuxi administraator“

Docker Compose on hämmastav tööriist, mis aitab luua töökeskkonda
tehnoloogilistele hunnikutele, mida teie rakendus kasutab. See võimaldab teil määratleda
igal teie rakenduse komponendil, järgides selget ja lihtsat süntaksit YAML-
failides..

Docker compose v3 saabudes võib neid YAML-faile kasutada otse töökeskkonnas, töötades klastriga.
Aga kas see tähendab, et saate sama docker-compose faili kasutada Docker Swarm.

arendusprotsessis ja tootmis keskkonnas? Või kasutada sama faili
etappide jaoks? Noh, üldiselt – jah, kuid selle funktsionaalsuse jaoks on vajalik järgnev:
Muuttuvate muutmine: keskkonnamuutujate kasutamine teatud

• väärtuste jaoks, mis muutuvad igas keskkonnas.
  Konfigureerimise ülekirjutamine: võimalus määratleda teine (või mõni
• muud järeltulevat) docker-compose fail, mis muudab midagi esimeses failis,
  ja docker compose hoolitseb mõlema faili ühendamise eest.
  Arenduse ja tootmise failide erinevused

Arenduse käigus soovite tõenäoliselt kontrollida koodi muudatusi

Arenduste tegemise ajal soovite tõenäoliselt jälgida koodi muudatusi
reaalajas. Selle saavutamiseks monteeritakse tavaliselt koodiga konteiner,
kus asub teie rakenduse tööaeg. Kuid tootmis keskkonnas
selline lähenemine ei sobi.

Tootmises on teil klaster, mis koosneb paljusid sõlmedest, ja konteiner on kohaliku
sõlme suhtes, kus teie konteiner (või teenus) töötab, seega te ei
saa monteerida lähtekoodi ilma keeruliste toiminguteta, mis hõlmavad
koodi sünkroniseerimist, signaale jne.

Selle asemel soovime tavaliselt luua pildi, mis sisaldab konkreetset versiooni teie koodist.
Seda on harjutatud märgistama sobiva sildiga (võite kasutada semantilist
versioonihaldust või muud süsteemi teie valikul).

Konfiguratsiooni ülekirjutamine

Kuna teie sõltuvused võivad erineda arenduse ja tootmise stsenaariumides, on selge, et vajame erinevaid konfiguratsioonifaile.
Docker compose toetab erinevate compose-failide ühendamist lõpliku konfiguratsiooni saamiseks. Kuidas see töötab, on näidatud näiteks:

Docker compose toetab erinevate compose-failide ühendamist, et
saada lõplik konfiguratsioon. Kuidas see töötab, näete järgmisel näitel:

$ 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  | 
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, docker compose toetab mitme compose-faili ühendamist,
see võimaldab teises failis erinevaid parameetreid ületada. 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  | 
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 arendamise käigus eriti mugav, kui käsku
tuleb mitu korda täita.

Õnneks otsib docker compose automaatselt spetsiaalset faili nimega
docker-compose.override.yml väärtuste ülekirjutamiseks docker-compose.yml. Kui
kui teise faili nime muuta, saadakse sama tulemus algse käsu abil:

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Käivitamine composeconfigs_whale_1
Ühendatakse composeconfigs_whale_1-ga
whale_1  |  ______
whale_1  | 
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 väljus koodiga 0

Hea, nii on lihtsam meelde jätta.

Muutujate interpolatsioon

Konfiguratsioonifailid toetavad interpolatsiooni
muutujate ja vaikeväärtusi. 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 te käivitate docker-compose build (või push) ilma keskkonnamuutujata
$MY_SERVICE_VERSION, kasutatakse väärtust latest, aga kui seadistate
keskkonnamuutuja väärtuse enne ehitamist, kasutatakse seda ehitamisel või pushimisel
registrisse private.registry.mine.

Minu põhimõtted

Minu mugavad lähenemisviisid võivad olla kasulikud ka teile. Järgnen nendele
lihtsatele reeglitele:

• Kõik minu tootmis-, arendus- (või muude keskkondade) stekid määratakse
  docker-compose failide kaudu.
• Konfiguratsioonifailid, mis on vajalikud kõigi minu keskkondade katmiseks, püüavad
  maksimaalselt vältida dubleerimist.
• Vajan igas keskkonnas töötamiseks ühte lihtsat käsku.
• Põhikonfiguratsioon määratakse failis docker-compose.yml.
• Keskkonnamuutujad kasutatakse piltide silte või muid
  muutujate määratlemiseks, mis võivad keskkonniti (staging, integreerimine,
  tootmine) erineda.
• Tootmisväärtusi kasutatakse vaikeväärtustena, et minimeerida riske, kui
  steaki käivitamisel tootmises ei ole seadistatud keskkonnamuutujat.
  Teenuse käivitamiseks tootmiskeskkonnas kasutatakse käsku
• docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name Töökeskkond käivitatakse käsklusega.
• Vaatame lihtsat näidet. docker-compose up -d.

Võin kasutada

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

JA

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

docker-compose (docker-compose up) , et käivitada stekarendusrežiimis, kus lähtekood on monteeritud.
arendamisrežiimis, kus allikas on montaažis /project/src.

Saab kasutada samu faile tootmisriigis! Ja ma võiksin kasutada täpselt
sama faili docker-compose.yml etappimisel. Selle käivitamiseks tootmise keskkonnas pean lihtsalt koguma ja saatma pildi kindla sildiga
CI etapil:
export MY_SERVICE_VERSION=1.2.3 docker-compose -f docker-compose.yml build docker-compose -f docker-compose.yml push

Tootmisriigis 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 soovite teha sama etapis, tuleb lihtsalt määrata

vajalikud keskkonnamuutujad töötamiseks etappi keskkonnas:
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

Kokkuvõttes kasutasime kahte erinevat docker-compose faili, mis võivad kasutada

konfiguratsioonide dubleerimist mis tahes teie keskkonnas!
konfiguratsioonide dubleerimist saab kasutada teie igas keskkonnas!

Tutvuge kursusega „Linuxi administraator“

Allikas: habr.com