ProHoster > Blogs > Administrācija > Docker Compose: no izstrādes līdz ražošanai

Docker Compose: no izstrādes līdz ražošanai

Sagaidot kursa sākumu sagatavotās podkāsta transkripcijas tulkojums "Linux administrators"

Docker Compose: no izstrādes līdz ražošanai

Docker Compose ir pārsteidzošs rīks darba izveidei
vide jūsu lietojumprogrammā izmantotajam stekam. Tas ļauj definēt
katru jūsu lietojumprogrammas komponentu, ievērojot skaidru un vienkāršu sintakse YAML-
failus.

Ar Advent Docker Compose v3 šos YAML failus var izmantot tieši ražošanas vidē, strādājot ar
klasteris Dokera bars.

Bet vai tas nozīmē, ka varat izmantot to pašu docker-compose failu
izstrādes procesā un ražošanas vidē? Vai arī izmantojiet to pašu failu
iestudējums? Nu, kopumā jā, bet šai funkcionalitātei mums ir nepieciešams:

  • Mainīgo interpolācija: vides mainīgo izmantošana dažiem
    vērtības, kas mainās katrā vidē.
  • Konfigurācijas ignorēšana: iespēja definēt sekundi (vai jebkuru
    vēl viens nākamais) docker-compose fails, kas kaut ko mainīs
    Pirmkārt, un docker compose parūpēsies par abu failu sapludināšanu.

Atšķirības starp izstrādes un ražošanas failiem

Izstrādes laikā jūs, visticamāk, vēlēsities pārbaudīt koda izmaiņas
īsts laiks. Lai to izdarītu, parasti tiek ievietots sējums ar avota kodu
konteiners, kurā ir jūsu lietojumprogrammas izpildlaiks. Bet ražošanas videi
Šī metode nav piemērota.

Ražošanā jums ir kopa ar daudziem mezgliem, un apjoms ir vietējs
attiecībā pret mezglu, kurā darbojas jūsu konteiners (vai pakalpojums), tāpēc jums tas nav jādara
avota kodu var uzstādīt bez sarežģītām darbībām, kas ietver
kodu sinhronizācija, signāli utt.

Tā vietā mēs parasti vēlamies izveidot attēlu ar noteiktu jūsu koda versiju.
Ir ierasts to atzīmēt ar atbilstošu tagu (varat izmantot semantisko
versiju vai cita sistēma pēc jūsu ieskatiem).

Konfigurācijas ignorēšana

Ņemot vērā atšķirības un to, ka jūsu atkarības dažādos scenārijos var atšķirties
izstrāde un ražošana, ir skaidrs, ka mums būs nepieciešami dažādi konfigurācijas faili.

Docker Compose atbalsta dažādu sastādīšanas failu sapludināšanu
iegūt galīgo konfigurāciju. Kā tas darbojas, var redzēt piemērā:

$ 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

Kā jau minēts, dokera komponēšanas atbalsti, apvienojot vairākas kompozīcijas -
failus, tas ļauj ignorēt dažādus parametrus otrajā failā. Piemēram:

$ 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

Šī sintakse nav ļoti ērta izstrādes laikā, kad komanda
būs jādara daudzas reizes.

Par laimi, Docker Compose automātiski meklē īpašu failu ar nosaukumu
docker-compose.override.yml lai ignorētu vērtības docker-compose.yml. Ja
pārdēvējiet otro failu, jūs saņemat to pašu rezultātu, tikai izmantojot sākotnējo komandu:

$ 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

Labi, to ir vieglāk atcerēties.

Mainīgo interpolācija

Konfigurācijas failu atbalsts interpolācija
mainīgie un noklusējuma vērtības. Tas ir, jūs varat veikt šādas darbības:

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

Un ja jūs to darāt docker-compize veidot (vai push) bez vides mainīgā
$MY_SERVICE_VERSION, tiks izmantota vērtība jaunākaisbet ja iestatāt
vides mainīgā vērtība pirms būves, to izmantos būvējot vai stumjot
uz reģistru privātais.reģistrs.mans.

Mani principi

Pieejas, kas darbojas man, var noderēt arī jums. Es sekoju šiem
vienkārši noteikumi:

  • Visas manas ražošanas, izstrādes (vai citas vides) skursteņi ir definēti caur
    docker-compose failus
  • Konfigurācijas faili, kas nepieciešami, lai pēc iespējas aptvertu visas manas vides
    izvairīties no dublēšanās.
  • Man ir nepieciešama viena vienkārša komanda darbam katrā vidē.
  • Galvenā konfigurācija ir definēta failā docker-compose.yml.
  • Vides mainīgie tiek izmantoti, lai definētu attēlu tagus vai citus
    mainīgie, kas dažādās vidēs var atšķirties (inscenējums, integrācija,
    ražošana).
  • Ražošanas mainīgo vērtības tiek izmantotas kā vērtības
    pēc noklusējuma tas samazina riskus, ja steks tiek palaists ražošanā bez
    iestatīt vides mainīgo.
  • Lai sāktu pakalpojumu ražošanas vidē, izmantojiet komandu docker steka izvietošana - sastādīt-fails docker-compose.yml -with-registry-auth my-steck-name.
  • Darba vide tiek startēta, izmantojot komandu docker-komponēt-d.

Apskatīsim vienkāršu piemēru.

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

Es varu izmantot docker-compose (docker-compose up)lai palaistu kaudzi
izstrādes režīms ar iebūvētu pirmkodu /projekts/src.

Šos pašus failus varu izmantot ražošanā! Un es noteikti varētu izmantot
tas pats fails docker-compose.yml iestudēšanai. Lai to paplašinātu uz
ražošana, man tikai nepieciešams izveidot un nosūtīt attēlu ar iepriekš noteiktu tagu
CI stadijā:

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

Ražošanā to var palaist, izmantojot šādas komandas:

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

Un, ja jūs vēlaties darīt to pašu uz skatuves, jums vienkārši ir jādefinē
nepieciešamie vides mainīgie, lai strādātu inscenēšanas vidē:

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

Rezultātā mēs izmantojām divus dažādus docker-compose failus, kuriem bez
Dublētas konfigurācijas var izmantot jebkurai jūsu videi!

Uzziniet vairāk par kursu "Linux administrators"

Avots: www.habr.com

Pievieno komentāru