Docker Compose: arenduse kuni tootmiseni

Podcasti transkriptsiooni tõlge on valmistatud ette kursuse alguseks Linuxi administraator

Docker Compose on hämmastav tööriist töötava
keskkonna loomiseks teie rakenduses kasutatava stacki jaoks. See võimaldab teil määratleda
iga teie rakenduse komponendi, järgides selget ja lihtsat süntaksit YAML-
failides.

Docker Compose v3 Nende YAML-failidega saab otse töötada tootmisväljas, töötades klastriga
Aga kas see tähendab, et saate sama docker-compose faili kasutada Docker Swarm.

arendusprotsessis ja tootmisväljas? Või kasutada sama faili
staging-eesmärkidel? Noh, üldiselt jah, kuid selle funktsionaalsuse jaoks on meil vaja järgmist:
Muuttuvate väärtuste interpolatsioon: keskkonnamuutujate kasutamine mõnede

• väärtuste jaoks, mis muutuvad igas keskkonnas.
  Konfiguratsiooni ülemineku võimalus: võimalus määratleda teine (või mõni
• muu järgneva) docker-compose fail, mis muudab midagi esimese
  suhtes, ja docker compose hoolitseb mõlema faili ühendamise eest.
  Arenduse ja tootmise failide erinevused

Arenduse käigus soovite tõenäoliselt koodi muudatusi reaalajas kontrollida. Selleks on tavaliselt

allika kood monteeritud konteinerisse, kus asub teie rakenduse tööaeg. Kuid tootmiskeskkonda
selline lähenemine ei sobi.
Tootmises on teil klaster paljude sõlmedega, ja montaaž on kohalik
sõlme suhtes, kus teie konteiner (või teenus) töötab, seega ei saa te

allika koodi montaaži teha ilma keeruliste toiminguteta, mis hõlmavad
koodi sünkroniseerimist, signaale jne.
Selle asemel soovime tavaliselt luua pildi teie konkreetse koodiversiooniga.
Tavaliselt märgistatakse see vastava sildiga (võib kasutada semantiline

versioonimine või muu süsteem vastavalt teie soovile).
Konfiguratsiooni üleminek
Arvesse võttes erinevusi ja et teie sõltuvused võivad arengus ja

tootmises erineda, on selge, et meil on vaja erinevaid konfiguratsioonifaile.

Docker compose toetab erinevate compose-failide ühendamist viimase
konfiguratsiooni saamiseks. Kuidas see töötab, saab näha näite abil:

Docker compose toetab erinevate compose-failide ühendamist
lõpliku konfiguratsiooni saamiseks. Kuidas see töötab, näeb 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, toetab docker compose 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

Selline süntaks ei ole arendamise käigus eriti mugav, kui käsku
peab korduvalt täitma.

Külastuseks, docker compose otsib automaatselt spetsiaalset faili nimega
docker-compose.override.yml väärtuste ületamiseks docker-compose.yml. Kui
teise faili nimetada, saadakse sama tulemus, ainult algse käsu abil:

$ 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  | 
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

Hea, nii on lihtsam meelde jätta.

Muutujate interpolatsioon

Konfiguratsioonifailid toetavad interpolatsiooni
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 docker-compose build (või push) ilma keskkonna muutujata
$MY_SERVICE_VERSION, kasutatakse väärtust latest, kuid kui seadistate
keskkonna muutujate väärtuse enne ehitamist, kasutatakse seda ehitamisel või pushimisel
registrisse private.registry.mine.

Minu printsiibid

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

• Kõik minu tootmis-, arendus- (või muude keskkondade) virnad määratakse
  docker-compose failide kaudu.
• Konfiguratsioonifailid, mis on vajalikud kõigi minu keskkondade katmiseks,
  väldivad duplikaate.
• Mul on iga keskkonna jaoks vajalik ühte lihtsat käsku.
• Põhik konfiguratsioon on määratud failis docker-compose.yml.
• Keskkonnamuutujad on kasutusel piltide siltide või muude määratlemiseks,
  mis võivad keskkonna kaupa muutuda (staging, integratsioon,
  tootmine).
• Tootmiseks kasutatavad muutujate väärtused on vaikeväärtused, see minimeerib riskid,
  kui virna käivitamine toimub tootmises ilma seadistatud keskkonnamuutujata.
  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 järgmise käsuga.
• docker-compose up -d Vaatame lihtsat näidet..

Ja

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

ma saan kasutada

# 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 virnaarendustasandi režiimis, kus lähtekood on ühendatud
Ma saan kasutada neid samu faile tootmises! Ja ma võiksin kasutada täpselt /project/src.

sama faili
stagingis. Selle tootmisse viimiseks pean lihtsalt koguma ja saatma pildi ettemääratud sildiga docker-compose.yml 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 soovite sama teha stagingis, peate lihtsalt määrama

vajalikud keskkonnamuutujad stagingikeskkonnas:

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 oleme kasutanud kahte erinevat docker-compose faili, mis

ilma konfiguratsiooni duplikaatideta saavad kasutada igas teie keskkonnas!

Tutvuge kursuse üksikasjadega
Teooria ja praktika ClickHouse'i kasutamisel reaalsetes rakendustes. Aleksandr Zaitsev (2018)

Pi-KVM — avatud IP-KVM projekt Raspberry Pi-l Linuxi administraator

Allikas: habr.com