🥇Docker Compose: de la dezvoltare la producție

Traducerea transcripției podcastului a fost pregătită înainte de începutul cursului „Administrator Linux”

Docker Compose este un instrument uimitor pentru crearea unui mediu de lucru
pentru stack-ul folosit în aplicația dumneavoastră. Acesta vă permite să definiți
fiecare componentă a aplicației dumneavoastră, conform unei sintaxe clare și simple în fișiere YAML.
Odată cu apariția.

docker compose v3 aceste fișiere YAML pot fi folosite direct în mediu de lucru, atunci când lucrați cu un cluster.
Docker Swarm Dar înseamnă asta că puteți folosi același fișier docker-compose în.

procesul de dezvoltare și în mediul de producție? Sau utiliza același fișier pentru
staging? Ei bine, în general - da, dar pentru această funcționalitate avem nevoie de următoarele:
Interpolarea variabilelor: utilizarea variabilelor de mediu pentru anumite

valori, care se schimbă în fiecare mediu.
Suprareglarea configurației: capacitatea de a defini un al doilea (sau orice
alt fișier docker-compose ulterior), care va modifica ceva în legătură cu
primul, iar docker compose se va ocupa de combinarea ambelor fișiere.
Diferențele dintre fișierele pentru dezvoltare și producție

În timpul dezvoltării, este foarte probabil să doriți să verificați modificările de cod în

timp real. Pentru aceasta, de obicei, volumul cu codul sursă este montat în
containerul în care se află runtime-ul aplicației dumneavoastră. Dar pentru mediul de producție
această abordare nu este potrivită.
În producție, aveți un cluster cu multe noduri, iar volumul este local față de

nodul pe care rulează containerul dumneavoastră (sau serviciul), astfel încât nu
puteți monta codul sursă fără operațiuni complicate, care includ
sincronizarea codului, semnale etc.
În schimb, de obicei, dorim să creăm o imagine cu o versiune specifică a codului dumneavoastră.

Este obișnuit să fie etichetată cu un tag corespunzător (se poate folosi versiune
semantica sau orice alt sistem la alegerea dumneavoastră).
Suprareglarea configurației

Având în vedere diferențele și faptul că dependențele dumneavoastră pot diferi în scenarii

de dezvoltare și producție, este clar că ne vor trebui fișiere de configurare diferite.
Docker compose suportă combinarea diferitelor fișiere compose pentru

a obține configurația finală. Cum funcționează acest lucru poate fi văzut prin exemplul:
obținerea configurației finale. Cum funcționează poate fi văzut ca exemplu:

$ 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

Așa cum a fost menționat, docker compose suportă combinarea mai multor compose-
fișiere, permițând astfel suprascrierea diferitelor parametrii în al doilea fișier. De exemplu:

$ 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

Acest sintaxă nu este foarte confortabilă în procesul de dezvoltare, când comanda
va trebui să fie executată de mai multe ori.

Din fericire, docker compose caută automat un fișier special cu numele
docker-compose.override.yml pentru a suprascrie valorile docker-compose.yml. Dacă
dacă redenumiți al doilea fișier, veți obține același rezultat, doar cu comanda inițială:

$ 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

Bine, așa se reține mai ușor.

Interpolarea variabilelor

Fișierele de configurație suportă interpolarea
variabile și valorile implicite. Adică, puteți face următoarele:

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

Și dacă executați docker-compose build (sau push) fără variabila de mediu
$MY_SERVICE_VERSION, se va folosi valoarea latest, dar dacă setați
valoarea variabilei de mediu înainte de construcție, aceasta va fi utilizată în timpul construcției sau în push
în registrul private.registry.mine.

Principiile mele

Metodele care sunt convenabile pentru mine pot fi utile și pentru tine. Urmez aceste
reguli simple:

Toate stivele mele pentru producție, dezvoltare (sau alte medii) sunt definite prin
fișiere docker-compose.
Fișierele de configurare necesare pentru a acoperi toate medii mele evită în mod maxim
duplicarea.
Am nevoie de un singur comanda pentru a lucra în fiecare mediu.
Configurarea principală este definită în fișierul docker-compose.yml.
Variablele de mediu sunt utilizate pentru a defini etichetele imaginilor sau alte
variabile care pot varia de la un mediu la altul (staging, integrare,
producție).
Valorile variabilelor pentru producție sunt utilizate ca valori implicite, ceea ce minimizează riscurile în cazul în care se lansează stiva în producție fără
variabila de mediu setată.
Pentru a lansa un serviciu într-un mediu de producție se folosește comanda
docker stack deploy --compose-file docker-compose.yml --with-registry-auth my-stack-name Mediul de lucru este lansat cu comanda.
Să aruncăm o privire asupra unui exemplu simplu. docker-compose up -d.

Pot folosi

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

Și

# 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) , pentru a lansa stiva înmod de dezvoltare cu codul sursă montat în
Pot folosi aceleași fișiere și în producție! Și aș putea folosi exact /project/src.

același fișier
pentru staging. Pentru a desfășura aceasta în docker-compose.yml producție, trebuie doar să construiesc și să trimit imaginea cu eticheta predefinită
în etapa CI:
export MY_SERVICE_VERSION=1.2.3 docker-compose -f docker-compose.yml build docker-compose -f docker-compose.yml push

În producție, aceasta poate fi lansată cu următoarele comenzi:

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

Și dacă vrei să faci același lucru în staging, trebuie doar să definești

variabilele de mediu necesare pentru a funcționa în mediu de staging:
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

În concluzie, am folosit două fișiere docker-compose diferite, care fără

duplicarea configurațiilor pot fi utilizate pentru orice mediu al tău!
Traducerea transcrierii podcastului a fost pregătită în pregătirea lansării cursului „Administrator Linux”

Află mai multe despre curs „Administrator Linux”

Sursa: habr.com