Compose: لا يسحب docker-compose up أحدث صورة إذا كانت الصورة موجودة محليًا

هل هناك سبب يجعل docker-compose pull && docker-compose up غير عملي؟

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

أحاول تنفيذ "إنشاء إنشاء عامل ميناء" ، لكنه لا يُحدّث الصورة المشار إليها في ملف Docker ، إلا عند استخدام _-- pull_.

يمكنك أيضًا إنشاء حاويات أثناء البدء بـ _up --build_. ولكن لن يتم سحب أحدث الصور. هل يمكن أن نتوقع أشياء مثل "عامل البناء - بناء - سحب" (أو ما شابه)؟ ربما يكون من المنطقي وضعها في YML نظرًا لأنه لا يجب تحديث كل الإنشاءات (راجع. الصور المحلية).

بدلاً من (أو بالإضافة إلى) إضافة --pull إلى cli ، ماذا عن إضافة شيء ما على تعريف الخدمة في ملف docker-compose ؟، على سبيل المثال

version: '2'

services:

  postgres:
    image: postgres
    container_name: postgres
    pull: true
    ports:
     - '5432:5432'

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

لقد جئت إلى هنا للبحث عن هذه الميزة لأننا نستخدمها في مجموعة إنتاج Kubernetes. هناك العلامة "imagePullPolicy" ويمكن تعيينها على "IfNotPresent" أو "Always" أو "Never". سيكون شيئًا مشابهًا لبيئة الإنشاء أمرًا رائعًا.

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

أي خبر عن هذا؟

أهلا،

أي أخبار عن هذا الموضوع؟

+1

+1

كما ذكرت سابقًا ، docker-compose pull && docker-compose up متطابق وظيفيًا. ليس هناك سبب وجيه لإضافة علامة أخرى لها.

تخيل أن git لا يحتوي على pull لأن git fetch && git merge origin/master متطابق وظيفيًا.

قد تكون إضافة علامة pull: true مفيدة على سبيل المثال إذا كانت بعض الصور التي تستخدمها في ملف الإنشاء موجودة في ذاكرة التخزين المؤقت. docker-compose pull pull _ all_ من الصور في ملف الإنشاء ، وسيفشل هذا السحب إذا كانت هذه الصور في ذاكرة التخزين المؤقت ولكن ليست في المستودع.

+1

أحد السيناريوهات التي يصبح فيها docker-compose pull && docker-compose up غير عملي هو عندما تستخدم عدة ملفات تكوين عامل الإرساء. يمكنك بسهولة الحصول على أمر مثل docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up .

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

@ shin - ماذا عن إعادة التفكير في قرارك بشأن هذا؟ أعتقد أن التعليقات وردود الفعل تجاههم تبدو وصفية للذات بدرجة كافية.

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

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

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

سنكون سعداء إذا قدمت هذه الميزة في الإصدار الجديد.

@ shin- أعتقد أن blockloop أظهر مع المثال git مدى ملاءمة / فائدة خيار السحب. بصراحة اتمنى لمثل هذه الاشياء ليس من الضروري تفرع اي مشروع.

أتفهم تمامًا النهج المحافظ ولكن يبدو أنه لم يعد يعتبر خيارًا بعد الآن. ربما يمكن أن يكون جزءًا من الإصدار القادم؟

سيكون A pull: IfNotPresent رائعًا. لذلك قد يكون من الممكن استخدام احتياطيات مثل
1) استخدم الصورة المحلية
2) اسحب إذا لم تكن محلية
3) بناء إذا لم يكن قادرا على سحب

@ shin- استمر في السؤال عن سبب عدم قطع طريقة && ، وسبب ذلك هو هذا. أستخدمه في صورة "التطبيق" للاختبار (Puppet PDK / Onceover). يعد ملف الإنشاء جزءًا من نموذج إعادة الشراء ، لذلك عندما يحتاج مطور العرائس (الأشخاص المهمون حقًا) إلى إنشاء وحدة نمطية جديدة يقومون بتشكيل هذا الريبو. يدير Jenkins الصورة للتحقق من صحة الدمج على وحدة إعادة الشراء هذه (داخليًا لدينا مكون إضافي لـ jenkins يتعامل مع التحديث للوظائف.) الآن لن يكون الأشخاص الذين يستخدمون هذا خبراء في الرصيف ، وعليهم إخبارهم بالقيام بـ && يعد أمرًا إضافيًا خطوة يمكنهم (وربما سيفشلونها). لا أفهم لماذا سيكون صعبًا أو ما العيب الذي سيحدثه ، لكن هذا المنطق يبدو سببًا مفيدًا لإضافته. يساعدنا المطورين على إرسال الأشياء التي تتطلب اتجاهات وخطوات أقل ..

باختصار .... للحماية من الكسل

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

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

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

تحاول معرفة الظروف التي تم بموجبها إغلاق هذه التذكرة - هل من الممكن أن يوضح أحد ما بالتفصيل؟ إذا كانت هناك أي مساعدة ، فأنا محترف بإضافة علامة --pull إلى docker-compose up .

أعتقد أن هناك مقترحين تتم مناقشتهما هنا:

1 - هل يجب إضافة هذا كخيار سطر أوامر؟ في الواقع القضية المنشورة.
2 - هل يجب إضافة هذا الخيار إلى ملف YML.

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

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

orodbhen لا داعي للجدال. لا يوجد أحد يستمع إلينا هنا.

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

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

يرجى الامتناع عن استخدام الألفاظ النابية.

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

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

lig لا أبحث عن الجدال. مجرد صنع القضية.

اعتمادًا على حاجتك ، قد يكون التفرع مبالغة. في حالتي الخاصة ، وجدت أن Compose لا يلائم البرمجة النصية جيدًا ، إلا إذا كان نصًا أساسيًا للغاية. يعد استخدام Docker Python API وملف YAML الخاص بي للحفاظ على الإعدادات أكثر تنوعًا وغالبًا ما يكون أبسط.

@ bdharrington7 - لكن عليك صيانة الشوكة وإبقائها مثبتة على جميع الأجهزة التي تستخدمها (نادرًا ما يكون ذلك ممكنًا). التحذير هو أن Docker Compose تحظى بشعبية ، ويمكن قول الآخرين: "من يهتم؟"

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

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

"يجب أن نحترم رد @ shin-'على هذا ، ونعتقد أن هناك أسبابًا وجيهة لعدم تنفيذها."

فقط لن يرضي الناس. يحتاج المجتمع لمعرفة "الأسباب الوجيهة".

تبقى النقطة هي أن الضرب بقبضات اليد والاستجداء نادرا ما ينتج
في الحصول على ما تريد ، كان الكثير منها يحدث في هذا الموضوع.
كان هناك الكثير من حالات الاستخدام الجيد التي تم طرحها في الموضوع أيضًا ،
ولكن ما لم تكن تدفع بالفعل مقابل البرنامج ، فلا يوجد أي التزام
من المشرفين لفعل أي شيء حيال ذلك ، ولا إعطاء أي أسباب للسبب. انا
مجرد إعطاء @ shin- والشركة فائدة الشك هنا.
في السبت 24 مارس 2018 الساعة 5:39 صباحًا كتب Greg Pakes [email protected] :

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

للأسف ، سيؤدي ذلك دائمًا إلى مشكلات مثل هذه مع البعض
عدم الرضا. أعتقد أن القضية الرئيسية هنا هي أنه لا يبدو أن هناك
كانت قضية مناسبة تم طرحها لسبب كونها فكرة سيئة. ال
"يجب علينا احترام رد @ shin- http: /// shin- على هذا ،
ونعتقد أن هناك أسبابًا وجيهة لعدم تنفيذها "
سوف ترضي الناس. يحتاج المجتمع لمعرفة "الأسباب الوجيهة".

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

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

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

كان هناك الكثير من حالات الاستخدام الجيد التي تم طرحها في الخيط أيضًا

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

ليس هناك أي التزام من المشرفين بفعل أي شيء حيال ذلك ، ولا إعطاء أي أسباب للسبب

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

ما المنتج المجاني هنا بالضبط؟ إذا استخدمت docker-compose.exe وقمت بتشغيل docker EE ، ألا يعني ذلك حقًا أنني أقوم بالدفع مقابل المنتج؟

يجب أن يسحب IMHO --build ؛ لا حاجة لأي علم أو تكوين آخر. إذا كنت لا تريد أن يتم سحبها ، فحدد إصدار الصورة.

@ ET-CS: نسخ الصور ليست سوى علامات ويمكن تغييرها إلى تجزئة مختلفة

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

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

أتوقع --build لإحضار كل شيء إلى الأحدث.

إذن ، هذه حالة استخدام جيدة:

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

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

agnjunio هذا يبدو حقا مؤسف ، آسف. ومع ذلك ، إذا نسي الشخص تشغيل docker-compose pull ، فأنا لست متأكدًا من أن احتمال نسيان استخدام العلم الافتراضي هو --pull ؟

@ shin- عذرًا ، لقد نسيت أن أذكر شيئًا مهمًا: الحل في حالتي هو أن يكون هناك علامة pull: always داخل yaml ، ربما داخل خيارات image:

@ ET-CS من https://github.com/docker/compose/issues/3574#issuecomment -382451356:

كنت أتوقع - بناء لأحدث كل شيء.

IMHO - يجب سحب البناء ؛ لا حاجة لأي علم أو تكوين آخر. إذا كنت لا تريد أن يتم سحبها ، فحدد إصدار الصورة.

AFAIK الذي من شأنه أن يمنع حالة الاستخدام مع بناء باستخدام FROM الذي هو نتيجة بناء depends_on .

version: "3.4"
services:
  some-base-image:
    image: our/base-image
    build:
      context: ./base
  # This Dockerfile has FROM our/base-image
  coolthing:
    depends_on:
    - some-base-image
    build:
      context: ./coolthing

أؤيد وضع علامة على النحو المقترح في https://github.com/docker/compose/issues/3574#issuecomment -252861859 و https://github.com/docker/compose/issues/3574#issuecomment -279460839

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

@ shin- يتمثل الاختلاف هنا في أنه إذا قمت بتشغيل docker-compose up --help فسوف أتلقى طريقة وصفية في كيفية استخدام: أحدث صورة ، وبدلاً من ذلك يجب أن أبحث في المستند أو في google الذي يقودني إلى هذا الموضوع وأنا بحاجة إلى قراءة جميع التعليقات لفهم أن docker-compose up لا يفعل ما أحتاجه / أريده ، لذلك أنا الآن بحاجة إلى تشغيل أمرين.

agnjunio هذا يبدو حقا مؤسف ، آسف. ومع ذلك ، إذا نسي الشخص تشغيل Docker-compose pull ، فأنا لست متأكدًا من مدى احتمال نسيانه لاستخدام علم السحب الافتراضي؟

بحرارة

أحد الأسباب الرئيسية لاستخدام عامل البناء هو القدرة على وضع ملف docker-compose.yaml في المستودع والحصول على مخرجات قابلة للتكرار عندما يسحب المطور المستودع ويقوم بتشغيل docker-compose up [service] .

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

القدرة على وضع:

services:
  codegen:
    image: myimage:latest
    pull: Always

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

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

تخيل عندما اقترح شخص ما إضافة --stop إلى docker-compose rm أن الإجابة كانت "ما الخطأ في docker-compose stop myapp && docker-compose rm myapp ، أو إذا طلب شخص ما تنفيذ docker-compose down فقد كان الأمر كذلك سئل لماذا docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ... غير عملي؟

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

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

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

ربما يجب علينا فقط أن نفترق في تكوين عامل الميناء ونقوم بتحديثه بأنفسنا.

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

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

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

حقيقة أن هذه القضية "المغلقة" ظلت نشطة للغاية تشير إلى أنه لم يتم التعامل معها بشكل جيد.

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

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

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

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

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

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

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

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

أنا أبحث عن سياسة سحب صور kubernetes في إنشاء عامل ميناء ، ستكون رائعة إذا كان من الممكن استخدام "السحب".

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

يمكنك أن تختلف معي ، لكنني أشعر بخيبة أمل لأنك ستلجأ إلى hominems الإعلانية ،Wenzil. مجتمعنا بشكل عام يحمل نفسه على مستوى أعلى.

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

كثير من الناس يختلفون مع @ shin- لأسباب وجيهة للغاية موصوفة. على الأقل ، يجب أن يكون هذا تصريح خدمة. لا يُعد تجميع أوامر bash معًا حلاً جيدًا لعمليات النشر المبرمجة.

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

هذه. وهي ليست مجرد عامل بناء. كل من Docker-stack و docker-machine و docker-cli كلها متشابهة.

https://github.com/docker/compose/issues/6316#issuecomment -438564025

قفل لأن هذا يستمر في الخروج عن مساره. سنعيد التقييم حسب مصير https://github.com/docker/cli/pull/1498

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