jmmills ألا يمكنك بدء تشغيل الحاويات الخاصة بك مثل: "

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

@aanm هل تتوقع أن docker-compose up يجب أن تأخذ scale المعلمة في الاعتبار؟ المشكلة الوحيدة في هذا التي أراها هي أننا نقدم معلمات في التكوين التعريفي غير متوافقة مع مفاهيم Docker / Docker API الأساسية ولكنها خاصة جدًا بـ Docker Compose.

إذا أردنا القيام بذلك في المستقبل ؛ أقترح شيئًا مثل:

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

حيث يشير $<parameter> إلى شيء معين Docker Compose.

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

الآن بعد أن أصبح لدينا طريقة أولية لزيادة إنشاء ملفات extends (ونأمل أن تكون أفضل قريبًا - # 1380 ، # 758) ، المخاوف التي أثارتها في https://github.com/docker/compose / pull / 630 # issuecomment -69210279 ربما تكون مشكلة أقل.

أرغب في تعيين scale=0 في ملف yml الخاص بي للخدمات المتعلقة بالاختبار التي لا أرغب عادةً في البدء بها. أريد فقط إنشاء هذه الخدمات بشكل صريح باستخدام docker-compose run أو scale .

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

يبدو شيء من هذا القبيل مفيدًا جدًا لتكوينات dev

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

jmmillsjamshid ماذا عن enabled المعلمة / المفتاح في ملف YAML في الخدمة؟ بحيث يمكنك تعطيل / تمكين الخدمة؟

prologic لماذا تفعل ذلك عندما تحل معلمة "المقياس" كلا الحاجتين؟
إذا كنت تريد تخيل عملية / حاوية قيد التشغيل كمثيل لفئة ، فيمكن حتى تسميتها instances

jmmills أنا فقط أحاول إيجاد _solution_ لحالة الاستخدام الخاصة بك والتي لا تتضمن كسر القيمة الحالية docker-compose على هذا النحو. أميل إلى الاعتقاد بأن scale=0 لا يبدو ذلك مناسبًا ، وأنا في ذهني حول ما إذا كان يجب أن يكون scale=X جزءًا من Compose نفسه.

مقياس في رأيي (أو عدد النسخ) هو جزء من تكوين الخدمة ، وبالتالي يجب أن يتم تضمينه في التأليف.

حسنًا ، أعتقد أننا إما أن يكون لدينا مفتاح scale=0 أو disabled مفتاح.

: +1: على القدرة على تعيين حجم افتراضي scale لمثيل. وأنا أوافق ، بمجرد إدخال المقياس ، ليست هناك حاجة لمفتاح disabled ، حيث يمكنك ببساطة تعيين مقياس على 0.

+1

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

$ docker-compose up && docker scale thing=4

لا يعمل لأن ما يصل لا يخرج.
ولكن إذا كان ملف التكوين الخاص بي يحدد حجم حاوياتي ...

$ docker-compose up

أصبح DWIM.

لست متأكدًا من أنني أحب هذا حقًا ؛ فجأة يأخذ up إمكانيات:

• قم بإحضار أي حاويات لا تحتوي على معلمة scale .
• أحضر أي حاويات بها scale=0 .

نحن الآن نسيء استخدام أمر "up" حقًا. يأخذ "المقياس" أيضًا معنى جديدًا من حيث أنه يقوم الآن بأمرين:

• حجم الحاويات لأعلى / لأسفل
• تعطيل الحاويات / الخدمات عن طريق " scale=0

لماذا يجب إحضار حاويات بـ scale=0 ؟
سوف ينشئ Build صورًا scale=0 ، مما يسهل الحاجة إلى الصورة الأساسية.

قد أكون مخطئًا لكن قراءة تعليقك الأخير يعني نوعًا ما أن :)

اسمحوا لي أن أوضح:

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

الآن ، السلوك المتوقع: ينشئ docker-compose build أي حاويات باستخدام "إنشاء" (هل يتم سحب الصور الخارجية عند الإنشاء؟ لا تتذكر) ، docker-compose up أي شيء بمقياس إيجابي (الإعداد الافتراضي هو 1) ، سيقوم docker-compose run test_harness ببناء "base_thing" إذا لزم الأمر وتشغيل الأمر الوحيد الخاص بي. ذكي؟ :)

تحرير: docker-compose up سيشغل 1 "شيء" و 4 "worker_for_thing"

حسنا شكرا؛ المثال الخاص بك يجعل ثنائية أكثر منطقية وأكثر وضوحًا فيما يتعلق بقصد scale=0

أعتقد أن docker-compose "يسحب" الصور على up / run .

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

+1 لـ scale=X . هذا سيكون مفيد جدا
و +1 للتعليق jmmills مع وصف التكوين والنتائج المتوقعة.

ياي! مقابل scale=x . سيساعد بدء مجموعة من الحاويات بالتأكيد على تحديد ظروف السباق المحتملة عند إعداد تكوينات الكتلة.

+1 لـ scale=x (بما في ذلك scale=0 لتعطيل الخدمات لأول docker-compose up )

+1 لـ scale=x .

x هو NaN ، أقترح -1 بدلاً من ذلك.

+1 للمقياس = x.

+1

+1

ماذا لو توقفنا عن +1 ، من فضلك؟

+ 1'ing مفيد لمعرفة مستوى الاهتمام بالميزة.

shofetim أعرف طريقة أفضل للقيام بذلك: تنفيذ الميزة المعنية وإرسال طلب سحب ...

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

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

فيما يلي حل بديل لحالة استخدام "scale = 0":

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

wkonkel نعم ، لقد فعلت أشياء مماثلة في الماضي.

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

هناك بالفعل علاقات عامة قديمة مفتوحة لهذا: # 630.

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

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

حالة scale: 0 يجب معالجتها بالفعل بواسطة # 1754. يمكن أن تحتوي حاوية "no-op" على أمر يخرج على الفور (echo ، true ، إلخ). عادة ما تكون حالات الرغبة في الحصول على scale: 0 واحدة من اثنتين: حاويات حجم البيانات ، أو "مهام مخصصة / إدارية".

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

يتم التعامل مع المهام الإدارية بشكل أفضل باستخدام # 2051. يمكنك تحديد admin.yml الذي يمتد إلى الأساسي docker-compose.yml ويسمح لك بربط مهامك الإدارية بـ "التكوين الأساسي" دون التشويش على تعريف كل منها.

كلا هذين التغيرين في الوضع الرئيسي الآن وسيكون متاحًا في الإصدار 1.5.0 (وهو قاب قوسين أو أدنى).

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

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

يمكن أن تهتم التطبيقات بالحد الأدنى لعدد الخدمات قيد التشغيل.

هل يمكنك إعطاء مثال على هذه الحالة؟

فيما يتعلق بالحاوية no-op ، فإنه من الصعب تشغيل حاوية بالفعل عندما يكون الغرض من تلك الحاوية هو تشغيل صورة أساسية يتم بناؤها حيث تستخدم الحاويات الأخرى لحقل الصورة الخاص بهم

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

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

wkonkel باستخدام

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

أنت تتداول باستخدام خدمة مجردة مع تجاوز no-op command بدون ملخص مع تجاوز no-op على ports . هل هذا يبدو صحيحا؟

1988 يتعلق بالخدمات المجردة.

dnephin نعم ، هذا يعمل في حالتي.

في الواقع ، استرجع ذلك ... لقد جربته للتو مع docker-compose-1.4.2 ويبدو أن "المنافذ: []" لا تتجاوز الأصل ، لذلك فشل app_worker في البدء بـ "تم تخصيص المنفذ بالفعل ".

dnephin ربما يكون للخيط تفسير أفضل ، لكنني سأحاول توضيحه هنا.

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

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

أعتقد فقط أن وجود أمر no-op يبدو وكأنه مضيعة للموارد لمجرد الحصول على صورة أساسية مشتركة مبنية بنفس الطريقة مثل بقية مكدس التطبيقات. ينتهي بك الأمر مع حلقة while / sleep loop فقط للحصول على صورة أساسية ، وهو عمل رائع ، ولكن لا يبدو أنه طريقة بديهية لتحقيق ذلك. ناهيك عن ترك عنصر في شجرة العمليات الخاصة بنا بدون وظيفة وقت التشغيل.

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

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

أعتقد فقط أن وجود أمر no-op يبدو وكأنه مضيعة للموارد لمجرد الحصول على صورة أساسية مشتركة مبنية بنفس الطريقة مثل بقية مكدس التطبيقات.

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

dnephin Cool ، فهل ستوفر بعد ذلك link لتلك الحاوية الأساسية / الوسيطة للتأكد من بنائها أولاً؟

dnephin : لديّ عداء CI يقوم بما يعادل docker compose up . أرغب في تشغيل بيئة الاختبار الخاصة بي بإصدارات متعددة من الخدمة (على سبيل المثال ، مقياس). يمكنني نسخ كتلة التكوين بالكامل ولكن هذا قد ينطوي على تكرار نفسي. في هذه الحالة ، هذا ليس "مجرد مشكلة تشغيلية" ، إنه شيء أحتاجه في بيئة التطوير الخاصة بي أثناء تطوير تطبيق مجمع ، والذي يتم وصفه بالكامل حاليًا كملف مؤلف. في الوقت الحالي ، يجب أن يكون لدي بعض التكوين خارج النطاق ثم استدعاء بطريقة ما docker-compose scale ، على ما أفترض ، لكن هذا لا يبدو مثاليًا ويقدم فرصًا أخرى للفشل والسباق.

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

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

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

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

هل يمكنك إعطاء مثال على هذه الحالة؟

يحتاج القنصل أو MariaDB Master-Master أو أي تطبيق موزع آخر على Swarm حقًا إلى وجود 3 عقد على الأقل في المجموعة لتكون موثوقًا بها. هناك بالتأكيد حالات استخدام لعدد من الخدمات المتوفرة في ملف التكوين ، ولا أفهم سبب رفضك لها. كبير: +1: مني هنا.

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

خذ هذا المثال الذي يفترض أننا نضيف بعض إعدادات التهيئة إلى ملف الإنشاء:

1. لقد قمت بتعيين مقياس مبدئي من 3 لخدمة
2. أقوم بتشغيل docker-compose up -d ، وتتسع خدمتي إلى 3
3. أركض docker-compose scale service=4
4. أقوم بإجراء بعض التغييرات وإعادة النشر باستخدام docker-compose up -d .. ماذا يحدث؟ هل يتم تقليل الحجم إلى 3 مرة أخرى؟ هل يتجاهل المقياس تمامًا الآن؟

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

إذا تمت إضافته إلى ملف الإنشاء ، أعتقد أننا نرغب في إزالة الأمر scale ، حتى لا يتعارضوا.

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

باستخدام المثال الموضح أعلاه بواسطة dnephin :

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

الإجابة على السؤال الذي طرحه dnephin هي أنني أتوقع أن يكون عدد الخدمات / الحاويات قيد التشغيل كما كان قبل التعديل.

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

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

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

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

تفقدdnephin مع # 2496 تأليف القدرة على التوسع أو

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

سيتم حل السيناريو الذي ذكرته في الاقتراح الجديد بسهولة عن طريق خدمة / أداة جديدة كاملة الحالة.

+1

+1

+1

dnephin ألن يكون السلوك هو نفسه إذا قمت بذلك:

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

أليست هذه مشكلة تتعلق بكيفية استمرار حجم التأليف داخليًا.

هذا هو الشيء ، "إنشاء التطبيق" هو ​​عديم الحالة. الحالة الوحيدة هي في 1) ملف الإنشاء ، و 2) ملصقات حاوية عامل الإرساء التي يديرها المحرك.

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

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

في الوقت الحالي ، تتمثل خياراتنا بشكل أساسي إما في الاحتفاظ بالمقياس كخيارات لسطر الأوامر ، أو نقله إلى ملف الإنشاء ، ولكن كما أصف في # 2496 ، أعتقد أن وجود كليهما أمر محير ويؤدي إلى سلوك غير صحيح.

up && scale && up يفعل الشيء الصحيح الآن. سيعيد up إنشاء جميع الحاويات ، وبما أنه لا توجد قيمة مقياس في التكوين ، فلا يوجد أي لبس حول المقياس المطلوب. تم تعيينه بالفعل بواسطة أمر scale ، وتم تعقبه بواسطة تسميات الحاوية.

dnephin أعتقد أنني أتفق مع ما تقوله ، [قد أكون مخطئًا في هذا الافتراض] أن ما تستفسر عنه حقًا هو _if_ عدد مثيلات المكون هو في الواقع مصدر قلق لتكوين الخدمة (مجموعة من الحاويات تشغيل حاويات مكونات مختلفة). أود أن أقول إنه يعالج هذا القلق حاليًا ، فقط مع تحذير من عدم التكافؤ بين CLI وتعريف التكوين (yaml).

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

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

+1

+1

+1

أحتاج حاليًا إلى الإعلان عن أشياء من هذا القبيل:

السيلينيوم كروم 1:
...
السيلينيوم كروم 2:
...

سيكون من الرائع:
السيلينيوم كروم:
مقياس: 2

+1

بالضبط ما قال caioquirino . +1

docker-compose up بيئة عمل دون الحاجة إلى عمل آخر. الطريقة الوحيدة لإحضار الخدمات التي تتطلب عقدًا متعددة هي استخدام النمط caioquirino . بتجاهل انتهاكات DRY هنا ، فإن النموذج تنبعث منه رائحة خاطئة عندما تحاول بعد ذلك استخدام الأمر scale لإضافة عقدة أخرى لأنه ليس من الواضح أي "خدمة" يجب تحجيمها.

مقياس في ملف yml يصلح هذا.

+1 كبيرة ، أود أيضًا استخدام هذا لتحديد الخدمات التي تم ضبط مقياسها على 0 في البداية.

على طول الطريق ل...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

الفكرة هي أنه يمكنك استخدام docker-compose.yml والانتقال بسلاسة من بيئة التطوير إلى الإنتاج. ستنضم مثيلات consul_master تلقائيًا إلى الطوافة وتؤسس النصاب القانوني بعمل docker-compose scale consul_master=3 . هذا سيكون رائعا

للرد علىdnephin ...

خذ هذا المثال الذي يفترض أننا نضيف بعض إعدادات التهيئة إلى ملف الإنشاء:

1. لقد قمت بتعيين مقياس مبدئي من 3 لخدمة
2. أقوم بتشغيل docker-compose up -d ، وتتسع خدمتي إلى 3
3. أقوم بتشغيل خدمة مقياس تكوين عامل الإرساء = 4
4. أقوم بإجراء بعض التغييرات وإعادة النشر باستخدام عامل الإرساء-تكوين up -d .. ماذا يحدث؟ هل يتم تقليل الحجم إلى 3 مرة أخرى؟ هل يتجاهل المقياس تمامًا الآن؟
5. أحبها
6. على ما يرام
7. مازلت معك
8. أعتقد أنه يجب أن يكون هناك بعض التمايز بين النشر الحالي والنشر الجديد بحيث يمكن الحفاظ على استمرارية النطاق لعمليات النشر الحالية التي تتلقى تحديثات مستمرة. قد يتضمن النشر الفردي DOCKER_HOST env وما إلى ذلك ، جنبًا إلى جنب مع مقياس كل مكون ومعرفات الصورة وسجل عمليات إعادة النشر. قد يكون هذا مكانًا جيدًا للربط بآليات upstack مثل النشر المستمر أو عمليات النشر الزرقاء الخضراء؟ أتخيل سير عمل جاهزًا للإنتاج أكثر قليلاً ، لذا يمكنك ببساطة الاتصال بـ DOCKER_HOST مختلف والقيام بـ docker-compose up -d ثم توفير الخطافات حتى تتمكن أدوات upstack من إدارة أشياء مثل CI وعمليات الإطلاق الزرقاء / الخضراء. ربما تضيف شيئًا مثل DOCKER_COMPOSE_ENV = {"testing" || "انتاج" || "ديف"}؟

IMHO ، مع وجود "تشفير" scale ، لنقل 3 ، يجب أن يبدأ بـ 3 حاويات

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

+1 لـ "initial_scale" ، سيصف أيضًا هذا المعامل صراحةً على أنه خاص بالتركيب ، لأن عامل الإرساء نفسه لا يحتوي على مثل هذه المعلمة.

هناك شيء مثير للاهتمام يحدث ، في منشور المدونة https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ في الفيديو "48.56 يوضح أنه في مركز بيانات عامل الإرساء الجديد الذي تم إصداره ، يمكن عند نقطة إنشاء المكدس إعداد عدد مثيلات الحاوية التي تريد تشغيلها. لذا ، هذه الفكرة ليست جديدة على فريق عامل الإرساء ، آمل أن يتم تضمينها في إصدارات الإنشاء التالية

+1

+1

الملايين من الإصدارات والطلبات مقياس / العد الأولي وما إلى ذلك .. وما زالت لم يتم التخطيط لها.

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

+1

+1

+1

+1

توقف أرجوك!
لا تضيف +1!
فقط اشترك في هذه القضية!

+1 ( @ بيير آسف)

+1 إنه مهم جدًا ( pierrre ، آسف)

أوافق ، لكنني لا أريد تلقي 100000 إشعار بخصوص "+1"!

/ me forks docker يؤلف ويبدأ في تعلم قاعدة البيانات.

العديد من النقاط الصالحة أعلاه ، يبدو أن وجود معلمة default/inital scale في ملف التكوين + أمر scale cli سيعالج كليهما. لإضافة حالات استخدام لدعم خيار النطاق الأولي ، ضع في اعتبارك الخدمات المجمعة حيث يتكون النصاب القانوني من عدد X من العقد والتي لا ينبغي أن تعمل بخلاف ذلك (على سبيل المثال لا تقل عن 3). الهدف من docker-compose هو الحصول على واصف كامل لمثل هذا النظام.

حالة الاستخدام الخاصة بي هي:

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

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

هم في بعض الأحيان بالفعل:

• docker-compose up service
• docker-compose scale service=1 .

وإذا كان scale يعرض جميع خيارات cli (على سبيل المثال --force-recreate ) التي up ، أو إذا كان up علم بالعد ، فعندئذٍ سيكونون في الأساس كذلك.

إذا تمت إضافة توجيه "مقياس أولي" إلى docker-compose.yml ، كما تقترح هذه المشكلة ، فسيتعين على up تعلم العد. عند هذه النقطة ، ألا يجب أن يدعم up فقط بناء جملة الجرد docker-compose up service=10 (والذي يمكن أن يستبدل أي مقياس محدد في yaml)؟

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

mattgiles أوافق ، هذا ما كنت أذهب إليه مع # 2496 ، لكنني لم أعتبر أنه يمكن إضافة service=count إلى up . أعتقد أن هذا قد يتعامل مع الموقف. المشكلة الوحيدة التي أراها هي أن up web يعني فقط إحضار خدمة الويب وتبعياتها. محاولة القيام بـ up web=3 ستظل تعني نفس الشيء. مما يعني أنه لا توجد طريقة للحصول على كل شيء up وتجاوز مقياس العد مرة واحدة ، ولكن هذا على الأرجح جيد.

سوف أقوم بتحديث الاقتراح في # 2496

dnephin فاتني الاقتراح الأحدث. مذهل!

fwiw ، أعتقد أنه من البديهي تمامًا أن تقوم docker-compose up web=3 بإحضار ثلاث حاويات لخدمة "الويب" ، بالإضافة إلى أي تبعيات ... بالنسب المحددة في yaml (لكل شيء مثل scale التوجيه

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

أشياء مثل --force-recreate المحتمل أيضًا أن تترك الأعداد بمفردها إذا كانت أعلى من المحدد في yaml ، ولكن لا تزال تعيد إنشاء جميع الحاويات لتتماشى مع السمات الأخرى.

سيكون من المنطقي بالنسبة لي أيضًا أن أكون قادرًا على قتل الحاويات ، كما هو الحال حاليًا مع scale ، عن طريق الاتصال بشيء مثل docker-compose up web=2 إلخ إلخ.

+1

+1 (فقط لإزعاج @ بيير ؛))

+1

+1 للمقياس = x.

فيما يتعلق بهذا أود طريقة لوصف Singletons. scale=1

أي نجاح هنا مع خيار المقياس

+1

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

شكرا،
جايسون ميلز

• أرسلت من الجوال.

في 8 آب (أغسطس) 2016 ، الساعة 5:19 مساءً ، كتب lavvy [email protected] :

أي نجاح هنا مع خيار المقياس

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

+1

+1

+1

+1

+1 (لإزعاج @ بيير مرة أخرى)

+1

أود إعادة تكرار القضية

مقياس = 0
مفيد للاختبار والتصحيح. تحقق وما إلى ذلك من الخدمات التي لا تريد عادةً طرحها ، ولكنك تريد تعريفها - لأنها تُستخدم عادةً في سياق الخدمات الأخرى في الملف.

مقياس = 1
لأنني أريد واحدًا فقط من هؤلاء - _ أبدًا_. في مجموعة MariaDB ، هناك حالة قد أرغب فيها فقط في تكوين عقدة واحدة بمحرك تخزين معين (مثل Spider و ColumnStore وما إلى ذلك).

مقياس = ن
نظرًا لأن هناك أوقاتًا أعلم فيها أنني بحاجة إلى تشغيل الخدمات ، على سبيل المثال ، مجموعة MariaDB حيث سيكون لدي دائمًا واحد أساسي (بتكوينه) واثنان من الثانوية (مع تكوينهما المختلف عن الأساسي).

من المنطقي بالنسبة ليalvinr. يجب أن يكون الافتراضي احتمال 1.

إخلاء المسئولية: أنا لست ممثلًا لماراثون أو ميزوسفير

هذا مثال آخر على طلب ميزة بسيط إلى حد ما تم التخلي عنه / دفعه من قبل فريق دعم عامل الميناء لأكثر من عام. https://github.com/docker/docker/pull/12749 مثال آخر. كان لدى Kubernetes و Marathon هذه الخيارات لبعض الوقت الآن ("المثيلات": 3 في ملف marathon.json) وحتى تنفيذ التدرج التلقائي. إن عدم رغبة مجموعة دعم عامل الإرساء هو الذي دفعني بعيدًا عن مركز بيانات عامل الإرساء والسرب لبعض الوقت الآن.

لدى Kontena هذا أيضًا instances: 3 (https://www.kontena.io/docs/references/kontena-yml)

هناك طريقة أخرى يمكننا من خلالها القيام بذلك وهي إضافة قسم scale في إصدار ملف الإنشاء 2.

لن تختلط مع خيارات عامل الإرساء فقط المستخدمة في الخدمات.

مثال على ذلك:

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

هذا مع القدرة على تحديد scale: 0 المحتمل أن يقتل عصفورين بحجر ، والآخر هو https://github.com/docker/compose/issues/1896

هذا يبدو وكأنه لا يفكر.

أريد نشر nginx + nodejs + mongodb مع 3 أو 4 مثيلات nodejs. في كل مرة أقوم بتشغيل التطبيق.

إذا كان لديك خيار سطر أوامر للقيام بذلك ، فلماذا ليس في ملف yml؟

docker-compose up scale nodejs = 4

ستفعل.

انه سهل. يريدون أن يسلكوا طريق "شخص آخر نبنيها ونحن
سيحاولون دعمه ". بخلاف عامل الإرساء الأساسي ، لم يتم إنشاؤه
اى شئ. كان Compose منتجًا مختلفًا استهلكوه والآن لديهم
لا توجد فكرة عن كيفية دعمها / تمديدها ، ولهذا السبب منتجات مثل marathon و
kubernetes أكثر شيوعًا من السرب.

في 16 تشرين الأول (أكتوبر) 2016 ، الساعة 9:36 مساءً ، "مايكل شوارتز" [email protected]
كتب:

هذا يبدو وكأنه لا يفكر.

أريد نشر nginx + nodejs + mongodb مع 3 أو 4 مثيلات nodejs. كل
وقت بدء تشغيل التطبيق.

إذا كان لديك خيار سطر أوامر للقيام بذلك ، فلماذا ليس في ملف yml؟

docker-compose up scale nodejs = 4

ستفعل.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/1661#issuecomment -254093296 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AES98nZt1uIejnIU9iajVt54QbzdlVK1ks5q0tETgaJpZM4FS8ZQ
.

أنا بصراحة مندهش قليلاً لأن هناك _ أي _ تراجع في هذا الأمر لأنه يبدو من الواضح جدًا أن ...

westlakem دعونا نأمل ألا يعاني Docker لنظام MacOS من نفس المصير ، ونأمل أن يظل رجال Unikernel.

سيكون من الجيد إحضار كومة كاملة بحجمها الوظيفي دفعة واحدة. في حالة الاستخدام الحالية ، يحتاج مكدس الخدمة إلى "عمال = 16" للعمل بشكل صحيح.

هذا فظيع:

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

والتي من الواضح أنه يمكن استبدالها بشيء مثل:

docker-compose up --abort-on-container-exit --scale workers=16

تحرير: أرى أن "Rancher" يحتوي على عامل بناء مثل بناء الجملة ويدعم معلمة مقياس أولية: https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

الحل البديل هو استخدام YAML anchor ودمج القدرات وتكرار الخدمة داخل ملف إنشاء عامل الإرساء.

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

إلخ ...

سيكون هذا مفيد للغاية!

هذا غريب للغاية هذا غير موجود ...

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

هذا موجود بالفعل في ملف الملحن v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json والذي سيكون مدعومًا بالفعل على docker-compose v1. 10.0-rc1

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

يوم الجمعة ، 6 كانون الثاني (يناير) 2017 الساعة 6:30 صباحًا ، ياسماني كوبيلا مدينا <
[email protected]> كتب:

هذا بالفعل في العمل على ملف الملحن v3 https://github.com/aanand/
إنشاء ملف / blob / رئيسي / مخطط / بيانات / config_schema_v3.0.json سيكون
وهو مدعوم بالفعل على docker-compose v1.10.0-rc1

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/1661#issuecomment-270886347 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AES98nOAW-h0BVaR8D9uQfLpMCQRfdyfks5rPiXEgaJpZM4FS8ZQ
.

+1

+1

مرحبًا ، لدي سؤال متعلق بذلك.
كنت أتساءل يومًا ما أن docker-compose up يمكنه تذكر المقياس الذي قمت بتعيينه على الإطلاق.

على سبيل المثال ، أقوم بتشغيل docker-compose scale nodejs_web=4 ثم docker-compose down ،
ثم أبدأ مرة أخرى docker-compose up ، وسوف يبدأ 4 nodejs_web.

أريد أن أعرف أين يحفظ الأمر scale الرقم 4؟

يمكن أن يكون docker-compose.yml:

version: '2'
services:
  nodejs_web:
    image: node
    command: node

أنا أؤيد اقتراح
يرجى إعطائنا هذه الميزة الأساسية.

تقدم الخدمات في الإصدار الجديد من Docker ميزة "النسخ المتماثلة".

يوم الإثنين ، 20 آذار (مارس) 2017 الساعة 3:28 مساءً ، دائمًا ما يكون لديك إخطارات من github.com
كتب:

أنا أدعم اقتراح https://github.com/dnephin على # 2496
https://github.com/docker/compose/issues/2496
يرجى إعطائنا هذه الميزة الأساسية.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/1661#issuecomment-287870998 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AES98uWGEnbyCFyxNSSlv7QkXy5oBek1ks5rntNBgaJpZM4FS8ZQ
.

westlakem - هذه الميزة خاصة بالسرب. انها ليست لتوسيع نطاق الخدمة العادية.

الكثير من الإيجابيات ، القليل من السلبيات. ما خطب هذه القضية؟

يوجد اقتراح أحدث حول إزالة أمر المقياس تمامًا في https://github.com/docker/compose/issues/2496

أنا حقًا لا أفهم لماذا أو لماذا لا يوجد خيار initial_scale: 3 في ملف الإنشاء (أنا أفهم لماذا لا يمكن أن يكون scale: 3 )

تم تنفيذه مرة أخرى في 1.13.0. شكرًا لكم جميعًا على ملاحظاتكم وصبركم.

@ shin - لماذا يعتبر هذا مغلقًا؟ في إدارة التطبيقات واسعة النطاق حيث يتم تشغيل كل شيء تلقائيًا وفي التحكم في الإصدار ، يجب علي الآن تعديل Ansible الذي ينفذ Docker لتحديد عدد مثيلات الخدمة التي سيتم تشغيلها.

يجب أن يقوم Ansible بإعداد كل شيء حتى يتمكن Docker من تشغيله. يجب أن يحدد Docker عدد مثيلات الخدمة التي يحتاجها التطبيق. الآن تقع على عاتق Docker مسؤولية معرفة مخزون الخدمات ولكن مسؤولية Ansible هي الاتصال بـ Docker حتى يعرف عدد الحاويات التي يجب تدويرها؟

greenscar معذرة ، لست متأكدًا تمامًا من المشكلة - هل أنت غير سعيد بالطريقة التي تم بها تنفيذ الميزة؟ إذا كان الأمر كذلك ، فبأي طريقة يمكننا تحسينه؟

لماذا هذا غير موجود في الإصدار 3؟ مربك للغاية نظرًا لأن "publish.replicas" و "up" ليسا متكافئين ، يمكنك القول أن هذه الميزة مفقودة في v3.

cgarciae deploy.replicas يخدم نفس الغرض مثل scale . لماذا لا تتساوى في وجهة نظرك؟

@ shin - إذا لم أرغب في إنشاء سرب واستخدمت فقط docker-compose up -d ، يخبرني عامل الإرساء أنه سيتجاهل إعدادات "النشر".

cgarciae لماذا تستخدم ملف v3 إذا كنت لا تريد إنشاء Swarm؟

أعتقد أن كل شخص يستخدم docker يتوقع أن تعمل معلمة المقياس مع ملفات docker 2 أو 3. لا يوجد سبب لعدم قيامه بذلك ، بل يمكنه أيضًا تعيين القيمة الافتراضية لـ publish.replicas أيضًا. إذا تم تعيين النشر المتماثل ، فإنه يتخطى النطاق في السرب. ما الخطأ في هذه الصورة بصرف النظر عن كونها ما يتوقعه الجميع (وبالطبع إذا لم تعجبك فلا داعي لاستخدامها في docker-compose.yml)؟

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

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

أوه انتظر ، لذلك إذا قمت بتغيير تكوين عامل الإرساء الخاص بي إلى version: "2.2" فيمكنني استخدام scale: 2 ولكن إذا كان أحد يريد الانتقال إلى إصدار لاحق ، فلا يوجد خيار للقيام بذلك؟

حسنًا ، أرى أن مشكلة "الإصدار" هذه لا تعني حقًا طرح الإصدارات بالفعل ، https://github.com/docker/compose/issues/4693

أستخدم v3.6 لأنني بحاجة إلى بعض التكوينات غير الموجودة في 2.2. بالنسبة للتنمية المحلية ، لا أستخدم سربًا ، لكنني أريد تعيين مقياس = 0 لبعض الحاويات في docker-compose.overrides.yml. لأن بعضها مخصص لعمليات الإنشاء فقط مثل حاوية الواجهة الأمامية. تشترك هذه الحاوية في بعض الأحجام مع حاويات أخرى قيد التشغيل ، ولكن لا ينبغي أن تبدأ مع هذه الحاويات الأخرى الموجودة في عامل الإرساء. لذا فإن buildcontainer يعمل فقط باستخدام الأمر run. نعم ، يمكنني تعيين معلمة - مقياس عند استدعاء عامل إنشاء عامل ، لكنني أعتقد أنه من الأفضل كتابتها مباشرة إلى التهيئة. :)

شكرا لمعلمة المقياس. لقد تمكنت من استخدامه في docker-compose.yml غير إنتاجي بحيث يمكن لأي شخص استخدام تكوين HA لـ Consul و Vault. جعل معامل المقياس اعداد توصيف HA محلي أمرًا سهلاً. https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

في هذه الحالة ، مخصص فقط لشخص ما لتجربة Consul و Vault في تكوين HA واستخدام Consul DNS.

ما هو إصدار عامل الإرساء الذي تعمل عليه؟ منذ الإصدار 3 ، تم إسقاط هذه الميزة (أعني بالإسقاط ، لم يتم تنفيذها مطلقًا) ، لذلك تم تجاهلها. راجع https://docs.docker.com/compose/reference/scale/

لا أستخدم تنسيق v3 أبدًا بسبب عدم وجود ميزات. أميل إلى استخدام تنسيق 2.1 أو 2.2 الأدنى اعتمادًا على الميزات التي أستخدمها.

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

حسنًا ، خمنت أنك تتحدث عن عامل الميناء يؤلف مع سرب المكدس ، لهذا السبب. لم أحاول أبدًا ، لكن من الغريب التحدث عن HA مع عامل عامل التأليف بدون منسق وعقدة متعددة. هل هو لغرض "Poc" أو لغرض الاختبار؟ على أي حال ، لم أحاول أبدًا في هذا السياق

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