Compose: تحديد الخدمات التي لم تبدأ بشكل افتراضي

+1 للخيار 1

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

بعض هذه المشكلات (تلك التي تتعامل مع حاويات البيانات فقط ، # 942 ، التعليق الأخير من @ cpuguy83) تم إصلاحها بالفعل بواسطة # 1754 ، لا أعتقد أننا بحاجة إلى اعتبارها مشكلة بعد الآن (بعد 1.5 ).

نقوم بتطوير ملحقات Magento. للقيام بذلك ، نحتاج إلى طريقة بسيطة لتشغيل متجر ويب على حزمة LAMP. التأليف يجعل ذلك سهلاً. لكننا نريد أيضًا تشغيل phpunit ، وأدوات تحليل ثابتة متنوعة ، ومنشئي وثائق ، وما إلى ذلك. في الواقع ، فإن الغالبية العظمى من "خدماتنا" هي مجرد أوامر ، مثل docker-compose run --rm phplint . من الناحية المثالية ، أمر غير مؤهل مثل

docker-compose up -d

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

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

kojiromike ، ما هو موضوع (1) غير المناسب لحالة الاستخدام الخاصة بك؟ هل يتعلق الأمر فقط بدلالات الأوامر ( docker-compose run --rm phplint مقابل docker-compose --file phplint.yml up )؟

وهو أن docker-compose up -d يحاول "بدء" phplint ويبلغ docker-compose ps أن خدمة "phplint" معطلة. في الواقع ، هذه ليست حاوية خدمة ، إنها حاوية أدوات ، يجب ألا يكون لها مفهوم لأعلى / لأسفل. كنت أفهم أن حاويات الأدوات يتم احتضانها من قبل عامل التحميل (كيف يمكنك تشغيل شيء مثل redis-cli ، من الواضح أنه ليس "خدمة") وبينما أستخدمها أكثر في التطوير ، أعتقد أن لديها مكانًا للإنتاج أيضًا ؛ مثل لماذا قلنا أن awk مثبتًا على آلات الإنتاج أو في الحاويات ، فلماذا لا يتم تشغيله من خلال حاوية مع الارتباط للحصول على سلوك يمكن التنبؤ به.

: +1: أجد نفسي بشكل روتيني أرغب في إنشاء حاوية tests جنبًا إلى جنب مع خدماتي الأخرى لتغليف اختبارات الوحدة قيد التشغيل. يتمثل "الحل البديل" في تعيين الأمر على "/ bin / true" وتشغيل الحاوية باستخدام أمر اختبار الوحدة المحدد في CLI. ستكون القدرة على تحديد الحاويات التي يجب أن تبدأ بسعر up مرة أمرًا رائعًا!

(راجع للشغل ، عمل جميل في كل مكان ، أيها الناس)

ccjameydeorio

ryneeverett الدلالات هي جزء منها. إنها مشكلة التوثيق الذاتي وإمكانية العثور عليها. حاليًا ، نخبر المطورين docker-compose run --rm foo bar . ندعوهم إلى إنشاء دالة shell أو اسم مستعار ، لكننا لا نحتفظ بالاسم المستعار / rcfile القياسي للمشاريع. (لا نريد توحيد الأشياء خارج الحاويات ؛ نريد استخدام Docker _to_ standardize.) تؤدي إضافة ملف جديد لبعض الأوامر إلى إنشاء تسلسل هرمي للأهمية: يصبح ملف docker-compose.yml هو الملف "الافتراضي" للمهم الأشياء ، ويصبح ملف "الآخر" أقل أهمية.

الشيء الآخر هو أن مجرد الحفاظ على العلاقات بين الخدمات يصبح أكثر صعوبة. فقط لأننا نريد عدم تشغيل شيء ما بشكل افتراضي لا يعني أنه لا يستخدم link أو volume من خدمة تعمل لفترة طويلة. extends جميع التسهيلات التي نحتاجها لربط الخدمات بـ "الأوامر" (خدمات التشغيل مرة واحدة). حتى لو حدث ذلك ، إذا اضطررنا إلى استخدام ملفات yaml متعددة ، فسنضطر إلى استخدام extends حيث لن نحتاج إلى ذلك.

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

kojiromike هذا ما كنت أظن. أتساءل عما إذا كنت ستكون راضيًا عن الدعم المحسّن لـ extends + بعض الطرق للقيام بالأوامر الفرعية (والتي ستكون مطابقة وظيفيًا لـ extends ) ضمن docker-compose.yml . لكن ربما الأخير هو نفسه (4).

2) إضافة خيار للخدمات لجعلها لا تبدأ بشكل افتراضي

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

أعتقد أن حلنا المقترح لـ https://github.com/docker/compose/issues/1987#issuecomment -139632238 سيتعامل مع هذا. يمكن تعريف خدمات "admin" في تكوين منفصل ، وإضافتها بـ -f عندما يلزم تشغيل أمر مسؤول مقابل تركيبة.

dnephin الحل في # 1987 (تعليق) _does_ يتعامل مع "خدمات الإدارة" ، لكنه _ لا يعالج "حاويات البيانات فقط" ، أليس كذلك؟ لا يزال يتعين عليك استخدام الحل البديل command: /bin/true .

يجب ألا تحتاج إلى حاويات البيانات فقط مع إنشاء لأن الإنشاء سيتولى تبديل وحدات التخزين إلى الحاويات المعاد إنشاؤها لك.

@ cpuguy83 في المثال التالي ، ليست حاوية البيانات ضرورية حقًا ، ولكن إذا أردت تغيير الحجم ، فأنا بحاجة فقط إلى إلقاء نظرة على مكان واحد محدد.

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

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

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

لست مُحدّثًا تمامًا مع الأحجام الجديدة API التي ستصدر ، ولكن آمل أن نتمكن من إضافة قسم volumes: لتأليفه والذي سيتعامل مع حجم البيانات بطريقة أفضل (بدلاً من طلب حاوية لهم).

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

أشعر أن (2) هي الأسهل في الفهم. ليس لدي حقًا طريقة لتأكيد ذلك ، لكن حدسي يقول إن معظم الأشخاص الذين ليسوا على دراية وثيقة بجميع خيارات docker-compose التي تواجه المشكلة التي نحاول حلها هنا ، "أتمنى أن يكون هناك طريقة ما لجعل هذه الحاوية _ لا تبدأ_ عندما أقوم بتشغيل docker-compose up ،" ورأوا start: false و bam ، لقد انتهينا وسعداء.

لا يقولون ، "إذا كان هناك طريقة فقط لإنشاء ملف ثانٍ بقصة ربط محرجة لحل هذا ..." (أدركت أن https://github.com/docker/compose/issues/ 1987 # issuecomment-139632238 يساعد في "قصة الربط المحرجة" ، يا؟).

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

اليوم كنت أبحث عن (2) بالضبط ولكن انتهى بي الأمر مع أقل الحلول المفضلة لدي ، وهو ملف YML ثانٍ. حالة الاستخدام الخاصة بي:

لدي حاويتين وكلهم مرتبطون بنفس الحاوية mongo . أود أن أقدم لنفسي وللفريق القدرة على تحميل التركيبات في قاعدة بيانات mongo واكتشفت أن أسهل طريقة للقيام بذلك هي تحميل الحاوية mongo تحت اسم مختلف fixtures ذلك نفسها مرتبطة بـ mongo ثم قم بتشغيل mongorestore --host mongo --port 27017 --drop /dump . نظرًا لأننا لا نريد تحميل التركيبات في جميع الأوقات ، فقد شعرنا أنه من الطبيعي الحصول عليها بـ start: false ولكن انتهى الأمر بامتلاك ملف YML منفصل لكل من الحاويات fixtures و mongo .

يعمل بشكل جيد ولكن start: false يعد IMO أنظف كثيرًا. إذا كان لدي 10 أو أكثر من التباديل لما يسمى بحاوية التركيبات ، فإن نعم start: false ستكون فكرة سيئة وسأختار (1) .

كان عليك فقط إنشاء ملف إنشاء حيث لا ينبغي تنفيذ بعض الخدمات باستخدام الأمر docker-compose up -d . بالنسبة لي ، سيكون الخيار (2) هو أفضل حل لمشكلتي.

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

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

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

سيكون من الرائع تشغيل هذا البرنامج النصي ضمن بنية التأليف لدينا. أتخيل شيئًا مثل:
docker-compose run node bower install

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

إذا كان هناك بعض الإجماع ، يمكنني محاولة إرسال طلب سحب لشيء مثل "إعادة التشغيل"
ابدأ: دائمًا
ربما ... dunno.

تصويت آخر للخيار 2.

أفضل الخيار 2 أيضًا. يمكن تحديد حاويات بيانات Docker الجديدة في ملف إنشاء عامل الإرساء ولكن لا يلزم تشغيلها لاستخدامها.

الخيار 2 بالنسبة لي أيضا

الخيار 2 سيكون رائعا.

+1 للخيار 2

+1 للخيار 2. الاحتفاظ بملفات متعددة وكتابة أسمائها هو مجرد إهدار للوقت. علم منطقي واحد سيحكمهم جميعًا. :بيرة:

+1 للاختيار 4 ،
إذا كان لا بد لي من اختيار المفضلة الثانية ، فإن الخيار 2.

صحيح أن أفضل الخيارات هي 2،4 إذا كان بإمكاني إجراء 1+ على حد سواء ، فهذا ما أفعله إذا لم أذهب مع الأغلبية وأصوت لـ 2.

التصويت لـ 2

من الجيد امتلاك كل من 2 و 4.
+1 لـ 2

لا أعتقد أنه من الضروري تقديم مفهوم جديد للمهام. هذه القراءة جيدة جدًا في رأيي وهي ممكنة دون العديد من التعديلات:

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

"الحل" الحالي مع ملف الإنشاء المنفصل ليس حلاً في الحقيقة في رأيي. كما قال xaka ، لا أحد يريد كتابة كل هذا:

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

ما ستنتهي به هو نص برمجي ./run-task يضيف كل الصيغة المعيارية قبل myTask لك. ولكنك الآن أضفت نقطة إدخال وواجهة أخرى إلى تطبيقك متعدد الحاويات. يرى المطورون docker-compose.yml ويفكرون: _ "رائع ، تطبيق إنشاء. أعرف كيفية التعامل مع هذا الشيء!" _ والآن عليك أن تخبرهم: _ "حسنًا ، يمكنك إدارته بـ docker-compose مثل أي تطبيق إنشاء آخر ... أوه ، لكن انتظر ... هناك أيضًا هذا النص الإضافي الذي تحتاج إلى معرفته ... "_

ربما يكون start: false / up: false / some-additional-flag-to-a-service: false هو أبسط شيء يتم تنفيذه ، ولكنه على الأرجح أيضًا أوضح وأسهل طريقة للفهم. وسيحسن الاستخدام كثيرًا.

ماذا قال sherter . : arrow_up:

: +1: لذلك. يعد ملف dockerfile المنفصل ألمًا كبيرًا خاصةً عند مشاركة الشبكات

الأسلوب start: true|false محدود للغاية. ماذا لو تم استخدام بعض الخدمات للاختبار ، والبعض الآخر للمشرف والبقية للتشغيل العادي؟

أفضل إضافة فكرة التجميع إلى الخدمات.

    myservice:
       group: `admin`

إذا كان group لم يتم تعريف السمة، default يفترض.
بهذه الطريقة يمكننا بدء الخدمات الافتراضية والإدارية باستخدام docker-compose up -g admin -d .

الأفضل من ذلك ، اجعل مصفوفة groups .

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

في الإصدار 2 من عامل الإرساء ، يتم الإعلان عن كل حاوية داخل عنصر المستوى الأعلى services: .
يبدو أن الإعلان عن خدمة باستخدام start: never لتشغيل برنامج نصي أمر خاطئ.
لذا بالنظر إلى التنسيق الجديد ، ألا يجب أن نعلن عن عنصر إضافي على المستوى الأعلى بصرف النظر عن _الخدمات_و_المجلدات_و_الشبكات_؟

اقتراحي:

• إضافة عنصر المستوى الأعلى scripts: ، transients: (أو فكر في اسم أفضل) إلى الإصدار 2.
• داخل العابرين يمكنك تحديد حاوية كما تفعل مع أي خدمة
• الاختلاف الوحيد هو أنهم لن يبدأوا افتراضيًا ، لأن الغرض منهم هو الاستخدام المؤقت فقط.

مثال:

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

وبعد ذلك يمكنك الجري:

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

اهتمامات:

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

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

PD: @ bfirsh ربما إذا أعجبتك الفكرة يمكنك إضافتها إلى "الاقتراحات الممكنة"

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

التصويت للخيار 2: أوضح وأسهل قراءة ولا تحتاج إلى تعلم مفاهيم جديدة
فقط تريد خدمة لا تبدأ بشكل افتراضي

ماذا عن شيء مثل disabled: true

@ cpuguy83 يبدو أن هذا يعني أن الخدمة بأكملها معطلة ، حتى بالنسبة إلى run . سأجدها مربكة.

qcho hmm ، الآن بعد أن أعدت التعرف على Docker منذ 1.6 ، يمكنني رؤية ما تتحدث عنه أنت و @ gittycat . بهذا المعنى ، أحب حقًا نهج gittycat . أتخيل (السماء الزرقاء) واجهة مثل:

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

في هذه الأثناء ، في القشرة ...

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

نهج مثل هذا سيكون رائعًا ويلغي الحاجة إلى هذه البطاقة ، ولكنه يتجاوز نطاقها.

kojiromike لا أعتقد ذلك. هذه هي الطريقة التي تشير بها أنظمة init إلى الخدمات التي لا ينبغي أن تبدأ تلقائيًا.

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

@ cpuguy83 أعتقد أن دلالات "الخدمات" هي بالضبط ما هو محير في المقام الأول. أوافق على أن الشيء التجميعي هو زحف النطاق. بهذا المعنى ، أفضل نهج الخيار 4 / qcho ، حيث

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

ربما كان يجب أن تأخذ "النسخة 2" من التنسيق هذه المشكلة في الاعتبار. على سبيل المثال يمكن أن تكون المواصفات الأخرى

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

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

qcho يعتمد على تعريف الخدمة ، ولكن على أي حال - أود أن

لنفترض أن الإنشاء يعتمد شيئًا مثل كائن job .

1. يتم تشغيل الوظائف مرة واحدة فقط
2. بدأت الوظائف بعد الخدمات
3. من المتوقع الخروج من الوظائف
4. ؟؟؟

يحتاج التأليف الآن أيضًا إلى الاحتفاظ ببعض الولاية المحلية حول الوظيفة ، وهو ما لا يقوم به حاليًا على الإطلاق.

وهذا هو السبب في أن إضافة auto-up: false أو autorun: false هي أسهل وأقل طريقة (scopewise) للتعامل مع هذا الأمر.

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

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

لا أفهم لماذا يستمر الناس في قول ذلك

services:
  my-script-container:
    auto-up:false

أبسط من:

scripts/containers/transients/you_name_it:
  my-script-container:

إنه نفس مستوى التعقيد. ولكن أقل دلالة.

للحصول على الأفكار في موضوع واحد ، مرجع # 2803

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

الاقتراح: نضيف خيارًا لوضع عامل الإرساء-cmpose.overrider.yml لاستبعاد صورة محددة في docker.compose

بمعنى آخر

بعض الصور:
استبعاد: نعم

سيكون السلوك هو تجاهل هذا الإدخال في docker-compose.yml

هل يمكنك إخباري بما يعتقده الفريق ، سأكون مهتمًا بإجراء التغيير.

التصويت لصالح # 2 أيضًا ... واجهت هذه الحاجة اليوم.

سيعمل اقتراح

+1 لـ 2. لدي موقف أحتاج فيه إلى إنشاء صورة عامل إرساء كجزء من عملية الإنشاء ولكنها لا تعمل كخدمة. تقوم الخدمات الأخرى (التي تحتوي على جورب عامل إرساء مثبت بداخلها) بتشغيل الحاويات من الصورة بين الحين والآخر.

+1 لـ 2. و +1 لـ "auto-up" أو "auto-run" كلغة.

ولا يمكن معالجة حالات مجموعات الخدمات (كما أوضح ذلكgittycat) عبر متغيرات البيئة ala "auto-up: $ {ADMIN}"؟

أرى أيضًا حالات استخدام حقيقية لتمييز الخدمات في docker-compose.yml بحيث لا تبدأ تلقائيًا بـ docker-compose up بسيط ولكن بدلاً من ذلك يجب أن تبدأ بشكل صريح فقط.

الحل 1) هي إحدى الطرق الممكنة الآن ولكن في رأيي مرهقة للغاية حيث يتعين على المرء تحديد ملف yml واحد أو أكثر بدلاً من مجرد استدعاء docker-compose up والاضطرار إلى تقسيم الملفات أو حتى تكرارها.

نظرًا لأنني أرغب حقًا في رؤية شيء مثل الحل 2) (كما يفعل الكثيرون أيضًا) فقد طبقت إثباتًا لمفهوم هذا في # 3047 حتى تتمكن من التلاعب به قليلاً لمعرفة ما إذا كان يمكن أن يكون قابلاً للتطبيق المحلول.

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

+1 لكلا الخيارين 2 و 4

+1 للخيارين 2 و 4

+1 للخيار 4. يجب عدم السماح ببعض التهيئة للنصوص البرمجية (على سبيل المثال: إعادة التشغيل: دائمًا)

مع الخيار 2 ، يمكن أن تحتوي على هذه الحالة الغريبة:

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

ماذا يعني ذلك؟

mathroc : هذا يعني: "لا تبدأ تشغيل هذه الحاوية تلقائيًا عند تنفيذ الإنشاء. عندما تتوقف هذه الحاوية (بعد أن تبدأ صراحة) ، أعد التشغيل بغض النظر عن رمز الخروج." ما الغريب في ذلك؟

niko أوه صحيح ، يجب أن أفكر في ذلك لفترة أطول قليلاً قبل النشر ...

تغيير "تصويتي" إلى 1+ للخيار 2

+1 للخيار 2 ، لقد احتجت إلى هذا في عدة مشاريع.

الأزيزdnephinbfirsh:
هل يمكنك إعطاء تحديث بخصوص هذه المسألة؟ نظرًا لأن معظم التعليقات هنا تؤيد الخيار 2 ، فهل توجد حاليًا أي خطط لتنفيذ شيء من هذا القبيل (أو الخيار 3/4)؟
يمكنني تحسين طلب السحب (# 3047) وإكماله بالاختبارات والوثائق إذا كنت تفكر في دمجها بعد ذلك.

شكرا لك.

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

أعتقد أن الخيار 1 قد ينجح ، لكننا بحاجة إلى طريقة أفضل لتقليل الإسهاب في:

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

ربما يمكن إضافة علامة مبسطة / زيادة؟ docker-compose --augment tests up وحلها تلقائيًا إذا كان اختلافًا docker-compose.yml - وإلا سيحتاج المستخدم إلى أن يكون صريحًا.

تعجبني حقًا فكرة الكلمة الرئيسية الجديدة ذات المستوى الأعلى ، ربما suites و commands ؟

يسمح التكوين التالي بما يلي:

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

أستطيع أن أرى في الكود أن هناك بالفعل فكرة الخدمات "الفردية" (تستخدم IMHO فقط عند استدعاء docker-compose run .
هل يمكن إعادة استخدامها؟
إذا صنفت حاوية بـ com.docker.compose.oneoff=True ، فهل ستحاول بدء تشغيلها؟

خلاف ذلك ، سأصوت للخيار 2.

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

1. متغيرات البيئة "العالمية": الأسلوب المقترح هنا هو استخدام extends ، وهو ما يناسبني ... ولكن الآن أحتاج إلى تحديد image لهذا الشيء الذي أقوم بتمديده منه ، ولا يمكنك استخدام scratch (لذلك انتهى الأمر بـ https://hub.docker.com/r/tianon/true/).
2. خدمات "التحجيم": بشكل افتراضي لدي مثيل MongoDB واحد ، ولكن بالنسبة لبعض الاختبارات ، أود تحديد حالة ثانية غير نشطة ، والتي يمكنني طرحها لهذه الاختبارات. هنا ، يبدو استخدام extends في ملف مختلف فكرة قابلة للتطبيق (لا يزال يتعلم عن عامل الإرساء / عامل الإرساء وأفضل الممارسات المتضمنة).

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2
يبدو أنه تغيير بسيط ...

+1 الخيار 2 ،

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

auto-start:true|false

بعد أن حصلت على حل جيد منذ سبتمبر الماضي يسمى rocker- compose ، أوصي بتشغيل: _always_ | _ مرة واحدة | _أبدا_. أنا أيضًا أحب الحالة: _running_ | _ran_ | _ تم إنشاؤه_ أيضًا.

لست معجبًا باستخدام مشروع منفصل لهذه الميزة فقط ، انتهى بي الأمر بسرقة أمر كود True asm من مشروع tianon / true حتى يتم تنفيذ ذلك

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

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

في حالتي ، يكون التمييز بين state: created (تم تشغيله 0 مرات) و state: ran (تم التشغيل> = 1 مرة) مهمًا لأن بعض مهام الأداة المساعدة / المسؤول قد تكون مدمرة ويجب استخدامها فقط في ظروف معينة مثل خدمات الترحيل.

بالنظر إلى أنني الآن أميل أكثر نحو state: running | ran | created كما هو الحال في Rocker-compose أو الخيار 4 مع المستوى الأعلى _task_ أو _job_ object + القدرة على التعبير عن التبعية حتى تتمكن الخدمة من تشغيل مهمة قبل / بعد نفسها .

أود أن أذكر أن هذا مهم لحالة الاستخدام الخاصة بي. أستخدم docker-compose لإنشاء بيئة اختبار وتشغيل مجموعة اختبار. تكمن مشكلة بدء تشغيل جميع الحاويات مرة واحدة في أنه لا يمكنني السماح بسهولة لحاويات الخدمة (مثل قاعدة البيانات أو عمال الكرفس) بالتهيئة قبل تشغيل مجموعة الاختبار.

من الأفضل أن تكون قادرًا على إنجاز شيء مثل:

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

يمكنك أن تتخيل شيئًا أكثر تفصيلاً من كتابة sleep 5 للتحقق من حدوث التهيئة ولكن هذا ليس ضروريًا لمثال المقتطف.

لم أقرأ خيارًا عن علم cli. لذلك أقترح إضافة علامة --exclude إلى قائمة الخيارات. و --exclude أن العلم نقول لل up القيادة لا لبدء حاوية المحدد. سيتم تحليل العلامة --exclude بحيث يمكن استبعاد عدة حاويات من بدء التشغيل حسب الضرورة.

: +1:

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

يمكن أن يعمل ملف "docker-compose-pilot.yml" منفصل ، ولكن هذا يعني أن جميع الوثائق الخاصة بالعمل على هذا المكون يجب أن تتم كتابتها بطريقة واحدة بينما لا يزال المكون قيد التجربة ، ثم تتم مراجعته بمجرد أن يصبح جزءًا من المجموعة القياسية من الخدمات.

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

acran ، أود أن أراكم ترسل طلب السحب الخاص بك لمعرفة ما إذا كان بإمكاننا الحصول على بعض الدفع للمضي قدمًا ، ربما إذا قمت بإعادة التأسيس لإزالة التعارض في # 3047 ، فسيتم انتقاؤه ، ولست متأكدًا من كيفية لفت الانتباه إلى هذا.

jimzucker well # 3047 بالفعل طلب سحب وما زلت أنتظر بعض التعليقات عليه من قبل المطورين: محبط:

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

+1 خيار 2

acran ، أود مساعدتك في تحديث المستندات ذات الصلة وحالات الاختبار. هل الامور على ما يرام ؟

+1 خيار 2

أو ربما تحديد نوع من الوظائف ، كما هو الحال في Kubernetes؟

+1 للخيار 2

لدينا عامل ميناء مؤلف مع خدمات متعددة ويجب إطلاق واحدة منها (قاعدة البيانات) في بيئة التطوير ولكن ليس في بيئة الإنتاج. لذلك ، يتعين علينا الاحتفاظ بملفي إنشاء عامل ميناء. الخيار 2 هو بالضبط ما نبحث عنه!

: +1: للخيار الثاني

+1 خيار 2

acran إنني الروابط هنا في SF لاكتشاف العملية / القناة الصحيحة للحصول على تعليقات حتى يمكن المضي قدمًا ، ابق على اتصال ؛)

👍 للخيار 2

+1 للخيار 2

+1 خيار 2

+1 خيار 2

كما أنني أصوت للخيار 2

فكرة أخرى: لدينا الآن المستوى الأعلى networks و volumes ، يمكننا إضافة خيار images أيضًا. قد يكون هذا تلميحًا لكتابة أنه يجب سحب هذه الصور أو إنشائها حتى يعمل التطبيق ، ولكن لن يتم تشغيلها عندما تقوم بعمل docker-compose up .

هذا من شأنه أن ينجح في حالتي استخدام ، من أعلى رأسي:

1) المشكلة الشائعة هنا ، حيث تريد تشغيل نوع من أوامر الإدارة. يمكن أن يعود docker-compose run إلى تشغيل الصور إذا لم تكن الخدمة موجودة.
2) تطبيقات مثل هذه تعمل على تشغيل صور Docker ولكنها لا تعمل طوال الوقت.

/ سم مكعبdnephinaanand @ shin-

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

في 13 سبتمبر 2016 3:58:41 صباحًا CDT ، كتب Ben Firshman [email protected] :

فكرة أخرى: الآن لدينا المستوى الأعلى networks و volumes ، يمكننا ذلك
إضافة خيار images أيضًا. سيكون هذا تلميحًا لتكوين هذه
يجب سحب الصور أو بناؤها حتى يعمل التطبيق ، لكنها
لن تعمل عندما تفعل docker-compose up .

هذا من شأنه أن ينجح في حالتي استخدام ، من أعلى رأسي:

1) المشكلة الشائعة هنا ، حيث تريد نوعًا من الإدارة
أمر للتشغيل. قد يتراجع docker-compose run إلى تشغيل الصور
إذا كانت الخدمة غير موجودة.
2) تطبيقات مثلهذا الذي يجري
صور Docker لكنها لا تعمل طوال الوقت.

/ سم مكعبdnephinaanand @ shin-

أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub:
https://github.com/docker/compose/issues/1896#issuecomment -246618909

مُرسَل من جهازي الذي يعمل بنظام Android مع K-9 Mail. عذرا على الاختصار.

أنا أتفق مع mgriego على هذا. فكر في حاوية إنشاء الإنشاء - سيكون من الأفضل أن يكون لديك الأمر والخيارات معدة بالكامل و docker-compose up foo فقط وجعلها تقوم بالبناء والخروج.

محاولة الحصول على مزيد من الفهم هنا: هل الخيار 2) مجرد حالة متخصصة للأكثر عمومية "نريد قيمة initial_scale docker-compose.yml "؟ (انظر # 1661 ، # 2496 وآخرون).

ankon لا على الإطلاق.

إضافة images [قسم]

bfirsh يبدأ هذا في التحرك في الاتجاه الذي https://github.com/dnephin/dobi. لقد ابتعدت عن "الأقسام" (واستخدمت فقط عناصر المستوى الأعلى لكل مورد بدلاً من ذلك). أعتقد أنه سيكون من الصعب إجراء ذلك مع نموذج Compose.

1. networks و volumes بشكل مباشر مطلقًا ، بل يتم إنشاؤها فقط حسب الحاجة بواسطة حاوية. لن يؤدي تقسيم الصور إلى قسم خاص بها إلى تغيير السلوك الذي لدينا الآن ، بل سيجعل تكوين الإنشاء أكثر تعقيدًا. إذا كنت تريد فقط إنشاء صورة ، فقم بتشغيل docker-compose build .
2. لا أعتقد أنه يعمل بالفعل على إصلاح المشكلات المحددة في هذه المشكلة. الناس يريدون حاويات ، وليس مجرد صورة

إعادة قراءة الخيط والمناقشة في # 2496 حول التصريح عن قيود القياس في ملف الإنشاء ، أنا أفضّل الخيار 4 (أي قسم جديد من المستوى الأعلى) على الخيار 2.

على وجه التحديد ، سيكون اسم القسم مثل utilities مناسبًا جيدًا: المكونات التي لا تحتاج إليها عادةً ، ولكن عندما تحتاج إليها ، فأنت تريد تكوين المكونات الأخرى المرتبطة بها مسبقًا بدلاً من الاضطرار إلى ذلك اجعل الناس يبنون تعويذة مناسبة بأنفسهم docker run .

سيغطي هذا النهج بعد ذلك ليس فقط أوامر المسؤول لمرة واحدة ، ولكن أيضًا تصحيح الأخطاء المساعدة وخدمات الاستبطان مثل pgweb و Celery Flower (والتي تعد مفيدة جدًا للتشغيل قيد التطوير ، ولكنك لن ترغب عادةً في الإنتاج بسبب الأمان الإضافي مساحة سطح التهديد التي ينشئونها).

كما أن تحديد دلالات هذه "ليست خدمات" الجديدة يصبح أسهل كثيرًا: فهي _ بالضبط _ هي نفسها services (بما في ذلك جميع التغييرات المستقبلية لهذا التنسيق) ، مع استثناء وحيد وهو الأوامر غير المؤهلة مثل docker-compose build تجاهلها بالكامل docker-compose pull و docker-compose up - إذا كنت تريد معالجة أي مكون مدرج في "الأدوات المساعدة" بدلاً من "الخدمات" ، فأنت بحاجة إلى تسميته على وجه التحديد (على الرغم من وجود يمكن أن يكون خيار --all ، مشابه للخيار الحالي لـ docker-compose rm ). ومع ذلك ، فإن واجهة سطر الأوامر (CLI) للتفاعل مع هذه الأدوات المساعدة بالاسم ستكون مماثلة لتلك الخاصة بالتفاعل مع الخدمات العادية (على عكس الوضع الراهن ، حيث تحتاج إلى تحديد ملف تكوين الأداة الإضافية) ، وسيهتم عامل الإرساء بمنع تعارض الأسماء بين تعريفات الخدمة والمرافق.

في حين أن اقتراح التحجيم في # 2496 يمكن استخدامه (ab) للحصول على هذا السلوك ، إلا أنه لا يزال يبدو كحل بديل وليس ميزة مصممة بشكل صحيح.

أحب هذا التصميم ،ncoghlan.

بدلاً من utilities ماذا عن مجرد تسميته .services ؟ يوضح هذا بشكل طبيعي أن services و .services يستخدمان نفس الدلالات بالضبط ، والفرق الوحيد هو أن .services لا يتم تشغيلهما افتراضيًا. إنه تناظرية قريبة جدًا من أسماء الملفات التي لا يتم عرضها افتراضيًا. أفترض أن الجانب السلبي هو أن التمييز بين الاثنين دقيق بعض الشيء.

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

1. لا توافق على أن _all_ الأوامر غير المؤهلة يجب أن تتجاهل هذه الأدوات بشكل افتراضي. في رأيي ، يجب تشغيل جميع الأوامر بشكل طبيعي باستثناء تلك التي قد تؤدي إلى تشغيل حاوية. (بشكل أساسي ، up و start .)
2. فيما يتعلق بتعليقdsem ، أحب دلالات "المنفعة" أفضل من ". الخدمات". أنا أفهم منطق الملف المخفي unixy ، لكن هذه الأشياء ليست مجرد خدمات مخفية ، إنها مساعدين للخدمة.

bfirshncoghlan أتفق تمامًا مع dnephin :

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

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

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

لأي شخص يريد اختبار ذلك ، إليك أوامر إنشاء وتشغيل عامل ميناء في حاوية:

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

acran ، أود مساعدتك في تحديث المستندات ذات الصلة وحالات الاختبار. هل الامور على ما يرام ؟

@ dattran-vn01 بالطبع ، سأكون سعيدًا: مبتسم:

acran في up baz .
يمكنك أيضًا إنجاز الأمر نفسه باستخدام عدة ملفات Compose.

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

acran في Compose الحالي هو الأول ، ويمكن تحقيق هذا السلوك باستخدام up baz.
يمكنك أيضًا إنجاز الأمر نفسه باستخدام عدة ملفات Compose.

dnephin نعم ، بالضبط ، أعرف ، وفي هذا المثال سيكون أسهل طريقة.
لكن تخيل هذا مع 10 خدمات وخدمة واحدة لمرة واحدة فقط (مثل "init" أو "backup" / "dump"): في هذه الحالة سيكون عليك إدراج جميع الخدمات في سطر الأوامر باستثناء تلك الخدمة الفردية- خارج الخدمة مثل docker-compose up service1 service2 ... service10 (انظر أدناه). على وجه الخصوص ، سيتعين عليك تذكر جميع الخدمات وتتبع أي تغييرات يدويًا في docker-compose.yml .

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

هنا مثال آخر docker-compose.yml لتصور المشكلة:

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

تبدأ هنا docker-compose up _ مع السمة auto_up كل الخدمات باستثناء الخدمة init . لتحقيق نفس الشيء بدون ذلك ، سيتطلب الأمر كتابة أمر أطول بكثير مع 10 خدمات أو تقسيم ملف YAML والاضطرار إلى تحديد ملفات متعددة.

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

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

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

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

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

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

تبدو هذه البطاقة مثل مثال رئيسي على هذا :)

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

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

أرغب في عدم بدء خدمات "تصحيح الأخطاء" تلقائيًا ، ولكن إذا أردت إضافتها ، يمكنني القيام بذلك باستخدام docker-compose up -d database-gui بسيط وسيتم إضافته فقط.

أيضًا: أحيانًا أغير رأيي وأريد أن تبدأ إحدى هذه الخدمات دائمًا ... => باستخدام الخيار 2) يمكنني فقط تغيير هذا العلم

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

هنا فقط لإضافة +1. أنا أعمل على تطبيقات Django وعند تشغيلها في docker سيكون من الجيد أن يكون لديك حاوية تقوم بتشغيل shell أو الاختبارات أو ترحيل الأوامر لهذه المسألة. لكنني لا أريد تشغيل أي من هذه في كل مرة أقوم فيها بتشغيل التطبيق. أثناء استخدام ملفات تكوين متعددة ، قد يتطلب الأمر كتابة أو كتابة نصوص أو تسمية أسطر أوامر بطول ميل. إذا أردت أن أفعل ذلك ، فلن أستخدم الإنشاء على الإطلاق ، فسأقوم فقط بشل حاوياتي (أو نصوص Python ... ربما أضيف ملف YAML موحدًا لتخزين تكوينات الحاوية ... انتظر ...) لا أريد القيام بأي شيء مثل docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate فقط لتشغيل عمليات ترحيل قاعدة البيانات على الحاوية الخاصة بي. البديل هو استخدام /bin/true كأمر والقيام بشيء مثل docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate' وهو أمر غير أنيق أيضًا. لذا فإن وجود أوامر لمرة واحدة مخزنة في مكان ما في التكوين سيكون مفيدًا جدًا بالنسبة لي. أي من الخيارات 2 و 3 و 4 سيعمل معي.

أود أن أقترح عليك إلقاء نظرة على dobi ، وهي أداة كنت أعمل عليها استنادًا جزئيًا إلى التعليقات الواردة من هذا الموضوع.

تم تصميم Compose لبدء تشغيل خدمات طويلة الأمد تشكل "بيئة".
dobi يركز على بناء مشروع تسلسلي taks.

الأشياء التي تبحث عنها (تشغيل shell ، تشغيل اختبارات الوحدة ، تشغيل الترحيل) كلها مهام مشروع ، لذا فهي تناسب نموذج dobi بشكل أفضل.

يعمل dobi and Compose معًا بشكل جيد ، يمكنك بدء الإنشاء من dobi باستخدام مصدر التأليف .

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

التي يمكنك تشغيلها باستخدام:

dobi dev-environment

يوجد مثال لتكامل الإنشاء وتشغيل عمليات ترحيل db هنا: https://github.com/dnephin/dobi/tree/master/examples/init-db-with-rails

توجد أمثلة للعديد من مهام سير العمل (بما في ذلك إجراء الاختبارات ، وبدء غلاف تفاعلي ، والإصدار ، وبناء الحد الأدنى من الصور) هنا: http://dnephin.github.io/dobi/examples.html

+1 لـ 2). من وجهة نظرنا ، لا داعي للتفكير في حالات الاستخدام غير المألوفة ومناقشتها مثل الأوامر لمرة واحدة ، ولكننا نريد فقط الحصول على خدمات حقيقية يتم إنشاؤها وجاهزة للاستخدام ، ولكن يمكن البدء عند الطلب عند الحاجة (وعدم الاستهلاك الافتراضي مصادر).

"حالات استخدام غير شائعة"؟ هل تدير عمليات ترحيل قاعدة البيانات؟ هل تجري اختبارات الوحدة؟ هل تدير لينت؟ حزمة الويب؟

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

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

اتصل بهم المهام ، الأوامر ، أيا كان ، لكنني نوعا ما بدونها.

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

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

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

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

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

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

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

قيد التطوير ، لدينا حاليًا 4 ملفات إنشاء عامل ميناء:

• docker-compose.yml : يحدد الخدمات الأساسية اللازمة لتشغيل تطبيقنا بالكامل ، على سبيل المثال redis و MySQL و php-fpm ومعالج Laravel queue و nginx و Solr
• docker-compose-utils.yml : يحدد خدمات المرافق اللازمة لتشغيل مهام التطوير ، مثل gulp، npm، artisan (Laravel)، composer، redis-cli ، وعادة ما يتم تشغيلها مع الخدمات المذكورة أعلاه
• 2 المزيد من ملفات docker-compose لتعريف البيئة والأحجام للخدمات المذكورة أعلاه

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

نحن نطور على أنظمة macOS و Windows و Linux. بالإضافة إلى ذلك ، تتطلب العديد من مهام dev نوعًا من تحديد المعاملات (على سبيل المثال ، إنشاء ترحيل قاعدة بيانات ، تشغيل أمر composer / artisan / npm مع الوسائط الخاصة به) ، لذلك قمت بإنشاء schmich/runx كتثبيت عبر عداء مهام النظام الأساسي لتجميع مهام التطوير المشتركة لدينا.

على سبيل المثال ، يتيح لنا ذلك أن نقول إن runx يهاجر: اجعل create_some_table لتشغيل docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table بفعالية ، أو

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

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

نظرًا لأن لا أحد علق على حالات الاستخدام باستخدام ملفات .env ، فإليك لي:

لدي 4 ملفات مؤلفة: docker-compose.yml و docker-compose.local.yml و docker-compose.prod.yml و docker-compose.ci.yml. لكل بيئة لدي .env مختلفة:

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

وهلم جرا...

لا داعي للقلق من المستخدمين و / أو البرامج النصية بشأن ملفات الإنشاء التي يجب استخدامها نظرًا لأن البيئات تم تكوينها بالفعل بشكل فردي.

ولكن لدي مثيل صيانة ليتم تشغيله في النهاية ، ولا يمكن تهيئته داخل docker-compose.yml الرئيسي وسيكون أحد الحلول هو إنشاء docker-compose.worker.yml وتنفيذ سطر أوامر مع 3 خيارات "-f" تتغير مع كل بيئة. هذا خطأ عرضة ليكون خيارًا قابلاً للاستخدام.

كان الحل الذي وجدته هو إنشاء دليل "عامل" ، ووضع ملف yml هناك ، وربط ملف env العلوي بهذا الدليل وإنشاء ملفات docker-compose فارغة. [ci | local | prod] .yml (وإلا كنت سأمتلك لتغيير قيمة متغير COMPOSE_FILE).

هذا يعمل بشكل جيد ، لكنه بعيد عن أن يكون الأمثل. أي حل آخر من البروتوكول الاختياري سوف يزيل هذا دون أي فوضى.

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

لذلك أرغب حقًا في نقل المناقشة هنا من _if_ يجب تنفيذ هذا أكثر إلى _كيف _ يجب تنفيذ ذلك. هل يمكن أن نتفق جميعا على هذا ؟

فيما يتعلق بـ _how_ يمكن تحقيق ذلك ، قام bfirsh بإدراج بعض الخيارات في التعليق الافتتاحي:

1) نوصي المستخدمين باستخدام ملف تكوين منفصل

هذا هو الحل الوحيد المتاح حاليًا لحالة الاستخدام هذه. ولكن كما ذكرنا أعلاه ، فإنه في هذه الحالة أكثر من حل بديل لأنه يتطلب كتابة أسطر أوامر طويلة يدويًا وتذكر ملفات الإنشاء التي سيتم تضمينها لأي أمر يتم تشغيله.
بالطبع ، في إعداد CI أو النشر التلقائي للإنتاج ، هذه ليست مشكلة ، حيث يجب تحديد سطر الأوامر مرة واحدة فقط وعدم كتابته يدويًا. إذن ، يتعلق الأمر فقط بالراحة في البيئات غير الآلية ، أي التطوير ، والذي يعد وفقًا لدليل عامل الإرساء أحد حالات الاستخدام الرئيسية لـ Compose نفسه:

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

إن الاضطرار إلى كتابة شيء مثل docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init فقط لتهيئة إعداد محلي لا يبدو لي _ مريحًا_ ولكنه أشبه بشيء يمكن العثور عليه في _ a متعدد الصفحات "دليل بدء مطور" _.

وللنظر في الخيار 1 ب) هنا:

نوصي المستخدمين باستخدام برنامج نصي / أداة مجمعة لاستخدام ملفات تكوين منفصلة

إذا كان عليّ سحب أدوات وتبعيات إضافية لهذا الغرض فقط ، فلماذا استخدم docker-compose في المقام الأول؟ نظرًا لأن كل ما يفعله docker-compose يمكن - من الناحية النظرية - أن يتم أيضًا باستخدام برنامج نصي shell مخصص والعميل الأصلي docker مباشرةً.
أرى الميزة الرئيسية لـ docker-compose في واجهة المستخدم المعيارية (أنا استنساخ مشروع ، شاهد docker-compose.yml هناك وأعلم أنني يجب أن أشغل docker-compose up للبدء) . الحاجة دائمًا إلى معرفة ملف الإنشاء الذي يجب استخدامه لما يضعف هذه الميزة بشكل كبير.

2) إضافة خيار للخدمات لجعلها لا تبدأ بشكل افتراضي
3) أضف خيار تكوين عالي المستوى لتحديد الخدمات الافتراضية

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

4) أضف مفهومًا لشيء مثل الخدمة ، ولكنه مخصص فقط للأوامر الفردية ("البرامج النصية" ، "المهام" ، إلخ ...)

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

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

أوافق على أن الخيار 2 ربما يكون الأقل تدخلاً. الميزة الوحيدة التي أرى أن الخيار 4 قد يوفرها هي القدرة على تشغيل الأوامر على الحاويات الموجودة (باستخدام آلية docker exec). على سبيل المثال ، إذا كان كل ما أريده هو تشغيل ترحيل قاعدة البيانات أو اختبارات الوحدة ، فقد لا يكون هناك سبب لإنشاء حاوية منفصلة كاملة لها إذا كان لدي بالفعل حاوية تقوم بتشغيل تطبيقي. ومع ذلك ، فإن الحاويات خفيفة الوزن وسأكون سعيدًا تمامًا بالخيار 2.

MadWombat لدي نفس الشعور تجاه الخيار 4 ، ولهذا السبب اقترحت ميزة أخرى لحالة الاستخدام هذه: # 4096. يوجد تداخل مع الميزة الموضحة هنا ، لكنني أعتقد أنه قد يكون مفيدًا بمفرده أو بشكل إضافي لهذه الميزة

mathroc لقد ذكرت الخيار 4 باستخدام docker exec ، حيث سأل

الميزة الوحيدة التي أرى أن الخيار 4 قد يوفرها هي القدرة على تشغيل الأوامر على الحاويات الموجودة (باستخدام آلية docker exec).

إنها بالفعل حالة استخدام جديدة من شأنها أن تبرر (وتتطلب) تقديم مفهوم جديد عالي المستوى يختلف عن الخدمات. ولكن طالما أن الأوامر لا تحتاج إلى تشغيلها عبر docker exec داخل حاوية الخدمة الموجودة بالفعل ، يجب أن يكون مفهوم الخدمة الحالي كافياً.

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

أقرب حالة يمكنني التفكير فيها هي شيء مثل تغيير ملف التكوين داخل الحاوية وتشغيل إعادة التحميل بواسطة التطبيق ؛ باستخدام مثالmathroc من # 4096:

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

على الرغم من ارتباطه بهذه المشكلة ، إلا أن # 4096 يحتوي على حالات استخدام خاصة به وربما الخيار 4) هل من الأفضل نقله إلى هناك؟

لقد مر أكثر من عام من المناقشة ولا يبدو أننا نتخذ قرارًا بعد الآن. يجب على bfirsh اختيار أسلوب ما والذهاب معه: ابتسم:

+1

+1 ، ستكون ميزة مفيدة جدًا.

و +1 آخر للخيار 2 ، بشيء مثل auto-start: false أو enabled: false .

حالة الاستخدام الخاصة بي توسع الخدمات. لا يمكن توسيع الخدمات التي لديها depends_on set ، لذا فإن ما أود فعله هو تحديد قالب خدمة ، ثم تمديد عدة خدمات منه. من الواضح أن القالب يجب أن يُبنى ، لكن لا يعمل تلقائيًا.

لقد أنشأت الحل الخاص بي ، احصل على حرية الاستخدام.
لا يزال في الإصدار التجريبي :)

https://github.com/jonathanborges/picles-docker

الكثير من الخيارات الرائعة هنا. الحاجة إلى الميزة حقيقية.

من الواضح أن الخيار 2 هو الأكثر شيوعًا:

1 -> 4
2 -> 52
3 -> 3
4 -> 10

آخر 👍 للخيار 2

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

docker-compuse up -d
docker-compose run tools tests

نعم ، ستظهر خدمة الأدوات على أنها "متوقفة" في docker-compose ps . إذا كان هذا غير مقبول ، فأنا الخيار متعدد الملفات من https://github.com/docker/compose/pull/2051 يعمل. على سبيل المثال

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

على الرغم من أنه يبدو أنه يتم كتابة الكثير من مساعدي التنسيق لهذه الحاجة ، وأنا مذنب بالعمل على واحد أيضًا :).

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

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

يتعلق الأمر بالراحة ، حول عدم الاضطرار إلى كتابة docker-compose -f docker-compose.yml -f docker-compose-tools.yml up يدويًا على cli ، يتعلق الأمر بعدم الاضطرار إلى تذكر ما إذا كان docker-compose run tools tests أو docker-compose run utils tests أو حتى الاعتماد عليه "دليل بدء مطور" متعدد الصفحات _ ولكن بدلاً من ذلك به واجهة موحدة وبسيطة للمطور.

مرة أخرى، CCingbfirsh،dnephin: هل يمكن أن يرجى تقديم _any_ ردود الفعل على هذه القضية؟ هل هناك أي أمل في أن نرى شيئًا كهذا في خارطة الطريق القادمة مقابل docker-compose ؟؟

briceburg لبيئة بسيطة ، ربما يكون الحل البديل مقبولًا ، لكنه في بعض الأحيان ليس كذلك. انظر إلى الإعداد الخاص بي:

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

لدي 8 ملفات إنشاء (أستخدمها في مجموعات متعددة) بالإضافة إلى الملفات الموجودة في الدليل worker ، حيث أقوم بتكوين حاويات "لا تبدأ افتراضيًا". الدليل worker (مع ملف env مرتبط بالأصل وبعض ملفات الإنشاء الفارغة للتوافق مع متغير env COMPOSE_FILE الخاص بالوالدين) هو الحل البديل ، لكن حياتي ستكون أسهل بكثير عندما يكون لدينا حل هذه المسألة.

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

في معظم الحالات ، سترغب في التأكد من أن الفحوصات الصحية تمر على الخدمات / الحاويات التابعة قبل تنفيذ الاختبارات - على سبيل المثال ، يتم تشغيل jenkins

إذا كنت سأقترح حلًا سحريًا ، فسيكون ذلك للسماح بتعيين ملف تعريف إنشاء عبر المتغيرات البيئية (مثل DOCKER_COMPOSE_PROFILE = "الاختبارات") ، والسماح للخدمات بأن تعتمد على ملف تعريف - حيث يتم تعيين جميع الخدمات افتراضيًا على "الافتراضي" "الملف الشخصي أو أيا كان. أود أيضًا أن أضمن أن الخدمات التي تعتمد على خدمة أخرى تعتمد أيضًا على HEALTHCHECK لتلك الخدمات. شيء من هذا القبيل

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

+1 للخيار 2.

اقترح الكثير هنا ميزات جديدة مثيرة للاهتمام ، ولكن ما هو جوهر المشكلة هنا؟ أنا أصوت لإبقائها بسيطة قدر الإمكان.

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

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

ما هي أبسط ميزة ممكنة "تنجزها" لنا جميعًا؟ إنه تحديث صغير لمواصفات docker - @ فكرة autostart: false

أصوت لصالح: "فقط افعل شيئًا لنا ، شكرًا". نصوت ، نحتاج الآن إلى إجابة واحدة على الأقل. 4 الله!

ما هي أبسط ميزة ممكنة "تنجزها" لنا جميعًا؟ إنه تحديث صغير لمواصفات docker - bfirsh رقم 2) حيث يمكن للخدمة تحديد التشغيل التلقائي: false

هذه طريقة أفضل من أي بديل آخر :)

في غاية البساطة.
scale: 0
https://github.com/docker/compose/issues/1661

@ درو ص ماذا؟

@ jonathanborges1542 إنها docker-compose scale servname=2 . لا يوجد مكافئ في ملف docker-compose.yml .

@ drew-r scale: 0 حاليًا بإخبار Docker daemon بإرسال SIGTERM / SIGKILL إلى جميع الحاويات الخاصة بالخدمة. هذا من شأنه أن يقتل أي مهمة صيانة حتى لو لم تكمل وظيفتها بعد. هذا هو السلوك المتوقع. تغيير هذا سيكون حالة سيئة من التحميل الزائد لما هو واضح السلوك الآن.

أتفهمgittycat ، لكن ما نريده هنا هو كتابة "

لقد كنت أتابع هذا الموضوع منذ أكثر من عام الآن (معظم المشاركات على جانب عامل الميناء).
أعتقد أن "الوظائف" الجديدة ذات المستوى الأعلى والتي تعيش جنبًا إلى جنب مع "الخدمات" و "الأحجام" و "الشبكات" هي الخيار الأفضل. هذا هو الخيار 4 في قائمة OP أعلاه.
إنه أيضًا اقتراح انتهى في Docker repo.
https://github.com/docker/docker/issues/23880

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

من الصعب قياس مدى سلامة هذا الحل من قائمة الملفات

كان الهدف هو إظهار أن لدي العديد من مجموعات الملفات وأن استخدام خيارات "-f" متعددة عرضة للخطأ جدًا بحيث لا يمكن القيام بها يدويًا.

أقترح فقط استخدام نقطة إدخال / أمر افتراضي لا يفعل شيئًا لتلك الخدمات التي تفضل عدم تشغيلها تلقائيًا.

في بعض الأحيان لا مفر من الهلاك. لكني أفضل الحل: أستخدم دليلًا مختلفًا لن يتم "تكوينه" أبدًا ، لذلك لن تكون هناك حاويات متوقفة عديمة الفائدة تلوث بيئتي. لهذا السبب لدي دليل عامل مع ".env" مرتبط بالأصل ".env".

إذا كنت سأقترح حلًا سحريًا ، فسيكون ذلك للسماح بتعيين ملف تعريف إنشاء عبر المتغيرات البيئية (مثل DOCKER_COMPOSE_PROFILE = "الاختبارات")

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

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

+1 @ درو- r # 1661

هل سيتم تنفيذ هذه المشكلة في وقت ما أم أنها مجرد شيء لا يريد المطورون فعله؟ سيكون من الجيد معرفة ذلك حتى يتمكن المجتمع من البدء في البحث عن حل آخر.

بالمناسبة أنا أصوت للخيار 2.

شكرا لك

+1 للخيار 2.
هل ستحترم التبعيات الصريحة على الرغم من ... links إلخ؟

إذا كنت أحدد الخدمة التي يجب طرحها بـ docker-compose up [service] فمن النادر أن أرغب في بدء أي خدمات بخلاف الخدمة المعنية وتبعياتها.

تصويت آخر للخيار 2. هناك أيضًا إعلان عام له (https://github.com/docker/compose/pull/3047) والذي كان لطيفًا بما يكفي لإنشاء acran ، لذلك يجب أن يكون الجهد من مطوري التأليف صغيرًا إلى حد ما ، لأنهم يحتاجون فقط إلى مراجعتها (وهي قصيرة جدًا وبسيطة) وعدم كتابة أي رمز.

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

إن تكوين

يتم تعقب الطلب في مستودع محرك الرصيف https://github.com/docker/docker/issues/23880
هذا هو المكان الذي سيأتي منه القرار / العمل.

أقترح إغلاق هذه القضية.

لا يزال لدى gittycat compose خيار إخبار المحرك ببدء الخدمة أم لا. هذا طلب صالح للغاية لا يزال.

أتخلى عن عامل الشحن في الإنتاج ، فهناك الكثير من المشاكل. ثم أهاجر إلى المتشرد.

صوت آخر لـ 2)

صوت آخر لـ 2 و 4.

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

إن وجود أمر بسيط للإعداد و / أو للاختبارات من شأنه أن يجعل الأمور أكثر نظافة.

صوت آخر لـ 2!

لقد قرأت هذا الموضوع لكنني قررت إنشاء منشور جديد (https://github.com/docker/compose/issues/4650) ، والذي تم إغلاقه وتمت إحالتي هنا. النقطة التي أردت توضيحها هي أنه في حين أن معظم المناقشة في هذا الموضوع تتعلق بعلامات لتعطيل تشغيل الحاويات ، فإن حالة الاستخدام الخاصة بي هي حالة ثالثة: إنشاء الحاويات.

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

ekkis لدي فضول لمعرفة كيف حدث ذلك. تتضمن حالة المستخدم الخاصة بي الإشارة إلى صورة الحاوية الرئيسية وتكوين "إجراءات" بديلة ، يمكن إجراؤها باستخدام شيء مثل bash ولكن من المنطقي استخدام Docker.

هل تتفضل بتقديم المزيد من التفاصيل حول مشكلتك؟

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

ekkis أقترح عليك إلقاء نظرة على # 963 ، يبدو مرتبطًا بما تبحث عنه.

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

+1 للخيار 2

: +1: للخيار رقم 2 مع سؤال عن أي تقدير لهذه الميزة؟ ما هو أفضل حل بديل؟ بقدر ما أستطيع أن أتخيل ، أحتاج إلى سرد جميع خدماتي مثل:

docker-compose up service1 service2 service3

... وحذف تلك التي لا أريد أن أبدأها افتراضيًا

هل هناك أي طريقة يمكننا في مجتمع المصادر المفتوحة المساعدة في المساهمة بهذه الميزة التي تبدو مطلوبة بشدة؟

+1 للخيار 2.
طريقة لتحديد "المرحلة" ستكون رائعة. لنفترض أن الخدمة ستعمل فقط في الإنتاج.

+1 للخيار 2.

التصويت للخيار 2

up ستكون تصفية الأوامر مثالية - docker-compose up service1 service3

: +1: للخيارين 2 و 4

في هذه المرحلة ، يبدو أن الخيار 2 هو ما يريده المستخدمون. ما هي الخطوات التالية لتحقيق ذلك؟

هنا لإجراء +1 للخيار 2 ، صادفت هذه المشكلة على أمل أن تكون هذه الوظيفة موجودة بالفعل.

+1 على الخيار 2

... وآخر +1 للخيار الثاني

+1 للخيار 2

+1 للخيار 2 :-)

+1 للخيارين 2 و 4

تحية للجميع،
+1 خيار 2

IMHO ، سيكون الخيار مفيدًا جدًا في البيئات المحلية ، عندما يكون لديك تطبيق يعتمد على الخدمات الصغيرة أو مع بنية سداسية ؛ كمطور ، يمكنني تشغيل العناصر الضرورية فقط لأقرب أعمالي ؛

الخيار 2 هو الخيار الذي يريده معظم المستخدمين. هل لا يزال يتعين اتخاذ القرار بشأن هذا الأمر أو أن التطوير قد بدأ ويجري تتبعه في مكان آخر؟

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

بالطبع +1000 للخيار الثاني

+1 خيار 2

هل سيحدث أي فرق إذا قمت بالتصويت للخيار الثاني؟ يبدو أنه من غير المحتمل أن يحدث ذلك.

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

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

@ shin- قبل قفل هذا ، هل يمكنني الحصول على الوضوح إذا كان المجتمع يرغب في التطوير ، فهل يقوم الفريق الأساسي بدمجه إذا كان يفي بمعايير الفريق؟ في المواضيع هناك تنفيذ وأعضاء المجتمع على استعداد لإكماله ، كانوا يبحثون فقط عن بعض التأكيد على أنه لن يكون مضيعة لاستثماراتهم. إذا تمكنا من الحصول على بعض الملاحظات ، فسأقوم بتتبع هذه المواضيع لنقلها لمعرفة ما إذا كان بإمكاننا نقل هذا إلى الإغلاق.

jimzucker لا - لأن المشكلة هنا ليست في التنفيذ ؛ قد يستغرق التنفيذ الأساسي لهذا الأمر نصف يوم لمطورك العادي. ما يهمنا هنا هو مشكلة أساسية في التصميم.

1. ما هي الخدمة؟ حسب التصميم ، فإن الخدمة هي عملية محددة بوضوح وطويلة الأمد تتفاعل مع خدمات أخرى لتشكيل تطبيق. هذا هو الافتراض الأساسي الذي يعمل في إطاره Compose وهو يوجه تصميمنا لمعظم الميزات التي ننفذها ، إن لم يكن جميعها.
2. وفقًا لهذا التعريف ، فإن "الخدمة التي لم يتم تشغيلها افتراضيًا" ليست خدمة في الواقع [1] - إنها مهمة محددة مسبقًا ، تعمل في حاوية وتعمل على التطبيق ، بدلاً من أن تكون جزءًا منها.
3. ومن ثم فمن الخطأ (جوهريًا حسب التصميم) تسميتها خدمة. في هذه المرحلة ، نحتاج إلى التفكير في إنشاء نوع جديد من التعريف في ملف Compose الخاص بك (سأسميها "مهمة" للإيجاز ، المصطلحات الدقيقة لا تهم هنا).
4. نظرًا لأن المهام هي عمليات تشغيل قصيرة بطبيعتها ، فإنها تستخدم مجموعة مختلفة من الخيارات مقارنة بالخدمات. على سبيل المثال ، يمكننا أن نستشعر أن المهام لا تحتاج إلى كشف المنافذ [2]. من ناحية أخرى ، يمكن أن يكون خيار مثل ملف CID الذي لا معنى له في الغالب للخدمات مفيدًا حقًا للمهام.
5. الآن ، في معظم المشاريع ، تميل المهام إلى أن يكون لها سلاسل تبعية (لهذا السبب في العالم التقليدي غير الحاوية ، لدينا ملفات Makefiles) - لذلك نحتاج على الأقل إلى تنفيذ أساسي لسلاسل التبعية ، بالتوازي ، والقدرة على معرفة إذا كانت مهمة إنشاء JAR التي تستغرق دائمًا 10 دقائق تحتاج حقًا إلى التشغيل مرة أخرى.
6. بعد ذلك ، تعتمد بعض الخدمات فعليًا على المهام التي تم تشغيلها قبل التمكن من البدء ، مما يضيف مستوى آخر من التعقيد إلى كيفية حساب التبعيات والتعامل معها.
7. وتحتاج بعض المهام إلى بعض الخدمات ليتم تشغيلها (مثل ترحيل قاعدة البيانات).

في هذه المرحلة ، أصبح هذا جزءًا جديدًا تمامًا من الكود ربما يطابق أو يتجاوز cmake من حيث النطاق والتعقيد. هذا هو السبب في أننا قاومنا تنفيذ هذا الأمر لفترة طويلة - ويرجع ذلك جزئيًا إلى أن هذا ليس ما تم تصميم Compose من أجله على الإطلاق ، ولكن أيضًا لأننا [3] ببساطة لا نملك الوقت أو الموارد لتنفيذ هذه الميزة أو الحفاظ عليها أن تصبح مفيدة حقًا للناس.

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

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

@ شين - أرى النقطة. ما أسعى وراءه هو "الخدمات الاختيارية" في حواشيكم وحالات الاستخدام لذلك ، وليس فكرة المهام ، هل يمكننا بطريقة ما الاتفاق على كيفية إحراز تقدم في هذه النقطة حيث كان ذلك جزءًا من الموضوع الذي أحاول الدفاع عنه و تذكرتي بوضوح على هذا المسار حيث أغلقت لصالح هذا الموضوع. إذا تمكنا من فصل ذلك عن النقاط التي حددتها بوضوح على أنها "مهام" ، فيمكننا تحقيق بعض التقدم. عندما يقوم الأشخاص بإجراء +1 للخيار 2 في قراءتي ، فإن ذلك يكون للخدمة الاختيارية. يسعدني أخذ هذا دون اتصال بالإنترنت للمناقشة ويمكننا بعد ذلك العودة إلى المنتدى ، أنا على [email protected]

@ shin- وجهة نظرك رقم 2 خاطئة. الخدمة هي خدمة بغض النظر عما إذا كانت قيد التشغيل. هناك عدد لا يحصى من حالات الاستخدام حيث ستعمل الخدمات التابعة على تعديل السلوك عندما لا تكون التبعية متاحة ، لذلك قد لا تتطلب طبقة التطبيق الخاصة بك ، ولا يجب ، أن تكون جميع "الخدمات" متاحة في جميع الأوقات

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

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

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

بالضبط ، باستخدام حقل منطقي بسيط ، يمكننا بسهولة تمكين / تعطيل الخدمات من ملف .env وتجنب تحرير ملف yaml.

ekkis أعتقد أنك تخلط بين التسامح مع الخطأ

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

@ shin - أقدر لك قضاء بعض الوقت في إجراء هذا الحوار معنا. أوافق على أن هناك عدة طرق للقيام بذلك ، نظرًا لأنك تقترح ملفات yml متعددة ، يمكنك أيضًا تمرير قائمة من الخدمات ولكنها ليست مريحة وتؤدي إلى خطأ المستخدم مما يؤدي إلى حدوث مخاطر تشغيلية. خاصة في حالة المنتج التجاري ، نريد توزيع ملف إنشاء واحد والحصول افتراضيًا على السلوك الشائع المطلوب وإعطاء إرشادات للخيارات المتقدمة ، ملف واحد يجعل كل هذا أكثر إتقانًا لكل من dev و CI / CD والتوزيع. كانت إضافة متغيرات ENV مع الإعدادات الافتراضية مساعدة كبيرة لنا وألغت الحاجة إلى وجود العديد من ملفات yml ، وستكون هذه خطوة أخرى نحو إدارة ملف واحد يصف النشر.

هل هناك أي شكل يرغب فيه الفريق الأساسي في قبول مساهمة في LMK.

shin ، لم

@ shin- أتفق بشدة مع ekkis : عدم البدء _ افتراضيًا_ لا ينتهك تعريف كونها خدمة ، وبالتالي فإن نقطتك 2. هي افتراض غير صحيح _ بالضرورة _ وكذلك النقاط المتتالية نظرًا لأنها تستند إلى افتراض 2.

على سبيل المثال: عندما أقوم بتطوير تطبيق باستخدام mysql DB ، عادةً ما أقوم بتعريف _service_ إضافية phpmyadmin . هذه خدمة حقيقية: منافذ مكشوفة طويلة المدى تعتمد على الخدمات الأخرى.
لكنني لا أريد أن أبدأ هذه الخدمة _ افتراضيًا_ ولكن فقط عند الطلب / قيد التطوير.
أدرك ذلك حاليًا من خلال وضع هذه الخدمة في مبلغ إضافي docker-compose.yml وبدء تشغيله من خلال تقديم كلا الملفين إلى docker-compose - تمامًا كما اقترحت أعلاه.

لذا ، نعم ، هناك بالفعل طرق ممكنة لتحقيق ذلك ؛ سواء كان ذلك عن طريق تقسيم الخدمات إلى ملفات متعددة أو ببساطة باستخدام أداة أخرى غير docker-compose . ولكن كما كتبت أعلاه : لا تتعلق هذه المشكلة بميزة / وظيفة جديدة تمامًا أو مفهوم جديد (مثل _المهام_) ولكنها تتعلق بالراحة ، خاصة في بيئات التطوير .
إن الاضطرار إلى كتابة docker-compose -f docker-compose.yml -f docker-compose-tools.yml up ليس شيئًا مريحًا ، وبالتالي فإن docker-compose لا يفي بوعوده الخاصة :

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

الخدمات التي يجب بدء تشغيلها أو ملفات yml يجب استخدامها في أي بيئة يمكن العثور عليها عادةً في _متعدد الصفحات "دليل [مطور] بدء التشغيل" _ - إذا كان موجودًا على الإطلاق ...

لذا في رأيي ، وكما كتب jimzucker ، فإن معظم إجراءات 1+ هنا هي حقًا "للخدمات الاختيارية" بدلاً من مفهوم جديد للمهام. على الأقل جميعهم أفضل حالًا باستخدام قيمة منطقية بسيطة للإشارة إلى _خدمة_ ليتم تشغيلها افتراضيًا أم لا.

نظرًا لأن PoC الخاص بي يُظهر تغيير الرمز المطلوب - من أجل "الخدمات الاختيارية" - يمكن التحكم فيه تمامًا ويوفر لمعظم الأشخاص هنا فائدة كبيرة في الراحة. الخيار 2 - يُقرأ على أنه "_ إمكانية وضع علامة على خدمة اختيارية_" - هو حل وسط معقول لحل هذه المشكلة.

@ shin- ألا توافق على أن منح المستخدمين إمكانية تمييز الخدمات على أنها اختيارية - لكنها لا تزال خدمات - من شأنه أن يساعدهم كثيرًا؟
عند تقليصها إلى "تعليم _ الخدمات_ على أنها اختيارية / لم تبدأ بشكل افتراضي" ، هل سيتم قبول ودمج هذه المشكلة / طلب السحب لهذا الغرض؟

shin ، للإضافة إلى نقطة acran أعلاه ، قد أرغب في إنشاء خدمات معينة فقط لأن هذه الخدمات سيتم تشغيلها بواسطة خدمات أخرى باستخدام الأسماء . ضع في اعتبارك أنه في كل مرة أقوم فيها بـ "up" أحصل على مجموعة من "الخدمات" المسماة project_app_1 ، و project_otherapp_1 ، وما إلى ذلك ، فهذه لا معنى لها لأنها تحتاج إلى أن يتم تشغيلها باستخدام المعلومات الموجودة في قاعدة بيانات (لدي خدمة رئيسية تعمل على تشغيلها) . لذلك يجب أن أقتلهم دائمًا. لذلك بالنسبة لي ، فإن علامة NO_RUN أو BUILD_ONLY منطقية تمامًا. سيكون هذا مناسبًا

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

ألا توافق على أن منح المستخدمين إمكانية تمييز الخدمات على أنها اختيارية - لكنها لا تزال خدمات - من شأنه أن يساعدهم كثيرًا؟

أنا لا أوافق على مقدار المساعدة - أعتقد أن كلمة "كبيرة" مبالغ فيها. في المثال الخاص بك ، مجرد الحصول على docker-compose.phpmyadmin.yml الذي يمكن إدراجه اختياريًا ليس أكثر صعوبة أو تعقيدًا (من حيث التعليمات "أدلة المطور") من تعيين متغير بيئة / تعديل تعريف الخدمة داخل الملف الرئيسي.
أنا أفكر أيضًا في المقايضة بين منح المطورين "المسدسات" عندما لا يكون ذلك ضروريًا تمامًا.

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

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

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

shin إذا كان من الممكن استخدام docker - compose.yml لإنشاء خدمة ، فهي أداة مفيدة للغاية في مركزية عملية البناء الخاصة بي. إنه لمن المنطقي في الواقع أنني قد أرغب (بشروط) في إنشاء خدمة قبل تشغيلها ، وأنا أحيي هذه الوظيفة

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

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

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

@قصبة-

في المثال الخاص بك ، مجرد وجود docker-compose.phpmyadmin.yml الذي يمكن تضمينه اختياريًا ليس أكثر صعوبة أو تعقيدًا (من حيث التعليمات "أدلة المطورين") من إعداد متغير بيئة / تعديل تعريف الخدمة داخل الملف الرئيسي.

في الواقع لم أفكر في تضمين متغيرات البيئة هنا حتى الآن. أخيرًا ستسمح "الخدمات الاختيارية" لسير العمل المطلوب كما يلي:

• أنا أنسخ / استنساخ مشروع جديد
• أرى أن هناك ملفًا (واحدًا) docker-compose.yml فيه ، لذلك أعلم ، كل ما علي فعله هو تشغيل docker-compose up ويتم إنشاء التطبيق وتشغيله
• الآن أريد أن أبدأ إحدى الخدمات الاختيارية لأغراض التطوير (مثل التصحيح الإضافي ، phpMyAdmin). كل ما علي فعله هو docker-compose up phpmyadmin .

بالنسبة لي ، يعد هذا أكثر ملاءمة من استخدام ملفات متعددة docker-compose.yml ، وكما أفهم بالنسبة لمعظم الأشخاص الآخرين هنا أيضًا. فائدة الحصول على "خدمات اختيارية" هنا

• من أجل عدم اضطرار المطور إلى نسخ أي شيء بين ملفات متعددة أو الاضطرار إلى التفكير بعناية في التعريفات التي يجب وضعها في أي ملف ، ولكن يتعين عليه فقط تعيين علامة منطقية واحدة ( auto_up: false ) على إحدى الخدمات
• لا يحتاج المستخدم إلى معرفة / تذكر الملفات التي يجب تضمينها من أجل الخدمات: هل أحتاج إلى التشغيل
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up أو حتى
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ؟
  
  
• بدلاً من ذلك ، فإن الشيء الوحيد الذي يحتاج المستخدم إلى معرفته هو أن هناك خدمة تسمى phpmyadmin ويعرف المستخدم على الفور كيفية بدء تشغيلها.

انظر أعلاه - بمجرد توفر هذه الميزة ، سيبدأ الأشخاص في استخدامها لأشياء أخرى غير الغرض المقصود منها ، ويتوقعون منا تنفيذ مجموعة ميزات جديدة لدعمها

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

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

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

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

أميل إلى استخدام شوكة docker-compose التي تنفذ هذه الميزة فقط لهذه الميزة الفريدة.

@ shin - على الرغم من أنني أعتقد أننا جميعًا نتفهم وجهة نظرك ونتعاطف معها ، لا أعتقد أن عبارة "قد يتم إساءة استخدامها" هي حجة جيدة لشيء ما - من الواضح - العديد من حالات الاستخدام القابلة للتطبيق. بالطبع _سوف يساء استخدامها. هذا هو بالضبط كيف تنمو البرامج والأفكار الجديدة ؛ من استخدام التكنولوجيا ليس تمامًا كما ينبغي. لن يكون الويب على ما هو عليه اليوم إذا لم نسيء استخدام جميع التقنيات المقدمة على مدار الـ 25 عامًا الماضية.

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

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

@ shin - إذا كان يجب عدم استخدام عامل الإرساء كملف makefile ، فلا ينبغي أن يوفر وظيفة makefile. إذا سمح لي ببناء مشاريعي (برافو!) ، فإن اتخاذ الموقف القائل بأنه ليس ملف عمل هو أمر سخيف

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

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

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

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

rysiekpl هذه مشكلة نتطلع إلى حلها بطريقة مختلفة ، راجع https://github.com/docker/cli/pull/452 (بمجرد مناقشة بناء الجملة ، ستشق طريقها إلى Compose و v2 مثل حسنا)

creynders أعتقد أن هذا نوع من <img> بشكل صريح غير صالح وما إذا كان يجب أن يدعمها متصفحنا المحدد أم لا.

أيضًا ، من وجهة نظرك:

لكن هذا التمييز لم يتم توضيحه أو شرحه في أي مكان في الوثائق. ولا يُشار في أي مكان إلى أن عامل الرصيف لا يُقصد به استخدامه لتدوير العمليات الزمنية.

هذه في الواقع هي الفقرة الأولى من صفحة https://docs.docker.com/compose/overview/ (التركيز لي):

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

ekkis يسعدني حقًا أن لمشاريعك ! آمل ألا أكون غير صادق في كل هذا ، فلا بأس إذا كانت هذه هي الطريقة التي تريد استخدام البرنامج بها. ومع ذلك ، فإن ما أقوله هو أن المضي قدمًا في هذا الاتجاه قد يزيد الأمر سوءًا على المدى الطويل. نعلم جميعًا ما يحدث للتطبيقات التي تحاول القيام بأشياء كثيرة (على الرغم من أنني أعتقد أن Emacs قد نجح في إيقافها: stuck_out_tongue:)

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

تقوم بإنشاء وبدء جميع الخدمات من التكوين الخاص بك.

وأعتقد أن رأينا هو أنه كان يجب قراءة "إنشاء و / أو البدء" ، على الرغم من أنه لكي نكون منصفين للغة لا يحتاج المرء إلى الإشارة إلى OR لأنها ضمنية في AND. بعبارة أخرى ، من الصحيح أنه يمكنك إنشاء خدمة وبدء تشغيلها ولكن ليس هناك ما يعني أنه يجب عليها القيام بالأمرين معًا

نعلم جميعًا ما يحدث للتطبيقات التي تحاول القيام بأشياء كثيرة جدًا

نعم ، يمكنني أن أقدر أنك تدير حدود المجال

لا أعتقد أنني كنت "سلطوية"

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

كفكر فراق ، أود أن أطلب منك إعادة مراجعة https://github.com/docker/compose/issues/4650 وهو ليس نفس الطلب الموجود في هذا الموضوع (كما أشرت عند إغلاقه) ولكنه يلائم استخدامي الحالة ، وهي أن العلم الذي تتم مناقشته هنا ليس ثنائيًا ولكنه ثلاثي

تعجبني حقًا فكرة تحديد ملفات متعددة. ومع ذلك ، فإن تضمين جميع الملفات ذات -f بما في ذلك الملف الأصلي يبدو أنه تجاوز إجمالي.

هناك بالفعل طريقة أكثر عملية ، تناسبني (انظر PS أدناه): ضع كل الخدمات التي لا تريد تشغيلها في docker-compose.override.yml . واستخدم docker compose -f docker-compose.yml up لبدء التشغيل العادي (لاحظ أن هذا أمر لمرة واحدة). في جميع المكالمات المتتالية ، سيتم تحديد مصدر التجاوز ...

بشكل عام ، هذا كله غير بديهي وغير مرضٍ بعض الشيء. إضافة إضافي:

• يعد خيار تعطيل الخدمات منطقيًا خاصة بالنسبة لعمليات التجاوز الأكثر تعقيدًا

• يعد الخيار -f ضئيلًا ولكنه ليس بديهيًا للغاية ، خيار -F <name> الذي يضيف فقط تجاوزات إضافية سيكون مرحبًا جدًا (على سبيل المثال ، عامل عامل البناء..yml. سيكون البديل باستخدامكدليل يتم فيه الحصول على جميع ملفات .yml : مع ارتباطات الرموز سيكون هذا قويًا بالمثل مثل /etc/apache/sites.available -> /etc/apache/sites.enabled

من ناحية أخرى: يمكن لأي شخص توفير برنامج نصي مجمّع simpe (وظيفة) لصدفته لمحاكاة هذا السلوك ...

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

حالة استخدام أخرى يكون الخيار 2 فيها رائعًا:

لنفترض أن لديك فريقًا من الأشخاص يعملون في نفس المشروع. يتمتع البعض منهم بإمكانية الوصول إلى خدمات AWS المُدارة ، ولكن يحتاج البعض منهم إلى تشغيل الموارد المقابلة كحاويات محلية. بناءً على سير العمل الخاص بي ، سأحتاج إما _ دائمًا_ أو _ أبدًا_ إلى حاويات Redis و MySQL في مجموعة النجوم الخاصة بي.

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

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

أتفق تمامًا معcampadrenalin.

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

الوقت الإضافي:

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

ألم تتوفر هذه الميزة لفترة طويلة؟ راجع https://docs.docker.com/compose/compose-file/#variable -substitution. أنا أستخدمه للسماح بتخصيص بيئة مطوري الإنشاء لدينا باستخدام ملف .env - على سبيل المثال موقع كود المصدر ، تعيين المنفذ وما إلى ذلك. منذ إنشاء الملف الإصدار 2.1 حتى الافتراضي متغير نمط shell ( ${VARIABLE:-default} / ${VARIABLE-default ) مدعوم.

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

أجد أن هذا - ربما نبرة قاسية بعض الشيء ، لكنه صالح في جوهره - ملخص جيد جدًا بواسطةrysiekpl.
لذا ، @ shin- ، هل اقتربنا من اتخاذ قرار بشأن هذه المشكلة؟ ما إذا كان سيتم إغلاقها فقط أو تنفيذ / قبول PR للخيار 2؟

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

نظرًا لأنه يبدو أنه تم إسقاط عامل الإرساء على المدى الطويل لصالح مكدس عامل الإرساء على أي حال ، أقترح أن ينتقل الجميع إلى تنسيق v3 الجديد وأداة docker stack أقرب وقت ممكن.

باستخدام مكدس على سرب (حتى على عقدة واحدة) ، يمكنك تحديد هذا:

        deploy:
            mode: replicated
            replicas: 0

يؤدي عدم وجود نسخ متماثلة إلى تعطيل الخدمة بشكل أساسي.

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

يمكنك بعد ذلك استخدام عنصر نائب في ملف yml الخاص بك:

        deploy:
            mode: replicated
            replicas: ${R}

ومعالجتها بهذه الطريقة:

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

لذا ، إذا كان سيتم إهمال docker-compose على المدى الطويل ، فما هي المشكلة بالضبط في دمج طلب السحب الموجود بالفعل ؟ أعني ، إذا كان docker-compose يسير في طريق طائر الدودو ، فكيف يكون "شخص ما سيطلب ميزات غريبة" مشكلة حقيقية؟

نظرًا لأنه يبدو أن تكوين عامل الإرساء قد تم إسقاطه على المدى الطويل لصالح مكدس عامل الإرساء

لذلك ، إذا كان عامل الإرساء سيتم إهماله على المدى الطويل

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

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

هل هذه الأشياء قابلة للتكوين على نظام مستقل غير متصل بالإنترنت

نعم ، يمكنك استخدامها في وضع عدم الاتصال.

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

أو ربما أسيء فهم كل شيء ...؟

+1 على الخيار 2!
وأعتقد أن انخفاض عامل الميناء الذي يؤلف لصالح سرب المكدس سيكون عائقًا كبيرًا للمجتمع. Docker Compose بسيط للغاية وسهل الاستخدام !!

tberne أتفق مع ذلك. docker-compose بسيط وبسيط شيء جيد. يجب علينا التصويت للاحتفاظ بها

هيه ، يا له من مناقشة مستفيضة! لا تهتم كثيرًا بهذا التعليق ، فقط سنتان.

في البداية ، اتفقت مع الأغلبية على إضافة نوع من العلم enabled .
ثم رأيت اقتراحًا لتقسيم التعريفات حسب المجموعات واعتبرتها فكرة جيدة.
ثم قرأت عن Dobi ، وجربته ، وتأكدت من أنه لا يمكن استخدامه في مشروعي الآن وواصلت القراءة.
ثم قرأت حجج @ shin- واعتبرتها جيدة بما فيه الكفاية ، على الرغم من أنني وافقت أيضًا على بعض الحجج المضادة.

الحل الحالي الذي أقدمه هو إنشاء بعض yamls لرسو السفن وكتابة بعض البرامج النصية لتغليف bash لعدم تشغيل docker-compose يدويًا.

على سبيل المثال ، هذه هي الطريقة التي أدير بها الحاويات التي تدير موقعًا على الويب (البرنامج النصي ./docker/scripts/up ):

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

كبير +1 إما الخيار 2 أو 3.

+1 للخيار 2 أو 3.

كما يبدو مفهوم "المجموعة" المقترح مثيرًا للاهتمام!

+1 للخيار 2

_ هناك الكثير من +1 on option x ، حتى أنني لا أستطيع العثور على البيان الأصلي. الرجاء استخدام أزرار رد الفعل الموجودة أسفل المشاركات بدلاً من ذلك.

لإضافة فكرة جديدة:

ألا يمكننا تعيين مقياس افتراضي على 0 ؟

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

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

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

+1 للخيار 2 أو 4

إذا لم تكن هناك أي خطط لإضافة هذه الميزة حاليًا ، فأنا أريد طريقة تشغيل هذه الخدمات (أو المهام) في تركيبة مكتوبة في مستندات docker-compose.

هذا خيط قديم ، وأنا أوافق على أن docker-compose لن يهتم بـ _الخدمات التي لن تعمل من البداية_.

لكني عادةً ما أضيف خدمة test ، لذا فإليك ما فعلته:

1. تجاوز entrypoint للخدمة.

2. في entrypoint ، تحقق مما إذا كان هناك tty متوفر ( docker-compose run يستخدم --tty افتراضيًا بينما up لا يستخدم).

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   سيؤدي هذا دائمًا إلى إنهاء الخدمة عند تشغيلها بدون tty (مع docker-compose up ، على سبيل المثال) بينما لا يزال يعمل كما هو متوقع مع docker-compose run

paulodiovani هذا يشبه الاختراق أكثر من كونه حلاً.

+1 لطلب ميزة.
الاختراقات مثل وجود أوامر لا تفعل شيئًا تعني أنه حتى إذا لم يتم تشغيل الحاوية ، فلا يزال يتعين بناؤها وتهيئتها وما إلى ذلك.

لقد قمت بحل هذا في مشروعي من خلال توفير برنامج نصي بسيط bash يستدعي الأمر المناسب docker-compose بناءً على الوسائط المتوفرة.

الآن إذا قمت بعمل ./docker-compose.sh -e testing up ، فإن النتيجة هي نفسها كما لو فعلت docker-compose -f docker-compose.yml -f docker-compose.testing.yml up .
إذا كنت أفعل فقط ./docker-compose.sh up ، فسأحصل ، كما تتوقع ، على docker-compose up عادي.

لذلك ، فإن خياري -e ${environment} (اختصار --env ) هو في الأساس اسم مستعار لـ -f docker-compose.yml -f docker.compose.${environment}.yml . ينتج عن هذا docker-compose.yml أن يكون ملف الإنشاء الأساسي / الافتراضي وملفات مثل docker-compose.testing.yml هي امتداداته.

هذا يحل إلى حد ما مشكلة acran المتمثلة في عدم معرفة المستخدم للملفات التي يجب تضمينها ( docker-compose خلال فرض الإعدادات الافتراضية السليمة. إنه ليس حلاً قويًا للغاية حيث قد يستخدم البعض تركيبات ملفات تكوين أكثر تعقيدًا ، لكنني أعتقد أن docker-compose يجب أن يكون قادرًا على فعل شيء مشابه. من المحتمل أن تبدأ معظم ملفات docker-compose بـ docker-compose. وتنتهي بـ .yml أي حال ، فلماذا يجب علي دائمًا كتابة مثل هذا الأمر الطويل ( docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ) إذا كنت بحاجة إلى خدمة إضافية واحدة لبيئة الاختبار الخاصة بي؟

لا حاجة لـ envsubst ، يقوم docker-compose config بمتغيرات البيئة ثم يأخذها docker stack من stdin:

docker-compose config | docker stack deploy --prune --compose-file -

لنستخدم أيضًا استبدالات docker-compose .env.

@ kogli أعتقد أن المشكلة هنا هي اختيار خيار. جميعها لها إيجابيات وسلبيات. كما قلت من قبل:

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

@ shin - أعتقد أنك الشخص الذي يسأل: هل من المنطقي حتى النظر في هذا؟ بالنظر إلى الموقف الحالي للفريق ، ومدى صعوبة تصميمه ، والأدوات العديدة المتوفرة ، أليس من الأسهل إخبار الأشخاص بأن هذا لن يحدث؟ وجد معظم الأشخاص ، إن لم يكن كل من علقوا هنا ، طريقة للتعامل معها.

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

فقط للتسجيل : لم يكن الحل الخاص بي مثاليًا ، ولكنه أفضل بكثير من اليومين اللذين استغرقهما تثبيت التبعيات وإصلاح الكثير من الأشياء وتشغيل المشروع (وقد استخدم بالفعل Docker). 3 أوامر فقط ، مع Docker و Docker Compose باعتبارهما التبعيتين الوحيدتين. نعم ، كان هناك رمز أكثر مما أردت. نعم ، هناك أمر سيء لتشغيل الأوامر. ونعم ، هناك القليل جدًا الذي يجب مراعاته. غطت صفحة ويكي هؤلاء. حسنًا ، إذا قلت ذلك بنفسي ، مما يعني أن Docker Compose قام بعمله ، فقد احتجت أيضًا إلى شيء آخر .

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

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

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

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

rubycut نعم ، هذا ما يحدث عندما

rubycut Talk رخيص ، أرني الكود. إذا استطعت ، أرسل العلاقات العامة الخاصة بك ، إذا لم تستطع ، فقط أبلغ عنها وانتظر.

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

فقط لمعلوماتك ، "الكود" موجود بالفعل: # 3047

wangwenpei حسنًا ، # 3047 ، هناك طلب السحب ...
في انتظار الحصول على بعض التعليقات عليه على الأقل لأكثر من عامين حتى الآن. تم إغلاقه مؤخرًا

للأسباب الموضحة في https://github.com/docker/compose/issues/1896#issuecomment -322285976

الأمر الذي يغضبني بشدة لأكون صادقًا لأن الحجج الواردة في https://github.com/docker/compose/issues/1896#issuecomment -322285976 لا تتعلق بأي شكل من الأشكال بطلب السحب:

1. ما هي الخدمة؟ حسب التصميم ، فإن الخدمة هي عملية محددة بوضوح وطويلة الأمد تتفاعل مع خدمات أخرى لتشكيل تطبيق. هذا هو الافتراض الأساسي الذي يعمل في إطاره Compose وهو يوجه تصميمنا لمعظم الميزات التي ننفذها ، إن لم يكن جميعها.
2. وفقًا لهذا التعريف ، فإن "الخدمة التي لم يتم تشغيلها افتراضيًا" ليست خدمة في الواقع [1] - إنها مهمة محددة مسبقًا ، تعمل في حاوية وتعمل على التطبيق ، بدلاً من أن تكون جزءًا منها.

لا أرى التأكيد By that definition, a "service that is not started by default" is not really a service ليكون صحيحًا. الخدمة التي لم يتم تشغيلها افتراضيًا هي مجرد خدمة لم يتم تشغيلها افتراضيًا ، لا أكثر ولا أقل في هذه المرحلة. بدء التشغيل بشكل افتراضي أم لا لا يقول أي شيء عن الخدمة التي تعمل لفترة طويلة أم لا ، كونها جزءًا من التطبيق أم لا ، فهي تقول فقط أنه لا يجب أن تبدأ افتراضيًا.

وهذا أيضًا بالضبط ما يفعله التغيير في طلب السحب: إضافة القدرة على تحديد خدمة لبدء التشغيل افتراضيًا أم لا.
ليست هناك حاجة لإدخال مفهوم جديد مثل المهام للقيام بذلك. في الواقع ، جميع الحجج الأخرى في https://github.com/docker/compose/issues/1896#issuecomment -322285976 تتبع الافتراض الخاطئ لـ 2. وبالتالي لا تنطبق على طلب السحب الذي لا يحاول فعل أي شيء آخر.

فقط للاكتمال:

[1] يذكر بعض الأشخاص الرغبة في الحصول على "خدمات اختيارية" ، ولكن هذه ليست حالة الاستخدام الأكثر شيوعًا المذكورة في هذا الموضوع. يريد معظم الناس ميزة "المهمة" ، بقدر ما أستطيع أن أقول.

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

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

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

@قصبة-

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

من ناحية أخرى ، فإن تسليط الضوء على أنه لا يوجد سوى مشرف واحد نشط بينما من ناحية أخرى يتجاهل طلبات السحب ، وبالتالي فإن إهدار أي فرصة ربما لإشراك مطورين آخرين في المشروع ليس شيئًا يمكنني فهمه.
تغييرات الكود الواردة في # 3047 تنفذ بالفعل ميزة ستكون مفيدة حقًا لـ [العديد] الأشخاص - ربما لا _جميع الأشخاص الذين لديهم _جميع _ حالات الاستخدام الخاصة بهم ، ولكن معظم الأشخاص هنا.

جميع المتطلبات الإضافية - الاضطرار إلى تقديم مفاهيم جديدة تمامًا ، وإدارة تبعية جديدة ، تصل إلى تعقيد يشبه cmake - اتبع ببساطة من فرضية خاطئة!

لقد صادفت هذه المشكلة منذ يومين فقط لأنني كنت أبحث عن ميزة مثل هذه.

نظرًا لأنه لم يتم تنفيذه للأسف ، ومما يمكنني جمعه ، فإن البديل المدعوم رسميًا هو استخدام ملفات yaml متعددة.

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

إذن ، هذا هو +1.