Traducerea transcripției podcastului pregătită în așteptarea începerii cursului
Docker Compose este un instrument uimitor pentru a crea un lucru
mediu pentru stiva utilizată în aplicația dvs. Vă permite să definiți
fiecare componentă a aplicației dvs., urmând o sintaxă clară și simplă în .
Odată cu apariția aceste fișiere YAML pot fi utilizate direct în mediul de producție atunci când lucrați cu
cluster .
Dar înseamnă asta că puteți utiliza același fișier docker-compose în
procesul de dezvoltare și în mediul de producție? Sau folosiți același fișier pentru
montare? Ei bine, în general, da, dar pentru această funcționalitate avem nevoie de următoarele:
- Interpolarea variabilelor: utilizarea variabilelor de mediu pentru unii
valori care se schimbă în fiecare mediu. - Modificarea configurației: capacitatea de a defini o secundă (sau oricare
un alt fișier ulterior) docker-compose care va schimba ceva în ceea ce privește
mai întâi, iar docker compose se va ocupa de îmbinarea ambelor fișiere.
Diferențele dintre fișierele de dezvoltare și producție
În timpul dezvoltării, cel mai probabil veți dori să verificați modificările codului în
în timp real. Pentru a face acest lucru, de obicei este montat volumul cu codul sursă
container care conține runtime pentru aplicația dvs. Dar pentru un mediu de producție
Această metodă nu este potrivită.
În producție, aveți un cluster cu multe noduri, iar volumul este local
raportat la nodul pe care rulează containerul (sau serviciul), deci nu
puteți monta codul sursă fără operații complexe care includ
sincronizare cod, semnale etc.
În schimb, de obicei dorim să creăm o imagine cu o anumită versiune a codului dvs.
Este obișnuit să îl marcați cu eticheta corespunzătoare (puteți folosi semantic
versiunea sau alt sistem la discreția dumneavoastră).
Suprascrierea configurației
Având în vedere diferențele și că dependențele dvs. pot diferi în scenarii
dezvoltare și producție, este clar că vom avea nevoie de fișiere de configurare diferite.
Docker Compose acceptă îmbinarea diferitelor fișiere de scriere la
obţine configuraţia finală. Cum funcționează acest lucru poate fi văzut în 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 | < 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 0După cum sa spus, docker compose acceptă combinarea mai multor compoziții -
fișiere, acest lucru vă permite să suprascrieți diferiți parametri din 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 | < 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 0Această sintaxă nu este foarte convenabilă în timpul dezvoltării, când comanda
va trebui făcută de mai multe ori.
Din fericire, docker compose caută automat un fișier special numit
docker-compose.override.yml pentru a suprascrie valorile Docker-compose.yml. dacă
redenumiți al doilea fișier, obțineți același rezultat, folosind doar comanda originală:
$ 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 0Bine, e mai ușor de reținut.
Interpolarea variabilelor
Suport fișiere de configurare ș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ă o faci docker-compose build (sau push) fără variabilă de mediu
$MY_SERVICE_VERSION, se va folosi valoarea Ultimeledar dacă ai setat
valoarea variabilei de mediu înainte de construire, aceasta va fi folosită la construirea sau împingerea
la registru privat.registru.al meu.
Principiile mele
Abordările care funcționează pentru mine ar putea funcționa și pentru tine. Le urmez pe astea
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 mediile mele, cât mai mult posibil
evita dublarea. - Am nevoie de o comandă simplă pentru a lucra în fiecare mediu.
- Configurația principală este definită în fișier Docker-compose.yml.
- Variabilele de mediu sunt folosite pentru a defini etichete de imagine sau altele
variabile care pot varia de la mediu la mediu (preparare, integrare,
producție). - Valorile variabilelor de producție sunt folosite ca valori pentru
implicit, acest lucru minimizează riscurile dacă stiva este lansată în producție fără
setați variabila de mediu. - Pentru a porni un serviciu într-un mediu de producție, utilizați comanda docker stack deploy - compus-fișier docker-compose.yml -with-registry-auth my-stack-name.
- Mediul de lucru este pornit folosind comanda docker-compuneți până-d.
Să ne uităm la un exemplu simplu.
# 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
...pot folosi docker-compose (docker-compose)pentru a rula stiva înăuntru
modul de dezvoltare cu codul sursă montat în /proiect/src.
Pot folosi aceleași fișiere în producție! Și cu siguranță aș putea folosi
același fișier Docker-compose.yml pentru montare. Pentru a extinde acest lucru la
producție, trebuie doar să construiesc și să trimit imaginea cu o etichetă predefinită
în stadiul 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 rulată folosind 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 pe scenă, trebuie doar să definești
variabilele de mediu necesare pentru lucrul în mediul de pregătire:
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 consecință, am folosit două fișiere docker-compose diferite, care fără
Configurațiile duplicate pot fi folosite pentru orice mediu pe care îl aveți!
Aflați mai multe despre curs
Sursa: www.habr.com