Moby: أضف دعمًا لميزة "الامتداد" في نشر Compose v3 / docker stack

لقد أضفت بعض الملاحظات https://github.com/docker/compose/issues/4315#issuecomment -280617251 إليّ مع إعادة الامتداد كما هو موجود حتى إصدار docker إنشاء ملف 2.1 ليس فكرة جيدة ولكن الميزة الرئيسية أنا Miss هو أن تكون قادرًا على الإعلان عن خدمات مجردة (لا ينبغي أبدًا تشغيلها ولكن يمكن استخدامها لتجميع الخصائص المشتركة للخدمات من أجل الراحة).

تمت الموافقة على التعليقات الواردة من عامل الإرساء / إنشاء # 4315 على أن الطريقة التي يعمل بها extends كانت بسيطة بعض الشيء.

لن أوصي بحل ، ولكن FWIW ، لإظهار مدى إساءة الاستخدام ، إليك الاتفاقيات التي تزين الجزء العلوي من ملف الإنشاء لدينا:

#
# Docker Compose configuration
#
# Due to lack of "expressivity" in Compose, we define our own couple of service
# "pseudo-types":
#
#   - image-only services (name: *-image)
#
#     The only goal of these is to build images. No other services build images.
#
#     These have entrypoint overridden to exit immediately.
#
#   - base services (name: *-base)
#
#     These contain common configuration and are intended to be extended.
#
#     Their command (not entrypoint, to keep the original one) is overridden to
#     exit immediately. Service must support a command to exit immediately.
#
#   - task services (name: *-task)
#
#     These are intended for running one-off commands.
#
#     Their default command is overridden to exit immediately. Service must
#     support a command to exit immediately.
#
#   - "real" services
#
#     These are actual services that stay up and running.
#
version: '2'
services:
  ...

أعتقد أن الامتدادات كما في v2.1 هي اختيار جيد. الامتداد هو في الواقع أمر بسيط ومفهوم ، وهذا ممارسة جيدة جدًا لكل بيئة للحصول على تحول بسيط ومقروء بين dev و prod و env.

في الحقيقة انه بحوزتي

• ملف إنشاء عامل ميناء مشترك يقدم القواعد الأساسية
• يقوم dev docker بتكوينه مع تسهيلات للمطورين
• يتكون عامل الإرساء المرحلي بشكل مشترك أيضًا ومع مرافق لهذه البيئة
• يتكون عامل إرساء الإنتاج بشكل مشترك أيضًا ومع مرافق لهذه البيئة ، وخاصة نسخ الحاويات ، وقواعد إعادة التشغيل ، وما إلى ذلك ...

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

يمنعنا من الترقية إلى تنسيق v3.x أيضًا.

نحتفظ بتعريفات حاوية عامل الإرساء الخاصة بنا في تخطيط مجلد لكل مثيل ، حيث يحتوي كل مجلد على docker-compose.yml الذي يحدد خصائص env لمثيل الحاوية في متناول اليد. لاستخراج العناصر الشائعة (DRY) ، نستخدم تعريفات الخدمة الأساسية في مجلد رئيسي ونستخدم extend .

لذلك عندما أحتاج إلى إدارة مثيل حاوية معين ، فأنا فقط بحاجة إلى cd في المجلد الصحيح ويمكن بعد ذلك مباشرة تشغيل أوامر docker-compose دون مزيد من التكوين (لا تتطلب أعلام -f ذلك أعضاء الفريق بحاجة إلى البحث أو المعرفة ، يعمل فقط كما هو متوقع خارج الصندوق).

لقد منعت من استخدام ملفات إنشاء الإصدار 3.

أستخدم services.yml لتحديد التخطيط الأساسي لخدماتي ثم توسيع ذلك بـ dev.services.yml أجل بيئة التطوير الخاصة بي (غالبًا ما تضيف وحدات تخزين) ولكني أحب إعادة استخدام (DRY) للتمديدات عندما كانت كذلك مضاف. إنها ليست صفقة رابحة ولكنها ستمنعني من الانتقال إلى الإصدار 3 ما لم تكن هناك ميزة ضرورية.

أنا لست ضد تحسين الإصدار v2.1 من حل "الامتداد" بشيء أكثر ملاءمة. يمكن أن يكون شيء مثل الخدمات المجردة أكثر أمانًا في الاستخدام وأكثر قوة.

على سبيل المثال (نظرًا لأنها مجردة) يمكنني تخيل دعم وحدات التخزين / نقاط التحميل / الشبكات المجردة ، حيث تحدد الخدمة الأساسية المجردة نقطة تحميل محلية أو شبكة مطلوبة لخدمة ما ، دون تحديد جزء المضيف - مما يعني أن الخدمة المشتقة يمكن أن تحدد / قم بتعيين الجزء المضيف من التركيبات / الأحجام والشبكات إلى ما هو مناسب في بيئة المضيف / المرحلة الخاصة به.

هذا مثال على شيء لا يمكننا فعله الآن مع "الامتدادات" بقدر ما أعرف ، وسيفتح بعض الاحتمالات المثيرة للاهتمام.

لم تكن ميزة الاستغناء عن الامتدادات مفيدة على الإطلاق. لدينا الكثير من خدمات الويب التي بدأت بنفس الأحجام المعينة ، ومجموعة متغيرات البيئة والتسميات. لديهم أيضًا نفس سياسات الفحص الصحي. ناهيك عن الموانئ. يعد دمج ملفات الإنشاء باستخدام خيار متعدد - f أمرًا مملًا وعرضة للخطأ إذا كنت تتعامل مع مشاريع متعددة في نفس المضيف.

@ shin- هل سيعاد هذا إلى المخطط 3.2؟

أود حقًا إعادة extends إلى تنسيق الملف. لقد كنت أستخدمه لتحسين الخدمات المجردة بشكل أكبر لعدد من المشاريع. أتفهم أن خيارات -f المتعددة تناسب الفاتورة تقريبًا ، لكنها لا تعمل دائمًا. على سبيل المثال ، غالبًا ما أقوم بتغيير اسم الخدمة المجردة إلى شيء أكثر أهمية في سياق المشروع قيد البحث. هذا شيء لا يدعمه التجاوز الذي يحدث مع خيارات -f المتعددة.

لا أمانع في خسارة extends بالضبط ، طالما أنها طريقة أخرى لـ "إنشاء مثيل" لخدمة مجردة في ملف.

لدي إعداد مع ملف خدمة مشترك ومجموعة من الخدمات التي تمدها ، وتغير في الغالب الأحجام ، لذلك أود أن أقول إنني أعتمد على ميزة extends ولا أرى طريقة جيدة أخرى لوصف الإعداد الخاص بي.

--frustrated

+1
يمكنني رؤية المنطق الكامن وراء التوصية بتسوية ملفات إنشاء عامل ميناء ، لكنني لا أحب فكرة تكرار الكود الذي يحدد طوبولوجيا خدمة التطوير لدينا عبر مشاريع متعددة. سنستخدم الحل البديل -f في الوقت الحالي ، مع البرامج النصية للصدفة بحيث لا يضطر المطورون إلى تذكر الخدمات التي يجب تضمينها في أي الحالات.

آمل أن يتم العثور على حل مرض هنا لتمكين تحليل هياكل التركيب بشكل أفضل!

في الجزء العلوي من قائمة حالات الاستخدام الخاصة بي ، توجد مجموعة خدمات DRYup التي يديرها التكوين الخاص بي. اعتقدت أنني سأكون قادرًا على الاستفادة من "الامتداد" إذا كان الإصدار 3. لا أريد العودة إلى الإصدار 2 ... ولا أريد أن يكون لدي حالات خاصة حيث يجب أن أستخدم الحل البديل للعملية -f.

مرحبًا ، هل بدأ أحد العمل على هذا؟ لا يمكنني العثور على علاقات عامة لتتبعها. سيبسط الكثير من الأشياء بالنسبة لنا هنا أيضًا (حالة الاستخدام تشبه إلى حد بعيد بعض الحالات الموضحة أعلاه).

نظرًا لأن الإصدار 3 تم تجميده وكنت بحاجة إلى طريقة لمشاركة التكوين المشترك ، فقد اخترقت حلًا صغيرًا ، أعتقد أنه يمكنني مشاركته هنا (لست متأكدًا مما إذا كان هذا هو المكان المناسب ولكن لا تتردد في إخباري أين يمكنني ذلك شارك هذه المعلومات :))

لن أتناولها بالتفصيل هنا ، نظرًا لوجود ملف تمهيدي في الريبو.
أتمنى لك واحدة لطيفة ، الجميع ☮️

يحرر:

عذرا ، ها هو الرابط: د

+1

+1

+1

شكرا على 1s 💃
في غضون ذلك ، عثرت على صورة docker noop أخرى ، والتي كانت أصغر بمعامل 10 ^ 3 (نظرًا لأن noop الفعلي يتم كتابته في التجميع).

لسوء الحظ ، لا يوجد ترخيص في هذا الريبو. لقد كتبت بالفعل رسالة إلى المالك على facebk لكنه لم يرد بعد. ربما سيضيف ترخيصًا إذا سأله المزيد من الأشخاص عنه :)

شيء قد يساعد بعض حالات الاستخدام الممتدة (تلك الموجودة في ملف واحد) سيكون دعمًا لمثبتات YAML: https://learnxinyminutes.com/docs/yaml/

يبدو أن مخطط JSON ربما أخفق في التحقق من صحتها service must be a mapping, not a NoneType. .

مرحبًا ، grayside ، تعمل مراسي yaml ، على الأقل بالنسبة لي. انظر تعليقي أعلاه لمعرفة كيفية استخدامها.

حسنًا ، لكن من المحزن جدًا استخدام بعض الخدمات noop ، أليس كذلك؟

ما نوع القيم التي يتعامل معها هؤلاء الأشخاص؟ إذا كان الأمر يتعلق بالأسرار ، فاستخدم ميزة أسرار الأسرار (أو أي حل أسرار آخر). إذا كان الأمر يتعلق بالإعدادات ، فنحن على ما يرام في أن معظم إعدادات الوقت مخصصة للتطبيق / الخدمة ، وليس الغرض منها مشاركتها بين الخدمات.

إذا كنت بحاجة إلى مشاركة الإعدادات بين الخدمات ، فمعظم الوقت يكون هذا هو الوقت الذي تقوم فيه بتشغيل نفس صورة الحاوية ولكن لأغراض / مهام مختلفة لوقت التشغيل (المستهلك ، المنتج ، عامل http ، ...).

إذا كان الأمر يتعلق بالإعدادات ، فنحن على ما يرام في أن معظم إعدادات الوقت مخصصة للتطبيق / الخدمة ، وليس الغرض منها مشاركتها بين الخدمات.

أنا أميل إلى الاختلاف. في المشروع الذي أعمل عليه حاليًا ، أستخدمه على سبيل المثال لوحدات التخزين:

# Volume paths
environment:
  - &volume_a        volume-a:/usr/share/my_project/volumes/volume-a
  - &volume_b        volume-b:/usr/share/my_project/volumes/volume-b
  - &volume_c        volume-c:/usr/share/my_project/volumes/volume-c
  - &volume_d        volume-d:/usr/share/my_project/volumes/volume-d

يمكنني الآن تحديد هذه الأحجام من هذا القبيل:

volumes:
  - volume-a:
  - volume-b:
  - volume-c:
  - volume-d:

services:
  some-service:
    image: some-image
    volumes:
      - *volume_a
      - *volume_b

  some-other-service:
    image: some-other-image
    volumes:
      - *volume_b
      - *volume_c

  some-third-service:
    image: yet-another-image
    volumes:
      - *volume_a
      - *volume_b
      - *volume_c
      - *volume_d

هذا يجعل من السهل التنقل بين وحدات التخزين المختلفة دون الحاجة إلى التفكير في الحاوية التي تكون فيها. Imho ، هذه طريقة واحدة لجعل إعداد Docker-compose أكثر اتساقًا وأسهل في الاستخدام والصيانة.

حسنًا ، نعم أفهم JanNash ولكن في

لكن المراسي ليست كافية للعديد من الحالات.

تتضمن حالتي دعم العديد من البيئات لنفس المشروع. يمكنك أن ترى سقالات لمشاريعنا هنا .

عند التطوير ، تستخدم devel.yaml ، لكن في الإنتاج تستخدم prod.yaml . هناك أيضًا test.yaml . كل منهم يرث من common.yaml ويحصل على بعض المتغيرات الشائعة من ملف .env .

كل واحد له خصائصه الخاصة:

• تهدف بيئة التطوير إلى سرعة التطوير ، لذا فهي تستخدم إنشاءات لإنشاءات أسرع ، وتحميل وحدات التخزين برمز التطبيق من كمبيوتر المطور ، وإضافة بعض الخدمات الوهمية التي تعزل التطبيق عن العالم الخارجي.
• يهدف prod إلى الاستقرار بدلاً من ذلك ، لذلك يقوم بتنزيل جميع التعليمات البرمجية وتجميعها وتجميعها في الصورة نفسها بدلاً من استخدام وحدات التخزين. المباني أبطأ لكنها أكثر أمانًا.
• يهدف الاختبار إلى أن يكون تمامًا مثل المنتج ، ولكن مع العزلة عن الخدمات الخارجية ، لتجنب تلويث العالم الخارجي.

يسمح هذا الفصل البسيط بالحصول على خط أنابيب DevOps رشيق ومرن للغاية ، حيث يستخدم الجميع نفس الكود بين المراحل المختلفة ، مع القليل من التعديلات اعتمادًا على البيئة المستخدمة.

حاولت الانتقال إلى إنشاء تنسيق ملف v3 ، ولكن ليس فقط extends غير مدعوم ، ولكن أيضًا .env ، لذلك في الوقت الحالي سيكون كابوسًا للصيانة (أكثر بسبب نقص .env ، أن نكون صادقين). عند الاختيار بين Swarm و DRY ، اخترنا DRY في الوقت الحالي ، لكن في يوم من الأيام سنحتاج إلى Swarm وآمل أن يتم دعم كلتا الميزتين مرة أخرى في ذلك اليوم ... ☺️

... أو على الأقل لدينا طريقة لإنشاء تنسيق صالح بدون جفاف من حل DRY-ful. اعتقدت أن docker-compose bundle كان لذلك ، ولكن يبدو أنه محكوم عليه بالإهمال الآن ...

... أو لدينا أداة مختلفة تصنع كل شيء (أنا أراقب الحاوية غير المرغوبة أيضًا). لكن بالتأكيد هذا ليس "الإصلاح".

يشتمل الرابط الموجود في https://github.com/moby/moby/issues/31101#issuecomment -301212524 على README مع مثال عملي لمثبتات YAML. بالنظر إليها وتجربتها مرة أخرى اليوم ، فإنها تعمل بشكل جيد. لست متأكدًا مما أفعله بشكل مختلف.

تضمين التغريدة

Yajo أسمعك وكما قيل ، إنه حل بديل وسيكون من الأفضل بترتيب من حيث الحجم إذا كان هناك حل جيد مدمج وجاف يتم توفيره بواسطة docker / moby / docker-compose (أيًا كان المرجع الصحيح) . دعونا نأمل جميعًا أن يأتي ذلك قريبًا لأنه بصرف النظر عن ذلك ، أنا سعيد جدًا بتأليف عامل الميناء 👍

~ من أجل فقدان دعم .env ، قمت أيضًا باختراق حل بديل (مشروعي ليس قيد الإنتاج بعد ، لذا فإن حديثي رخيص بعض الشيء ، أعرف :)). لدعم مجموعات مختلفة من متغيرات البيئة (التبعية وإصدارات / علامات الصور ، على سبيل المثال) في بيئات مختلفة (بالنسبة لي الآن ، هذا تطوير محلي وخادم تطوير صغير) ، أستخدم ملفين ، local.env و development.env وبدلاً من تشغيل أوامري من خلال docker-compose <command> ، إما أن أصدر ملف .env المعني في قشرتي من قبل ، أو أشغّله على النحو التالي: (. local.env && docker-compose <command>) . لا يزال اختراقًا ، لكن في الوقت الحالي ، أنا سعيد جدًا بهذا

أتمنى لك واحدًا لطيفًا ، أنتم جميعًا 🚶

ربما حتى اثنين من حيث الحجم: د

تضمين التغريدة هل .env غير مدعوم في 3 ؟

لا أعرف في الواقع ، لقد قرأت للتو في تعليق أنه لم يكن كذلك.
لقد كنت أستخدم إجراء local.env و development.env بشكل أساسي لأنني لم أكن أعرف شيئًا عن autoenv عندما قمت بتطبيقه: D
آسف للارتباك المحتمل.

آه، ذكرYajo المفقودين .env الدعم في هذا التعليق .
هل يمكن أن توضح ،Yajo؟

أوه آسف خطأي. لا يعني ذلك أنه لا يعمل ، إنه فقط يجب عليك

هل المناقشة لإسقاط extends أي مكان؟ أرغب في قراءتها قبل تقديم حالة الاستخدام الخاصة بنا لأنني أعتقد أنه من المفهوم جيدًا أنها كانت ميزة مستخدمة بشكل جيد.

مرحبا لدي سؤال واحد - متى؟ متى "يمتد" الدعم سوف يعود في v3؟

JanNash يمكنك الحصول على طريقة أصغر فائقة من ذلك. لقد قدمت للتو مشكلة في github ضد الريبو الخاص بك ، لقد حصلت على noop وصولاً إلى 1200 بايت من 750 كيلو بايت على جهازي.

أرى أنه لا يمكنني استخدام التمديد في الوقت الحالي في سرب.
هل لديك أية أفكار حول كيفية تشغيل نفس الخدمة بنفس منافذ النشر ، وبحاوية واحدة على الخدمة بها متغير بيئة إضافي واحد؟

+1 لتوسيع الدعم في نشر مكدس السرب

أهلا،
نحن نقوم بتشغيل تطبيق الخدمات المصغرة المنتشر في مستودعات git المتعددة (كل واحد يحتوي على ملف docker-compose الخاص به).
تتم عملية النشر بواسطة ملف إنشاء عامل ميناء "جذر" يقوم بتوسيع كل خدمة: بالنسبة لنا هذه الميزة extends مطلوبة بالفعل لنشر المكدس.
لذا +1 أيضًا لتوسيع الدعم في نشر مكدس السرب
شكرا.

يمكنك استخدام توريث YAML البسيط (انظر &default ، <<: *default ) كحل مؤقت:

version: '3'
services:
  worker: &default
    build: .
    command: bundle exec rake jobs:work
    env_file:
      - .env
    volumes:
      - .:/app
    depends_on:
      - db
      - redis
    links:
      - db:postgres
  web:
    <<: *default
    command: bundle exec puma -C config/puma.rb -p 3000
    ports:
      - "3000:3000"
  spring:
    <<: *default
    command: bundle exec spring server

بالطبع ، ميزة extends أفضل

ماذا عن عندما تقوم بتمديد ملف مختلف؟

لا يحتوي Yaml على خاصية تمديد الملف :(

هل هناك أي تحديث لهذه الميزة من أحد المساهمين في Docker؟ هل هذا مخطط لإعادة تقديمه؟ إذا لم يكن كذلك ، فهل هناك خطط لشيء مماثل؟ إذا لم يكن كذلك ، فلماذا لا ..؟

quolpr ، أخشى أن رمز "YAML simple وراثة" لا يحل محل extends في معظم الحالات لأن "النموذج الأولي" (على سبيل المثال &default ) سيتم تفسيره دائمًا بواسطة Docker Compose خدمة تسمى worker . أي خدمة أ) تحتاج إلى تعريف جيد ، ب) قد تكون غير مرغوب فيها.

على أي حال ، بالتأكيد ميزة مثيرة للاهتمام.

laugimethods ، يمكنك أيضًا استخدام مراجع YAML:

version: '3'
services:
  spring:
    build: ./app
    command: /bin/sh -c "bundle exec spring server"
    volumes: &default_volumes
      - ./app:/app:delegated
      - bundle:/bundle:nocopy
  worker:
    build: ./app
    command: bundle exec sidekiq -v -C config/sidekiq.yml
    volumes: *default_volumes

(انتبه إلى &default_volumes و *default_volumes )

لكنني حقًا لا أستطيع أن أفهم سبب إزالة ميزة extends 🤔

لمعلوماتك ، لاستبدال ميزة "extends" المفقودة ، أستخدم الآن تكوينًا / دمج ملفات .yaml :
https://github.com/Logimethods/smart-meter/blob/master/README.md#docker -compose

يمتد الأعمال ، ببساطة وناضجة ، أعتقد أنه إذا رأى شخص ما الامتدادات على أنها بعض النمط المضاد ، فلا تستخدم ذلك ، ولكن من فضلك لا تقطعه

هل لي أن أطلب شرحًا واضحًا للنهج المقصود دون استخدام extends ؟ أنا أستخدمه على نطاق واسع ، لا سيما عند الوراثة من الملفات الموجودة في وحدات Git الفرعية ، مما يسمح بتعريف مشروع ميتا يتعامل مع الأسلاك الشبكية عبر التطبيقات ، وما إلى ذلك. على الرغم من أنني أدرك جيدًا أنه يمكنني تحديد عدة ملفات docker-compose.yml و هل تم تجاوزها ، فهل هذا يعني أنني سأحتاج إلى تحديد الترابطات في سطر الأوامر ، بدلاً من التمكن من فحصها في التحكم بالمصادر باستخدام extends ؟ أو هل فاتني بعض الميزات الجديدة في مكان ما في الإصدار 3؟

أنا أستخدم extends بكثافة في مشاريع متعددة لتوريث مجموعة مشتركة من سمات الخدمة لبيئة مختلفة ومضيفين مختلفين (اقرأ: أستخدم extends للوراثة من ملف مختلف).

بعد أن قرأت في ذهول إزالة الكلمة الرئيسية extends ومحاولة العثور على بديل لا يتطلب تسلسل أقحوان -f docker يؤلف الملفات ، أشعر بالفضول الشديد ما هو سبب إزالة extends .

أتفهم مشكلة links و volume-from ولكن مجرد الامتناع عن استخدامها في ملفات yml الأساسية يبدو أن أفضل شيء يمكن فعله.

سيكون من غير المحتمل إزالة عجلة السيارة لمجرد أنها _ربما _ تعتاد على قلب السيارة رأسًا على عقب ... أليس كذلك؟

ملاحظة: تبدو noop and anchors مثيرة للاهتمام ولكنها تضيف تعقيدًا غير ضروري إلى أبسط المشاريع ...

كمثال بسيط للغاية:

common/common.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  ports:
    - "8080:8080"

prod/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  image: the-prod-image:latest-release
  ports:
    - "80:80"
    - "80:443"
  environment:
    NEW_RELIC_KEY:

فقط كيف تحافظ على مبادئ جاف دون extends ؟

لا أرى حاليًا أي سبب للترقية من الإصدار 2.1 بسبب ذلك.

teodorescuserban ،

تسلسل أقحوان - f docker يؤلف الملفات

ما المشكلة في ذلك؟ يمكنك إنشاء البرامج النصية الخاصة بك بأسماء مستعارة قصيرة للاتصال بـ docker-compose.

استخدم الهيكل التالي:

مشترك / مشترك. iml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev / docker-compose.yml

services:
  web:
    ports:
      - "8080:8080"

prod / عامل ميناء-compose.yml

services:
  web:
    image: the-prod-image:latest-release
    ports:
      - "80:80"
      - "80:443"
    environment:
      NEW_RELIC_KEY:

أوامر

docker-compose -f common/common.yml -f dev/docker-compose.yml -p myproject up --build

docker-compose -f common/common.yml -f prod/docker-compose.yml -p myproject up --build

لم أكن أعرف هذه الميزة. على الرغم من أنه يجعل CLI الخاص بك 💩 ، إلا أنه يمكن أن يعمل.

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

على سبيل المثال:

عامل ميناء compose.yml

version: "3"  # or whatever
extend:
  - ./common/common.yml
  - ./dev/docker-compose.yml
services: # Not required now
  # etc.

بهذه الطريقة يمكنك الإشارة إلى ملف واحد docker-compose.yml يقوم بكل ما تحتاجه.

قد يكون البديل المفيد هو دعم ملفات تكوين متعددة في COMPOSE_FILE env var.

تضمين التغريدة

قد يكون البديل المفيد هو دعم ملفات تكوين متعددة في COMPOSE_FILE env var.

من https://docs.docker.com/compose/reference/envvars/#compose_file :

يدعم هذا المتغير عدة ملفات إنشاء مفصولة بفاصل مسار (في Linux و macOS ، يكون فاصل المسار هو : ، وفي Windows يكون ; ). على سبيل المثال: COMPOSE_FILE=docker-compose.yml:docker-compose.prod.yml . يمكن أيضًا تخصيص فاصل المسار باستخدام COMPOSE_PATH_SEPARATOR .

@ dermeister0 يمكنك أيضًا دمج هذه الملفات بشكل دائم باستخدام أدوات مثل https://github.com/ImmobilienScout24/yamlreader :

> yamlreader common/common.yml prod/docker-compose.yml > docker-compose-prod.yml
> docker-compose -f docker-compose-prod.yml -p myproject up --build

> cat docker-compose-prod.yml
services:
    web:
        build: .
        environment:
            DOMAIN: null
            NEW_RELIC_KEY: null
            PREFIX: null
        image: the-prod-image:latest-release
        ports:
        - 80:80
        - 80:443

@ dermeister0 أشكرك على اقتراحك للأسف إنه طريقة صعبة للخروج منه. باستخدام extends أزل الحاجة لمعرفة بالضبط كيف تحتاج إلى سلسلة ديزي. بينما يمكنني التعايش مع القيام بذلك بنفسي ، لا يمكنني أبدًا تطبيق هذا الحل على مطوري الأعزاء.

ومع ذلك ، لم أكن أدرك أن المتغير env COMPOSE_FILE يمكن أن يحتوي على قيم متعددة. شكرا لك gsong ! هذا رائع ويمكن استخدامه (أنا أحدده في ملف .env ). توجد مشكلة واحدة هنا: في الملفات الأساسية / الشائعة ، قد يكون لدي أيضًا بعض الخدمات التي لا أحتاجها.

خذ على سبيل المثال ملفًا مشتركًا ثابتًا يحدد قاعدة البيانات وحاويات الويب. عند التدريج ، تريد تجميعها جميعًا معًا ولكن في prod قد ترغب في مضيفين منفصلين لـ db والويب.

أيضًا ، يتم تحميل docker-compose.override.yml افتراضيًا.

https://docs.docker.com/compose/extends/#understanding -multiple-compose-files

أستخدم هذا الأسلوب مع الإصدار 3.3:

• ضع خيارات التكوين الشائعة والخدمات في docker-compose.yml ؛
• استخدم docker-compose.override.yml لتكوين تطوير وخدمات معينة (مثل xdebug على سبيل المثال) ؛
• استخدم docker-compose.staging.yml لخيارات تكوين التدريج المحددة.

ملاحظة: لا أقوم بتشغيل Docker في الإنتاج.

باستخدام هذا الأسلوب يمكنني بسهولة الإنشاء محليًا باستخدام docker-compose build وعندما أنشر على التدريج أستخدم:

docker-compose -f docker-compose.staging.yml -f docker-compose.yml build

أنا أستخدم Apache ، وليس لدي ملفات مضيفة افتراضية منفصلة للتطوير والتشغيل المرحلي. لقد قضيت وقتًا طويلاً لتجنب وجود ملفات مختلفة. في النهاية ، رأيت أن الأسلوب الوحيد الصالح هو استخدام <IfDefine> ومتغيرات البيئة (التي قمت بتعيينها في قسم البيئة لملفات yml) ، لتضمين تكوين ssl على سبيل المثال. وأنا أستخدم TLD وبادئة المجال ، لذا يمكنني الحصول على شيء مثل www.example.local http: //www.example.local/ : 8080 و www.staging.example.com http://www.staging.example.com / . محليًا ، تعمل مواقع الويب تحت http وعلى التدريج على https. باستخدام هذا الأسلوب ، لا يتعين علي الاحتفاظ بإصدارات مختلفة من الملفات. أعتقد أنه يمكن فعل الشيء نفسه في الإنتاج ، لكن كما قلت ، أفضل تجنب Docker في الإنتاج ، أجهزة الصراف الآلي.

المسارات كلها أقارب ، لذلك ستعمل الحاويات في أي بيئة.

2 سنتي

-فيليبو

في حالتي ، استخدمت سابقًا شيئًا كهذا:

• مشترك. iml
• devel.yml -> تمديد common.yml
• prod.yml -> تمديد common.yml
• docker-compose.yml -> محلي ، تجاهل git ، ارتباط رمزي بالبيئة المرغوبة (تطوير أو إنتاج).

بفضل https://github.com/moby/moby/issues/31101#issuecomment -329482917 و https://github.com/moby/moby/issues/31101#issuecomment -329512231 ، والتي لم أكن أعرف عنها ، يمكنني الآن الانتقال إلى الإصدار 3 باستخدام مخطط مختلف:

• docker-compose.yml -> ما كان شائعًا سابقًا
• devel.yml -> تجاوز عامل الإرساء-compose.yml
• prod.yml -> تجاوز عامل الإرساء-compose.yml
• docker-compose.override.yml -> محلي ، تجاهل git ، ارتباط رمزي بالبيئة المرغوبة (تطوير أو إنتاج).

يمكنني أيضًا القيام بأي عمليات اختراق لازمة باستخدام المتغير env ، لذلك في حالتي تم إصلاح المشكلة. شكرا! 🎉 (آسف ، كان يجب أن أقرأ المستندات الجديدة بشكل صحيح قبل تقديم الشكوى).

ملاحظة: مع ذلك ، سيكون من الجيد استرجاع extends ، لكن على الأقل لدينا بديل عادل بما فيه الكفاية. 😊

@ shin- في البداية شعرت بخيبة أمل كبيرة لرؤية ميزة extends مفقودة في 3.0 ، لكن مذيعي YAML (مثال: https://github.com/JanNash/docker-noop) سيكون أكثر من بديل كاف.

الشيء الوحيد هو أنه ، كما في المثال أعلاه ، تحتاج إلى وضع نقاط الارتساء الخاصة بك في قسم صالح من ملف docker-compose.yml .

هل يمكننا الحصول على خاصية (المستوى الأعلى) templates أو مفاتيح مخفية كما هو الحال في GitLab لتكون أكثر مرونة في طريقة تحديد

@ schmunk42 ألق نظرة على https://github.com/docker/cli/pull/452

تكمن مشكلة الاعتماد على docker-compose.override.yml في أنه يفترض مسبقًا أن لديك نوعًا واحدًا فقط من التجاوزات التي تحتاج إلى تضمينها وطبقة واحدة من التجاوزات.

في حالتي ، أريد أن يكون لدي بعض السلوكيات المشتركة لجميع التطويرات المحلية ، ولكن قد أحتاج إليها أن تكون مختلفة بمهارة إذا كان المطور يعمل بنظام Windows أو OSX أو Linux. للحفاظ على هذا الأمر قابلاً للإدارة في سياق v3 docker-compose ، لدي مستخدمي Linux يعملون على نفس السلوك مثل بيئة التدريج ، والتي تعمل ولكنها تعني أنهم بعيدون قليلاً عن المطورين الآخرين.

أتجنب استخدام -f للتنمية المحلية لأنني وجدت أنه عرضة جدًا للخطأ البشري ، والاعتماد عليه كبديل للعديد من الأشياء يسبب مشاكل. اختيار ملف واحد يبدو معقولًا ، واختيار متعدد شيء أتجنب فرضه بعناية.

لمعلوماتك، أعتقد أنه بمجرد أن الإختراق مع x- المذكورة أعلاه، وكذلك تسلسل ديزي ملفات عامل ميناء يؤلف باستخدام COMPOSE_FILE متغير في .env ملف المشروع، إضافة docker- يجب أن يحل compose.override.yml كل حالة استخدام واجهتها حتى الآن.

المراسي yml هي أيضًا شيء أنيق أنوي استخدامه في المستقبل القريب.

لست سعيدًا جدًا بجمال الاختراق x- ولكن يمكنني التعايش مع ذلك.

شكرا يا رفاق لالمدخلات الخاصة بك!

يبدو أن إزالة extends يسبب الكثير من الحموضة المعوية وإما منع الانتقال إلى الإصدار v3 أو اللجوء إلى الاختراقات. أحب القدرة على تحديد خدمة "نموذج" (أو مجردة) يمكنها أن تحمل بعض الأشياء الشائعة (مثل سياسات التحديث)

أنا أعمل على أداة تصفية golang بسيطة يمكنها معالجة ملف إنشاء عامل ميناء باستخدام extends وإخراج ملف نظيف v3 مع حل الامتدادات:
تصميم العزم نشر كومة عامل ميناء -c docker-compose.yaml
(or docker-compose up)

هل سيعمل هذا على الأقل على بعض حالات الاستخدام الخاصة بك / لماذا مسكنا؟

pnickolov سيكون ذلك رائعًا بالنسبة لي.

لقد كنت أبحث عن حاوية غير مرئية (أستخدمها بشكل شخصي ، ولكني لم أعمل بعد) ، والتي يبدو أنها ستفعل كل ما أحتاجه ، لكن نصًا مثل نصك سيكون أكثر تفضيلًا (أقل إزعاجًا)

طالما أنه يمكنه معالجة المفاتيح extends: بشكل متكرر ، فسأكون سعيدًا!

حسنًا ، يبدو أننا وجدنا بدائل لـ extends ... 👍

الأمر المقلق هو حقيقة أن Moby's Project Management لا يبدو أنها تفكر في الحفاظ على التوافق كعنصر أساسي. يعد التوافق الأمامي أمرًا ضروريًا للتبني على نطاق أوسع ، خاصة للتطبيقات الكبيرة التي يتم نشرها في الإنتاج. كيف يمكننا الضغط من أجل Docker Swarm / Docker EE عندما لا يوجد ضمان بأن الميزات الأساسية مثل extends ستبقى؟ 👎
من الصعب كسب السمعة الطيبة ومن السهل خسارتها ...

أنا شخصياً أفضل الاعتماد على ميزات YAML الأصلية لإنجاز المهمة التي تتم معالجتها بواسطة بناء جملة extends في صيغة v2 ، بدلاً من نص مخصص أو حل أكبر مثل غير مرغوب فيه. كنت أواجه مشكلات مماثلة في وقت سابق وبدأت في كتابة المحول الخاص بي قبل أن يكون هناك حل مثل استخدام ملفات .yml متعددة وما إلى ذلك. (https://github.com/schmunk42/yii2-yaml-converter-command) - لكن لم يكن حل قابل للتطبيق.

بالنسبة لي ، من الجيد أيضًا إهمال الميزات ، إذا تم ذلك جنبًا إلى جنب مع سياسة الإصدار ؛ لا يمكنك حمل الأشياء القديمة إلى الأبد ، حتى لو كان هذا يعني بعض العمل من جانبنا.

@ schmunk42 يعد إهمال الميزات

• الميزة التي تمت إزالتها لم تعد مستخدمة حقًا أو أنها مانع حقيقي للتطورات
• أعلن مقدما
• يتم توفير مسار الهجرة على الفور

للأسف ، لا ينطبق أي من هذه المتطلبات (في كتابي) على إيقاف العمل بـ extends ...

laugimethods ما سبب احتياجك لاستخدام v3 ؟

@ schmunk42 بسبب سرب:

تم تصميم الإصدار 3.x ، الإصدار الأحدث والموصى به ، ليكون متوافقًا بين وضع التأليف ووضع سرب محرك Docker. هذا محدد بإصدار: "3" أو إصدار: "3.1" ، إلخ ، الإدخال في جذر YAML.

يدعم أمر Docker stack publishing أي ملف Compose من الإصدار “3.0” أو أعلى

راجع للشغل ، تعليقي لا يتعلق فقط بـ extends ، ولكن بأي إهمال (مؤلم) قد يحدث في المستقبل ...

نعم ، نحن نواجه نفس المشكلة بسبب وضع السرب.

سألت نفسي في المقام الأول ، لماذا بحق الجحيم يمكن لـ Docker CLI الآن استخدام إدخال --composer-file . ولكن من تعلمنا باستخدام docker/swarm ، يبدو الأمر معقدًا جدًا لتشغيل مكدسات على سرب (ذاتي الإدارة) وأن هناك عدة أسباب وجيهة لنقل هذا إلى المحرك.

فقط لألاحظ بعض النتائج التي توصلت إليها هنا ... الانتقال من v2 إلى v3.4 بعيدًا عن أن يكون سهلاً.

بعض مشاكلي:

• هناك خيارات أخرى غير مدعومة مثل volumes_from ، يسهل التحايل عليها ، لأننا أردنا إزالتها على أي حال
• .env (مثل ملفات docker-compose ) ليس لها تأثير مع Docker CLI
• يبدو أن تحديد ملفات إنشاء متعددة ( docker stack deploy -c docker-compose.yml -c docker-compose.override.yml doro ) لا يعمل بشكل صحيح ، ولا يوجد خطأ ، ولكن يبدو لي أنه لم يتم دمجها بشكل صحيح - ولكن لا يوجد أمر مثل docker-compose config للتحقق من ذلك
• لا يوجد برنامج ثنائي "سهل التثبيت" (ما قبل الإصدار) لـ docker-compose والذي يدعم بناء الجملة v3.4 ؛ مثل Docker edge
• يجب إنشاء الشبكات الخارجية --scope swarm

CC:handcode

باستخدام أحدث البنيات

• عامل ميناء 17.09.0 م
• عامل تركيب 1.17.0dev

أنا الآن أستخدم خط أنابيب التكوين هذا لاستبدال استخدامي لـ _extend_ و _ noop_
يحافظ على الأشياء أكثر جفافاً
أمل أن هذا يساعد شخصاما

base.yml (تعريفات مشتركة ، هذا مستند yaml صالح ، لذا قابل للدمج باستخدام _docker-compose config_)

version: '3.4'
networks:
  net_back:
    external: true

base-injection.yml (تعريفات الربط المشتركة ، للأسف لا يمكن إضافتها إلى base.yml حيث لا يمكن الإشارة إلى الارتساءات عبر ملفات yaml المختلفة ، بدلاً من ذلك يتم إدخالها كنص في foo.yml ، وهي ليست طريقة مثالية للقيام بذلك)

x-logging: &logging
  driver: json-file
  options:
    max-size: "50m"
    max-file: "2"

foo.yml (عام تعريف المكدس، مراجع الكائنات من base.yml، المراسي من قاعدة inject.yml والكائنات تجاوز في فو dev.yml)

version: '3.4'
[[base-inject]]
services:
  foo:
    image: ${DOCKER_REGISTRY}/foo:${IMAGE_VERSION}
    volumes:
      - type: volume
        source: "volfoo"
        target: "/foo"
    networks:
     - net_back
    logging:
      <<: *logging

foo-dev.yml (حسب تعريف مكدس البيئة)

version: '3.4'
services:
  foo:
    ports:
      - "8080:80"
volumes:
  volfoo:
    name: '{{index .Service.Labels "com.docker.stack.namespace"}}_volfoo_{{.Task.Slot}}'
    driver: local

ثم أمر النشر:

docker stack rm stack_foo && echo "waiting..." && sleep 3 &&
  cat foo.yml | sed -e '/base-inject/ {' -e 'r base-inject.yml' -e 'd' -e '}' > ./foo-temp1.yml &&
  export $(sed '/^#/d' ./dev.env | xargs) &&
  docker-compose -f base.yml -f ./foo-temp1.yml -f foo-dev.yml config > ./foo-temp2.yml
  docker stack deploy --with-registry-auth --prune --compose-file ./foo-temp2.yml stack_foo

1. إزالة المكدس القديم
2. انتظر حتى تنتشر المكدس القابل للإزالة
3. حقن المراسي في تعريف عام ، حفظ في ملف tmp
4. قراءة + تعيين متغيرات ملف env من الملف
5. استخدم عامل إنشاء لدمج الملفات الثلاثة معًا
6. نشر ملف مدمج

بالنسبة لأولئك الذين يتوقون إلى ما بعد extends في إنشاء أكثر من 3 ملفات ، فقد وضعت يدي للتو على أداة تسمى baclin . baclin بوضع هذه التوجيهات بشكل خطي ، مع استبدال جميع توجيهات extends بشكل متكرر بمحتواها. هذا هو برنامج ألفا ، الكود هو جزء من أجهزتي حيث أقوم حاليًا بكتابة التعليمات البرمجية لدعم وضع Swarm ونشر المكدسات. ثنائيات النظام الأساسي لإصدار مبكر من baclin متوفرة هنا . الرجاء الإبلاغ عن أي تعليق أو قضية هنا .

هذا حقا محير!
يجب أن تكون هذه الميزة متاحة عند قراءة مستند الإصدار الأخير من عامل الإرساء ( v17.09 ) وأيضًا مستند الإصدار v17.06 .

$ head -n1 docker-compose.yml
version: '3'

لكن عوائد compose up

ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.admin_application: 'extends'

عند استخدام الكلمة الأساسية extends .
أيضًا ، لا يمكنني العثور على أي شيء حول إزالة extends في سجل التغيير compose .

الآن ما هو ؟!
لا ينبغي أن يكون من الصعب العثور على معلومات حاسمة مثل هذه أو إخفاؤها داخل بعض مشكلات جيثب الغامضة.

$ docker --version
Docker version 17.09.0-ce, build afdb6d4

$ docker-compose --version
docker-compose version 1.16.1, build 6d1ac21

jottr ، راجع المستندات :

يتم دعم الكلمة الأساسية الموسعة في تنسيقات ملفات Compose السابقة حتى إصدار ملف Compose 2.1 (انظر يمتد في v1 ويمتد في v2) ، ولكن لا يتم دعمه في إنشاء الإصدار 3.x.

لذلك إذا كنت تريد استخدام extends فأنت بحاجة إلى استخدام version: '2.1' .

خطأي. يجب أن يظل في أعلى المستند بعلامة تحذير حمراء للإيقاف.

خطأي. يجب أن يظل في أعلى المستند بعلامة تحذير حمراء للإيقاف.

jottr فقط استخدم Github لإنشاء مشكلة منفصلة لذلك أو حتى إنشاء https://github.com/docker/docker.github.io/issues/5340

في حالتي ، لدي docker-compose-override.yml النحو التالي:
yaml version: "3.4" services: common: extra_hosts: - "host1:172.28.5.1" - "host2172.28.5.2" - "host3:172.28.5.3" networks: default: external: name: "common-network"
ولدي العديد من ملفات docker-compose.yml التي تحتاج إلى مشاركة الشبكة والمضيفات الإضافية. كيفية القيام بذلك باستخدام ميزة الامتداد بدون؟

yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" hostname: "mongo" volumes: - "/opt/docker/mongo/default.conf:/usr/local/etc/mongo/mongod.conf" - /opt/data/mongo:/data/db" ports: - "27017:27017" command: "mongod --config /usr/local/etc/mongo/mongod.conf" networks: default: ipv4_address: "172.28.5.4"
سيكون من الرائع إذا كان عامل الإرساء يؤلف مرساة yaml والمراجع بين الملفات المختلفة. ربما ، تطبيق المرساة والمراجع بعد دمج الملفات.
على سبيل المثال:
yaml version: "3.4" services: common: &common extra_hosts: ... networks: ...
yaml version: "3.4" services: mongo: <<: *common image: "mongo" container_name: "mongo" ...
يجب أن تكون النتيجة:
yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" extra_hosts: // EXTRA HOSTS HERE networks: ...

@ sandro-csimas هذا ممكن مع: https://docs.docker.com/compose/compose-file/#extension -fields
@ shin- هل يمكن إغلاق هذه التذكرة؟

rdxmb لا أعتقد ذلك. مما يمكنني رؤيته ، لا يمكنك التمديد من ملف إنشاء عامل ميناء آخر

هل أنا محق في التفكير في أن هذه مشكلة لـ https://github.com/docker/compose/issues ؟

بعض التصحيح:

# cat docker-compose.yml 
version: "3.4"
services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

هذا العمل مع
docker stack deploy -c docker-compose.yml test

عند استخدام عامل البناء:

# docker-compose up 
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./docker-compose.yml", line 4, column 10

تغيير ملف yml إلى:

version: "3.4"

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR

يعمل أيضًا مع عامل البناء.

لذلك اعتقدت أن هذا يجب أن يعمل أيضًا مع ملفات متعددة ، وهذا ليس هو الحال:

# docker-compose -f compose-services.yml -f compose-default.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10
t# docker-compose -f compose-default.yml -f compose-services.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10

# cat compose-services.yml 
version: "3.4"

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

# cat compose-default.yml 
x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

ومع ذلك ، بالطبع ، يمكن دمج هذا باستخدام بسيط cat :

# cat compose-default.yml compose-services.yml > docker-compose.yml && docker-compose up -d
WARNING: The Docker Engine you're using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use `docker stack deploy`.

Creating network "test_default" with the default driver
Creating test_foo-bar_1 ... 
Creating test_foo-not-bar_1 ... 
Creating test_foo-bar_1
Creating test_foo-bar_1 ... done

يعمل على xenial بالإصدارات:

# docker --version
Docker version 17.11.0-ce, build 1caf76c
# docker-compose --version
docker-compose version 1.17.0, build ac53b73

@ rdxmb ، شكرا!
لذلك يجب أن أذهب لدمج ملفات الإنشاء باستخدام الأمر "cat" وتنفيذ الملف النهائي.

أستخدم أيضًا docker-compose config للقيام بذلك. مثال للإعدادات الخاصة بالبيئة:

يتم تشغيل هذا بواسطة خط أنابيب CI: docker-compose -f docker-compose.yml -f docker-compose.override.prod.yml config > docker-compose.prod.yml ثم أستخدم docker stack deploy -c .\docker-compose.prod.yml my-stack

التصويت لهذا ، الامتدادات مفيدة جدا ل v3.

استخدمته كثيرًا مع الإصدار 2 ، وهو مفيد جدًا بالفعل!
+1

أرغب في رؤية دعم extends في الإصدار 3. سيساعد ذلك في تجفيف ملف docker-compose.yml كثيرًا.

لقد مر ما يقرب من عام منذ طرح هذه المشكلة ومن الواضح حقًا أن الكثير من الأشخاص يحتاجون إلى هذه الميزة. ومع ذلك ، لم أقرأ استجابة مطور Docker لهذا الطلب على الإطلاق ، ولا تفسيرًا لسبب عدم تضمينه في docker-compose v3 قبل الإصدار.

حالة محزنة للبرامج إذا لم نتمكن حتى من التواصل أو الحفاظ على ميزات لعملائنا الذين يؤمنون بتكنولوجيا جديدة.

أحد التفسيرات المحتملة (وربما أيضًا ملخصًا للموضوع الحالي) للموقف هو كما يلي:

• تحقق نقاط ارتساء / مراجع YAML بالإضافة إلى حقول الامتداد 3.4 نفس الشيء تقريبًا.
• يمكن جعل ملفات متعددة للعمل. انظر إلى cat البسيط والطريقة المتقدمة في هذا الموضوع. يُظهر تعليق النهج البسيط مشكلة إنشاء عامل ميناء تحميل ملفات متعددة في النهاية (هل أنشأ أي شخص مشكلة لذلك؟). إذا تم إصلاح ذلك في docker-compose ، فلن تحتاج حتى إلى دمج الملف على الإطلاق. لذلك بالنسبة لي ، يجب على الأشخاص الراغبين في دعم متعدد الملفات الاستمرار في عامل الإرساء / الإنشاء / المشكلات كما اقترح rdxmb .
• تم النظر في إعادة extends (راجع أحداث مشروع GitHub ، شفافية لطيفة هنا من فريق Docker ، شكرًا!) وقد تفسر النتيجة على أنها "هناك الكثير من الأشياء الأخرى الأكثر أهمية من الناحية الإستراتيجية بالنسبة لهم" ولكن يمكنك لا يزال يكتب طلب سحب extends ما أظن.

بالنسبة لي ، هذه وجهة نظر مفهومة تمامًا.

تضمين التغريدة

IMHO ، على الرغم من أن الأساليب التي ذكرها aCandidMind تعمل ، إلا أنها تضيف تعقيدًا إلى آلية أبسط وأنظف يوفرها extends .
ربما يكون هذا أنا ، لكن نقل تكوين معقد إلى حد ما يؤدي إلى توسيع التكوين إلى حقول الامتداد يصبح من الصعب قراءته وصيانته.
بعد قراءة العديد من التعليقات والمنشورات ، لا يزال من غير الواضح بالنسبة لي سبب إسقاط الامتدادات وما هي مزايا هذا التراجع في القدرات.

من الممكن مع القليل من سحر bash أن أضع ريبوًا تجريبيًا حتى تتمكن من تجربته بنفسك.

ما عليك سوى إنشاء أمر stack deploy النحو التالي:

docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config) <stackname>

tylerbuchea - الجانب السلبي الوحيد لهذا السحر هو أنك قد تحصل على WARNING: Some services (<service-name(s)>) use the '<key>' key, which will be ignored. Compose does not support '<key>' configuration . هذا يمكن أن يسبب بعض الالتباس. لكن مهلا ، إنه يعمل 👍

dnmgns أنت على حق! شكرا لتوضيح ذلك. مثل joaocc قال لا شيء سيتغلب على الدعم المحلي ، لكن الحل الذي ذكرته أعلاه هو أفضل حل يمكن أن أجده نظرًا لعدم وجود تبعيات أخرى غير bash.

tylerbuchea إحدى الطرق القذرة هي إعادة توجيه stderr إلى / dev / null :)
docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config 2> /dev/null) <stackname>

لا عيب فيه 😄

أعتقد أن الوثائق يجب أن تكون أكثر وضوحًا حول هذا الالتباس حول extend .
يعيد وصف extend توجيه المستخدم إلى مستندات "كيفية الترقية" ، ويعيد "محرر مستندات كيفية الترقية" الرجوع إلى الوصف الخاص بـ extend للحصول على مزيد من المعلومات. هذا ليس مفيدًا بدرجة كافية: بصفتي مستخدمًا ، أتوقع بعض المساعدة في كيفية التعامل مع هذه المشكلة برمتها ، وما هي الخيارات المتاحة أمامي وما الذي يجب أن أفكر فيه. أنا متأكد جدًا من وجود فكرة واضحة وراء قرار إزالة extend من الإصدار 3.

ارى:
https://docs.docker.com/compose/extends/#extending -services
https://docs.docker.com/compose/compose-file/compose-versioning/#upgrading

فيما يتعلق بحلtylerbuchea الرائع
للأسف لا يدعم بعض ميزات مكدس Docker المتقدمة:

WARNING: Some services (web) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
WARNING: Some services (web) use the 'configs' key, which will be ignored. Compose does not support 'configs' configuration - use `docker stack deploy` to deploy to a swarm.

ليس هذا منذ أن تم دمج https://github.com/docker/cli/pull/569 ، بدءًا من 18.03 ، وسيدعم docker stack deploy دمج ملفات إنشاء متعددة في ملف واحد. لا يحل محل المفتاح extends بالكامل من تنسيق composefile v2 ولكن نأمل أن يغطي طريقة استخدام أكثر 👼

كان الحل الخاص بي هو استخدام yq (يمكن دمجه في سطر واحد في حالة استخدام Bash):

yq merge --overwrite docker-stack.yml docker-stack.preprod.yml > merged-docker-stack.yml
docker stack deploy -c merged-docker-stack.yml preprod

@ Lucas-C إنها تحذيرات فقط من أن الناتج سيظل يتضمن مفاتيحك deploy و config . يمكنك التحقق من ذلك إذا قمت بتشغيل docker-compose -f docker/prod.yml -f docker/dev.yml config

إنه مخصص لإنشاء ملفات v3.4 وما بعده. وهو يدعم إشارات yaml المتقاطعة (جزئية). انتهيت من هذا البرنامج النصي zsh alias / perl:

alias regen=$'perl -MFile::Slurp=read_file -MYAML=Load,Dump -MHash::Merge::Simple=merge -E \'
  local $YAML::QuoteNumericStrings = 1;
  $n=read_file("/data/docker-compose.yml");
  $s=Dump(merge(map{Load($n.read_file($_))}@ARGV));
  local $/ = undef;
  $s =~ s/\\bno\\b/"no"/g;
  say $s;
  \' $(find /data -mindepth 2 -maxdepth 4 -name docker-compose.yml) >! /data/x-docker-compose.yml'
regen
export COMPOSE_FILE=/data/x-docker-compose.yml

1. اقرأ /data/docker-compose.yml مع الجزء المشترك.
2. اعثر على كل عامل الإرساء يؤلف بشكل متكرر (على سبيل المثال ، هناك حوالي 40 حاوية مختلفة / ملفات docker-compose.yml في هذا المشروع)
3. قم بإرفاق كل عامل ميناء-compose.yml بمحتوى /data/docker-compose.yml
4. دمج
5. احفظ النتيجة في /data/x-docker-compose.yml

الإيجابيات : perl أداة شائعة ، جميع وحدات perl أيضًا ، الجيل سريع.
السلبيات : أكره الاختراق ولكن لا توجد طريقة أخرى لـ DRY. يتكون عامل الإرساء النهائي من حوالي 900 سطر. هل تريد حقًا أن أدعمه كملف واحد من البداية؟ إنه لأمر مخز أن يكون عامل ميناء ثنائي ملفوفًا بقطعة عامل ميناء بيثون ملفوفة بخرق بيرل.

كيف يمكنك فقط إخراج ميزة مثل الامتدادات؟ هذا يبدو وكأنه ميزة أساسية.

أدى استخدام docker-compose config إلى خيار الإدخال القياسي docker stack deploy -c - إلى حل المشكلة بالنسبة لي:

docker-compose -f docker-compose.yml \
               -f docker-compose.extended.yml \
               config \
| docker stack deploy -c - my-stack

لم أجرب هذا ، لكنني لاحظت ذلك أيضًا في وثائق docker stack deploy :

إذا تم تقسيم التكوين الخاص بك بين ملفات تكوين متعددة ، على سبيل المثال تكوين أساسي وتجاوزات خاصة بالبيئة ، فيمكنك تقديم علامات --compose-file .

مع هذا كمثال:

docker stack deploy --compose-file docker-compose.yml -f docker-compose.prod.yml vossibility

https://docs.docker.com/engine/reference/commandline/stack_deploy/#compose -file

هل الأساس المنطقي لإزالة extends موثق في مكان ما؟ لا يبدو أنه موضح في المستندات الرسمية ، على سبيل المثال هنا: https://docs.docker.com/compose/extends/#extending -services
إذا تمكن المستخدمون من فهم الأساس المنطقي ، فيمكن عندئذٍ للمستخدمين تطوير فكرة أفضل عن كيفية الرد على الإزالة. شكرا.

@ shaun-blake انتهى بي الأمر باستخدام ملفات الإنشاء المتعددة. يبدو أن هذا هو النهج الذي يستخدمه الناس. بدلاً من الميراث ، إنه أشبه بمزج. عند البناء أو التشغيل ، أنسخ قالب yaml الخاص بالبيئة الصحيحة إلى docker-compose.override.yml.

ملفات يؤلف عامل ميناء متعددة (على سبيل المثال: base.yml ، local.yml ، prod.yml ) لا يسمح باستخدام خدمة المراسي YAML من الملفات الأخرى بحيث لا يمكن تعريف تعريفات الخدمة يؤخذ من بين الملفات yml متعددة .
ملاحظة ، هذه المشكلة هي رقم 13 الأكثر تعليقًا : https://github.com/moby/moby/issues؟q=is٪3Aissue+is٪3Aopen+sort٪3Acomments-desc والثالث الأكثر إعجابًا .

إذا تمكن المستخدمون من فهم الأساس المنطقي ، فيمكن عندئذٍ للمستخدمين تطوير فكرة أفضل عن كيفية الرد على الإزالة. شكرا.

+1 على التوثيق على الأساس المنطقي لإزالة extends في المقام الأول ...

لم يتم تمديد _ بعد مرور عام ونصف تقريبًا. Cmon ، devs ، u لا تزيل شيئًا دون إعطاء بديل.

لقد فعلوا ، لقد عرضوا بديلًا يسمى التكوين. من فضلك اقرأ إجابتي في الموضوع.

-فيليبو

في 30 يوليو 2018 ، الساعة 09:41 ، كتب Xiaohui Liu [email protected] :

لا يزال لا يمتد بعد ما يقرب من عام ونصف العام. Cmon ، devs ، u لا تزيل شيئًا دون إعطاء بديل.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/moby/moby/issues/31101#issuecomment-408790200 ، أو كتم صوت الموضوع https://github.com/notifications/unsubscribe-auth/AAS_0AOynjpfVnVo4ZqciMbmjksBmkcM3

dedalozzo ، "في الموضوع" ==؟

يرجى الاطلاع على تعليقي هنا:

https://github.com/moby/moby/issues/31101#issuecomment -329527600 https://github.com/moby/moby/issues/31101#issuecomment-329527600

يجب عليك في الأساس استخدام سلسلة من ملفات .yml لتجاوز أو تغيير تكوين الحاويات الخاصة بك.

الرجاء قراءة "تحديد ملفات تكوين متعددة"

يمكنك توفير ملفات تكوين متعددة. عند توفير ملفات متعددة ، يجمعها Compose في تكوين واحد. ينشئ الإنشاء التكوين بالترتيب الذي توفره للملفات. تلغي الملفات اللاحقة وتضيف إلى سابقاتها.

https://docs.docker.com/compose/reference/overview/ https://docs.docker.com/compose/reference/overview/

يستخدم هذا النهج تكوينًا على الميراث للحصول على نفس النتيجة تقريبًا.

في 30 يوليو 2018 ، الساعة 15:23 ، كتب Serban Teodorescu [email protected] :

dedalozzo https://github.com/dedalozzo "في الموضوع" ==؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/moby/moby/issues/31101#issuecomment-408880809 ، أو كتم صوت سلسلة المحادثات https://github.com/notifications/unsubscribe-auth/AAS_0FZO30NplqHRid_Id8VBOJW7uM4Diga .

ألن نكون قادرين على استعادة نفس القابلية للتمديد إذا قمنا بدمجها
حقول ملحق yaml (تكوين 2.1 + / 3.4 +)
بالسماح لتلك الحقول x- بالإشارة إلى

لذلك يمكننا السماح لقائمة جذر include لتحديد الملفات المراد تحميلها.
سيتم وضعها في x-include ويمكن استخدامها على الفور عبر مراسي ودمج YAML القياسي.

# /docker-compose.yml
version: '2.1'

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

# /proxy/docker-compose.yml
version: '2.1'
services:
  proxy:
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '2.1'
services:
  app:
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /proxy/docker-compose.yml
version: '3.9'
services:
  proxy:
    &proxy
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '3.9'
services:
  app:
    &app
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /docker-compose.yml
version: '3.9'
include:
  - /proxy/docker-compose.yml
  - /webservice/docker-compose.yml

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    restart: 'always'
    << : *proxy
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    restart: 'no'
    extends:
      file: web1/docker-compose.yml
      service: app
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

@@ /proxy/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   proxy:
+    &proxy
     build: ./
     volumes:
       - /certs:/certs:ro
 ```

 ```diff
 @@ /webservice/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   app:
+    &app
     build:
       context: ./folder
       args:
         LINUX_VERSION: 20.s
         LINUX_FLAVOR: dash
     environment:
       - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
       - bootstrap.memory_lock=true
     ulimits:
       memlock:
         soft: -1
         hard: -1
 ```

 ```diff
 @@ /docker-compose.yml @@
-version: '2.1'
+version: '3.9'
+include:
+  - /proxy/docker-compose.yml
+  - /webservice/docker-compose.yml

 volumes:
   nginx_file_sockets:
     external: false
     driver: local

 services:
   reverse_proxy:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'always'
     ports:
       - "80:80"
       - "443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   reverse_proxy_test:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'no'
     ports:
       - "8080:80"
       - "8443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'always'
     environment:
       ENVIRONMENT: 'production'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web_staging:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'no'
     environment:
       ENVIRONMENT: 'staging'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx
 ```
<hr>
Resulting in the final version, which should be already yaml parsable:

```yml
# /docker-compose.yml
version: '3.9'
#include:
#  - /proxy/docker-compose.yml
#  - /webservice/docker-compose.yml
x-include:
  /proxy/docker-compose.yml:
    version: '3.9'
    services:
      proxy:
        &proxy
        build: ./
        volumes:
          - /certs:/certs:ro
  /webservice/docker-compose.yml:
    version: '3.9'
    services:
      app:
        &app
        build:
          context: ./folder
          args:
            LINUX_VERSION: 20.s
            LINUX_FLAVOR: dash
        environment:
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
          - bootstrap.memory_lock=true
        ulimits:
          memlock:
            soft: -1
            hard: -1

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    << : *proxy
    restart: 'no'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    << : *app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

AFAIK هي إحدى ميزات YAML ، المضمنة في مواصفات laguage نفسها ، لتجنب تكرار الأجزاء في نفس الملف. عند استخدام ملفات مختلفة ، فهذا مستحيل أساسًا.

يجب أن تقترح هذه الميزة لمواصفات YAML نفسها.

تختفي هذه المناقشة إلى:

• كيف يكون docker-compose -f file.yml أفضل بكثير من docker-compose -f file.yml -f file_extension.yml ؟
• أو: الأسلاك على مستوى الأوامر _vs_ الأسلاك على مستوى الملف.

فقط عند العمل على سطر الأوامر ، يصبح الإزعاج ملحوظًا. علينا أن نعترف بذلك للحظة. كل شيء آخر هو نصي ، على أي حال.

إذا كانت هذه هي الحجة الحقيقية ، فإن docker-compose up service لديه دلالات أفضل من docker-compose -f service.yml up : حدد كل ما هو مطلوب للتنمية المحلية (ويعرف أيضًا باسم سطر الأوامر) في docker-compose.override.yml .

الدلالات المعطاة نظيفة للغاية ومدروسة جيدًا. ربما يعني اعتماد service.yml _ لسطر الأوامر use_ تقليل تجربة المستخدم. هناك حجة أخرى لذلك: بينما هو واضح للوهلة الأولى ، ما هو docker-compose.yml ، يمكن أن يكون service.yml أي شيء ، حقًا أي شيء.

تنويه: رأي استفزازي. : wink: لم آخذ بعين الاعتبار كل حالة استخدام ممكنة ...

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

أعتقد أن أحد الأشياء التي يمكننا القيام بها هو تحسين قصة التوثيق حول الإصدار 2 مقابل الإصدار 3. يفترض الكثير أن الإصدار 3 استبدل الإصدار 2 ، لكن هذا ليس صحيحًا تمامًا. كلاهما يتلقى ميزات جديدة تركز على حالات الاستخدام الخاصة بهما. بدأت مشكلة GH هذه حتى نتمكن من إجراء مناقشة حول الميزات المستقبلية اللازمة لتشق طريقها من docker-compose إلى Swarm ، وكيفية تحسين المستندات لاستخدام docker-compose ، وتنسيق ملف الإنشاء ، و Swarm stacks معًا. لا يزال الامتداد يعمل بشكل رائع في الإصدار 2.4 المحدث. آمل أن أتمكن من المساعدة في تقديم معلومات حول الحلول التي لدينا اليوم:

v2: لـ docker-compose cli فقط. ركز سير عمل التطوير على آلة ومحرك واحد. جيد أيضًا لبناء / اختبار سير عمل CI. تلقى فرع الإصدار هذا ميزات جديدة حتى ديسمبر 2017 في الإصدار 17.12

الإصدار 3: مثالي لمكدسات Swarm / Kube ، مع مفاهيم متعددة العقد ويحافظ على الدعم لمعظم ميزات cli لتكوين عامل الإرساء.

إذا كنت لا تستخدم حزم Swarm أو Docker Enterprise Kubernetes ، فلا يوجد سبب لاستخدام الإصدار 3 . العصا مع V2.4، وتحصل على كل CLI-عامل ميناء يؤلف الميزات بما في ذلك يمتد، depends_on والحقول الإرشادية، وحتى depends_on مع healthchecks (لتجنب الانتظار مقابل ذلك البرامج النصية).

تم إنشاء v3 لمحاولة دمج ميزات عالم cli المكون من عامل إرساء بمحرك واحد مع عالم مجموعة متعدد العقد. ليست كل ميزات v2 (مثل تعتمد على) منطقية في المجموعة. الميزات الأخرى (مثل الامتداد) لم يتم تحويلها إلى الإصدار 3 ، على الأرجح لأنه قبل وجود الإصدار 3 ، كانت جميع الكودات في بايثون ، ولإصدار 3.0 لدعم Swarm ، كان عليهم إعادة كتابة ذلك في docker cli Go ، والآن يقومون بكتابته مرة أخرى في برنامج المحرك الخفي ليصنعوا في النهاية واجهة برمجة تطبيقات Swarm Stacks ، والتي لم تكن موجودة بعد.

بالنسبة لأولئك الجدد في هذه المشكلة ، لاحظ أيضًا الكثير من العمل الجاري لحل مشكلات التكوين والقوالب وسير عمل الفريق المختلفة منذ الإصدار 3.0:

• 3 ميزات أناقشها بإيجاز في هذه المقالة (إنفارس ، نموذج ، وتأليف نطاق)
• تجاوز الملفات و docker-compose config و. env
• عامل ميناء التطبيق النموذجيه التجريبية والتعبئة والتغليف المبادرة القطرية. تحقق من هذا
• واجهة المستخدم الرسومية القادمة Docker-Compose (مقدمة تشويقية في DockerCon 2018 keynote)

يجب أن تؤكد المستندات الموجودة على https://docs.docker.com/compose/extends/#extending -services باللون الأحمر على حقيقة أن الكلمة الأساسية الموسعة تمت إزالتها في الإصدار 3 ، لأنها أكثر أهمية من مجرد _note_.
لقد قمت بترحيل المستندات وتصفحها لمعرفة سبب توقفها عن العمل ، ثم تابعت العديد من المشكلات المغلقة قبل أن ينتهي بي الأمر هنا ، ثم عدت إلى المستندات الأصلية ولاحظت الصياغة.

يتم دعم الكلمة الأساسية الموسعة في تنسيقات ملفات Compose السابقة حتى إصدار ملف Compose 2.1 (انظر يمتد في v1 ويمتد في v2) ، ولكن لا يتم دعمه في إنشاء الإصدار 3.x.

يمكن إعادة صياغتها على النحو التالي:

تمت إزالة الكلمة الأساسية الموسعة في إصدار Compose 3.x ، لكنها لا تزال مدعومة في تنسيقات ملفات Compose السابقة حتى إصدار ملف Compose 2.1 (انظر التوسيع في v1 ويمتد في v2).

إنه فرق بسيط ، لكن من السهل التغاضي عنه عند مسح المستندات.

@ krisrp العلاقات العامة بدأت

شكرا BretFisher

هل هناك أي خطط لإعادة تسمية v2 إلى "version: docker-cli" و v3 إلى "version: swarm / kube"؟
سيكون من المنطقي التمييز بينها بهذه الطريقة ، مع الأخذ في الاعتبار كيف أن الإصدار 3 يحل محل الإصدار 2 في معظم أنظمة النسخ الأخرى. في الوقت الحالي ، يتم الحفاظ على كلاهما وتباعدهما ، لذلك ما لم أكن مخطئًا ، يبدو أنهما سيكونان في الجوار لفترة من الوقت.

krisrp على العكس من ذلك ، فإن سبب زيادة رقم إصدار رئيسي هو الإشارة إلى الاختلاف في التوافق.

@ cpuguy83 لم أكن
كان لدى IIRC Gnome 2 & 3 أيضًا هذا الارتباك منذ سنوات عندما تم الحفاظ على شوكات مستقلة لكل منها.

لا أريد إخراج هذا الموضوع عن مساره لمناقشة دلالات تعيين الإصدار (التورية السيئة) ، لذلك سأتركه عند هذا الحد. كانت مشاركة ستساعدني وربما الآخرين.

@ shin- @ cpuguy83 بالنظر إلى هذه المشكلة بعد أكثر من عام ، ما هو سبب عدم إضافتها مرة أخرى في الإصدار 3؟

لم أتمكن من العثور على الكثير حول هذا الموضوع ، بخلاف "يمكننا القيام بذلك بشكل مختلف" (ولكن لم يتم تقديم حل فعلي أفضل)
هل هناك قيود فنية؟ أو مجرد عدم وجود طلب سحب؟

بعد كل شيء ، لا تزال ملفات تكوين 2.1 الخاصة بي تعمل بشكل جيد.

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

في هذه المرحلة ، يبدو هذا وكأنه نكتة قاسية يلعبها كاتب التوثيق.

في النهاية ، لا يتم التحكم في تنسيق "المكدس" هنا وهو جزء من Docker CLI.

أنا شخصياً لا أعرف سبب استبعاده من الإصدار 3 ... كما أنني لا أعتقد أنني رأيت أي شخص يحاول بالفعل إضافته.
قد يكون من الأفضل طرح هذا الأمر في docker / cli ... ربما حتى مجرد علاقات عامة مع تغيير مستند عالي المستوى يعمل كما لو كانت الميزة موجودة بحيث يمكن مناقشتها ويمكن إضافة التنفيذ بمجرد الموافقة على التصميم .

في الأساس ، إذا أراد شخص ما ، قم بعمل علاقات عامة. أقترح تغيير المستند فقط للتأكد من أنك لا تضيع الكثير من الوقت في حالة رفضه ... منذ مرة أخرى ، لست متأكدًا من سبب حذفه من الإصدار 3.

كما ورد أعلاه. في انتظار حل هذا قبل استخدام عامل البناء مرة أخرى.

+1 يرجى إصلاح هذا ، فلدينا ملفات إنشاء قائمة على تمديد ولا يمكننا استخدام إنشاء سرب بسبب ذلك.

+1 لتمديد الميزة

أي أخبار عن هذا؟

ما زلت في انتظار ذلك

كذلك هنا. مازلت منتظرا.

أي تحديث؟

هل تم تقديم أي سبب على الإطلاق لسبب إزالته؟

في الإثنين ، 5 أغسطس 2019 ، الساعة 11:10 ، كتب Jaykishan ، [email protected] :

أي تحديث؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/31101؟
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABOE6GCEFFJ3SOLDWRWX2IDQC74CZANCNFSM4DANZGSQ
.

أي تحديث؟

لذلك .. لقد مر ما يقرب من 3 سنوات ...
لكن ما زلت آمل أن تهبط: د

يجب أن يكون هناك نوع من البديل للتمديد إذا لم يعود. لماذا لا نسمح للخدمات المجردة؟ سيكون تنسيق الملف ثابتًا وستكون جميع إقرارات الخدمة في ملف واحد. يمكنك استخدام خدمات مجردة جنبًا إلى جنب مع قدرة yaml على إضافة أسماء مستعارة للعقدة (عبر & ) لإعادة استخدام هذه الأسماء المستعارة عبر عامل التشغيل <<: .

لماذا 3 سنوات !! يبدو أنك تعمل وتركز على أشياء لا يهتم بها أحد

أي تحديث على هذا؟

هذا مثير للشفقة. يستخدم Terraform التركيب - لذا فهو قابل للتنفيذ ، فلماذا لا يستطيع التأليف متابعة ممارسات التصميم الجيدة هذه ؟!
تكوين وحدات Terraform
أفضل ممارسات Terraform

"مثير للشفقة" ، لطيف.

@ Cristian-Malinescu تفضل بتنفيذها من فضلك.
هذا برنامج مجاني ومفتوح المصدر.

بدلاً من الشكوى مثل أي شخص آخر في هذه الدردشة.
هذا فقط لا يضيف أي قيمة هنا ، حقًا.
كما قيل عدة مرات ، لم يرغب أحد في تنفيذ ذلك حتى الآن ،
لذا فهي مجرد مشكلة يجب على شخص آخر إصلاحها ، شكرًا.

luckydonald بفضل إبعاد @ Cristian-Malinescu بإجابة سهلة / سلبية-عدوانية ، إنها ، مثل عدم المساعدة دائمًا. @ Cristian-Malinescu إنه قابل للتنفيذ كما تم بالفعل من قبل ولكن تمت إزالته ، يجب (آمل) أن يكون هناك سبب. هل يوجد أي شخص على هذا الموضوع في فريق إنشاء عامل التحميل حتى يتمكن من إلقاء الضوء على شيء؟

تم ذكر الخيط المقشود والاستفادة من وظائف YAML المدعومة.

يعتقد أن هذا المثال قد يساعد.

nomasprime شكرا لك على هذا الاكتشاف! كنت أقرر بين الإصدارين 2 و 3 لمشروعي ، وقد أدى ذلك إلى حل المعضلة الكبيرة في هذا الموضوع. متفاجئ أن هذه الحلول البديلة غير مذكورة في المستندات الرسمية لميزة الخدمات الموسعة.

رائع ، يبدو أنه فرصة جيدة لاستخدام رابط Request docs changes على شريط التنقل الأيمن لصفحة المستندات.

nomasprime نعم ، كانت هذه الفكرة موجودة في هذا الموضوع من قبل.

إذا أمكن دمج ذلك مع آلية تحميل ملفات لملفات yml الأخرى ، فهذا كل ما هو مطلوب حقًا للحصول على جميع وظائف depends القديمة.

انظر أعلاه ، على سبيل المثال https://github.com/moby/moby/issues/31101#issuecomment -413323610

لن يكون _ قابلاً للقراءة_ جدًا ، ولكنه سيكون _ على الأقل _ ممكنًا _.

nomasprime شكرا لك على هذا الاكتشاف! كنت أقرر بين الإصدارين 2 و 3 لمشروعي ، وقد أدى ذلك إلى حل المعضلة الكبيرة في هذا الموضوع.

arseniybanayev المقالة على الوسيط تقول عن الإصدار 3 فقط ، لكن الإصدارات الأحدث من v2 تدعم أيضًا الارتساء وحقول الامتداد . في حالتي ، اخترت الإصدار 2 (2.4 بشكل أكثر تحديدًا) لأنني استخدم docker-compose وليس swarm (و v3 لا يدعم بعض ميزات v2 مثل الحد من ذاكرة الحاوية )

و v3 لا يدعم بعض ميزات v2 مثل الحد من ذاكرة الحاوية

يدعم الإصدار 3 تقييد الذاكرة ، لكن الحقل أقل من deploy -> resources -> limits https://docs.docker.com/compose/compose-file/#resources

thaJeztah أعني ، مقابل docker-compose (لأنني لا أستخدم سربًا في المشروع الذي كنت أشير إليه في تعليقي السابق). انتشار IIRC هو فقط للسرب ، أليس كذلك؟

هل من المنطقي عمل تكوين منفصل للسرب والمحلي؟ يبدو أن هذين متعارضين مع بعضهما البعض. من المفهوم أن Docker يرغب في زيادة استخدام السرب ، لكن الكثير من الناس يستخدمون التأليف فقط من أجل التنمية المحلية.

أنا شخصياً لم أستخدم أبدًا حاويات سرب وتشغيلها في الإنتاج باستخدام ECS أو k8s أو GAE.

يجب أن تكون معظم الخيارات قابلة للترجمة / قابلة للاستخدام لكل من خدمات السرب / kubernetes وللحاويات التي تم نشرها من خلال الإنشاء. يجب أن أتحقق من سبب عدم تطبيق حدود memory على docker-compose

ما زلت أفتقد ميزة الامتدادات ، ولكن بالنسبة لحالة الاستخدام الرئيسية الخاصة بي ، قمت بالتبديل إلى ملفات إنشاء عامل الإرساء المتعددة عبر COMPOSE_FILE env. أنا أستخدمه في الغالب لاستخدام نفس قاعدة docker-compose.yml من أجل dev و prod بكلمات مرور أو تكوين مختلف.

مثال:

• على dev: export COMPOSE_FILE= docker-compose.yml` # افتراضي
• على المنتج: export COMPOSE_FILE= docker-compose. yml: docker-compose.prod.yml `# يستخدم كلا ملفي yaml

في docker-compose.prod.yml قمت فقط بالكتابة فوق env vars بكلمات مرور prod.

هذا الإعداد بسيط ولا أحتاج دائمًا إلى إضافة "-f" متعددة إلى الأمر docker-compose . أحتاج فقط إلى تعيين COMPOSE_FILE env var بشكل مختلف على كمبيوتر dev والخادم وتجاهل git ملف docker-compose.prod.yml.

مازلت منتظرا :)

لقد كنت أستخدم هذا كوسيلة للتوسيع:

docker-compose \
  -f ./docker/base.yml \
  -f ./docker/extended.yml \
  up

لكن التمديد في الملف سيكون أجمل ، فلا حاجة إلى نص برمجي إضافي.

لقد كنت أستخدم هذا أيضًا للتمديد ديناميكيًا من نص bash النصي:

extended_docker_compose="
  version: '3.5'
  services:
    my-service:
      restart: always
"

echo "$extended_docker_compose" | docker-compose \
  -f ./docker/base.yml \
  -f /dev/stdin \
  up

@ dave-dm هذه تجاوزات قديمة بسيطة!

أعتقد أن هذه حالة استخدام محتملة صالحة للتمديد

https://github.com/NerdsvilleCEO/devtools/blob/master/doctl/docker-compose.yml#L10

لدي غلاف docker-compose والذي أستخدمه لجذب الخدمات https://github.com/nowakowskir/docker-compose-wrapper

تحرير: حالة استخدام أخرى محتملة هي أن شخصًا ما لديه حزمة LAMP / LEMP ويريد توسيع هذه الخدمات لاستخدامها مع خدمة معينة مثل Wordpress

لا تزال تنتظر منذ عام 2017 أثناء استكشاف بدائل إنشاء عامل ميناء.

nomasprime نعم ، كانت هذه الفكرة موجودة في هذا الموضوع من قبل.

إذا أمكن دمج ذلك مع آلية تحميل ملفات لملفات yml الأخرى ، فهذا كل ما هو مطلوب حقًا للحصول على جميع وظائف depends القديمة.

انظر أعلاه ، على سبيل المثال # 31101 (تعليق)

لن يكون _ قابلاً للقراءة_ جدًا ، ولكنه سيكون _ على الأقل _ ممكنًا _.

luckydonald شكرا للإشارة. من الغريب أنه لا توجد وظائف مدمجة في YAML ، فمن المؤكد أنها ستحل الكثير من المشكلات.

يبدو أنه سيكون من السهل جدًا تنفيذ حل تابع لجهة خارجية على الرغم من أنك لست متأكدًا من سبب عدم إحضار هذا إلى الإصدار 3 🤷‍♂

تذكير بسيط بأن الكثير من الأشخاص يرغبون في هذه الميزة :)

ما هو سبب عدم تحويله إلى الإصدار 3 بالمناسبة؟

نسيت ولكن هل هناك سبب حقيقي لسحبها؟

في الأربعاء ، 6 مايو 2020 ، الساعة 23:14 ، كتب Julien Marechal ، [email protected] :

تذكير بسيط بأن الكثير من الأشخاص يرغبون في هذه الميزة :)

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/31101#issuecomment-624919070 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ABOE6GGDIVGATP734YJA4UTRQHOLJANCNFSM4DANZGSQ
.

الطريقة التي تتعامل بها مراسي yaml مع حالة الاستخدام هذه غير ملائمة بعض الشيء مقارنةً بـ extend . إنها القوة ، في رأيي ، أتت إلى حد كبير من الدمج المتكرر للعناصر. تصلك المراسي إلى 75٪ من الطريق إلى هناك - فهي لا تدمج yaml بشكل متكرر ؛ كل ما تبذلونه من الدمج يحدث في المستوى الأعلى. ستؤدي الإشارة إلى قالب خدمة مثبتة ثم إعادة تعريف كتلة environment إلى استبدال كتلة بيئة الخدمة المثبتة بدلاً من الدمج. ستحتاج إلى إرساء كل قاموس والإشارة إليه أسفل شجرة متكررة من القواميس من أجل مطابقة سلوك الكلمة الرئيسية extend .

مثال:

# anchors for the service, environment, deploy, and deploy.placement blocks
# you'll need an anchor for every dict that you want to merge into
x-common-app: &common-app
  image: app:1.0
  environment: &common-app-environment
    common_option: a
    overwrite_option: b
  deploy: &common-app-deploy
    max-replicas-per-host: 3
    placement: &common-app-deploy-placement
      constraints:
        - 'node.labels.app_host==true'

services:
  myapp: << *common-app
    environment: << *common-app-environment
      foo: bar
      baz: xyzzy
      overwrite_option: quz
    deploy: << *common-app-deploy
      replicas: 15
      placement: << *common-app-deploy-placement
        preferences:
          - spread: node.labels.region

# The above yields the following:
services:
  myapp:
    image: app:1.0
    environment:
      common_option: a
      overwrite_option: quz
      foo: bar
      baz: xyzzy
    deploy:
      replicas: 15
      max-replicas-per-host: 3
      placement:
        constraints:
          - 'node.labels.app_host==true'
        preferences:
          - spread: node.labels.region

قد لا يبدو الأمر مزعجًا للغاية في هذا المثال ، ولكنه يصبح مزعجًا ويصبح أقل قابلية للقراءة إذا كنت تقوم بعمل قوالب لخدمات متعددة (10+) من كتلة امتداد واحدة.

في رأيي ، السيناريو المثالي هو مزيج من نهج yaml anchor ونهج extend - السماح extend ing فقط من مستوى أعلى x- كتلة حقل ملحق مسبوقة ، مع خصائص الدمج الأكثر ذكاءً.

في مؤسستي وجدنا أن المراسي yaml قذرة بعض الشيء من الناحية التركيبية ، لذا قمنا بإعادة تطبيق ميزة extend في برنامج نصي خارجي من نوع Python. هذا يعمل بالنسبة لنا ، لكنها طريقة واهية للتعامل مع شيء ما. وبالمثل ، كان علينا إنشاء أدوات خارجية خاصة بنا للتعامل مع إزالة depends_on مقابل v3 / Swarm stacks.

لقد فعلت الكثير من gitlab CI YAML مؤخرًا. إنه يحتوي على هذه الميزات بالضبط ، والتي تعد رائعة جدًا لتحقيق قوالب وتكوينات نهائية يمكن قراءتها وإدارتها:

• يمكنك تضمين ملفات YAML أخرى (جيدة للقوالب)
• يمكنك التمديد (حتى عبر المشاريع / باستخدام الموارد البعيدة من خلال https). يصف التوثيق الممتد بالضبط ما يصفه @ a-abella لتنسيق التأليف.
• يمكنك أيضًا "الاختباء" من اعتبار الأشياء الحقيقية. في تنسيق الإنشاء ، يكون x- ، في gitlab CI هو . مبدئيًا بدلاً من ذلك.

هذه هي مجموعة الميزات الدقيقة التي تجعل هذه الملفات محتملة.

لقد وصلت إلى هذه المشكلة من مستندات عامل الإرساء ، وفي حالتي كنت أرغب في إنشاء نموذج لإعدادات docker-compose ، وكحل بديل ، اتبعت النصيحة أعلاه وقررت البحث عن برنامج قوالب حالي. لن أستعيد تلك الساعات ، لذا فأنا أورد بالتفصيل القليل مما وجدته هنا ، بغض النظر عن أي مناقشة حول طلب الميزة الفعلي هذا ، ومع ذلك ، قد يشعر المشاركون باستخدام نظام قوالب يستند إلى YAML إنشاء ملف إنشاء بدلاً من دمج هذه الميزة في docker-compose نفسها قد يكون أكثر ملاءمة من حيث التغليف واختيار الأداة المناسبة للوظيفة.

بالنسبة لبعض السياق ، أستخدم وكيلًا عكسيًا أساسيًا مع Let's Encrypt والعديد من حاويات التطبيق (Nextcloud حاليًا ، واحد لي ، وبعض الحاويات المنفصلة للأصدقاء) - في هذه الحالة ، أردت إنشاء قالب لحاويات Nextcloud لذلك أنني أتجنب الأخطاء والازدواجية بضربات المفاتيح للإعدادات المتشابهة جدًا. الحزم التالية كانت ما جربته:

• ytt
• Dhall
• إشارة
• Jsonnet

يبدو ytt شاملاً للغاية وهو الخيار الوحيد لاستخدام YAML محليًا. بدت قوية والأداة المناسبة للمهمة ، وتستخدم Starlark ، مجموعة شاملة من Python ، مباشرة داخل ملف YAML لإجراء المعالجة. ومع ذلك ، بعد فترة ليست طويلة ، أصبح القالب فوضويًا للغاية ، وتناثر أجزاء من التعليمات البرمجية وأجزاء من YAML ، بالإضافة إلى خلط أنواع بيانات Python مثل القواميس والمصفوفات وأجزاء YAML (التي يبدو أنها تتم معالجتها إلى حد ما مثل النص ، إلى حد ما مثل استخدام محرك قالب HTML الذي ينتج عنه علامات مثل السلاسل) أدى في النهاية إلى العديد من الأخطاء وفوضى الملف. يبدو Dhall أيضًا شاملاً للغاية ويستخدم لغة أصلية فريدة يمكن إخراجها إلى مجموعة متنوعة من التنسيقات ؛ يبدو الأمر أشبه بلغة البرمجة الوصفية أكثر من كونه نظامًا نموذجيًا ، ولكن بالنظر إلى أن بناء الجملة وظيفي ويتم كتابته بدقة شديدة ، سرعان ما أصبح أكثر تعقيدًا مما كان يستحق ذلك بالنسبة لقالب بسيط لـ YAML غير منظم. نظرًا لما يبدو قليلاً مثل مزيج من JSON و Haskell ، فقد تطلب الأمر الكثير من التفكير في العمل على ما أحتاجه في اللغة.

من المثير للاهتمام ، أنه في بعض الأحيان كان الأمر صعبًا مع كل من Dhall و ytt كانا يستخدمان أسماء الحقول ذات المعلمات ، وكلاهما كان سيعمل بشكل جيد بما فيه الكفاية ، لكنني بحاجة إلى ظهور اسم المثيل الخاص بي في أسماء الخدمات ووحدات التخزين ، وفي كلاهما كان هذا قبيحًا إلى حد ما ؛ يعد استخدام الحجج للقيم في التجزئة أمرًا سهلاً ، ولكن استخدام هذه الوسيطات في أسماء المفاتيح كان فوضويًا أو لم أتمكن من العثور على كيفية القيام بذلك بدقة ، بالإضافة إلى أن Dhall يفرض أمان الكتابة وهذا يتعارض مع هذا المفهوم. مع Jsonnet كان الأمر بسيطًا مثل وضع التعبير بين قوسين مربعين.

إن كلا من CUE و Jsonnet موجهان إلى JSON ، ولكن تشغيلهما من خلال محول ليس بالأمر الصعب على الإطلاق ، ويبدو مرة أخرى ، مثل Dhall ، أن CUE لديها الكثير من الميزات القوية وقد ولدت من عيوب في Jsonnet ، ولكن جزئيًا في التوثيق ، أصبح من الواضح أنها كانت مبالغة بالفعل ؛ ربما مع مزيد من الوقت لتعلمه بشكل صحيح ، سيكون الخيار الأفضل ، لكن يبدو أن CUE أكثر توجهاً نحو التحقق من الصحة والتخطيط أكثر من وظيفة القالب البسيطة ، ولذا انتقلت بسرعة إلى Jsonnet وأنهيت المهمة بسرعة كبيرة.

أخيرًا ، فقط بعد أن أكملت كل هذا أدركت طوال الوقت الذي كنت أقارن فيه هذه الأدوات ببساطة العلامات السائلة أو قوالب HTML المماثلة ، ربما كان بإمكاني في الواقع استخدام Liquid في المقام الأول. لقد استخدمته فقط في سياق موقع Jekyll ، لذلك لم يحدث لي مطلقًا بعد أن أحصل على حزمة قائمة بذاتها ، ولكن مع التكرار الأساسي والقوائم ، والقدرة على تقييم التعبيرات مباشرة في نص في المكان ، من المحتمل أن يكون هذا كان أفضل بكثير بالنسبة للوظيفة ؛ من المحتمل أن يكون Jsonify هو الأفضل بالنسبة لـ JSON ، ولكن السائل يمكن أن يعمل في YAML النقي وبالتالي يصبح الملف أكثر قابلية للقراءة مرة أخرى.

كان +1 مصدر إلهام للحل المفصل الذي قمت بتطبيقه في العمل منذ أن تم إنشاء هذه التذكرة لدعم ترحيل عدد كبير من أدوات الاختبار إلى k8s. كنت حريصًا جدًا على تجنب الأجراس والصفارات ولكن سرعان ما بررت ميزة مماثلة. تبدو المناقشة الفلسفية (التركيب مقابل الميراث وما إلى ذلك) بالنسبة لي وكأنها إلهاء عن الفطرة السليمة (مع الإدراك المتأخر - لا يزال بدون حل بعد ما يقرب من 3 سنوات). من الواضح أنه مطلوب من قبل الأشخاص الذين قد يستمرون في استخدام عامل البناء.

+1: +1:

لقد استخدمت هذه الميزة بكثرة من قبل لبيئات dev / test / ci ، حيث يمكنني التمديد من ملف إنشاء في مسارات دليل فرعي ./config/{dev,test,ci}/compose.yaml . كان لديّ .env يحتوي على COMPOSE_ENV=dev ، لكن يمكن للمطوّرين تجاوزه ، ومن الواضح أنني سأتجاوز ci .

لقد صدمت بإهمال الميزة وعدم استبدالها بشيء يمكن أن يفعل شيئًا مشابهًا. ربما تسمح لنا فقط باستخدام jinja2 والقيام بما نريد. آمل أن يكون Docker-Compose أقل مقاومة للجفاف. : '(

يبدو أن extends مدعوم من docker-compose منذ الإصدار 1.27 (https://github.com/docker/compose/pull/7588).

إحدى حالات الاستخدام التي أستخدم فيها الميزة بكثرة ، هي إصدار صور عامل الإرساء إلى التعليمات البرمجية. يمتد كلا من ملفي إنشاء docker dev و prod من docker-images.yml حيث يتم سرد الخدمة الأساسية فقط وإصدار ذي علامات من صورة الخدمة.

لم يتم العثور على حل سهل لهذا في الإصدار 3.