Compose: مخطط التسمية الافتراضي للحاويات التي تم إنشاؤها بواسطة Compose

للأسف لا ، آسف.

نفس الشيء هنا. يجب أن تكون ميزة slug هذه اختيارية. ما مدى صعوبة تمرير علم على أمر up أو build لإيقاف تشغيله؟

أوافق - يجب أن يكون هذا اختياريًا. العديد من البرامج التي تستخدم Docker Compose تعمل الآن فقط إذا قمت بالرجوع إلى 1.22.

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

نفس الشيء بالنسبة لنا ، يجب أن نبقى عند 1.22 حيث نستخدم ميزة "مجلدات من" ونعتمد على نظام التسمية القديم. من فضلك ، اجعلها ميزة اختيارية في 1.24.

تجعل هذه الميزة من الصعب الرجوع إلى الحاويات بعد رفعها.

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

راجع للشغل ، ما هي فوائد هذا التغيير؟ هل يستحق حقا كسر التوافق مع الإصدارات السابقة؟

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

عذرًا ، ولكن "ارتباطات_ خارجية" غير قابلة للاستخدام الآن. يجب أن أعرف اسم الحاوية لربطها.
+1 لجعله اختياريًا

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

services:
  app:
    image: app
    external_links:
      - "other-project_other-app_1:other-app"
networks:
  default:
    external:
      name: other-project_default

وهذا كل شيء. الآن ، هذا لن يعمل على الإطلاق.

كيف هذا الشيء ليس اختياريًا على الأقل؟

خطوة أخرى نحو موت عامل المرفأ ، على ما أعتقد.

لذا ، هناك حل بديل. يتم استخدام المعلمة container_name كما هي ولا يتم استخدام slug عليها. على الأقل ، هذا يساعد.

@ shin- من فضلك ، لا تعتبر هذا تقرير خطأ حول slug لا يتم استخدامه مع container_name . اتركها كما هي. أنا حرفيا أتعبأ هنا.

يا ولد! https://github.com/ansible/ansible/issues/47978

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

@ shin- يجب أن تتعلم أنت شخصيًا وكل فريق عامل الإرساء والتركيب بالفعل ما هو التغيير غير المتوافق الرجعي وكيفية إدخاله في مشروع معتمد على نطاق واسع تعتمد عليه الصناعة بأكملها.

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

التغيير غير المتوافق مع الإصدارات السابقة هو عندما تكسر شيئًا تعتمد عليه قاعدة المستخدمين لديك بالفعل. ولا يهم ما هي الضمانات لأنها Apache 2.0 بعد كل شيء والمشروع بأكمله provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND . يقرر المستخدمون لديك ما يعتمدون عليه. ويجب أن تبدأ أنت (الفريق بأكمله) في تعلم كيفية إدراك من يستخدم مشروعك ولماذا وكيف.

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

• https://www.python.org/dev/peps/pep-0004/
• http://api.mongodb.com/python/current/compatibility-policy.html
• https://docs.openstack.org/python-novaclient/pike/reference/deprecation-policy.html
• https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation -policy

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

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

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

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

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

حاولت استخدام التوجيه docker-compose container_name ولكنه لم يسري على GitLab.
ولكن يبدو أن الإصدار الأخير من docker-compose على Mac Os Mojave يعمل. غير متأكد ما يحدث :)

يقوم ملف .gitlabci.yml بتنزيل آخر صورة من tmaier (يجب أن يكون 1.23.1).

مرحبًا بالجميع ، بعض التعليقات العامة التي آمل أن تعالج بعض المخاوف التي تم التعبير عنها هنا:

• أنا أفهم بالتأكيد أن هذا يكسر بعض النصوص. ملاحظات الإصدار الخاصة بنا منذ 1.23.0-rc1 تقول ذلك في الجزء العلوي. هذا إلى حد كبير نوع من "تمزيق الضمادة" حيث يساعدنا الألم اللحظي على المضي قدمًا بقاعدة صحية.
• فوائد الحل الحالي عديدة ويتم التعبير عنها جزئيًا في هذه المشكلة طويلة الأمد: # 1516 - وتم الإبلاغ عن المشكلة مع docker-compose run بشكل خاص عدة مرات هنا: # 4688 # 4549 # 5240
• لا ينبغي أن يكون اكتشاف الخدمة مشكلة حيث يجب التعامل معها باستخدام أسماء الخدمة (بدلاً من أسماء الحاويات) والأسماء المستعارة للشبكة ، والتي تكون ثابتة على الشبكة المرتبطة بها. يمكنك قراءة مستندات الشبكات للحصول على مزيد من التفاصيل حول ذلك على وجه التحديد
• أعتقد أن هذا يجعل استخدام volumes_from و external_links عبر مشاريع الإنشاء أكثر صعوبة. يُرجى مراعاة أنه حتى قبل هذا التغيير ، لم يكن هناك ما يضمن أن Compose سيحترم التنسيق "المتوقع" لاسم حاوية معين (انظر على سبيل المثال # 6155 أو البادئة المذكورة في # 3415) ، مما يجعله حلاً معيبًا عرضة للتشغيل في قضايا غامضة على المدى الطويل.
  
  
  
  • الطريقة الموصى بها للسماح للحاويات من المشاريع المختلفة بالتواصل هي مشاركة شبكة external واستخدام الاسم (الأسماء) المستعارة للخدمة الأخرى. وبالمثل، volumes_from عبر المشاريع بدلا من ذلك ينبغي الاستفادة external مجلدات اسمه.
  
  
• أنا مهتم بالاقتراحات حول كيفية توصيل هذا التغيير بشكل أفضل. للإشارة ، تم استدعاء التغيير في ملاحظات الإصدار الخاصة بنا ومتاح للاختبار منذ 1.23.0-rc1 ، والذي تم إصداره في 26 سبتمبر. تم إصدار 1.23.0 GA بعد أكثر من شهر ، ومعرفة أن التغيير سيكون مثيرًا للجدل ، نضعه كتحذير كبير في الجزء العلوي من سجل التغيير. إذا كان هناك أي شيء يمكنني القيام به لجعل هذا التغيير مرئيًا ، فأنا سعيد للاستماع والقيام بهذه الأشياء في المرة القادمة التي نفكر فيها في تغيير محفوف بالمخاطر مثل هذا التغيير.
  
  
  
  • على الجانب الآخر ، إذا كانت الوجبات الجاهزة العامة هنا هي "عدم إجراء أي تغيير جذري على الإطلاق ، أو السماح لي بإلغاء الاشتراك فيها جميعًا إلى أجل غير مسمى" ، فأنا متأكد من أن معظمكم يدرك أنها ليست طريقة صحية ومعقولة حول الحفاظ على مشروع برمجي بحجم Compose ، والذي يقفز بالفعل من خلال الكثير من الأطواق للحفاظ على التوافق مع الإصدارات السابقة مع مجموعة كبيرة من إصدارات Docker Engine وتنسيقات ملفات Compose والتعابير التي تم إيقافها.
  
  

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

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

@ shin- لم تقرأ تعليقي الأخير والروابط التي قدمتها ، أليس كذلك؟

آخر شخص منك يبدو لطيفًا ولكنه يشعر بنفس الشعور.

أنا مهتم بالاقتراحات حول كيفية توصيل هذا التغيير بشكل أفضل.

TL ؛ DR

• قدم version من docker-compose.yml
• أضف DeprecationWarning لـ external_links مع رابط إلى مستند يصف التحديث ويقدم نموذجًا للحل لمن يرغبون في الترحيل.
• دعم السلوك القديم لجميع إصدارات تنسيق الملفات السابقة للإصدار الجديد.

للإشارة ، تم استدعاء التغيير في ملاحظات الإصدار الخاصة بنا

التغيير هو شيء للمساهمين. لا يقرأها المستخدمون. يقوم المستخدم بتثبيت docker-compose ويصلي أنه لا يزال يعمل بعد أمس.

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

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

يسعدني مساعدتك في أسئلة مثل "كيف أفعل XYZ بدون أسماء يمكن التنبؤ بها؟" حتى ذلك الحين ، في هذا الموضوع أو على Slack.

من فضلك ، قدم الحل لـ external_links والأحجام الخارجية بدون container_name (كما نرى أنه لا يعمل دائمًا) في docker-compose.yml في هذا الموضوع.

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

لا تخرج المحادثة عن مسارها

@ shin - أصبحت جميع المحادثات التي قرأتها حتى الآن والتي تتضمنك قد خرجت عن مسارها لأنك لم تفعل شيئًا لحل المشكلات التي يواجهها الناس.

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

ملاحظة: آسف لتعليق آخر "بعيد المنال". لا تتردد في قفل هذه المشكلة لأنك معتاد أيضًا.

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

فعلت بالفعل ، يرجى الرجوع إلى تعليقي السابق:

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

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

بصراحة @ shin-

أنا مهتم بالاقتراحات حول كيفية توصيل هذا التغيير بشكل أفضل

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

أنا هنا وعلى استعداد لإجراء مناقشة

حتى لو قدمنا ​​حججًا جدارة خالصة ، فأنت تتجاهلها فقط. فلماذا تهتم؟

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

فعلت بالفعل ، يرجى الرجوع إلى تعليقي السابق:

آسف ، لا أرى حل نموذج عملي هناك.

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

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

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

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

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

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

FWIW ، اختراق متوافق مع الإصدارات السابقة للتنفيذ في حاوية تم إنشاؤها بواسطة إنشاء:

docker container exec -it $(docker container ls -f name=expected -q) cmd

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

هل يمكنك من فضلك تقديم مثال قصير هنا لربط اسم الخدمة عبر نهج ملفات إنشاء عامل ميناء مختلفة؟

docker container exec -it $(docker container ls -f name=expected -q) cmd

هذا لا علاقة له مع عامل البناء.

lig يعمل هذا على حل التغيير إلى اسم expected تم إنشاؤه بواسطة docker-compose. لم يكن هذا الحل موجودًا لولا التغيير في نظام التسمية.

joebowbeer المشكلة الرئيسية بعد هذا التغيير تتعلق بالربط عبر ملفات عامل عامل

@ shin - أعتقد أننا جميعًا ما زلنا ننتظر تفسير سبب حاجتنا إلى ملحن عامل ميناء لإنشاء أسماء حاوية خط سرب.

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

السؤال الثاني الكبير هنا هو: لماذا لم يتم تضمينها كميزة اختيارية من خلال مناقشة؟ لا أرى في منتدياتي ومجتمعاتي أشخاصًا يطلبون أن يكون هذا السلوك سلوكًا افتراضيًا. لذلك ربما يجب أن نقدمه على أنه وسيط جديد: docker-compose up --slug . بسيطة وأنيقة ولن تحطم أي نص.

  * On the flipside, if the general takeaway here is "don't make any breaking change ever, or let me opt out of all of them indefinitely", I'm sure most of you realize that it's not a healthy, reasonable way to go about maintaining a software project the size of Compose, which already jumps through a lot of hoops to maintain backward-compatibility with a wide array of Docker Engine versions, Compose file formats, and deprecated idioms.

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

لا يبدو أن Docker-compose يحتوي على مفهوم للإصدارات الرئيسية ، لكنني لا أرى كيف يقتصر خيار "تعطيل هذا" المؤقت (سواء من سطر الأوامر أو في ملف الإنشاء) على إصدار واحد أو إصدارين (1.23 و ربما 1.24) "إلى أجل غير مسمى".

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

هذا التغيير المفاجئ كارثة. انكسر الكثير من النشر التلقائي فجأة. من فضلك لا تفعل ذلك مرة أخرى.

* Introduce the new `version` of the `docker-compose.yml` 
* Add `DeprecationWarning` for `external_links` with a link to a document which describes the update and provides a sample solution for those willing to migrate.
* Support the old behavior for all compose file format versions prior the new one.

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

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

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

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

هل يمكننا فصل عامل البناء عن العمل للتأكد من عدم كسره لأشياءنا فجأة؟

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

ق / معطل / ممكّن /. على الأقل في إصدارات ملف الإنشاء الموجودة.

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

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

هذا يذكرني حقًا بالوقت الذي تلقت فيه تسمية جهاز الشبكة المتسقة اعتمادًا واسع النطاق في Linux (ولكن هذا هو الشيء المعاكس للتسمية ... idk). تم ترميز الكثير من التعليمات البرمجية لـ ethN (ولا تزال موجودة في بعض الأماكن المفاجئة) ولم يتغير ذلك حقًا. بيد أن هناك وسيلة للحصول على دعم السلوك القديم على أنظمة سيستم دي (وعلى أنظمة أخرى، لكنها يمكن أن تختلف) وذلك بإضافة net.ifnames=0 إلى وسائط النواة.

(آسف للتشدق بالمرور الثاني ، لكنني لا أعتقد أن أول مرة كانت بناءة للغاية.)

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

على سبيل المثال ، مثيلات خدمة متعددة كخوادم أولية لـ Nginx.

تحرير: انظر # 6365 لمزيد من المعلومات

واو ، يا له من تغيير مروع. 👎

كيف يُفترض بنا أن نحصل على السلسلة التي تم إنشاؤها عشوائيًا لاستخدامها في البرامج النصية؟

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

مشاكلي وتوصياتي هي:

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

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

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

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

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

إذا كنت تعتمد سابقًا على docker container exec -it project_php_1 bash ، فلا يمكنك استخدام هذا.

يجب عليك استخدام docker ps للعثور على معرّف الخدمة.

ومع ذلك ، لا يمكنك استخدام docker ps -q --filter=name=project_php لأن ذلك سيتطابق مع الخدمات المسماة project_php و project_php_xdebug أو أي شيء آخر يتبقى يطابق project_php .

يجب أن يصبح docker container exec -it project_php_1 bash كان يمكن قراءته سابقًا على النحو التالي:

docker container exec -it \
    $(docker ps -q \
        --filter label=com.docker.compose.project=project \
        --filter label=com.docker.compose.service=php) \
    bash

كان هذا تغييرًا سيئًا.

jtreminio FWIW ، من المشروع لا يزال بإمكانك القيام بـ docker-compose exec php

شكرًا لكل من خصص وقتًا لمشاركة أفكاره حول التغيير. نحن نتفق على أن هذا تم التعامل معه بشكل سيء ومفرط في إرجاعه جزئيًا في نحتفظ بلواحق عشوائية للحاويات التي تم إنشاؤها بواسطة docker-compose run ، مما يتيح لنا التعامل مع هذه الأشياء بطريقة أكثر رشاقة : # 4688 # 4549 # 5240 ، كما كان مقصودًا في البداية).

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

هل هناك أي خطة لإضافة إما خيار سطر أوامر لإيقاف تشغيل هذا --no-slug أو يفضل أكثر --slug بحيث يكون الإعداد الافتراضي هو العمل كما اعتاد.

1.23.2 يعود إلى ما كان عليه من قبل.

تم إرجاعه فقط مقابل docker-compose up ولكن ليس لـ docker-compose run

شكرا لك على الحل السريع لهذا !!

في 28 تشرين الثاني (نوفمبر) 2018 ، الساعة 8:09 مساءً ، كتب Joffrey F [email protected] :

شكرًا لكل من خصص وقتًا لمشاركة أفكاره حول التغيير. نحن نتفق على أن هذا تم التعامل معه بشكل سيئ ومفرط في الحماس من جانبنا ، وقد تم إرجاعه جزئيًا في Compose 1.23.2 (نحن نحتفظ بلواحق عشوائية للحاويات التي تم إنشاؤها عن طريق تشغيل عامل إنشاء السفن ، مما يتيح لنا التعامل مع هذه بشكل أكثر رشاقة: # 4688 # 4549 # 5240 ، كما كان مقصودًا في البداية).

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

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

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

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

تم تغييره من <project>_<service>_<index> إلى <project>_<service>_<index>_<slug>

هذا خطأ وليس ميزة.
شكر!
فكر في دفاتر اللعب غير المعقولة التي تعمل بـ ansible_connection=docker ... 😔 !!
هل يجب أن نعطي صراحة container_name ؟ أم نستمر في تحديث مخزوننا بالعشوائية <slug> !!.
حقا سيء جدا!