Compose: Depends_on في الإصدار 3

لا يزال depends_on موجودًا في الإصدار 3 ، لكن تبعيات healthcheck (ونتيجة لذلك ، البنية الموسعة) لن يتم نقلها.

HTH

لكنني كتبت docker-compose v3 وأحاول النشر على سرب ولكن لا يعمل يعتمد على الحاوية حيث لا تبدأ بالطريقة التي يجب أن تبدأ بها.

هل تستخدم docker-compose أو docker stack deploy ؟

أنا أستخدم نشر مكدس عامل ميناء
وأحاول نشره على سرب من 7 آلات

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

ما هي النية لتقديمه في docker-compose v2.1 ثم إسقاطه لـ v3؟ أقوم حاليًا بإعداد ملفات إنشاء مختلفة لتطبيقاتنا ، لكنني لا أرغب في استخدام الميزات التي يتم إسقاطها في الإصدار التالي ، وبالتالي منع الاستخدام من التحديث إلى إصدار أحدث من ملف إنشاء عامل الإرساء.

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

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

هل يمكنني أن أسأل لماذا ليس في الخطط؟ أفترض أنه سيكون من المفيد جدًا القيام بذلك.

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

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

إذن ما هو بناء جملة يعتمد على دعم v3؟ https://docs.docker.com/compose/compose-file/#version -3 لا يذكر يعتمد على ، وعندما أستخدم docker-compose v1.10 لنشر تطبيق ، لا يعتمد الإصدار 2 أو v2.1 على النكهات التي تعمل من أجلها لي في ملف إنشاء الإصدار 3 ...

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

هل يمكنني أن أسأل لماذا ليس في الخطط؟ أفترض أنه سيكون من المفيد جدًا القيام بذلك.

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

هل يمكنك توضيح السبب؟ وعن البدائل (إن وجدت)؟

من https://github.com/docker/docker/issues/30404#issuecomment -274825244

depends_on غير متاح عند استخدامه مع docker stack deploy . يتم إعادة تشغيل خدمات وضع Swarm عندما تفشل ، لذلك لا يوجد سبب لتأخير بدء تشغيلها. حتى لو فشلوا عدة مرات ، فسوف يتعافون في النهاية.

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

إذن ما هو بناء جملة يعتمد على دعم v3؟

عند استخدام docker-compose ، فإن بناء الجملة المدعوم لـ v3 هو بنية القائمة (على غرار تلك المستخدمة في 2.0). إذا كنت تستخدم docker stack deploy ، فلن يتم تكريم التبعيات (انظر أعلاه للتبرير)

تنسيق الإصدار 3 هو الخطوة الأولى في الابتعاد عن الأداة docker-compose نحو الحل المتكامل docker stack . التنفيذ الحالي له المراوغات التي يجري العمل عليها. يهدف دعم تنسيق الإصدار 3 في docker-compose إلى المساعدة في هذا الانتقال. وهناك الكثير من الأمور قد تغيرت وتحسنت في عامل الميناء منذ fig / يؤلف لأول مرة، وهذا يعني الكثير من الأشياء التي تستخدم لمعنى أصبحت الآن بالية. docker stack بداية جديدة باستخدام مفاهيم جديدة ويتخلص من بعض أكثر التركيبات والمفاهيم صعوبة ، من volumes_from إلى depends_on .
إذا كانت لديك مخاوف خاصة بشأن بعض هذه التغييرات ، فالرجاء الإبلاغ عنها في Docker / Docker repo حيث يتم تكرارها بنشاط.
إذا لم تكن مستعدًا بعد للانتقال إلى خدمات Docker و docker stack ، فلا تتردد في الاستمرار في استخدام تنسيق v2. في حين أنه من المعقول افتراض أن المشروع سينتهي في وقت ما في المستقبل ، فسيتم الإعلان عنه مسبقًا. وبعد ذلك ستبقى الشفرة متاحة ومفتوحة المصدر.

شكر. الآن من المنطقي.

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

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

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

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

@ Marvel77 افتراضيًا ، نعم ، ولكن يمكنك تجاوز هذا السلوك باستخدام قسم deploy.restart_policy : https://docs.docker.com/compose/compose-file/#restartpolicy

@ شين - شكرا جزيلا لك!

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

hsmade لكن تقريبًا كل init (

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

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

ولكن بعد ذلك مرة أخرى ، هذه هي أفكاري في هذا الأمر ، وقد أكون مخطئًا ؛)

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

رفاق،

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

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

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

ozlatkov يجب نشر هذا بالفعل على متتبع مشكلة عامل الرصيف / عامل

@ شين - شكرا لك! لقد قمت بنقلها إلى أداة تعقب السفن / عامل الإرساء:

https://github.com/docker/docker/issues/31333

أعتقد أنه من السيئ حقًا أن يفترض فريق Docker استخدام Docker Swarm. من المفترض أن يكون التأليف أداة قائمة بذاتها وظيفية بالكامل.

ومع ذلك ، فإننا نستخدم Docker Compose كثيرًا في خطوط أنابيب الاختبار الخاصة بنا ، ومثل هذا الإزالة الأساسية للميزات (دون إعطاء بديل عملي) له تأثير سلبي كبير على المستخدمين.

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

من المفترض أن يساعدنا Docker في الوصول إلى أهدافنا ، وليس زيادة صعوبة الأمر عن طريق إزالة الميزات الهامة التي تعتمد عليها العديد من الفرق بالفعل.

يرجى إعادة النظر في نقل كل هذا إلى Docker Compose 3.

مقدر جدا.

للمرة المائة الآن: لا يوجد سبب لاستخدام تنسيق v3 إذا كنت لا تنوي استخدام خدمات السرب.

هل هذا يعني أن الفريق ملتزم بدعم تنسيقات 2.X لأولئك الذين يستخدمون التأليف كأداة تطوير مستقلة؟

سؤالي بالضبط: هل فريق Compose ملتزم بدعم تنسيق v2 إلى الأبد؟

لا يمكننا التوحيد القياسي في Docker Compose إذا تمت جدولة تنسيق v2 للإيقاف في أي وقت.

أشعر أن هذا يفرض جميع الحاويات على نمط init container ، ويزيل سياسة إعادة تشغيل عامل الإرساء ويخلق نهجًا متسللًا لأمر بدء التشغيل. هل ينبغي افتراض أن> = v3 من الإنشاء سيتحرك في هذا الاتجاه للتركيز على الحزم وإنشاء حزم التطبيقات؟ وإذا كان هذا صحيحًا ، فهل يمكنك توجيهي في اتجاه كيفية الحفاظ على نظام بدء التشغيل في كومة عامل ميناء؟ هل wait-for-it.sh أو dockerize هو الأسلوب المتبع هناك؟

ما هو المكافئ التصريحي لـ docker-compose.yml للمكدس؟

مرحبًا يا شباب ، ما هي أفضل الممارسات إذا كنت أنوي استخدام مكدس عامل الإرساء والتخلص من عامل الإرساء؟

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

شكر.

mustafaakin شكرا على التصويت السلبي الخاص بك! مفيد جدا؟

VinceOPS لست متأكدًا من "أفضل الممارسات" ولكني كنت أستخدم healthchecks و restart: always لذا فهي تدور فقط حتى تعمل ¯ \ _ (ツ) _ / ¯

hutchic ولكن كما ذكر في المحادثة أعلاه ، لا يمكن أن يكون لها تاريخ انتهاء ، نوع من إعادة التشغيل الدائري عند الفشل.

لماذا يزيل فريق Docker هذه الميزة في الإصدار 3 ويرفض إضافتها؟

@ tianhao-au انظر المناقشة على https://github.com/moby/moby/issues/31333 (و https://github.com/moby/moby/issues/31333#issuecomment-409143581)

للإنشاء ، تركت أيضًا اقتراحًا في https://github.com/moby/moby/issues/31333#issuecomment -333265696 (لديك x-depends_on )

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

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