Docker Compose: განვითარებადან წარმოებამდე

კურსის დაწყების მოლოდინში მომზადებული პოდკასტის ტრანსკრიპციის თარგმანი "ლინუქსის ადმინისტრატორი"

Docker Compose არის საოცარი ინსტრუმენტი სამუშაოს შესაქმნელად
გარემო თქვენს აპლიკაციაში გამოყენებული სტეკისთვის. ის საშუალებას გაძლევთ განსაზღვროთ
თქვენი აპლიკაციის თითოეული კომპონენტი, მკაფიო და მარტივი სინტაქსის შემდეგ YAML-
ფაილები.

დადგომისთანავე docker compose v3 ამ YAML ფაილების გამოყენება შესაძლებელია უშუალოდ საწარმოო გარემოში მუშაობისას
კასეტური დოკერის გროვა.

მაგრამ ნიშნავს თუ არა ეს, რომ თქვენ შეგიძლიათ გამოიყენოთ იგივე docker-compose ფაილი
განვითარების პროცესში და საწარმოო გარემოში? ან გამოიყენეთ იგივე ფაილი
დადგმა? ზოგადად, დიახ, მაგრამ ამ ფუნქციონირებისთვის ჩვენ გვჭირდება შემდეგი:

• ცვლადის ინტერპოლაცია: ზოგიერთისთვის გარემოს ცვლადების გამოყენება
  ღირებულებები, რომლებიც იცვლება თითოეულ გარემოში.
• კონფიგურაციის უგულებელყოფა: მეორე (ან რომელიმეს) განსაზღვრის შესაძლებლობა
  კიდევ ერთი შემდგომი) docker-compose ფაილი, რომელიც შეცვლის რაღაცას
  პირველი, და docker compose იზრუნებს ორივე ფაილის გაერთიანებაზე.

განსხვავებები განვითარებისა და წარმოების ფაილებს შორის

განვითარების დროს, სავარაუდოდ, გსურთ შეამოწმოთ კოდის ცვლილებები
რეალური დრო. ამისათვის, როგორც წესი, ჩამონტაჟებულია მოცულობა წყაროს კოდით
კონტეინერი, რომელიც შეიცავს თქვენი აპლიკაციის გაშვების დროს. მაგრამ საწარმოო გარემოსთვის
ეს მეთოდი არ არის შესაფერისი.

წარმოებაში, თქვენ გაქვთ კლასტერი მრავალი კვანძით და მოცულობა არის ადგილობრივი
იმ კვანძთან შედარებით, რომელზედაც მუშაობს თქვენი კონტეინერი (ან სერვისი), ასე რომ თქვენ არა
თქვენ შეგიძლიათ დააინსტალიროთ საწყისი კოდი რთული ოპერაციების გარეშე, რომელიც მოიცავს
კოდის სინქრონიზაცია, სიგნალები და ა.შ.

ამის ნაცვლად, ჩვენ ჩვეულებრივ გვინდა შევქმნათ სურათი თქვენი კოდის კონკრეტული ვერსიით.
ჩვეულებრივია მისი აღნიშვნა შესაბამისი ტეგით (შეგიძლიათ გამოიყენოთ სემანტიკური
ვერსია ან სხვა სისტემა თქვენი შეხედულებისამებრ).

კონფიგურაციის უგულებელყოფა

განსხვავებების გათვალისწინებით და რომ თქვენი დამოკიდებულებები შეიძლება განსხვავდებოდეს სცენარებში
განვითარება და წარმოება, გასაგებია, რომ დაგვჭირდება სხვადასხვა კონფიგურაციის ფაილი.

Docker compose მხარს უჭერს სხვადასხვა შედგენის ფაილების გაერთიანებას
მიიღეთ საბოლოო კონფიგურაცია. როგორ მუშაობს ეს, ჩანს მაგალითში:

$ 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

როგორც ითქვა, docker compose მხარს უჭერს მრავალი კომპოზიციის გაერთიანებას -
ფაილები, ეს საშუალებას გაძლევთ გადალახოთ სხვადასხვა პარამეტრები მეორე ფაილში. Მაგალითად:

$ 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

ეს სინტაქსი არ არის ძალიან მოსახერხებელი განვითარების დროს, როდესაც ბრძანება
ბევრჯერ დასჭირდება გაკეთება.

საბედნიეროდ, docker compose ავტომატურად ეძებს სპეციალურ ფაილს, რომელსაც ეწოდება
docker-compose.override.yml ღირებულებების გადალახვა docker-compose.yml. თუ
დაარქვით მეორე ფაილს, თქვენ მიიღებთ იგივე შედეგს, მხოლოდ ორიგინალური ბრძანების გამოყენებით:

$ 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

კარგი, ამის დამახსოვრება უფრო ადვილია.

ცვლადების ინტერპოლაცია

კონფიგურაციის ფაილების მხარდაჭერა ინტერპოლაცია
ცვლადები და ნაგულისხმევი მნიშვნელობები. ანუ შეგიძლიათ გააკეთოთ შემდეგი:

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

და თუ თქვენ docker-compose build (ან ბიძგი) გარემოს ცვლადის გარეშე
$MY_SERVICE_VERSION, მნიშვნელობა იქნება გამოყენებული უკანასკნელიმაგრამ თუ დააყენე
გარემოს ცვლადის მნიშვნელობა აშენებამდე, ის გამოყენებული იქნება მშენებლობისას ან დაძაბვისას
რეესტრში კერძო.რეგისტრი.ჩემი.

ჩემი პრინციპები

ის მიდგომები, რომლებიც ჩემთვის მუშაობს, შეიძლება თქვენთვისაც იმოქმედოს. მე მივყვები ამათ
მარტივი წესები:

• ყველა ჩემი დასტა წარმოებისთვის, განვითარებისთვის (ან სხვა გარემოებისთვის) განისაზღვრება მეშვეობით
  docker-compose ფაილები
• კონფიგურაციის ფაილები საჭიროა ჩემი ყველა გარემოს მაქსიმალურად დასაფარად
  თავიდან აიცილოთ დუბლირება.
• მე მჭირდება ერთი მარტივი ბრძანება თითოეულ გარემოში მუშაობისთვის.
• ძირითადი კონფიგურაცია მითითებულია ფაილში docker-compose.yml.
• გარემოს ცვლადები გამოიყენება გამოსახულების ტეგების დასადგენად ან სხვა
  ცვლადები, რომლებიც შეიძლება განსხვავდებოდეს გარემოდან გარემოში (დადგმა, ინტეგრაცია,
  წარმოება).
• წარმოების ცვლადების მნიშვნელობები გამოიყენება როგორც მნიშვნელობები
  ნაგულისხმევად, ეს ამცირებს რისკებს, თუ სტეკი წარმოების გარეშე დაიწყება
  გარემოს ცვლადის დაყენება.
• საწარმოო გარემოში სერვისის დასაწყებად გამოიყენეთ ბრძანება docker stack deploy - compose-file docker-compose.yml -with-registry-auth my-stack-name.
• სამუშაო გარემო იწყება ბრძანების გამოყენებით დოკერ-შეადგინე -დ.

მოდით შევხედოთ მარტივ მაგალითს.

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

შემიძლია გამოვიყენო docker-compose (docker-compose up)დასტის გასაშვებად
განვითარების რეჟიმი ჩამონტაჟებული წყარო კოდით /პროექტი/src.

მე შემიძლია იგივე ფაილების გამოყენება წარმოებაში! და აუცილებლად გამოვიყენებდი
იგივე ფაილი docker-compose.yml დადგმისთვის. ამის გასაფართოვებლად
წარმოება, მე უბრალოდ უნდა ავაშენო და გავაგზავნო სურათი წინასწარ განსაზღვრული ტეგით
CI ეტაპზე:

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

წარმოებაში, მისი გაშვება შესაძლებელია შემდეგი ბრძანებების გამოყენებით:

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

და თუ გსურთ იგივე გააკეთოთ სცენაზე, უბრალოდ უნდა განსაზღვროთ
გარემოს აუცილებელი ცვლადები დადგმის გარემოში მუშაობისთვის:

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

შედეგად, ჩვენ გამოვიყენეთ ორი განსხვავებული docker-compose ფაილი, რომელთა გარეშეც
დუბლიკატი კონფიგურაციები შეიძლება გამოყენებულ იქნას ნებისმიერ გარემოში, რომელიც გაქვთ!

შეიტყვეთ მეტი კურსის შესახებ "ლინუქსის ადმინისტრატორი"

წყარო: www.habr.com