Compose: कम्पोज द्वारा बनाए गए कंटेनरों के लिए डिफ़ॉल्ट नामकरण योजना

दुर्भाग्य से नहीं, क्षमा करें।

इधर भी ऐसा ही है। यह स्लग सुविधा वैकल्पिक होनी चाहिए। एक ध्वज को ऊपर से गुजारना या इसे बंद करने की आज्ञा देना कितना कठिन है?

मैं सहमत हूं - यह वैकल्पिक होना चाहिए। डॉकर कंपोज़ का उपयोग करने वाले कई कार्यक्रम अब केवल तभी चलते हैं जब आप 1.22 पर डाउनग्रेड होते हैं।

मैं सहमत हूं, यह वैकल्पिक होना चाहिए। हमें इस स्लग सुविधा की बिल्कुल भी आवश्यकता नहीं है और बहुत सारे बैश-स्क्रिप्ट पुराने नामकरण प्रारूप का उपयोग कर रहे हैं।

हमारे लिए भी, हमें 1.22 पर बने रहना चाहिए क्योंकि हम "वॉल्यूम" फ़ीचर का उपयोग करते हैं और पुरानी नामकरण योजना पर भरोसा करते हैं। कृपया, इसे 1.24 में वैकल्पिक सुविधा बनाएं।

इस सुविधा के बाद कंटेनरों को संदर्भित करना मुश्किल हो जाता है, क्योंकि उनका उपयोग हो चुका होता है।

मुझे इस परिवर्तन की बात नहीं आती। वर्तमान में न तो डॉकटर और न ही किसी सेवा खोज की पेशकश करते हैं। इसलिए, अगर मैं कंटेनर के अंदर से एक होस्टनाम प्राप्त करना चाहता हूं, तो मुझे क्या करना चाहिए? मेरी स्वयं की सेवा खोज को रोल करें?

BTW, इस परिवर्तन के क्या लाभ हैं? क्या यह वास्तव में पिछड़ी संगतता को तोड़ने लायक है?

डिफ़ॉल्ट _slug नाम परिवर्तन सही दृष्टिकोण है, लेकिन इसे पर्यावरण चर या कमांड लाइन विकल्प के माध्यम से अक्षम करने का तरीका नहीं होने से बहुत सारे मौजूदा वर्कफ़्लो टूट जाते हैं। कृपया इस सुविधा पर विचार करें कि किसी प्रकार का ध्वज जोड़ने के लिए <= 1.22.0 docker- रचना नामकरण व्यवहार वापस लाएं।

क्षमा करें, लेकिन अब "external_links" अनुपयोगी हैं। मुझे इसे लिंक करने के लिए एक कंटेनर का नाम जानना होगा।
इसे वैकल्पिक बनाने के लिए +1

@ पिंडली- यह नया व्यवहार पूरी तरह से बर्बाद कर देता है। इससे पहले कि यादृच्छिक slug एक डॉकटर-कंपोज़ फ़ाइल से लॉन्च किए गए कंटेनर को किसी अन्य फ़ाइल के अंदर संबोधित करना संभव था

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

और बस। अब, यह बिल्कुल काम नहीं करेगा।

कैसे यह बात कम से कम वैकल्पिक नहीं है?

डॉकटर-कम्पोजिट डेथ का एक और कदम, मेरा मानना ​​है।

इसलिए, वर्कअराउंड है। container_name पैरामीटर का उपयोग किया जाता है और उस पर slug का उपयोग नहीं किया जाता है। कम से कम, वह मदद करता है।

@ नली कृपया, इस बारे में एक बग रिपोर्ट पर विचार नहीं करते slug के साथ उपयोग नहीं किया जा रहा है container_name । जैसा है वैसा ही छोड़ दो। मैं सचमुच यहाँ बैगिंग कर रहा हूँ।

ओह यार! https://github.com/ansible/ansible/issues/47978

जबकि मैं बदलाव के पीछे के प्रोत्साहन को समझता हूं, यह बहुत ही निराशाजनक है, खासकर जब से कम से कम डेवलपर्स को अपनी स्क्रिप्ट को समायोजित करने के लिए कोई अनुग्रह अवधि नहीं है। इस नामकरण परंपरा को ध्यान में रखते हुए बहुत सी लिपियाँ लिखी गईं जो हमेशा के लिए मौजूद थीं। मूल रूप से यह बदलाव किसी भी अन्य डॉक-कंपोज के साथ Do-Compose 1.23 गैर-पीछे की ओर संगत बनाता है।

@ पिंडली- आप व्यक्तिगत रूप से और सभी डॉकटर-कंपोज और डॉकटर टीम को पहले से ही सीखना चाहिए कि पिछड़े हुए असंगत परिवर्तन क्या हैं और इसे व्यापक रूप से अपनाई गई परियोजना में कैसे लाया जाए, यह पूरे उद्योग पर निर्भर करता है।

सबसे पहले, पिछड़े असंगत परिवर्तन आपके बारे में नहीं है जिसे आपने पहले नहीं करने की गारंटी दी है। किसी को परवाह नहीं है अगर इस चीज का उपयोग कोई नहीं करता है।

पिछड़े असंगत परिवर्तन तब होता है जब आप अपने उपयोगकर्ता आधार पर वास्तव में भरोसा करते हैं। और इससे कोई फर्क नहीं पड़ता कि क्या गारंटी थी क्योंकि यह अपाचे 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/#deprec- पॉलिक

तीसरा, @ शिन-, आपको व्यक्तिगत रूप से उन लोगों से बात करना सीखना चाहिए जो आपकी परियोजना में प्रत्यक्ष योगदानकर्ता नहीं हैं और जो सिर्फ आपके उपयोगकर्ता हैं, लेकिन साथ ही वे बहुत व्यस्त लोग हैं जो आपके प्रोजेक्ट के प्रति वफादार हैं और अपना कीमती निवेश करने के लिए पर्याप्त हैं अनुरोधों को दर्ज करने और परियोजना के भविष्य के विकास में कुछ समझ लाने के लिए और दूसरे समाधान में दूर प्रवास में अधिक संसाधनों के निवेश से बचने की कोशिश करने के लिए यहां केवल चर्चा के लिए अनुरोध करने और चर्चा में भाग लेने का समय।

चौथा, डॉकटर टीम डोकर से पैसा बनाने की कोशिश कर रही है लेकिन यह डॉकटर के बारे में नहीं है। जिस तरह से डॉकटर के लिए भुगतान करना एक अच्छी बात हो सकती है, अगर पूरे डोकर के बुनियादी ढाँचे के प्रमाण इसके भुगतान के लायक हैं। मैं यह नहीं देखता कि यह उपयोगकर्ता की सफलता के लिए एक उत्पाद उन्मुख कैसे हो सकता है यदि विकास टीम ज्यादातर समय समुदाय में वापस आती है।

पांचवां, एक बार फिर, हम सभी यहां आपके कॉलेज और दोस्त हैं, न कि दुश्मन। और क्योंकि हम आपके दोस्त हैं, डॉक स्टैक से पलायन दर्दनाक होगा, लेकिन जिस तरह से, यह अब चला जाता है, विदाई बिल्कुल भी अवास्तविक नहीं लगती है।

यह एक प्रमुख संस्करण-ब्रेकिंग परिवर्तन का एक भयानक कार्यान्वयन है, यह हमारे ढांचे को तैनात करने की क्षमता को पूरी तरह से तोड़ देता है और मैं कल्पना भी नहीं कर सकता कि कितने अन्य एक ही सटीक मुद्दे का अनुभव करेंगे, बिल्कुल शून्य अग्रिम चेतावनी के साथ; जब तक कोई व्यक्ति मैन्युअल रूप से नवीनतम चेंजलॉग के लिए डॉकटर की तलाश में नहीं जाता है, उन्हें इस बारे में कोई पता नहीं होगा, और मुझे लगता है कि ज्यादातर लोग ऐसा नहीं करेंगे

@ पिंडली- यह परिवर्तन मौजूदा वर्कफ़्लोज़ के लिए अत्यधिक विघटनकारी है और स्लग उत्पन्न नहीं करने के लिए एक ध्वज होना चाहिए। हजारों घंटे का विकास समय स्क्रिप्ट लिखने और सेवाओं को स्वचालित करने में चला गया है जो कि docker-compose की भविष्यवाणी पर निर्भर करते हैं। उचित सेवा खोज के बिना, व्यक्तिगत कंटेनरों के स्वचालित लक्ष्यीकरण की अनुमति देने के लिए टीम की योजना क्या है?

मैंने docker-compose container_name निर्देश का उपयोग करने की कोशिश की लेकिन इसका GitLab पर कोई प्रभाव नहीं पड़ा।
लेकिन ऐसा लगता है कि मैक ओएस Mojave पर docker-compose मेरे नवीनतम संस्करण पर यह काम कर रहा है। यकीन नहीं हो रहा है कि क्या हो रहा है :)

मेरी .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 जीए एक महीने से अधिक बाद में जारी किया गया था, और यह जानना विवादास्पद होगा कि, हमने इसे चैंज के शीर्ष पर एक बड़ी चेतावनी के रूप में रखा। अगर इस बदलाव को दिखाई देने के लिए मैं कुछ और कर सकता हूं, तो अगली बार जब हम इस तरह के जोखिम भरे बदलाव पर विचार करेंगे, तो मुझे खुशी होगी।
  
  
  
  • फ़्लिप्सीड पर, अगर यहाँ सामान्य टेकअवे है "कभी कोई ब्रेकिंग चेंज न करें, या मुझे उन सभी में से अनिश्चित काल के लिए बाहर जाने दें", मुझे यकीन है कि आप में से अधिकांश को पता है कि यह एक स्वस्थ, उचित तरीका नहीं है एक सॉफ्टवेयर प्रोजेक्ट को बनाए रखने के बारे में कंपोज़ का आकार, जो पहले से ही डॉक इंजन इंजन संस्करणों, कम्पोज़ फ़ाइल स्वरूपों और विस्तृत मुहावरों की एक विस्तृत सरणी के साथ पिछड़े-संगतता को बनाए रखने के लिए बहुत से हुप्स के माध्यम से कूदता है।
  
  

मुझे पता है अगर वहाँ कुछ भी है कि यहाँ संबोधित नहीं है। मैं समझता हूं कि यह आप में से एक के लिए एक प्रमुख गति टक्कर है और जब हम अप्रत्याशित परिस्थितियों से निपट रहे हैं तो टेम्परर्स भड़क सकते हैं। अपग्रेड के माध्यम से जाने और समय के लिए अपने कंपोज संस्करण को पिन करने की आवश्यकता है। "मैं पूर्वानुमानित नामों के बिना XYZ कैसे करूं?" तब तक, इस धागे में या स्लैक पर। और कृपया इन मंचों पर दूसरों के साथ बातचीत करने के तरीके पर विचार करें, यह जांचें कि आपके द्वारा साझा की जा रही जानकारी सही है (मैंने पहले से ही कुछ धागों का उल्लेख किया है या वहां पुनर्निर्देशित किया है, जिनका इस बदलाव से कोई लेना-देना नहीं है , जो अनावश्यक रूप से अलार्म का निर्माण करता है और उन लोगों की समस्या को हल करने में मदद नहीं करता है जो गलत तरीके से यहां पहुंच रहे हैं), और बातचीत को पटरी से नहीं उतारते। आपके समय और धैर्य के लिए आपका धन्यवाद।

संचार भाग पर, मैं इस तरह के बदलाव की अपेक्षा करूंगा और कुछ संचार चैनल के माध्यम से पहले से समझा जाऊंगा, मूल रूप से जिस तरह से आपने इसे इस धागे में यहां किया है, यह समझाते हुए कि क्यों, और अभी के लिए क्या करना है, लेकिन इससे पहले सब के बाद।

@ पिंडली- आपने मेरी पिछली टिप्पणी और लिंक को नहीं पढ़ा है, जो आपके पास है?

आप में से अंतिम व्यक्ति दयालु दिखता है लेकिन वही महसूस करता है।

मुझे इस सुझाव पर दिलचस्पी है कि इस बदलाव को बेहतर तरीके से कैसे सूचित किया जा सकता है।

टी एल; डॉ

• नए version docker-compose.yml परिचय दें
• दस्तावेज़ में लिंक के साथ DeprecationWarning external_links जो अपडेट का वर्णन करता है और माइग्रेट करने के इच्छुक लोगों के लिए एक नमूना समाधान प्रदान करता है।
• नए से पहले सभी फ़ाइल स्वरूप संस्करणों की रचना के लिए पुराने व्यवहार का समर्थन करें।

संदर्भ के लिए, परिवर्तन को हमारे जारी किए गए नोटों में कहा गया है

चेंजगॉग योगदानकर्ताओं के लिए एक चीज है। उपयोगकर्ता इसे नहीं पढ़ते हैं। एक उपयोगकर्ता docker-compose स्थापित करता है और प्रार्थना करता है कि यह कल के बाद भी काम करता है।

फ़्लिप्सीड पर, अगर यहाँ सामान्य टेकअवे है "कभी कोई ब्रेकिंग चेंज न करें, या मुझे उन सभी में से अनिश्चित काल के लिए बाहर जाने दें", मुझे यकीन है कि आप में से अधिकांश को पता है कि यह एक स्वस्थ, उचित तरीका नहीं है एक सॉफ्टवेयर प्रोजेक्ट को बनाए रखने के बारे में कंपोज़ का आकार, जो पहले से ही डॉक इंजन इंजन संस्करणों, कम्पोज़ फ़ाइल स्वरूपों और विस्तृत मुहावरों की एक विस्तृत सरणी के साथ पिछड़े-संगतता को बनाए रखने के लिए बहुत से हुप्स के माध्यम से कूदता है।

मेरे पास तुम्हारे लिए अच्छी खबर है। आपने पहले ही गारंटी दी है कि "कभी भी कोई परिवर्तन न करें, या मुझे अनिश्चित काल तक उन सभी से बाहर रहने दें"। और अधिक, आपके पास इसके लिए एक विशेषता है। यह version docker-compose.yml फ़ाइल में है। इसलिए, ASAP के इस बदलाव को वापस लेने और अगले version संख्या के लिए इसे शुरू करने पर विचार करें।

"मैं पूर्वानुमानित नामों के बिना XYZ कैसे करूं?" तब तक, इस धागे में या स्लैक पर।

कृपया, के लिए समाधान प्रदान करते हैं external_links और बिना बाहरी मात्रा container_name परिभाषित (जैसा कि हम देखेंगे कि यह काम हमेशा नहीं करता है) किसी अन्य रूप में docker-compose.yml इस सूत्र में।

यह एक लोकप्रिय तरीका है जिससे आपके उपयोगकर्ता आपकी परियोजना का उपयोग करते हैं। आपके अधिकांश उपयोगकर्ता स्थानीय विकास के लिए docker-compose का उपयोग करते हैं। अक्सर एक के विकास में कई परस्पर जुड़े प्रोजेक्ट होते हैं। ऐसे मामले में एक ही नेटवर्क में कई डॉकटर-कंपोज करने वाली फाइलों को निर्देशित करना और डेवलपर की मशीन पर एक दूसरे तक पहुंचने में सक्षम होने के लिए विभिन्न परियोजनाओं से सेवाओं के लिए external_links को परिभाषित करना एक आम बात है।

बातचीत को पटरी से न उतारें

@ पिंडली - आपके द्वारा अब तक पढ़ी गई सभी बातचीत आप लोगों की समस्याओं को हल करने के लिए कुछ नहीं करने के कारण पटरी से उतर गई हैं।

गंभीरता से, इस तरह के रवैये के साथ उपयोगकर्ताओं के अनुरोधों को लगातार नकारना और अपने सामुदायिक संघर्ष को मजबूर करना जब आप इस बात से बच सकते हैं कि आप इस परियोजना को किसी और को बेहतर तरीके से पारित करते हैं।

पुनश्च: एक और "अपमानजनक" टिप्पणी के लिए क्षमा करें। इस मुद्दे को बंद करने के लिए स्वतंत्र महसूस करें क्योंकि आप भी उपयोग किए जाते हैं।

कृपया, इस थ्रेड में एक और डॉक-कंपोज़.माइल में कंटेनर_नाम परिभाषित के बिना बाहरी_लिंक और बाहरी वॉल्यूम के लिए समाधान प्रदान करें (जैसा कि हम देखते हैं कि यह हमेशा काम नहीं करता है)।

पहले से ही किया था, कृपया मेरी पूर्व टिप्पणी को देखें:

विभिन्न परियोजनाओं से कंटेनरों को संवाद करने की अनुमति देने का अनुशंसित तरीका उनके लिए external नेटवर्क साझा करना और अन्य सेवा के उपनाम (एस) का उपयोग करना है। इसी तरह, परियोजनाओं के लिए volumes_from बजाय external नाम वाले संस्करणों का लाभ उठाना चाहिए।

आपकी बाकी पोस्ट अनावश्यक रूप से प्रतिकूल है और मैं इसका जवाब नहीं दूंगा। मैं यहाँ हूँ और एक चर्चा के लिए तैयार हूँ, लेकिन मुझे आपकी बदमाशी नहीं करनी है।

ईमानदारी से, @ पिंडली-

मुझे इस सुझाव पर दिलचस्पी है कि इस बदलाव को बेहतर तरीके से कैसे संप्रेषित किया जा सकता है

मुझे नहीं लगता कि आप „रुचि रखते हैं”। फ़ाइल बनाने से पहले छवि खींचने के बारे में टिकट बंद करना और इसे (स्पैम ’(योग्य) के रूप में चिह्नित करना मुझे बताता है कि आप निश्चित रूप से रुचि नहीं रखते हैं कि समुदाय क्या सुझाव देता है। मैं वास्तव में नहीं जानता कि आप क्या हासिल करना चाहते हैं लेकिन मुझे लगता है कि समुदाय के साथ संबंध बनाए रखना किसी और के पास होना चाहिए।

मैं यहां हूं और चर्चा के लिए तैयार हूं

यहां तक ​​कि अगर हम शुद्ध मेधावी तर्क प्रदान करते हैं, तो आप उन्हें अनदेखा करते हैं। तो परवाह क्यों?

पुनश्च। इसे अपमानजनक के रूप में चिह्नित करें, आगे बढ़ें, हमें दिखाएं कि आप हमारी राय का सम्मान कैसे करते हैं। विभिन्न मतों पर इतने उतार-चढ़ाव देखकर दर्द होता है?

पहले से ही किया था, कृपया मेरी पूर्व टिप्पणी को देखें:

मुझे वहां कोई सैंपल सॉल्यूशन नहीं दिख रहा है, सॉरी।

आपकी बाकी पोस्ट अनावश्यक रूप से प्रतिकूल है और मैं इसका जवाब नहीं दूंगा। मैं यहाँ हूँ और एक चर्चा के लिए तैयार हूँ, लेकिन मुझे आपकी बदमाशी नहीं करनी है।

क्षमा करें, यदि आपको ऐसा लगता है। कृपया, वर्तमान डॉकटर के लिए पुराने व्यवहार का समर्थन करने के लिए फ़ाइल संस्करणों की रचना करें और नए प्रारूप संस्करण को पेश करें जो नए तरीके से व्यवहार करेगा। यह एकमात्र विकल्प है जो आपको अपने यूजरबेस को एक अच्छा समाधान प्रदान करना है।

कृप्या। इन दो टिप्पणियों को एक विचार के साथ फिर से पढ़ने पर विचार करें कि मैं आपके दिमाग में परियोजना की मदद करने को तैयार हूं:

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

पुन: संचार: हमें मैक के लिए डॉकर के माध्यम से अपडेट मिला, और इस परिवर्तन को इंगित करने वाले किसी भी प्रकार के चैंज को दिखाने के लिए ऐसा प्रतीत नहीं हुआ, इसलिए यह पता लगाने में थोड़ा समय लगा कि हमारे पर्यावरण चर क्यों बदल गए थे।

एक बार जब मुझे इस बारे में पता था, हालांकि मैंने इसे v1 से v3 तक हमारे कॉन्फिगरेशन को अपग्रेड करने और पर्यावरण के चर के बजाय सेवा के नामों का उपयोग करने के लिंक के रूप में लिया था, और यह वास्तव में चीजों को बहुत क्लीनर बनाता है this

FWIW, कंपोज द्वारा बनाए गए कंटेनर में निष्पादित करने के लिए एक पिछड़े-संगत हैक:

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

एक बार जब मुझे इस बारे में पता चल गया, हालांकि मैंने इसे v1 से v3 तक हमारे कॉन्फिगरेशन को अपग्रेड करने और पर्यावरण चर के बजाय सेवा नामों का उपयोग करने के लिंक के रूप में लिया, और यह वास्तव में चीजों को बहुत क्लीनर बना दिया है

क्या आप अलग-अलग डॉकटर-कम्पोज़ फ़ाइलों के दृष्टिकोण को जोड़ने वाली सेवा के नाम के लिए एक छोटा उदाहरण यहाँ दे सकते हैं?

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

हालांकि इसका डॉकटर-कंपोज से कोई लेना-देना नहीं है।

@ लिग यह expected नाम में परिवर्तन के आसपास काम करता है। यदि यह नामकरण योजना में परिवर्तन के लिए नहीं था तो यह समाधान मौजूद नहीं होगा।

इस बदलाव के बाद @joebowbeer मुख्य समस्या

@ पिंडली- मुझे लगता है कि हम सभी अभी भी इस स्पष्टीकरण की प्रतीक्षा कर रहे हैं कि हमें झुंड लाइन कंटेनर नामों को उत्पन्न करने के लिए डॉक संगीतकार की आवश्यकता क्यों है।

मेरे लिए यह बहुत स्पष्ट है कि उनके राज्य में कोई भी उत्पादन उद्देश्य के लिए संगीतकार का उपयोग करने की आवश्यकता नहीं होगी। कंपोज़ स्थानीय स्तर पर परीक्षण किए जाने वाले प्रोजेक्ट को रैंप करने के लिए एक शक्तिशाली है। मैं एक उपकरण के लिए docker झुंड perk / कार्यक्षमता प्राप्त करने की अपील नहीं देखता, जो कि केवल स्थानीय परीक्षणों के लिए बड़े पैमाने पर उपयोग किया जाता है। यदि हमें कंटेनरों के लिए झुंड जैसा नाम चाहिए तो हम झुंड का उपयोग करेंगे। सही?

यहां दूसरा बड़ा सवाल यह है कि एक तर्क के माध्यम से इसे विकल्प के रूप में शामिल क्यों नहीं किया गया? मैं अपने मंचों और समुदायों के लोगों से अपील नहीं करता कि वे इस व्यवहार को एक डिफ़ॉल्ट के रूप में देखें। इसलिए हमें संभवतः इसे नए arg: 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.

उद्यम में काम करते हुए, अतीत में, हमने परिवर्तन को तोड़ने पर "दो प्रमुख संस्करण" नियम का पालन किया - एक में हटाएं, अगले में निकालें। मुझे वास्तव में यकीन नहीं है कि इसे ऑप्ट-इन कैसे बनाया जा सकता था, लेकिन एक _temporary_ ऑप्ट-आउट वास्तव में सराहना की गई होगी।

डॉकर-कंपोज़ में प्रमुख संस्करणों की अवधारणा नहीं दिखती है, लेकिन मैं यह नहीं देखता कि एक अस्थायी "अक्षम करें" विकल्प (कमांड लाइन से या कंपोज़ फ़ाइल में) एक या दो रिलीज़ (1.23) तक सीमित है या नहीं संभवतः 1.24) "अनिश्चित काल" का गठन करेगा।

यह देखते हुए कि यह गैर-लिनक्स उपयोगकर्ताओं के लिए स्वचालित अपडेट से बंधा हुआ है, बहुत से लोगों को आश्चर्यचकित किया गया था, और "स्क्रिप्टिंग को अपडेट करते समय" इस कमांड लाइन के ध्वज के साथ चलाने की तिमाही के शेष होने के बजाय। हमें डेवलपर्स का एक पूरा समूह मिला है, जिन्हें स्क्रिप्ट को अपडेट करने के लिए मैन्युअल रूप से डाउनग्रेड और / या ड्रॉप करना होगा।

यह टूटता परिवर्तन एक आपदा है। अचानक बहुत सारी तैनाती को तोड़ दिया। कृपया दोबारा ऐसा न करें।

* 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.

बहुत ज्यादा समझ में आता है ... पता नहीं क्यों इस तरह से नहीं किया है।

मैं यहाँ हूँ और एक चर्चा के लिए तैयार हूँ, लेकिन मुझे आपकी बदमाशी नहीं करनी है।

@ पिंडली-यह काफी स्पष्ट है कि यहां शून्य चर्चा है क्योंकि आप प्रस्तुत तर्कसंगत सुझावों पर विचार नहीं कर रहे हैं। इसके अलावा अगर किसी को धमकाया जा रहा है - आप हैं - इस टूटते हुए बदलाव के साथ आप दुनिया भर के कई देवों को प्रभावी ढंग से धमका रहे हैं।

बहुत सारे लोग (मैं और कुछ अन्य व्यक्ति शायद) झुंड मोड के लिए रचना का उपयोग नहीं करते हैं। मैं अपनी कंपोज़ फ़ाइलों के लिए एक निम्न संस्करण निर्दिष्ट करता हूं क्योंकि पिछले कुछ समय में मैंने जिन मुद्दों पर धारणा बनाई है, वह कंपोज़ फ़ाइल का उपयोग स्वैम्स के लिए सेवाओं को परिभाषित करने के लिए किया जाता है। मुझे लगा कि मैंने जो संस्करण निर्दिष्ट किया था, वह मेरे डॉक नोड पर उत्पन्न परिणामों से बंधा था और संस्करण को कुछ कम करने के लिए, मैं लगातार परिणाम प्राप्त करने में सक्षम हूं और फिर भी डॉक के संस्करण के साथ संगत रहने के लिए रचना करने के लिए अपडेट ले सकता हूं। मैं चल रहा हुँ। जाहिरा तौर पर मैं यहाँ उचित संस्करण की उम्मीद नहीं कर सकता।

क्या हम डॉकटर-कंपोज़ कर सकते हैं, यह सुनिश्चित करने के लिए कि वे अचानक हमारे सामान को तोड़ न दें?

मुझे लगता है कि सबसे अच्छा उपाय यह होगा कि डॉकटर-कम्पोज़.आईएमएल फ़ाइल में एक नया कॉन्फ़िगरेशन विकल्प पेश किया जाए, जहाँ कंटेनर के नाम में स्लग भाग को जोड़कर उसे निष्क्रिय किया जा सके।

एस / विकलांग / सक्षम /। कम से कम मौजूदा कम्पोज़ फ़ाइल संस्करणों पर।

यह व्यवहार लिखें फ़ाइल का संस्करण संख्या से बंधा होने की जरूरत है। भले ही यह व्यवहार "निर्दिष्ट" हो, यह बहुत व्यापक रूप से उपयोग किया जाता है, और इसलिए यह एक पिछड़ा-असंगत परिवर्तन है। क्यों उस बिंदु पर संस्करण को वैसे भी यदि कोई कम्पोज़ फ़ाइल मेरे बाइनरी को अपग्रेड करते समय उसी तरह से काम करने की गारंटी नहीं देता है? एक कम्पोज़ फ़ाइल युक्ति को दर्शाते हुए (बहुत चेतावनी के साथ जब docker-compose निश्चित रूप से चलाया जाता है) और फिर इसे हटाते हुए, यह निश्चित रूप से मेरी गलती होगी कि मेरा सारा सामान अब काम नहीं कर रहा है, लेकिन मुझे आपकी रिहाई के माध्यम से पढ़ने की उम्मीद है एक कार्यक्रम है कि मुझे मेरे चेहरे पर चेतावनी संदेश मुद्रण का विशेषाधिकार है के लिए नोट्स?

इस तरह के बदलाव करना ऐसा लगता है कि इसके प्रारूप के अलावा कल्पना के व्यवहार को संस्करण के लिए बहुत अच्छी प्रेरणा है: आप चेतावनी के साथ दूसरों के कोड की मान्यताओं को चित्रित कर सकते हैं। मुझे लगता है कि इस मुद्दे को नाम देने वाले बाहरी मुद्दों की मात्रा यह बताती है कि बहुत सारे लोगों के लिए यह कितना आश्चर्यजनक था। विरासत के व्यवहार को धराशायी होते देखना वास्तविक है, ताकि कोड जटिल न हो, लेकिन इस तरह के बदलाव एक बार में लागू नहीं किए जा सकते। क्या मैं कंटेनर नामों को तोड़ने के बारे में अन्य धारणाओं की उम्मीद कर सकता हूं? क्या सेवा का नाम हमेशा कंटेनर के नाम पर रहेगा या जिसे पूर्वानुमेय नामों की तरह हटाया जा सकता है?

यह वास्तव में मुझे याद दिलाता है जब लगातार नेटवर्क डिवाइस नामकरण को लिनक्स में व्यापक रूप से गोद लिया गया था (लेकिन यह विपरीत चीज है नामकरण ... आईडीके)। बहुत सारे कोड ethN के लिए हार्डकोड किया गया था (और अभी भी कुछ आश्चर्यजनक स्थानों में है) और यह वास्तव में नहीं बदला है। वहाँ हालांकि एक तरह से वापस systemd सिस्टम पर पुराने व्यवहार प्राप्त करने के लिए है (और अन्य प्रणालियों पर है, लेकिन यह भिन्न हो सकते हैं) जोड़कर net.ifnames=0 गिरी आर्ग के लिए।

(दूसरे पास के शेख़ी के लिए क्षमा करें, लेकिन मुझे नहीं लगता कि मेरा पहला वाला बहुत रचनात्मक था।)

ऐसा लगता है कि यह परिवर्तन --scale विकल्प को बेकार बनाता है। क्योंकि यादृच्छिक पोस्टफ़िक्स को किसी सेवा के बढ़े हुए उदाहरणों तक पहुंचने के लिए जाना जाना चाहिए।

उदाहरण के लिए, Nginx के लिए अपस्ट्रीम सर्वर के रूप में कई सेवा उदाहरण हैं।

संपादित करें: आगे के लिए # 6365 देखें

वाह, क्या गजब का बदलाव है। 👎

स्क्रिप्ट में उपयोग के लिए हमें बेतरतीब ढंग से उत्पन्न स्ट्रिंग कैसे प्राप्त करना चाहिए?

मैं इस मुद्दे में भी भाग गया और भविष्य के पिछड़े असंगत परिवर्तनों के लिए अपनी सिफारिश व्यक्त करना चाहूंगा। मैक पर उन लिपियों का उपयोग करने वाले कई लोगों के साथ हमारे पास भी project_service_index प्रारूप पर निर्भर स्क्रिप्ट हैं। एक आदर्श दुनिया में, हम मैक के लिए डॉकर के संस्करण को नियंत्रित करने में सक्षम होंगे जिसका लोग उपयोग करते हैं, लेकिन अब जब ऑटो-अपग्रेड संवाद दिखाई देता है तो लोग अपग्रेड करते हैं।

मेरे मुद्दे और सिफारिशें हैं:

1) अपग्रेड डायलॉग में इस महत्वपूर्ण बदलाव का कोई संकेत नहीं था, इसलिए हमारे पास इस बदलाव का कोई स्पष्ट सिर नहीं था। एक आदर्श दुनिया में हम प्रत्येक उन्नयन के लिए सभी रिलीज नोटों की जांच करेंगे, लेकिन हम इस समय नहीं हैं। तो, यह बहुत सराहना की जाएगी अगर इस तरह के कुछ महत्वपूर्ण को अद्यतन संवाद में स्पष्ट रूप से बुलाया गया था।

2) 1 के कारण), कोई स्पष्ट चेतावनी नहीं थी। यह बहुत अच्छा होगा अगर पिछले अपग्रेड में इस तरह का बदलाव कहा गया। उदाहरण के लिए, नवीनतम से पहले अपग्रेड यह कहेगा कि "कंटेनर नामकरण योजना अगले संस्करण में बदल रही है, कृपया अपनी स्क्रिप्ट्स अपग्रेड करें"

3) मैं समझता हूं कि इस धागे को पढ़ने के बाद, हम जो नामकरण योजना का उपयोग कर रहे हैं, उसकी गारंटी नहीं है, और मुझे लगता है कि बेहतर तरीके हैं जिनसे हम कंटेनरों का जिक्र कर सकते हैं। हालाँकि, हम सभी काम में व्यस्त रहते हैं और हमें अपने कार्यों की योजना बनाने की आवश्यकता होती है, इसलिए हमारी स्क्रिप्ट के अनुरक्षक के रूप में, मैं कंटेनर नामों के हमारे उपयोग को कुछ बेहतर तरीके से परिवर्तित करने में सक्षम नहीं हूं। मैं अनुशंसित सर्वोत्तम अभ्यास का उपयोग करके खुश हूं, लेकिन हमारे कोड को स्थानांतरित करने के लिए समय चाहिए। इसलिए, इस तरह के बदलाव के लिए एक डिप्रेसेशन रणनीति होना बहुत अच्छा होगा।

यहाँ मुख्य टेकअवे दुनिया के अधिकांश एक कंटेनर नामकरण योजना को मानती है जो डॉकटर कंपोज़ के उनके उपयोग के लिए मूलभूत है, और एक स्पष्ट पदावनति रणनीति के बिना डिफ़ॉल्ट व्यवहार को बदलना इन वर्कफ़्लोज़ के लिए हानिकारक हो सकता है।

लोग हमेशा सॉफ़्टवेयर का उपयोग नहीं करते हैं जिस तरह से इसका उद्देश्य था, और स्वामित्व उन लोगों पर है जो चीजों को ठीक करने के लिए हैं जब उनकी धारणा विफल हो जाती है। हालांकि, कुछ सरल संचार हमें भविष्य के बदलावों के लिए तैयार करने में मदद कर सकते हैं और हमें नवीनतम सर्वोत्तम प्रथाओं के लिए प्रेरित करने में मदद कर सकते हैं।

यदि आप पहले docker container exec -it project_php_1 bash पर निर्भर थे, तो आप अब इसका उपयोग नहीं कर सकते।

आपको सेवा ID खोजने के लिए 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 बजे, जोफ्रे एफ नोटिफिकेशन @github.com ने लिखा:

उन सभी को धन्यवाद जिन्होंने बदलाव पर अपने विचार साझा करने के लिए समय लिया। हम मानते हैं कि यह खराब था और हमारे हिस्से पर थोड़ा अधिक भार था, और यह कंपोजिट 1.23.2 में आंशिक रूप से वापस आ गया है (हम डॉकटर-कंपोज रन द्वारा बनाए गए कंटेनरों के लिए यादृच्छिक प्रत्यय रख रहे हैं, जो हमें और अधिक सुंदर रूप से संभालने की अनुमति देता है: # 4688 # 4549 # 5240, जैसा कि शुरू में इरादा था)।

मुझे बताएं कि क्या कोई बकाया मुद्दा है जिसे संबोधित करने की आवश्यकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

@ पिंडली- मुझे लगता है कि यह किसी बिंदु पर वापस आ जाएगा - संभवतः 1.24 में (क्योंकि यह एक ऐसा परिवर्तन है)। यदि हां, तो क्या आप उन लोगों के लिए वैकल्पिक हल्के तंत्रों को समझने और उनकी सिफारिश करने के लिए समुदाय के साथ काम कर सकते हैं, जो बिना झुग्गियों का उपयोग कर रहे थे? उस वार्तालाप के लिए सबसे अच्छी जगह के बारे में निश्चित नहीं है।

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

<project>_<service>_<index> से <project>_<service>_<index>_<slug>

ये एक गलती है कोई विशेषता नहीं।
धन्यवाद!
ansible_connection=docker ... के साथ चलने वाली ansible playbooks के बारे में सोचो !!
क्या हमें स्पष्ट container_name देना चाहिए? या हम यादृच्छिक <slug> साथ हमारी सूची को अद्यतन करते रहेंगे !!
रियली वेरी बैड!