Docker Compose: mula sa pag-unlad hanggang sa produksyon

Pagsasalin ng transkripsyon ng podcast na inihanda sa pag-asam ng pagsisimula ng kurso "Linux Administrator"

Docker Compose: mula sa pag-unlad hanggang sa produksyon

Ang Docker Compose ay isang kamangha-manghang tool para sa paglikha ng isang gumagana
environment para sa stack na ginamit sa iyong application. Pinapayagan ka nitong tukuyin
bawat bahagi ng iyong aplikasyon, kasunod ng malinaw at simpleng syntax sa YAML-
mga file
.

Sa pagdating ng docker compose v3 ang mga YAML file na ito ay maaaring gamitin nang direkta sa kapaligiran ng produksyon kapag nagtatrabaho kasama
kumpol Docker kuyog.

Ngunit nangangahulugan ba ito na maaari mong gamitin ang parehong docker-compose file sa
proseso ng pag-unlad at sa kapaligiran ng produksyon? O gamitin ang parehong file para sa
pagtatanghal ng dula? Well, sa pangkalahatan, oo, ngunit para sa pag-andar na ito kailangan namin ang sumusunod:

  • Variable interpolation: gamit ang environment variables para sa ilan
    mga halagang nagbabago sa bawat kapaligiran.
  • Override ng configuration: kakayahang tumukoy ng isang segundo (o anuman
    isa pang kasunod) docker-compose file na magbabago ng isang bagay tungkol sa
    una, at ang docker compose ang bahala sa pagsasama ng parehong mga file.

Mga pagkakaiba sa pagitan ng mga file ng pag-unlad at produksyon

Sa panahon ng pag-unlad, malamang na gusto mong suriin ang mga pagbabago sa code
totoong oras. Upang gawin ito, kadalasan ang volume na may source code ay naka-mount
container na naglalaman ng runtime para sa iyong application. Ngunit para sa isang kapaligiran ng produksyon
Ang pamamaraang ito ay hindi angkop.

Sa produksyon, mayroon kang isang kumpol na may maraming node, at lokal ang volume
kaugnay sa node kung saan tumatakbo ang iyong container (o serbisyo), kaya hindi mo gagawin
maaari mong i-mount ang source code nang walang kumplikadong mga operasyon na kasama
pag-synchronize ng code, mga signal, atbp.

Sa halip, karaniwang gusto naming gumawa ng larawan na may partikular na bersyon ng iyong code.
Nakaugalian na itong markahan ng naaangkop na tag (maaari mong gamitin ang semantic
bersyon o ibang sistema sa iyong paghuhusga).

Override ng Configuration

Dahil sa mga pagkakaiba at na ang iyong mga dependency ay maaaring magkaiba sa mga sitwasyon
pag-unlad at produksyon, malinaw na kakailanganin namin ng iba't ibang mga file ng pagsasaayos.

Sinusuportahan ng Docker compose ang pagsasama ng iba't ibang compose file sa
makuha ang panghuling pagsasaayos. Kung paano ito gumagana ay makikita sa halimbawa:

$ 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

Tulad ng sinabi, ang docker compose ay sumusuporta sa pagsasama-sama ng maramihang mga compose -
file, pinapayagan ka nitong i-override ang iba't ibang mga parameter sa pangalawang file. Halimbawa:

$ 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

Syntax na ito ay hindi masyadong maginhawa sa panahon ng pag-unlad, kapag ang command
ay kailangang gawin ng maraming beses.

Sa kabutihang palad, ang docker compose ay awtomatikong naghahanap ng isang espesyal na file na tinatawag
docker-compose.override.yml upang i-override ang mga halaga docker-compose.yml. Kung
palitan ang pangalan ng pangalawang file, makakakuha ka ng parehong resulta, gamit lamang ang orihinal na utos:

$ 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

Okay, mas madaling tandaan iyon.

Interpolation ng mga Variable

Suporta sa mga configuration file interpolation
mga variable
at mga default na halaga. Ibig sabihin, magagawa mo ang sumusunod:

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

At kung gagawin mo docker-compose build (o push) walang environment variable
$MY_SERVICE_VERSION, ang halaga ay gagamitin pinakahulingunit kung itinakda mo
ang halaga ng environment variable bago ang build, ito ay gagamitin kapag nagtatayo o nagtutulak
sa rehistro private.registry.mine.

Mga prinsipyo ko

Ang mga diskarte na gumagana para sa akin ay maaaring gumana din para sa iyo. Sinusunod ko ang mga ito
simpleng panuntunan:

  • Ang lahat ng aking mga stack para sa produksyon, pag-unlad (o iba pang mga kapaligiran) ay tinukoy sa pamamagitan ng
    docker-compose ng mga file
  • Kailangan ng mga configuration file upang masakop ang lahat ng aking kapaligiran hangga't maaari
    maiwasan ang pagdoble.
  • Kailangan ko ng isang simpleng utos upang gumana sa bawat kapaligiran.
  • Ang pangunahing pagsasaayos ay tinukoy sa file docker-compose.yml.
  • Ginagamit ang mga variable ng kapaligiran upang tukuyin ang mga tag ng larawan o iba pa
    mga variable na maaaring mag-iba mula sa kapaligiran sa kapaligiran (staging, integration,
    produksyon).
  • Ang mga halaga ng mga variable ng produksyon ay ginagamit bilang mga halaga para sa
    bilang default, pinapaliit nito ang mga panganib kung ang stack ay inilunsad sa produksyon nang wala
    itakda ang variable ng kapaligiran.
  • Upang magsimula ng isang serbisyo sa isang kapaligiran ng produksyon, gamitin ang command pag-deploy ng docker stack - compose-file docker-compose.yml -with-registry-auth my-stack-name.
  • Ang kapaligiran sa pagtatrabaho ay sinimulan gamit ang utos docker-compose up -d.

Tingnan natin ang isang simpleng halimbawa.

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

pwede kong gamitin docker-compose (docker-compose up)upang patakbuhin ang stack in
development mode na may source code na naka-mount /proyekto/src.

Magagamit ko ang parehong mga file na ito sa produksyon! At talagang magagamit ko
parehong file docker-compose.yml para sa pagtatanghal. Upang mapalawak ito sa
production, kailangan ko lang buuin at ipadala ang imahe na may paunang natukoy na tag
sa yugto ng CI:

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

Sa produksyon, maaari itong patakbuhin gamit ang mga sumusunod na command:

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

At kung gusto mong gawin ang parehong sa entablado, kailangan mo lamang tukuyin
kinakailangang mga variable ng kapaligiran para sa pagtatrabaho sa kapaligiran ng pagtatanghal ng dula:

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

Bilang resulta, gumamit kami ng dalawang magkaibang docker-compose file, na wala
Maaaring gamitin ang mga duplicate na configuration para sa anumang environment na mayroon ka!

Alamin ang higit pa tungkol sa kurso "Linux Administrator"

Pinagmulan: www.habr.com

Magdagdag ng komento