Compose: यदि छवि स्थानीय रूप से मौजूद है तो docker-compose up नवीनतम छवि को नीचे नहीं खींचता है

क्या कोई कारण है कि docker-compose pull && docker-compose up अव्यावहारिक है?

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

मैं "डॉकर-कंपोज़ बिल्ड" निष्पादित करने का प्रयास कर रहा हूं, लेकिन यह डॉकरफ़ाइल में संदर्भित छवि को रीफ्रेश नहीं करता है, सिवाय इसके कि जब आप _--pull_ का उपयोग करते हैं।

आप शुरुआत के दौरान _up --build_ के साथ कंटेनर भी बना सकते हैं। लेकिन नवीनतम छवियों को खींचा नहीं जाएगा। क्या हम "docker-compose up --build --pull" (या समान) जैसे sthg की अपेक्षा कर सकते हैं? शायद इसे वाईएमएल में रखना समझ में आता है क्योंकि सभी बिल्ड को रीफ्रेश नहीं किया जाना चाहिए (सीएफआर। स्थानीय छवियां)।

cli में --pull जोड़ने के बजाय (या इसके अलावा), docker-compose फ़ाइल में सेवा परिभाषा पर कुछ जोड़ने के बारे में क्या?, जैसे

version: '2'

services:

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

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

मैं यहां इस सुविधा की तलाश में आया हूं क्योंकि हम इसका उपयोग कुबेरनेट्स के अपने उत्पादन क्लस्टर में करते हैं। वहां टैग "imagePullPolicy" है और इसे "IfNotPresent", "Always", या "Never" पर सेट किया जा सकता है। एक रचना वातावरण के लिए कुछ ऐसा ही अच्छा होगा।

हमारे मामले में, हमें अनुप्रयोगों के लिए अद्यतन नवीनतम निर्भरता सुनिश्चित करने के लिए प्रतिदिन आधार छवि का पुनर्निर्माण करने की आवश्यकता है। एक ही टैग के साथ नवीनतम छवि खींचने के लिए डॉकर रचना एक अच्छी विशेषता है। क्यों नहीं !

इसके बारे में कोई ख़बर?

नमस्ते,

इस मुद्दे के बारे में कोई खबर?

+1

+1

जैसा कि मैंने पहले उल्लेख किया है, docker-compose pull && docker-compose up कार्यात्मक रूप से समान है। इसके लिए एक और झंडा जोड़ने का कोई अच्छा कारण नहीं है।

कल्पना कीजिए कि गिट में pull क्योंकि git fetch && git merge origin/master कार्यात्मक रूप से समान है।

उदाहरण के लिए pull: true टैग जोड़ना उपयोगी हो सकता है यदि आपकी रचना फ़ाइल में आपके द्वारा उपयोग की जाने वाली कुछ छवियां आपके कैशे में हैं। docker-compose pull अपनी लिखें फ़ाइल में _all_ छवियों को खींचें, और यदि ये छवियां आपके कैश में हैं लेकिन भंडार में नहीं हैं तो वह पुल विफल हो जाएगा।

+1

एक परिदृश्य जिसमें docker-compose pull && docker-compose up अव्यावहारिक हो जाता है, जब आप कई docker-compose फ़ाइलों का उपयोग कर रहे होते हैं। आप आसानी से docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up जैसे कमांड के साथ समाप्त कर सकते हैं।

हमारे पास एक परिदृश्य है जिसमें हम स्थानीय रूप से विकसित होते हैं और हम केवल कुछ छवियों को रिमोट से खींचना चाहेंगे। स्थानीय रूप से विकसित एक (या अधिक) अछूता रहना चाहिए। उस स्थिति में हम docker-compose up चलाने से पहले छवियों को मैन्युअल रूप से बनाने/खींचने के लिए बाध्य हैं।
एक pull: true फायदेमंद होगा।

@ शिन- इस पर अपने निर्णय पर पुनर्विचार करने के बारे में क्या? मेरा मानना ​​​​है कि उन पर टिप्पणियां और प्रतिक्रियाएं काफी आत्म-वर्णनात्मक लगती हैं।

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

docker-compose up कमांड में या तो एक फ्लैग जोड़ने पर सहमत हों या कॉन्फ़िगरेशन के लिए एक पैरामीटर। हम अतिरिक्त कॉन्फ़िगरेशन के साथ एक आधार छवि का उपयोग करते हैं जो विकास प्रक्रिया के दौरान अक्सर बदलती रहती है। हम एक फुल-प्रूफ वातावरण बनाना चाहते हैं, जहां एक डेवलपर बिना डिबगिंग के बस docker-compose up चला सकता है, जिसे उन्हें डिबग करने की आवश्यकता नहीं है।

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

यदि आप इस सुविधा को नए संस्करण में पेश करते हैं तो हमें खुशी होगी।

@ शिन- मुझे लगता है कि git उदाहरण के साथ दिखाया कि पुल विकल्प कितना सुविधाजनक/उपयोगी है। ईमानदारी से मुझे उम्मीद है कि ऐसी चीजों के लिए किसी प्रोजेक्ट को फोर्क करना जरूरी नहीं है।

मैं रूढ़िवादी दृष्टिकोण को पूरी तरह से समझता हूं लेकिन ऐसा लगता है कि इसे अब एक विकल्प के रूप में भी नहीं माना जाता है। शायद यह आगामी संस्करण का हिस्सा हो सकता है?

एक pull: IfNotPresent अच्छा होगा। तो फ़ॉलबैक का उपयोग करना संभव हो सकता है जैसे
1) स्थानीय छवि का उपयोग करें
2) खींचो अगर स्थानीय नहीं है
3) अगर खींचने में सक्षम नहीं है तो निर्माण करें

@ शिन- आप एक कारण पूछते रहते हैं कि && विधि इसे क्यों नहीं काटती है, और मेरा कारण यह है। मैं इसे परीक्षण के लिए "ऐप" छवि के लिए उपयोग करता हूं (कठपुतली पीडीके/एक बार)। कंपोज़ फ़ाइल टेम्प्लेट रेपो का हिस्सा है, इसलिए जब एक कठपुतली देव (वास्तव में ऑप्स लोगों) को एक नया मॉड्यूल बनाने की आवश्यकता होती है, तो वे उस रेपो को फोर्क करते हैं। जेनकिंस उस मॉड्यूल रेपो पर मर्ज सत्यापन के लिए छवि चलाता है (आंतरिक रूप से हमारे पास एक जेनकिंस प्लगइन है जो नौकरियों के लिए अपडेट को संभालता है।) अब जो लोग इसका उपयोग करते हैं वे डॉकर विशेषज्ञ नहीं होंगे, और उन्हें && करने के लिए कहना एक अतिरिक्त है कदम है कि वे (और शायद करेंगे) खराब कर सकते हैं। मैं नहीं देखता कि यह कठिन क्यों होगा या इससे क्या नुकसान होगा लेकिन यह तर्क इसे जोड़ने का एक सार्थक कारण लगता है। यह हमें डेवलपर्स को ऐसी चीजें भेजने में मदद करता है जिनके लिए कम दिशाओं और चरणों की आवश्यकता होती है।

इसकी कमी है.... आलस्य से बचाव के लिए

यहाँ बेहतर कारण है: && समकालिक है। लेकिन docker-compose ने समानांतर निष्पादक के लिए बहुत समर्थन किया है जो इस सामान को अनुकूलित करता है। docker-compose up --pull --build छवि बनाना शुरू कर सकता है और जैसे ही इसे खींचा जाता है, सभी छवियों को खींचने की प्रतीक्षा करने के बजाय इसे चला सकता है और उसके बाद ही निर्माण शुरू कर सकता है

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

यह हत्यारा कारण है कि मैं डॉकर-कंपोज़ का उपयोग नहीं कर सकता और विरासत डॉकर रन कमांड के साथ रैपर स्क्रिप्ट लिखने की आवश्यकता है, लेकिन यह बदसूरत है।

यह जानने की कोशिश की जा रही है कि किन परिस्थितियों में यह टिकट बंद किया गया - क्या कोई कृपया विस्तार से बताएगा? अगर यह कोई मदद है, तो मैं --pull ध्वज को docker-compose up जोड़ रहा हूं।

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

1 - क्या इसे कमांड-लाइन विकल्प के रूप में जोड़ा जाना चाहिए? दरअसल पोस्ट किया गया मुद्दा।
2 - क्या यह विकल्प वाईएमएल फाइल में जोड़ा जाना चाहिए।

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

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

@orodbhen को बहस करने की जरूरत नहीं है। यहां हमारी सुनने वाला कोई नहीं है।

ध्वज जोड़ने के तर्क में जोड़ने के लिए ... पिछले वर्ष के दौरान या तो मैंने खुद को इसी चीज़ की खोज में पाया है और यहां केवल यह पता लगाने के लिए समाप्त हुआ है कि मैंने पहले ही एक के पक्ष में कई टिप्पणियां दी हैं --pull झंडा। मुझे लगता है कि मैं अगली बार भी खुद को यहां फिर से पाऊंगा।

@ शिन-, कृपया इस मुद्दे को फिर से खोलें या लॉक करें। यह लगभग दो वर्षों से खुला है, लगातार कमेंट्री (बुद्धिमान और मनोरंजक दोनों), दर्जनों प्रतिभागियों और सैकड़ों वोट प्राप्त कर रहा है।
हालाँकि, यह स्पष्ट प्रतीत होता है कि कंपोज़ टीम इस सुविधा को आगे बढ़ाने में दिलचस्पी नहीं ले रही है। तो आइए किसी का समय बर्बाद न करें या झूठी आशा के लिए जगह न दें कि अगर ऐसा नहीं हुआ तो मुद्दा फिर से उठ जाएगा।

कृपया अपशब्दों के प्रयोग से बचें।

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

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

@lig बहस करने की तलाश में नहीं है। अभी मामला बना रहे हैं।

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

@ bdharrington7 - लेकिन आपको अपना कांटा बनाए रखना होगा और इसे आपके द्वारा उपयोग की जाने वाली सभी मशीनों पर स्थापित करना होगा (जो शायद ही कभी संभव हो)। कैविएट डॉकर कंपोज़ लोकप्रिय है, दूसरों को कहा जाएगा: "कौन परवाह करता है?"

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

अफसोस की बात है कि हमेशा कुछ असंतोष के साथ इस तरह के मुद्दों का परिणाम होगा। मुझे लगता है कि यहां मुख्य मुद्दा यह है कि ऐसा उचित मामला सामने नहीं आया है कि यह एक बुरा विचार क्यों है। तर्क

"हमें इस पर @ शिन- की प्रतिक्रिया का सम्मान करना चाहिए, और विश्वास करना चाहिए कि इसे लागू नहीं करने के अच्छे कारण हैं।"

बस लोगों को संतुष्ट करने वाला नहीं है। समुदाय को "अच्छे कारणों" को देखने की जरूरत है।

मुद्दा यह है कि अपनी मुट्ठी तेज़ करने और भीख माँगने का परिणाम शायद ही कभी होगा
आप जो चाहते हैं उसे पाने में, जिसका बहुत कुछ इस धागे में हो रहा था।
धागे में भी बहुत सारे अच्छे उपयोग के मामले सामने आए हैं,
लेकिन जब तक आप वास्तव में सॉफ़्टवेयर के लिए भुगतान नहीं कर रहे हैं, तब तक कोई बाध्यता नहीं है
अनुरक्षकों से इसके बारे में कुछ भी करने के लिए, और न ही कोई कारण बताएं। मैं हूँ
सिर्फ @ शिन- और कंपनी को यहां संदेह का लाभ दे रहे हैं।
शनिवार, 24 मार्च, 2018 को सुबह 5:39 बजे ग्रेग पेक्स नोटिफिकेशन @github.com ने लिखा:

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

अफसोस की बात है कि हमेशा कुछ के साथ इस तरह के मुद्दों का परिणाम होगा
असंतोष। मुझे लगता है कि यहां मुख्य मुद्दा यह है कि ऐसा प्रतीत नहीं होता है
एक उचित मामला सामने रखा गया है कि यह एक बुरा विचार क्यों है। NS
तर्क "हमें इस पर @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 चला रहा हूं, तो क्या इसका वास्तव में मतलब नहीं है कि मैं वास्तव में उत्पाद के लिए भुगतान कर रहा हूं?

आईएमएचओ --build खींचना चाहिए; किसी अन्य ध्वज या कॉन्फ़िगरेशन की कोई आवश्यकता नहीं है। यदि आप इसे खींचना नहीं चाहते हैं तो छवि संस्करण निर्दिष्ट करें।

@ ईटी-सीएस: छवि-संस्करण केवल टैग हैं और अभी भी एक अलग हैश में बदल सकते हैं

अच्छा बिंदु @lifeofguenter धन्यवाद। जांच कर सकते हैं कि क्या छवि एक अलग हैश में बदल गई है और उस मामले में भी खींचती है?

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

मुझे उम्मीद है कि --build सब कुछ नवीनतम पर लाएगा।

तो, यहाँ एक अच्छा उपयोग मामला है:

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

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

@agnjunio यह वास्तव में दुर्भाग्यपूर्ण लगता है, क्षमा करें। हालांकि, अगर व्यक्ति docker-compose pull चलाना भूल गया, तो मुझे यकीन नहीं है कि वे काल्पनिक --pull ध्वज का उपयोग करना कैसे भूल जाते हैं, इसकी संभावना कम है?

@ शिन- क्षमा करें, मैं एक महत्वपूर्ण बात का उल्लेख करना भूल गया: मेरे मामले में समाधान यम के अंदर pull: always टैग होना है, शायद image: विकल्पों के अंदर

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

मैं उम्मीद करता हूं --build सब कुछ नवीनतम में लाने के लिए।

आईएमएचओ --बिल्ड खींचना चाहिए; किसी अन्य ध्वज या कॉन्फ़िगरेशन की कोई आवश्यकता नहीं है। यदि आप इसे खींचना नहीं चाहते हैं तो छवि संस्करण निर्दिष्ट करें।

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 में सुझाए गए झंडे के पक्ष में हूं।

@solsson
मुझे यकीन नहीं है कि मैं इस उपयोग के मामले में क्यों या क्या अवरुद्ध कर रहा हूं।
कृपया इसके बारे में अधिक जानकारी साझा करें यदि आप कर सकते हैं।

@ शिन- यहां अंतर यह होगा कि यदि मैं docker-compose up --help चलाता हूं तो मुझे इसका उपयोग करने के तरीके में एक वर्णनात्मक तरीका प्राप्त होगा: नवीनतम छवि, इसके बजाय आजकल मुझे डॉक्टर या Google में खोजना है जो मुझे ले जाता है यह धागा और मुझे यह समझने के लिए सभी टिप्पणियों को पढ़ना होगा कि docker-compose up वह नहीं करता जो मुझे चाहिए/चाहता है, इसलिए अब मुझे दो कमांड चलाने की जरूरत है।

@agnjunio यह वास्तव में दुर्भाग्यपूर्ण लगता है, क्षमा करें। हालांकि, अगर व्यक्ति docker-compose pull चलाने के लिए भूल गया है, तो मुझे यकीन नहीं है कि वे एक काल्पनिक --pull ध्वज का उपयोग करना कैसे भूल जाते हैं, इसकी संभावना कम है?

cordially

डॉकटर-कंपोज़ का उपयोग करने के मुख्य कारणों में से एक docker-compose.yaml फ़ाइल को एक रिपॉजिटरी में रखने की क्षमता है और जब कोई डेवलपर रिपॉजिटरी को खींचता है और docker-compose up [service] चलाता है तो उसका पुनरुत्पादन योग्य आउटपुट होता है।

हम अपनी docker-compose फ़ाइलों के भीतर कई सेवाओं का उपयोग करते हैं जो कोडजेन चलाने और एक JSON स्कीमा को एक फ़ाइल में डीरेफरेंस करने के लिए एक टूल चलाने जैसे कार्य करते हैं।
यह सुनिश्चित करना कि ये उपकरण अप-टू-डेट हैं, महत्वपूर्ण है, खासकर यदि हम सभी परियोजनाओं में देखी जाने वाली कुछ सामान्य महत्वपूर्ण समस्या को ठीक करने के लिए अपनी कोडजन छवि को अपडेट करते हैं।

जगह देने की क्षमता होना:

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

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

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

कल्पना कीजिए जब किसी ने --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 ... अव्यावहारिक क्यों है?

यह धागा 2 साल पहले उठाया गया था और मैंने अभी भी सोचा था कि docker-compose.yml में ध्वज जोड़ना सबसे अच्छा तरीका है। मेरे मामले में, हमारे पास एक झुंड में 37 सेवाएं हैं, और उस कुल से 4-5 छवियों को अपडेट करना आसान नहीं है। मैंने अभी के लिए एक शेल बनाया है जो रिपोजिटरी से परिवर्तन की निगरानी कर सकता है और सेवा को फिर से बनाने से पहले विशिष्ट छवि के लिए पुल कर सकता है यदि इसे अद्यतन किया गया है।

यहां एक और बात यह है कि docker-compose up में --quiet-pull विकल्प है। जब मैं पहली बार यह पता लगाने की कोशिश कर रहा था कि क्या up में एक पुल शामिल है, तो मैंने माना कि यह इसकी उपस्थिति के आधार पर किया गया था। इसका कारण यह है कि --quiet-pull का उपयोग न करने से वर्बोज़ पुल होता है।

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

हो सकता है कि हमें केवल docker-compose को फोर्क करना चाहिए और इसे स्वयं अपडेट करना चाहिए।

अगर किसी को पीआर जमा करना था, तो क्या उसे स्वीकार किए जाने का मौका मिलेगा?
यह खुला स्रोत है। मैं इसे कुछ लागू करने की तलाश में हूं
बार खुद। मुझे लगता है कि इसे स्वीकार किया जा सकता है, अन्यथा यह भूमिका बंद हो जाएगी,
अधिकार?

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

इस मुद्दे को फिर से खोला जाना चाहिए क्योंकि चर्चा में इस अनुरोध को लागू नहीं करने का कोई अच्छा कारण नहीं है। लोगों द्वारा बंद मुद्दों के बजाय _open_ मुद्दों पर काम करना शुरू करने की अधिक संभावना है।

तथ्य यह है कि यह "बंद" मुद्दा इतना सक्रिय बना हुआ है कि यह सुझाव देता है कि इसे अच्छी तरह से संभाला नहीं गया है।

दुर्भाग्य से, मैंने पाया है कि कुछ गिटहब रेपो पर पोस्ट जारी करने के जवाब बहुत उपयोगी नहीं हैं। स्वर अक्सर संक्षिप्त होता है, और सुझाव देता है कि प्रतिक्रिया स्वागत से कम है।

कुछ लोगों ने यहां बताया है कि यह एक ओपन-सोर्स प्रोजेक्ट है, और (कम से कम हम में से अधिकांश) ग्राहकों को भुगतान नहीं कर रहे हैं। हालांकि, यह भी ध्यान देने योग्य है कि समस्या रिपोर्ट सबमिट करना एक महत्वपूर्ण समय निवेश का गठन करता है, इससे भी अधिक यदि आप समस्या के समाधान में भाग लेते हैं।

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

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

जाहिर है, टिप्पणियां जो केवल एक समस्या के बारे में शिकायत करती हैं और मांग करती हैं कि इसे ठीक किया जाना उपयोगी नहीं है, लेकिन अधिकांश ऐसा नहीं कर रहे हैं, और "यह खुला स्रोत है, बस कांटा है" जैसी टिप्पणियां समान रूप से बेकार हैं।

@ शिन- "--बिल्ड" क्यों लागू किया गया था? क्या यह डॉकर-कंपोज़ बिल्ड && डॉकर-कंपोज़ अप से अलग है? बस --build (जो जोड़ा गया) और --pull (जिसे बेमानी समझा गया है) के बीच दार्शनिक अंतर को समझने की कोशिश कर रहा है। विचार प्रक्रिया को समझने से मुझे यह याद रखने में मदद मिल सकती है कि चीजें कैसे काम करती हैं। और अगर इश्यू खुल जाता है, तो मुझे पीआर सबमिट करने में खुशी होगी। @everybodyelse ... क्या यह वास्तव में "ओपनसोर्स की भावना" है कि अगर आपको कुछ पसंद नहीं है तो आप कांटा? मैंने सोचा था कि ओपनसोर्स की भावना थी "यदि आपको कुछ पसंद नहीं है तो ए) आवश्यकताओं में योगदान करने में सहायता करें यदि आप वहीं हैं, बी) यदि आप कर सकते हैं तो कोड में योगदान करने में सहायता करें" और यदि आपकी आवश्यकताएं बहुत थीं तो आपने केवल फोर्क किया स्पष्ट रूप से केवल आपको ही कुछ लाभ होगा। यानी मैंने सोचा था कि जब हम साझा करते हैं तो हमें सबसे ज्यादा फायदा होता है - लेकिन मुझे यहां शिक्षित होने की खुशी है।

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

एक कारण है: यदि एक पुल विफल हो जाता है और ऐसा न करने का कोई अच्छा कारण नहीं है, तो डॉकर छवियों को रीफ्रेश नहीं करेगा।

मैं डॉकर कंपोज़ में कुबेरनेट्स इमेज पुल पॉलिसी की तलाश कर रहा हूं, अगर "पुल" का इस्तेमाल किया जा सकता है तो यह बहुत अच्छा होगा।

@ शिन- बचकाना होना बंद करो। इस सुविधा को लागू करने के कई अच्छे कारणों का उल्लेख किया गया है। कम से कम जनसंपर्क के लिए खुले रहें...

आप मुझसे असहमत हो सकते हैं, लेकिन मुझे निराशा है कि आप विज्ञापन गृहणियों, @Wenzil का सहारा लेंगे। हमारा समुदाय आम तौर पर खुद को एक उच्च स्तर पर रखता है।

@ शिन- हमारा समुदाय ज्यादातर यही सोचता है कि आपने जिस कारण का उल्लेख किया है, उसे अनकहा रखते हुए। @Wenzil इसे ज़ोर से कहने के लिए बस इतना ईमानदार है।
मुझे पता है कि बहुत से लोग परेशान नहीं करना पसंद करते हैं और इसे अपने उपयोगकर्ताओं की ओर बढ़ने के लिए डॉकर-कंपोज़ को मनाने की कोशिश करने पर छोड़ दिया।

बहुत से लोग @ शिन से असहमत हैं- वर्णित बहुत ही वैध कारणों के लिए। कम से कम, यह एक सेवा घोषणा होनी चाहिए। बैश कमांड को एक साथ स्ट्रिंग करना प्रोग्रामेटिक परिनियोजन के लिए विशेष रूप से अच्छा समाधान नहीं है।

मुझे पता है कि बहुत से लोग परेशान नहीं करना पसंद करते हैं और इसे अपने उपयोगकर्ताओं की ओर बढ़ने के लिए डॉकर-कंपोज़ को मनाने की कोशिश करने पर छोड़ दिया।

इस। और यह सिर्फ docker-compose नहीं है। डॉकर-स्टैक, डॉकर-मशीन और डॉकर-क्ली सभी समान हैं।

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

इससे ताला टूटता रहता है। हम https://github.com/docker/cli/pull/1498 के भाग्य के आधार पर पुनर्मूल्यांकन करेंगे

एक अद्यतन के रूप में, हमने आंतरिक रूप से सेवा परिभाषाओं में pull_policy पैरामीटर जोड़ने पर विचार करने का निर्णय लिया है। हमें अभी भी यह पता लगाना है कि विकल्प और सटीक सिंटैक्स क्या होगा, लेकिन हमें उम्मीद है कि यह इस धागे में व्यक्त की गई जरूरतों को पूरा करेगा।