🥇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 (یا فشار) بدون متغیر محیطی
$MY_SERVICE_VERSION، از مقدار استفاده خواهد شد آخریناما اگر تنظیم کنید
مقدار متغیر محیطی قبل از ساخت، در هنگام ساخت یا فشار دادن استفاده خواهد شد
به ثبت نام خصوصی.رجیستری.من.

اصول من

رویکردهایی که برای من کارساز هستند ممکن است برای شما نیز مفید باشند. من اینها را دنبال می کنم
قوانین ساده:

تمام پشته های من برای تولید، توسعه (یا محیط های دیگر) از طریق تعریف شده اند
فایل های docker-compose
فایل های پیکربندی مورد نیاز برای پوشش تمام محیط های من، تا حد امکان
اجتناب از تکرار
من برای کار در هر محیط به یک دستور ساده نیاز دارم.
پیکربندی اصلی در فایل تعریف شده است docker-compose.yml.
از متغیرهای محیطی برای تعریف تگ های تصویر یا موارد دیگر استفاده می شود
متغیرهایی که ممکن است از محیطی به محیط دیگر متفاوت باشند (مرحله بندی، ادغام،
تولید).
مقادیر متغیرهای تولید به عنوان مقادیر برای
به‌طور پیش‌فرض، این امر خطرات را به حداقل می‌رساند اگر پشته بدون راه‌اندازی تولید شود
تنظیم متغیر محیطی
برای شروع یک سرویس در محیط تولید، از دستور استفاده کنید docker stack deploy - compose-file docker-compose.yml -with-registry-auth my-stack-name.
محیط کار با استفاده از دستور شروع می شود docker-compose-d.

بیایید به یک مثال ساده نگاه کنیم.

# 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)برای اجرای پشته در
حالت توسعه با کد منبع نصب شده در /project/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

Docker Compose: از توسعه تا تولید

تفاوت بین فایل های توسعه و تولید

لغو پیکربندی

درون یابی متغیرها

اصول من

اضافه کردن نظر انصراف از پاسخ