🥇 تكوين عامل الإرساء: من التطوير إلى الإنتاج

ترجمة نسخ البودكاست المعدة استعدادًا لبدء الدورة "مسؤول Linux"

Docker Compose هي أداة رائعة لإنشاء سطح المكتب
بيئة المكدس المستخدمة في التطبيق الخاص بك. يسمح لك بتحديد
كل مكون من مكونات التطبيق الخاص بك ، باتباع بنية واضحة وبسيطة في يامل-
الملفات.

مع قدوم عامل ميناء يؤلف v3 يمكن استخدام ملفات YAML هذه مباشرة في بيئة الإنتاج ، عند العمل معها
تَجَمَّع عامل ميناء سرب.

ولكن هل هذا يعني أنه يمكنك استخدام نفس ملف إنشاء عامل الإرساء بتنسيق
عملية التطوير وبيئة الإنتاج؟ أو استخدم نفس الملف لـ
انطلاق؟ حسنًا ، بشكل عام ، نعم ، ولكن بالنسبة لهذه الوظيفة ، نحتاج إلى ما يلي:

الاستيفاء المتغير: استخدام متغيرات البيئة للبعض
القيم التي تتغير في كل بيئة.
تجاوز التكوين: القدرة على تحديد الثانية (أو أي
متابعة أخرى) ملف 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

هذا النحو ليس مناسبًا جدًا في عملية التطوير ، عندما يكون الأمر
تحتاج إلى القيام به عدة مرات.

لحسن الحظ ، يبحث عامل ميناء الإنشاء تلقائيًا عن ملف خاص باسم
عامل ميناء compose.override.yml لتجاوز القيم عامل ميناء-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}
...

وإذا فعلت إنشاء عامل بناء (أو دفع) بدون متغير البيئة
MY_SERVICE_VERSION دولار، سيتم استخدام القيمة آخرولكن إذا قمت بتعيين
قيمة متغير البيئة قبل البناء ، سيتم استخدامها عند البناء أو الدفع
للتسجيل Private.registry.mine.

مبادئي

قد تكون الأساليب المناسبة لي مفيدة لك. أنا أتابع هذا
قواعد بسيطة:

يتم تحديد كل مكدساتي للإنتاج أو التطوير (أو البيئات الأخرى) من خلال
إنشاء ملفات عامل ميناء.
ملفات التكوين اللازمة لتغطية جميع بيئاتي ، كحد أقصى.
تجنب التكرار.
أحتاج إلى أمر واحد بسيط للعمل في كل بيئة.
يتم تحديد التكوين الرئيسي في الملف عامل ميناء-compose.yml.
تستخدم متغيرات البيئة لتحديد علامات الصورة أو غيرها
المتغيرات التي يمكن أن تتغير من بيئة إلى بيئة (التدريج ، التكامل ،
إنتاج).
يتم استخدام قيم المتغيرات للإنتاج كقيم بواسطة
بشكل افتراضي ، هذا يقلل من المخاطر إذا قمت بتشغيل المكدس في الإنتاج بدون
تعيين متغير البيئة.
لبدء خدمة في بيئة إنتاج ، استخدم الأمر نشر حزمة عامل ميناء - تكوين ملف عامل ميناء compose.yml - مع التسجيل - المصادقة - اسم المكدس الخاص بي.
تبدأ بيئة العمل بالأمر عامل ميناء-يؤلف -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
...

استطيع ان استخدم عامل الميناء - يؤلف (عامل الميناء - يؤلف)لتشغيل المكدس في
وضع التطوير مع كود المصدر المركب في / مشروع / src.

يمكنني استخدام نفس الملفات في الإنتاج! ويمكنني استخدام بالضبط
نفس الملف عامل ميناء-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

نتيجة لذلك ، استخدمنا ملفين مختلفين لإنشاء عامل ميناء ، بدونهما
يمكن استخدام التكوينات المكررة في أي من بيئاتك!

تعلم المزيد عن الدورة "مسؤول Linux"

المصدر: www.habr.com

Docker Compose: من التطوير إلى الإنتاج

الفروق بين ملفات التطوير والإنتاج

تجاوز التكوين

الاستيفاء المتغير

مبادئي

إضافة تعليق إلغاء الرد