Compose: ऐसी सेवाओं को परिभाषित करें जो डिफ़ॉल्ट रूप से शुरू नहीं हुई हैं

विकल्प 1 के लिए +1

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

इन मुद्दों में से कुछ (डेटा-केवल कंटेनरों से निपटने वाले, # 942, @ cpuguy83 से अंतिम टिप्पणी) वास्तव में पहले से ही # 1754 द्वारा तय किए गए हैं, मुझे नहीं लगता कि हमें उन्हें किसी भी समस्या पर विचार करने की आवश्यकता है (1.5 के बाद )।

हम Magento एक्सटेंशन विकसित करते हैं। ऐसा करने के लिए, हमें LAMP स्टैक पर वेबस्टोर चलाने के लिए एक सरल तरीका चाहिए। कम्पोज करना इतना आसान है। लेकिन हम phpunit, विभिन्न स्थैतिक विश्लेषण उपकरण, प्रलेखन बिल्डरों आदि को भी चलाना चाहते हैं, वास्तव में, हमारी "सेवाओं" का विशाल बहुमत docker-compose run --rm phplint कमांड

docker-compose up -d

केवल लंबे समय तक चलने वाली सेवा (वास्तविक _services_ जैसा कि यह था) शुरू करेगा, और अनावश्यक रूप से फ़पुनिट जैसे अन्य प्रभावों को ट्रिगर नहीं करेगा। (यह भी महत्वपूर्ण है कि यह आउट-ऑफ-ऑर्डर चीजों को ट्रिगर नहीं करता है, जैसे वेब सेवा शुरू होने से पहले सेलेनियम परीक्षण चलाना।)

हम सभी वास्तव में ऐसा करने की कोशिश कर रहे हैं कि पर्यावरण प्रबंधन का दर्द डेवलपर्स से दूर हो, उत्पादन सेवाएं न चलाएं। मुझे नहीं पता कि @dnephin की टिप्पणी दिशा के प्रतिनिधि की रचना है या नहीं, लेकिन यह मेरे लिए अस्पष्ट है कि क्या कंपोज़ अभी भी आला की सेवा करने की योजना बना रहा है। अंजीर में शुरू हुआ (क्योंकि, स्पष्ट होने के लिए, मैं थिंक ऑप्शन 1 आसानी से उपयोग में आने वाले डेवलपर्स का समर्थन नहीं करता है, जो कि इसे स्पष्ट रूप से अंजीर के रूप में उपयोग करने की आवश्यकता है।) मैं पूरी तरह से समझता हूं कि अगर कंपोज कई जिम्मेदारियों को नहीं चाहता है, लेकिन मुझे उम्मीद है कि कोई हमें स्पष्ट रूप से बता सकता है अगर हममें से वे लोग इस उत्पाद का उपयोग तेजी से कर रहे हैं, तो अलग-थलग पड़े विकास वातावरण को दूसरी दिशा में ले जाना चाहिए।

@kojiromike , यह क्या है (1) के बारे में जो आपके उपयोग के मामले के लिए अनुपयुक्त है? क्या यह केवल कमांड शब्दार्थ के बारे में है ( docker-compose run --rm phplint बनाम docker-compose --file phplint.yml up )?

इसकी कि docker-compose up -d 'phplint' शुरू करने की कोशिश करती है और docker-compose ps रिपोर्ट करती है कि phplint 'सेवा' नीचे है। वास्तव में यह एक सर्विस कंटेनर नहीं है जो एक टूल कंटेनर है, इसमें अप / डाउन की कोई अवधारणा नहीं होनी चाहिए। यह मेरी समझ थी कि टूल कंटेनरों को डॉकटर द्वारा गले लगाया जाता है (इसके कारण आप रेडिस-क्ली जैसे कुछ कैसे चलाएंगे, स्पष्ट रूप से एक 'सेवा' नहीं) और जब मैं उनका उपयोग विकास में अधिक करता हूं, तो मुझे लगता है कि उनके पास उत्पादन के लिए भी जगह है; जैसे क्यों कहते हैं कि awk उत्पादन मशीनों पर या कंटेनरों में स्थापित किया गया है, क्यों इसे पूर्वानुमानित व्यवहार प्राप्त करने के लिए लिंक के साथ एक कंटेनर के माध्यम से न चलाएं।

: +1: मैं नियमित रूप से अपने आप को चल रही यूनिट परीक्षणों को एनकैप्सुलेट करने के लिए अपनी अन्य सेवाओं के साथ एक tests कंटेनर बनाना चाहता हूं। मेरा "वर्कअराउंड" कमांड को "/ बिन / सच" पर सेट करना है और सीएलआई पर निर्दिष्ट यूनिट टेस्ट कमांड के साथ कंटेनर चलाना है। यह निर्दिष्ट करने में सक्षम होने के कारण कि कौन से कंटेनरों को up शुरू होना चाहिए

(btw, चारों ओर अच्छा काम, लोग)

cc @jameydeorio

@ryneeverett शब्दार्थ इसका एक हिस्सा हैं। यह स्व-दस्तावेज और खोज की समस्या है। वर्तमान में, हम डेवलपर्स को docker-compose run --rm foo bar बताते हैं। हम उन्हें शेल फ़ंक्शन या अन्य नाम बनाने के लिए आमंत्रित करते हैं, लेकिन हम परियोजनाओं के लिए एक मानक उपनाम / आरसीएफईएल बनाए नहीं रखते हैं। (हम कंटेनरों के बाहर चीजों को मानकीकृत नहीं करना चाहते; हम डॉकटर _to_ का मानकीकरण करना चाहते हैं।) कुछ आदेशों के लिए एक नई फ़ाइल जोड़ने से महत्व का पदानुक्रम बनता है: docker-compose.yml फ़ाइल महत्वपूर्ण के लिए "डिफ़ॉल्ट" फ़ाइल बन जाती है। चीजें, और "अन्य" फ़ाइल कम महत्वपूर्ण हो जाती है।

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

विस्तार वास्तव में उन सभी सुविधाओं को प्रदान नहीं करता है जिन्हें हमें सेवाओं को "कमांड" (एक-रन सेवाओं) से जोड़ने की आवश्यकता होगी। अगर ऐसा हुआ भी, अगर हमें कई yaml फ़ाइलों का उपयोग करना पड़ता है, तो हमें उन एक्सटेंशनों का उपयोग करने के लिए मजबूर किया जाएगा जहां हमें अन्यथा आवश्यकता नहीं होगी।

@kojiromike यही मुझे शक था। मुझे आश्चर्य है कि अगर आप बेहतर से संतुष्ट हो जाएगा extends समर्थन + किसी तरह subcommands (जो करने के लिए कार्यात्मक रूप से समान हो जाएगा करने के लिए extends एक भी अंदर), docker-compose.yml । लेकिन शायद बाद वाला (4) जैसा है।

2) उन्हें डिफ़ॉल्ट रूप से शुरू नहीं करने के लिए सेवाओं में एक विकल्प जोड़ें

मैं विकल्प 2 के लिए मतदान करता हूं। जैसे कि start: false निर्देश। लाभ यह है कि हम कई कम्पोज़.माइल फ़ाइलों या अतिरिक्त कॉन्फिग फ़ाइलों की आवश्यकता से बचते हैं, आप पूरे ऐप स्टैक का अहसास पाने के लिए सिर्फ एक कंपोज़.आईएमएल पढ़ सकते हैं।

मुझे लगता है कि https://github.com/docker/compose/issues/1987#issuecomment -139632238 के लिए हमारा प्रस्तावित समाधान इसे संभाल लेगा। "व्यवस्थापक" सेवाओं को एक अलग कॉन्फ़िगरेशन में परिभाषित किया जा सकता है, और जब एक रचना के खिलाफ व्यवस्थापक आदेश चलाने की आवश्यकता होती है, तो -f साथ जोड़ा जाता है।

@dnephin # 1987 में समाधान command: /bin/true वर्कअराउंड का उपयोग करना होगा।

आपको कंपोज़ के साथ डेटा-ओनली कंटेनरों की आवश्यकता नहीं होनी चाहिए क्योंकि कंपोज़ आपके लिए फिर से बनाए गए कंटेनरों की स्वैपिंग को हैंडल करेगा।

@ cpuguy83 निम्नलिखित उदाहरण में डेटा कंटेनर वास्तव में आवश्यक नहीं है, लेकिन अगर मैं वॉल्यूम बदलना चाहता हूं, तो मुझे केवल एक निर्दिष्ट स्थान को देखना होगा।

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

हालांकि, मैं मानता हूं कि यह एक कोने का मामला है और अतिरिक्त सिंटैक्स जोड़ना संभवतः इसके लायक नहीं है। मैं सिर्फ यह कह रहा हूं कि प्रस्तावित समाधान इस मामले को संभालता नहीं है।

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

मैं नए संस्करणों के साथ पूरी तरह से अप-टू-डेट नहीं हूं जो एपीआई आ रहा है, लेकिन मेरी आशा है कि हम एक volumes: अनुभाग जोड़ पाएंगे जो डेटा वॉल्यूम को बेहतर तरीके से संभाल सकेगा (उनके लिए एक कंटेनर की आवश्यकता के बजाय)।

यह जरूरी नहीं कि यह सही विकल्प है, लेकिन मुझे लगता है कि सीखने की अवस्था / समझने में आसानी पर विचार किया जाना चाहिए।

मुझे ऐसा लगता है कि (2) समझाना सबसे आसान है। मेरे पास वास्तव में इस बात की पुष्टि करने का कोई तरीका नहीं है, लेकिन मेरे आंत के अधिकांश लोगों का कहना है कि वे सभी docker-compose विकल्पों से परिचित नहीं हैं जो उस समस्या में चलते हैं जिसे हम यहाँ हल करने का प्रयास कर रहे हैं, "काश, उस कंटेनर को _not start_ तक पहुंचने का कोई रास्ता होता, जब मैं docker-compose up चलता," और वे start: false और bam देखते हैं, हम कर रहे हैं और खुश हैं।

वे यह नहीं कहते हैं, "यदि केवल एक तरीका था तो मैं इसे हल करने के लिए एक अजीब लिंकिंग स्टोरी के साथ एक 2 डी फाइल बना सकता था ..." (मुझे पता चलता है कि https://github.com/docker/compose/issues/ 1987 # जारीकरण -139632238 "अजीब लिंकिंग स्टोरी," य?) के साथ मदद करता है।

(4) अस्पष्ट था, लेकिन स्क्रिप्ट के लिए रास्ते के लिए एक समर्पित एवेन्यू और इस तरह से एक-ऑफ्स यह "समझ में आता है" बिल।

आज मैं बिल्कुल (2) तलाश कर रहा था लेकिन अपने सबसे कम पसंदीदा समाधान, एक दूसरी YML फ़ाइल के साथ समाप्त हुआ। मेरा उपयोग मामला:

मेरे पास कुछ कंटेनर हैं और वे सभी समान mongo कंटेनर से लिंक हैं। मैं खुद को और टीम को मोंगो डेटाबेस में जुड़नार को लोड करने की क्षमता प्रदान करना चाहता हूं और मुझे लगा कि ऐसा करने का सबसे आसान तरीका mongo कंटेनर को एक अलग नाम fixtures तहत लोड करना है खुद को मोंगो से लिंक करें और फिर mongorestore --host mongo --port 27017 --drop /dump चलाएं। चूँकि हम सभी समय पर जुड़नार लोड नहीं करना चाहते हैं, start: false साथ ऐसा होना स्वाभाविक लगा लेकिन दोनों कंटेनरों के लिए एक अलग YML फ़ाइल fixtures और mongo ।

अच्छी तरह से काम करता है लेकिन start: false बहुत क्लीनर IMO है। अगर मेरे पास इस तथाकथित जुड़नार कंटेनर के 10 या अधिक क्रमपरिवर्तन होंगे, तो हाँ start: false एक बुरा विचार होगा और मैं (1) साथ जाऊंगा।

बस एक कंपोज़ फाइल बनानी थी जहाँ कुछ सेवाओं को docker-compose up -d कमांड के साथ निष्पादित नहीं किया जाना चाहिए। मेरे लिए विकल्प (2) मेरी समस्या का सबसे अच्छा समाधान होगा।

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

नमस्ते! यहाँ एक ही मुद्दा, खुशी है कि एक अच्छा समूहन मुद्दा है, महान काम!

मेरे मामले में मेरे पास सेवाओं के साथ कुछ कंटेनरों के साथ काम करने वाला अजगर ढेर है। सब कुछ ठीक काम कर रहा है, लेकिन मैंने अभी एक मामला स्टैक से बाहर पाया है। मैं बोवर के साथ स्थिर निर्भरता का प्रबंधन कर रहा हूं, और एक कंटेनर के अंदर बोवर कमांड चलाना चाहता हूं, यह सिर्फ एक स्क्रिप्ट है जिसे हम एक बार चलाते हैं।

हमारे पास इस संरचना को बनाने के लिए बहुत अच्छा होगा। मैं कुछ कल्पना करता हूं:
डॉक-कम्पोज़ रन नोड बोवर इंस्टॉल

इसलिए मुझे 4 वें विकल्प का 2 वां पसंद है। बस सेवा शुरू करने की आवश्यकता नहीं है, इसकी आवश्यकता नहीं है: पी

अगर कुछ सहमति है तो मैं "पुनः आरंभ" जैसी किसी चीज़ के लिए पुल-रीक भेजने की कोशिश कर सकता हूं
शुरू: हमेशा
शायद ... दुन्नो।

विकल्प 2 के लिए एक और वोट।

मैं विकल्प 2 को भी पसंद करूंगा। नए डॉकटर डेटा कंटेनरों को डॉकटर-कंपोज़ फ़ाइल में निर्दिष्ट किया जा सकता है लेकिन उनका उपयोग करने के लिए चलने की आवश्यकता नहीं है।

विकल्प 2 मेरे लिए भी

विकल्प 2 बहुत अच्छा होगा।

विकल्प 2 के लिए +1

विकल्प के लिए +1 2. कई फ़ाइलों को बनाए रखना और उनके नाम लिखना केवल समय बर्बाद करना है। एक एकल बूलियन ध्वज उन सभी पर राज करेगा। :बियर:

ऑप्ट 4 के लिए +1,
अगर मुझे एक दूसरा पसंदीदा चुनना होगा 2 ऑप्ट।

यह सच है कि सबसे अच्छा विकल्प 2,4 है अगर मैं दोनों को +1 कर सकता हूं, तो मैं क्या करूं अगर मैं बहुमत के साथ नहीं जा रहा हूं और 2 के लिए वोट करूं।

2 के लिए मतदान

2 और 4 दोनों के लिए अच्छा है।
2 के लिए +1

मुझे नहीं लगता कि कार्यों के लिए एक नई अवधारणा शुरू करना आवश्यक है। ये मेरी राय में बहुत अच्छी तरह से पढ़ते हैं और कई संशोधनों के बिना संभव हैं:

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

अलग कम्पोज़ फ़ाइल के साथ वर्तमान "समाधान" वास्तव में मेरी राय में समाधान नहीं है। जैसा कि @xaka ने कहा, कोई भी यह सब नहीं लिखना चाहता:

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

आपके साथ समाप्त होने वाला एक ./run-task स्क्रिप्ट है जो आपके लिए myTask से पहले सभी बॉयलरप्लेट जोड़ता है। लेकिन अब आपने अपने मल्टी-कंटेनर-ऐप में एक और एंट्रीपॉइंट और इंटरफ़ेस जोड़ा है। डेवलपर्स docker-compose.yml और सोचते हैं: _ "ओह महान, एक रचना ऐप। मुझे पता है कि इस चीज़ को कैसे संभालना है!" _ और अब आपको उन्हें बताना होगा: _ "सही है, आप इसे docker-compose साथ प्रबंधित कर सकते हैं।

start: false / up: false / some-additional-flag-to-a-service: false शायद लागू करने के लिए सबसे सरल बात है, लेकिन सबसे अधिक संभावना भी स्पष्ट और समझने में आसान है। और यह प्रयोज्यता में इतना सुधार करेगा।

@sherter ने क्या कहा। :ऊपरी तीर:

: +1: उसके लिए। अलग-अलग डॉकटराइल एक बड़ा दर्द है, खासकर जब नेटवर्क शामिल होते हैं

start: true|false दृष्टिकोण बहुत सीमित है। यदि परीक्षण के लिए कुछ सेवाओं का उपयोग किया जाता है, तो सामान्य संचालन के लिए कुछ अन्य और बाकी के लिए क्या होगा?

मैं सेवाओं में समूहीकरण की धारणा को जोड़ना पसंद करूंगा।

    myservice:
       group: `admin`

यदि group विशेषता को परिभाषित नहीं किया जाता है, तो default मान लिया जाता है।
इस तरह हम docker-compose up -g admin -d का उपयोग करके डिफ़ॉल्ट और व्यवस्थापक सेवाएँ शुरू कर सकते हैं।

बेहतर अभी तक, groups एक सरणी बनाते हैं।

सेवाओं के समूह-वर्ग बनाना ऐसा लगता है कि यह एक शक्तिशाली विशेषता होगी, लेकिन यह इस मुद्दे के लिए भी महत्वपूर्ण है।

डॉकटर-कम्पोज 2 संस्करण में , प्रत्येक कंटेनर को services: शीर्ष-स्तरीय-आइटम के अंदर घोषित किया गया है।
एक सेवा की घोषणा करना, स्क्रिप्ट चलाने के लिए start: never के साथ गलत लगता है।
इसलिए नए प्रारूप पर विचार करते हुए, क्या हमें _services_, _volumes_ और _networks_ के अलावा एक अतिरिक्त शीर्ष-स्तरीय आइटम की घोषणा नहीं करनी चाहिए?

मेरा प्रस्ताब:

• v2 में एक नया scripts: , transients: (या एक बेहतर नाम) शीर्ष स्तरीय आइटम जोड़ें।
• जैसा कि आप किसी भी सेवा के साथ करते हैं, उसके अंदर आप एक कंटेनर को परिभाषित कर सकते हैं
• एकमात्र अंतर यह है कि वे डिफ़ॉल्ट रूप से _start नहीं जा रहे हैं, क्योंकि वे केवल क्षणिक उपयोग के लिए अभिप्रेत हैं।

उदाहरण:

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

और फिर आप चला सकते हैं:

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

चिंताओं:

• यह लगता है कि OverPowered केवल प्रबंधन शुरू करने के उद्देश्य से एक और शीर्ष स्तर का आइटम बनाने के लिए है, लेकिन यह इस तथ्य से निकला है कि नया प्रारूप शीर्ष स्तर में व्यवहार की घोषणा कर रहा है।
• मैं अतिरिक्त लचीलेपन (और समस्याओं) की कल्पना करने की कोशिश कर रहा हूं।

अंत में, _groups फीचर_ पर, अच्छा लगता है, लेकिन अगर आपके पास बहुत से ग्रुपिंग हैं, तो मुझे उनमें से हर एक के लिए डॉकटर-कंपोज फाइल बनाने में समस्या नहीं दिखती है। संभवतः जो सुविधा आप चाहते हैं वह डॉकटर-कंपोज़ फाइल इनहेरिटेंस है , जो कमाल की होगी!

PD: @bfirsh शायद अगर आपको यह विचार पसंद आया तो आप इसे "संभावित सुझाव" में जोड़ सकते हैं

दूसरे पर हालांकि यह आसन्न नए प्रारूप की घोषणा करने के कारण 4 वें सुझाव का एक सुधार है।

विकल्प 2 के लिए मतदान: स्पष्ट, पढ़ने में आसान, और नई अवधारणाओं को सीखने की आवश्यकता नहीं है
बस एक ऐसी सेवा चाहते हैं जो डिफ़ॉल्ट रूप से शुरू न हो

disabled: true जैसी किसी चीज़ के बारे में क्या

@ cpuguy83 ऐसा लगता है कि पूरी सेवा अक्षम है, यहां तक ​​कि run । मुझे यह भ्रामक लगेगा।

@qcho हम्म, अब जब मैंने 1.6 के बाद से खुद को डॉकटर के साथ फिर से पहचान लिया है, तो मैं देख सकता हूं कि आप और @gittycat क्या बात कर रहे हैं। उस अर्थ में, मुझे वास्तव में @gittycat का दृष्टिकोण पसंद है। मैं चित्र (नीला आकाश) जैसा इंटरफ़ेस:

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

इस बीच, खोल में ...

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

इस तरह से एक दृष्टिकोण भयानक होगा और इस टिकट की आवश्यकता को कम करेगा, लेकिन इसके दायरे से बाहर जाता है।

@kojiromike मुझे ऐसा नहीं लगता। यह है कि init सिस्टम उन सेवाओं को संदर्भित करता है जो अपने आप शुरू नहीं होनी चाहिए।

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

@ cpuguy83 मुझे लगता है कि "सेवाओं" का शब्दार्थ वास्तव में वही है जो पहले स्थान पर भ्रमित है। मैं इस बात से सहमत हूं कि समूहीकरण की गुंजाइश गुंजाइश है। इस अर्थ में मैं विकल्प 4 / @qcho के दृष्टिकोण को पसंद करता हूँ, जहाँ वे "सेवाओं से नहीं" सेवाओं से "सेवाओं" को स्पष्ट रूप से अलग करते हैं।

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

हो सकता है कि प्रारूप के "संस्करण 2" को इस मुद्दे को ध्यान में रखना चाहिए। उदाहरण के लिए एक और कल्पना हो सकती है

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

ठीक है अब हमारे पास समुचित सेवाएं हैं, समूह परिभाषा के साथ। मैं उत्पादन या विकास सेवा समूह शुरू कर सकता हूं। या बस some_script_container में स्क्रिप्ट चलाएं। चूंकि यह किसी भी सेवा में परिभाषित नहीं है, किसी को भी शुरू नहीं किया जाएगा

@qcho एक सेवा की परिभाषा पर निर्भर करता है, लेकिन किसी भी मामले में - मैं सवाल में कुछ कहता हूं जिसे केवल अवसर पर चलाया जाना चाहिए, और केवल एक मानव यह निर्धारित कर सकता है कि इसे चलाया जाना चाहिए या नहीं।

तो चलिए हम कहते हैं कि कुछ job ऑब्जेक्ट की तरह कुछ अपनाएं।

1. नौकरियां केवल एक बार चलती हैं
2. सेवाओं के बाद नौकरी मिलने लगी है
3. नौकरियों से बाहर निकलने की उम्मीद है
4. ???

अब रचना को नौकरी के बारे में कुछ स्थानीय स्थिति रखने की आवश्यकता है, जो वर्तमान में बिल्कुल नहीं है।

यही कारण है कि इसे संभालने के लिए एक सरल auto-up: false या autorun: false सबसे आसान और कम डरावना (स्कोपाइज़) तरीका है।

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

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

मैं यह नहीं देखता कि लोग ऐसा क्यों कहते रहते हैं

services:
  my-script-container:
    auto-up:false

से सरल है:

scripts/containers/transients/you_name_it:
  my-script-container:

यह जटिलता का समान स्तर है। लेकिन शब्दार्थ में कम है।

विचारों को एक धागे पर लाने के लिए, # 2803 का संदर्भ लें

मामले का उपयोग करें: आपके पास कई घटकों और उपयोगकर्ताओं के साथ एक परियोजना है जिसे चुनना है और जिसे स्थापित करना है लेकिन वह रचना करता है फ़ाइल उन सभी को स्थापित करता है।

प्रस्ताव: हम docker-cmpose.overrider.yml में int डाल करने के लिए एक विकल्प जोड़ते हैं। docker.com में परिभाषित छवि को बाहर करने के लिए।

अर्थात

कुछ छवि:
बहिष्कृत: हाँ

व्यवहार को डॉकटर-कंपोज़.माइल में उस प्रविष्टि को अनदेखा करना होगा

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

# 2 के लिए भी वोटिंग ... बस आज इस जरूरत में भाग गया।

@jimzucker का प्रस्ताव भी काम करेगा, हालाँकि मुझे मुख्य .yaml में "start: false" देखने के बारे में सोचा गया है। आपको तुरंत इस बात का सुराग लगाना होगा कि यह 'सेवा' तब तक नहीं चलेगी जब तक आप इसे स्पष्ट रूप से नहीं बुलाते। अन्यथा आप (या मेरे मामले में एंड-यूज़र / डेवलपर जिसे आपने डॉकटर-कंपोज़ फाइल सौंपी थी) को ओवरराइड फ़ाइल देखने के लिए याद रखने की आवश्यकता है।

+1 के लिए 2. मेरे पास एक ऐसी स्थिति है जहां मुझे रचना के हिस्से के रूप में एक डॉकटर छवि बनाने की आवश्यकता है लेकिन यह एक सेवा के रूप में नहीं चलती है। अन्य सेवाएं (जिनके अंदर docker sock माउंट है) इमेज से कंटेनरों को हर बार चलाते हैं।

+1 के लिए 2 और "ऑटो-अप" या "ऑटो-रन" के शब्दों के लिए +1।

और सेवाओं के समूहों के लिए मामलों (जैसा @gittycat द्वारा समझाया गया है) को पर्यावरण चर "ऑटो-अप: $ {ADMIN}" के माध्यम से नियंत्रित नहीं किया जा सकता है?

मैं docker-compose.yml में सेवाओं को चिह्नित करने के लिए वास्तविक उपयोग के मामलों को भी देखता हूं जो कि स्वचालित रूप से एक सरल docker-compose up साथ शुरू नहीं किए जाते हैं, बल्कि केवल स्पष्ट रूप से शुरू किए जाते हैं।

समाधान 1) अब एक संभव तरीका है, लेकिन मेरी राय में भी बोझिल है क्योंकि एक को केवल docker-compose up कॉल करने और फ़ाइलों को विभाजित या डुप्लिकेट करने के बजाय एक या एक से अधिक yml फ़ाइलों को निर्दिष्ट करना पड़ता है।

चूँकि मैं वास्तव में समाधान 2 जैसा कुछ देखना चाहता हूं) (जैसा कि कई अन्य लोग भी करते हैं) मैंने # 3047 में इस बात का एक सबूत लागू किया है ताकि आप इसके साथ थोड़ा सा खेल सकें कि क्या यह एक व्यवहार्य हो सकता है उपाय।

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

दोनों विकल्पों 2 और 4 के लिए +1

विकल्प 2 और 4 के लिए +1

विकल्प के लिए +1 4. स्क्रिप्ट के लिए कुछ कॉन्फ़िगरेशन की अनुमति नहीं दी जानी चाहिए (जैसे: पुनरारंभ: हमेशा)

विकल्प 2 के साथ, यह अजीब मामला हो सकता है:

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

इसका क्या मतलब होगा?

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

@ ओंको ओह ठीक है, मुझे पोस्टिंग से पहले थोड़ी देर के बारे में सोचना चाहिए ...

विकल्प 2 के लिए मेरे "वोट" को +1 में बदलना

विकल्प 2 के लिए +1, मुझे कई परियोजनाओं में इसकी आवश्यकता है।

pinging @bfirsh @dnephin :
क्या आप इस मुद्दे के बारे में अपडेट दे सकते हैं? चूंकि यहां अधिकांश टिप्पणियां विकल्प 2 के पक्ष में हैं, क्या वर्तमान में ऐसा कुछ लागू करने की कोई योजना है (या विकल्प 3/4)?
मैं अपने पुल अनुरोध (# 3047) को पॉलिश कर सकता हूं और इसे परीक्षण और प्रलेखन के साथ पूरा कर सकता हूं यदि आप इसे विलय करना चाहते हैं।

धन्यवाद।

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

मुझे लगता है कि विकल्प 1 काम कर सकता है, लेकिन हमें निम्नलिखित क्रियाओं को कम करने के लिए एक बेहतर तरीका चाहिए:

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

शायद एक सरलीकृत / वृद्धि ध्वज जोड़ सकता है? docker-compose --augment tests up और यदि यह docker-compose.yml की भिन्नता है तो स्वचालित रूप से हल होता है - अन्यथा उपयोगकर्ता को स्पष्ट होने की आवश्यकता होगी।

मैं वास्तव में एक नए शीर्ष स्तर के कीवर्ड का विचार पसंद करता हूं, शायद suites और commands ?

निम्नलिखित कॉन्फ़िगरेशन इसके लिए अनुमति देगा:

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

मैं कोड में देख सकता हूं कि पहले से ही "वनऑफ" सेवाओं की धारणा है (आईएमएचओ केवल तब उपयोग किया जाता है जब docker-compose run कहा जाता है।
क्या इसका फिर से उपयोग किया जा सकता है?
अगर मैं एक कंटेनर को com.docker.compose.oneoff=True साथ लेबल करूं, तो क्या वह इसे शुरू करने की कोशिश करेगा?

अन्यथा, मैं विकल्प 2 के लिए मतदान करता हूं।

मैं बस इस पर ठोकर खाई, इसलिए यहां मेरे दो उपयोग मामले हैं:

1. "वैश्विक" पर्यावरण चर: यहाँ सुझाया गया दृष्टिकोण extends , जो कि मैं ठीक हूँ ... लेकिन अब मुझे उस चीज़ के लिए image परिभाषित करने की आवश्यकता है जो मैं यहाँ से निकाल रहा हूँ। , और scratch उपयोग नहीं कर सकते (इसलिए https://hub.docker.com/r/tianon/true/) के साथ समाप्त हुआ।
2. "स्केलिंग" सेवाएं: डिफ़ॉल्ट रूप से मेरे पास एक MongoDB उदाहरण है, लेकिन कुछ परीक्षणों के लिए मैं एक दूसरे निष्क्रिय को परिभाषित करना चाहूंगा, जिसे मैं उन परीक्षणों के लिए ला सकता हूं। यहां एक अलग फ़ाइल में extends का उपयोग करना एक व्यवहार्य विचार जैसा लगता है (अभी भी docker / docker-compose और शामिल सर्वोत्तम प्रथाओं के बारे में सीख रहा है)।

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1
एक साधारण परिवर्तन की तरह लगता है ...

+1 विकल्प 2,

कई कंटेनरों के उपयोग मामले में envs का एक सामान्य सेट साझा करने और इसे कॉन्फ़िगर करने से समझ में आता है कि आधार कंटेनर बनाने के लिए विस्तार करना है लेकिन वास्तव में कंटेनर को शुरू करने के लिए नहीं।

auto-start:true|false

पिछले साल सितंबर से रॉकर-कम्पोज नामक एक अच्छा समाधान होने के बाद, मैं चलाने की सलाह दूंगा: _always_ | _once_ | _कभी नहीँ_। मुझे भी राज्य पसंद है: _running_ | _ran_ | _created_ भी।

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

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

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

मेरे मामले में state: created ( state: ran (भागना = 1 गुना) के बीच का अंतर महत्वपूर्ण है क्योंकि उपयोगिता / व्यवस्थापक कार्यों में से कुछ विनाशकारी हो सकते हैं और केवल उनका उपयोग किया जाना है प्रवासन सेवाओं जैसी कुछ परिस्थितियों में।

यह देखते हुए कि मैं अब state: running | ran | created ओर बढ़ रहा हूं, जैसा कि शीर्ष-स्तर _task_ या _job_ ऑब्जेक्ट + क्षमता के साथ शीर्ष-स्तर_ विकल्प 4 में निर्भरता व्यक्त करने के लिए है ताकि कोई सेवा कार्य चलाने से पहले या उसके बाद ही चल सके। ।

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

यह कुछ करने में सक्षम होने के लिए बेहतर होगा:

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

आप कल्पना कर सकते हैं कि sleep 5 अधिक sleep 5 लिखा जा सकता है यह सत्यापित करने के लिए लिखा जा सकता है कि क्या हुआ है, लेकिन यह उदाहरण स्निपेट के लिए आवश्यक नहीं है।

मैंने एक ध्वज ध्वज के बारे में एक विकल्प नहीं पढ़ा। इसलिए मैं एक --exclude का प्रस्ताव करूंगा --exclude ध्वज up कमांड निर्दिष्ट कंटेनर को शुरू नहीं करने के लिए कहेंगे। --exclude ध्वज को ऐसे पार्स किया जाएगा कि कई कंटेनरों को आवश्यक रूप से स्टार्ट अप से बाहर रखा जा सके।

: +1:

एक अन्य उपयोग मामले के साथ वजन जहां विकल्प 2 एक उपयुक्त समाधान होगा: एक मौजूदा एप्लिकेशन के भीतर एक नए उप-सेवा पर पुनरावृत्ति। परियोजना के अधिकांश डेवलपर्स को अभी तक नई सेवा की आवश्यकता नहीं है, और आप निश्चित रूप से इसके काम में बाधा डालने वाली समस्याओं को नहीं चाहते हैं, लेकिन आप विस्तारित अवधि के लिए आउट-ऑफ-ट्री शाखा को बनाए रखने से भी बचना चाह सकते हैं। समय।

एक अलग "docker-compose-प्रयोगात्मक.yml" फ़ाइल _could_ काम करती है, लेकिन इसका मतलब है कि घटक पर काम करने के लिए सभी दस्तावेज़ीकरण को एक तरह से लिखा जाना चाहिए, जबकि घटक अभी भी प्रयोगात्मक है, और फिर एक बार यह मानक सेट का हिस्सा बन जाता है। सेवाओं की।

+1 से विकल्प 2

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

@acran मैं देखना चाहूंगा कि आप अपना पुल अनुरोध सबमिट करें और देखें कि क्या हम कुछ ट्रैक्शन को आगे बढ़ा सकते हैं, हो सकता है कि यदि आप # 3047 पर संघर्ष को खत्म करने के लिए

@jimzucker अच्छी तरह से # 3047 पहले से ही एक पुल अनुरोध है और मैं अभी भी

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

+1 विकल्प 2

@acran , मैं संबंधित डॉक्स और परीक्षण मामलों को अद्यतन करने में आपकी मदद करना चाहूंगा। ठीक है न ?

+1 विकल्प 2

या शायद एक तरह की नौकरी को परिभाषित करें, जैसे कुबेरनेट्स में?

विकल्प 2 के लिए +1

हमारे पास कई सेवाओं के साथ एक डॉकटर-कंपोज है और उनमें से एक (डेटाबेस) को विकास पर्यावरण पर लॉन्च किया जाना चाहिए, लेकिन उत्पादन वातावरण पर नहीं। इसलिए, हमें दो डॉकटर-कम्पोज़ किए गए फ़ाइलों को बनाए रखना होगा। विकल्प 2 वास्तव में वही है जो हम खोज रहे हैं!

: +1: विकल्प 2 के लिए

+1 विकल्प 2

@acran मैं एसएफ में कुछ कनेक्ट के लिए यहां पहुंच रहा हूं ताकि फीडबैक पाने के लिए सही प्रक्रिया / चैनल का पता लगाया जा सके ताकि यह आगे बढ़ सके, देखते रहें;)

विकल्प 2 के लिए 2

विकल्प 2 के लिए +1

+1 विकल्प 2

+1 विकल्प 2

इसके अलावा मैं विकल्प 2 के लिए मतदान कर रहा हूं

एक और विचार: अब हमारे पास शीर्ष-स्तरीय networks और volumes , हम images विकल्प भी जोड़ सकते हैं। यह एक संकेत होगा कि इन छवियों को काम करने के लिए आवेदन के लिए खींचना या बनाया जाना है, लेकिन जब आप docker-compose up करते हैं तो उन्हें चलाया नहीं जाएगा।

यह दो उपयोग-मामलों के लिए काम करेगा, मेरे सिर के ऊपर से:

1) यहां आम समस्या है, जहां आप चाहते हैं कि किसी प्रकार की प्रबंधन कमांड चले। यदि सेवा मौजूद नहीं है तो docker-compose run चल रही छवियों पर वापस आ सकती है।
2) इस तरह के ऐप्स जो डॉकर छवियों को चलाते हैं लेकिन वे हर समय नहीं चल रहे हैं।

/ cc @dnephin @aanand @

सिवाय इसके कि सभी विकल्पों को कॉन्फ़िगर करने में सक्षम होना अच्छा होगा, एक शॉर्ट-टर्म कंटेनर की आवश्यकता होगी (यानी वॉल्यूम / माउंट पॉइंट, नेटवर्क, लिंक, नाम, आदि) डॉक-कंपोज़ फ़ाइल में ताकि आपको न हो हर बार आपको उस कंटेनर को चलाने के लिए उन्हें जोड़ते रहना होगा ...

13 सितंबर, 2016 3:58:41 पूर्वाह्न सीडीटी, बेन फ़रमान सूचनाएँ @ithub.com ने लिखा:

एक और विचार: अब हमारे पास शीर्ष-स्तरीय networks और volumes , हम कर सकते हैं
एक images विकल्प भी जोड़ें। यह एक संकेत होगा कि यह लिखें
छवियों को काम करने के लिए आवेदन के लिए खींच या बनाया जाना चाहिए, लेकिन वे
जब आप docker-compose up करते हैं तो चलाया नहीं जाएगा।

यह दो उपयोग-मामलों के लिए काम करेगा, मेरे सिर के ऊपर से:

1) यहाँ आम समस्या है, जहाँ आप किसी प्रकार का प्रबंधन चाहते हैं
चलाने की आज्ञा। docker-compose run चल चित्र में वापस आ सकते हैं
यदि सेवा मौजूद नहीं है।
2) ऐप्स पसंद हैंयह जो चलता है
डॉकर चित्र लेकिन वे हर समय नहीं चल रहे हैं।

/ cc @dnephin @aanand @

आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें:
https://github.com/docker/compose/issues/1896#issuecomment -246618909

K-9 मेल के साथ मेरे Android डिवाइस से भेजा गया। मेरे संक्षिप्तता को माफ़ करो।

मैं इस पर @mgriego से सहमत हूं। बिल्ड जेनरेट करने वाले कंटेनर के बारे में सोचें - यह सबसे अच्छा होगा कि कमांड और ऑप्शन्स सेट अप करें और सिर्फ docker-compose up foo और इसे बिल्ड और एक्जिट करें।

यहां अधिक समझ प्राप्त करने की कोशिश कर रहा है: क्या विकल्प 2) अधिक सामान्य का केवल एक विशेष मामला है "हम initial_scale मूल्य docker-compose.yml " में चाहते हैं? (# 1661, # 2496 एट अल देखें।)

@ankon बिल्कुल नहीं।

एक images [अनुभाग जोड़ें]

@bfirsh यह उस दिशा में बढ़ना शुरू करता है जो मैंने https://github.com/dnephin/dobi के साथ लिया था

1. networks और volumes वास्तव में कभी भी सीधे संचालित नहीं होते हैं, वे सिर्फ एक कंटेनर द्वारा आवश्यकतानुसार बनाए जाते हैं। अपने स्वयं के अनुभाग में छवियों को विभाजित करने से अब हमारे द्वारा किए जाने वाले व्यवहार में बदलाव नहीं होगा, यह सिर्फ कंपोज़ कॉन्फिग को और अधिक जटिल बना देगा। यदि आप केवल एक छवि बनाना चाहते हैं, तो docker-compose build चलाएं।
2. मुझे नहीं लगता कि यह वास्तव में इस समस्या में पहचानी गई समस्याओं को ठीक करता है। लोग कंटेनर चाहते हैं, न कि केवल छवि

थ्रेड को फिर से पढ़ना और # 2496 में कम्पोज़ फाइल में स्केलिंग बाधाओं की घोषणा के बारे में चर्चा करना, मैं विकल्प 2 के ऊपर विकल्प 4 (यानी एक नया शीर्ष-स्तरीय अनुभाग) को प्राथमिकता देने के लिए आ रहा हूं।

विशेष रूप से, utilities जैसे एक सेक्शन का नाम एक अच्छा फिट होगा: ऐसे घटक जो सामान्य रूप से आवश्यक नहीं होते हैं, लेकिन जब आपको उनकी आवश्यकता होती है, तो आप पूर्व-निर्धारित करना चाहते हैं कि वे कौन से अन्य घटक हैं जिनके बजाय वे जुड़े हुए हैं लोगों को एक उपयुक्त docker run स्वयं का निर्माण करने के लिए प्राप्त करें।

यह दृष्टिकोण तब न केवल एक-ऑफ एडमिन कमांड को कवर करेगा, बल्कि pgweb और सेलेरी फ्लावर जैसी सहायक डिबगिंग और आत्मनिरीक्षण सेवाएं (जो विकास में बहुत आसान है, लेकिन आप अतिरिक्त सुरक्षा के कारण उत्पादन में नहीं चाहेंगे। खतरा सतह क्षेत्र जो वे बनाते हैं)।

इन नए "नहीं सेवाओं" के शब्दार्थ को परिभाषित करना भी बहुत आसान हो जाता है: वे _exactly_ services (उस प्रारूप में सभी भविष्य के परिवर्तनों सहित) के समान हैं, एकमात्र अपवाद के साथ, जो कि docker-compose build तरह अयोग्य आदेश हैं। docker-compose pull , और docker-compose up उन्हें पूरी तरह से अनदेखा करें - यदि आप चाहते हैं कि "सेवाओं" के बजाय "उपयोगिताओं" में सूचीबद्ध किसी भी घटक को संसाधित किया जाए, तो आपको इसे विशेष रूप से नाम देना होगा (हालांकि वहां शायद एक हो सकता है --all विकल्प, के लिए वर्तमान के समान docker-compose rm )। हालाँकि, नाम से इन उपयोगिताओं के साथ बातचीत करने के लिए सीएलआई सामान्य सेवाओं (यथास्थिति के विपरीत, जहाँ आपको अतिरिक्त उपयोगिता कॉन्फिगर फ़ाइल निर्दिष्ट करने की आवश्यकता है) के साथ बातचीत करने के लिए समान होगा, और डॉकटर-कंपोज़ नाम विवादों को रोकने का ध्यान रखेगा। सेवा और उपयोगिता परिभाषाओं के बीच।

हालांकि # 2496 में स्केलिंग प्रस्ताव संभवतः इस व्यवहार को प्राप्त करने के लिए इस्तेमाल किया जा सकता है, यह अभी भी ठीक से डिज़ाइन की गई सुविधा के बजाय एक वर्कअराउंड की तरह महसूस करता है।

मुझे वह डिज़ाइन पसंद है, @ncoghlan।

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

मुझे मूल विचार पसंद है @ncoghlan वहां के बारे में बात करता है, लेकिन ...

1. सहमत न हों कि _all_ अयोग्य आदेशों को इन उपयोगिताओं को डिफ़ॉल्ट रूप से अनदेखा करना चाहिए। मेरी राय में, सभी आदेशों को सामान्य रूप से चलना चाहिए, सिवाय इसके कि एक चालू कंटेनर में परिणाम होगा। (इसलिए मूल रूप से, up और start ।)
2. @Dsem की टिप्पणी के बारे में, मुझे '

@bfirsh @ncoghlan मैं पूरी तरह से हूँ :

मुझे नहीं लगता कि यह वास्तव में इस समस्या में पहचानी गई समस्याओं को ठीक करता है। लोग कंटेनर चाहते हैं, न कि केवल छवि

क्या मैं - और मुझे लगता है कि यहां ज्यादातर लोग - मेरे वांछित वर्कफ़्लो के लिए आवश्यक सरल सेवाएं हैं; वे किसी भी सामान्य सेवा की तरह परिभाषित होते हैं, वे सामान्य सेवाओं की तरह शुरू / बंद हो जाते हैं।
_Only_ अंतर यह है कि वे स्वचालित रूप से डिफ़ॉल्ट रूप से एक सरल docker-compose up द्वारा शुरू नहीं किए जाते हैं, लेकिन केवल जब स्पष्ट रूप से निर्दिष्ट किए जाते हैं (या एक निर्भरता के रूप में खींचा जाता है)।

इसलिए मुझे एक नए शीर्ष-स्तरीय खंड या इन एक-बंद कंटेनरों के लिए पूरी तरह से नई अवधारणा के लिए कोई आवश्यकता नहीं दिखती है, लेकिन केवल एक वैकल्पिक प्रति विन्यास पैरामीटर।
मैंने इसे अवधारणा के प्रमाण के रूप में अपने अनुरोध # 3047 में लागू किया। यह काफी छोटा बदलाव है लेकिन मेरे उपयोग-मामलों को पूरी तरह से संतुष्ट करेगा। इसलिए यदि इस विलय को प्राप्त करने के लिए मैं कुछ और कर सकता हूं, तो कृपया मुझे बताएं (=

जो कोई भी इसका परीक्षण करना चाहता है, उसके लिए यहां एक कंटेनर में डॉकटर-कंपोज़ बनाने और चलाने की आज्ञा है:

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran , मैं संबंधित डॉक्स और परीक्षण मामलों को अद्यतन करने में आपकी मदद करना चाहूंगा। ठीक है न ?

@ dattran-vn01 बेशक, मुझे खुशी होगी: स्माइली:

@acran आपके उदाहरण में वर्तमान कमांड से अलग व्यवहार वाला एकमात्र कमांड पहला है, और उस व्यवहार को up baz का उपयोग करके पूरा किया जा सकता है।
आप कई कंपोज़ फ़ाइलों का उपयोग करके एक ही चीज़ को पूरा कर सकते हैं।

डिफॉल्ट सेवाओं की एक अलग सूची में कुछ कमांड संचालित होने से यह बहुत ही भ्रामक लगता है, और यह एक कारण है कि मुझे यह सुविधा पसंद नहीं है।

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

@dnephin हाँ, बिल्कुल, मुझे पता है, और इस उदाहरण में यह सबसे आसान तरीका होगा।
लेकिन 10 सेवाओं और केवल एक वन-ऑफ सेवा (जैसे "इनिट" या "बैकअप" / "डंप") के साथ इसकी कल्पना करें: उस स्थिति में आपको कमांड लाइन पर सभी सेवाओं को सूचीबद्ध करना होगा, सिवाय इसके कि एक सिंगल- docker-compose up service1 service2 ... service10 (नीचे देखें) जैसी सेवा बंद। विशेष रूप से आपको सभी सेवाओं को याद रखना होगा और docker-compose.yml में किसी भी परिवर्तन का मैन्युअल रूप से ध्यान रखना होगा।

मैं कई YAML फ़ाइलों का उपयोग करने की संभावना के बारे में भी जानता हूं ,

यहाँ एक और उदाहरण docker-compose.yml समस्या की कल्पना करने के लिए:

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

एक साधारण docker-compose up _with_ auto_up विशेषता सेवा init को छोड़कर सभी सेवाओं को यहाँ शुरू करती है। बिना इसे प्राप्त करने के लिए 10 सेवाओं के साथ एक बहुत लंबी कमांड टाइप करने या YAML फाइल को विभाजित करने और कई फाइलों को निर्दिष्ट करने की आवश्यकता होगी।

इसलिए यहां मांगी गई सुविधा, cli पर कम सुविधा और टाइपिंग के बारे में अधिक है और पूरी तरह से नई सुविधा के बारे में नहीं है।

"कई कॉन्फिगर फाइल का उपयोग करें" विकल्प के बारे में (जो वास्तव में वर्तमान में उपलब्ध सबसे अच्छा विकल्प है), इसके साथ प्रयोज्य समस्या यह है कि यह व्यवहार में ऐसा दिखता है:

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

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

यह सब _doable_ है, यह कंपोज़ फाइल में कहने में सक्षम होने की तुलना में बस कष्टप्रद है "केवल इसे चलाएं जब मैं आपसे स्पष्ट रूप से पूछूं, इसे डिफ़ॉल्ट रूप से कभी न चलाएं"।

किसी ने एक बार मुझसे कहा था: _ "यदि कई स्मार्ट लोग यह तय नहीं कर सकते कि कौन सा दृष्टिकोण सबसे अच्छा है, आमतौर पर न तो बहुत बुरा है। सबसे बुरा कुछ भी नहीं है।" _

यह कार्ड इस का एक प्रमुख उदाहरण की तरह लगता है :)

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

मेरे सेटअप में, मेरे पास डॉकटर-कंपोज़ में सेवाएँ हैं जो मेरे बुनियादी ढांचे (nginx, database, webserver, message queues ...) को चलाने के लिए आवश्यक हैं। मैंने अतिरिक्त सेवाओं को भी परिभाषित किया है जो मुझे केवल डिबगिंग कारणों के लिए चाहिए (उदाहरण के लिए एक डेटाबेस वेब गुई)।

मैं "डिबगिंग" सेवाओं को स्वचालित रूप से शुरू नहीं करना चाहूंगा, लेकिन अगर मैं उन्हें जोड़ना चाहता हूं तो मैं एक सरल docker-compose up -d database-gui साथ ऐसा कर सकता हूं और यह बस जुड़ जाता है।

इसके अलावा: कभी-कभी मैं अपना दिमाग बदल देता हूं और चाहता हूं कि इनमें से एक सेवा हमेशा शुरू हो ... => विकल्प 2 के साथ) मैं बस उस एक झंडे को बदल सकता हूं

=> विकल्प दो के लिए वोट करें, क्योंकि यह सरल है और यह यहां सभी की आवश्यकताओं को पूरा करता है। हर दूसरा समाधान मुझे ओवर-इंजीनियरिंग की तरह लगता है ... दुर्लभ या केवल कल्पना किए गए उपयोग मामलों के आधार पर कॉन्फ़िगरेशन में जटिलता को जोड़ना, न कि व्यावहारिक आवश्यकता पर।

बस यहाँ मेरा +1 जोड़ने के लिए। मैं Django ऐप्स पर चल रहा हूं और जब उन्हें डॉक में चलाया जा रहा है तो एक कंटेनर होना अच्छा होगा जो शेल या परीक्षण चलाएगा या उस मामले के लिए कमांड को माइग्रेट करेगा। लेकिन मैं हर बार ऐप शुरू करने के बाद इनमें से कोई भी नहीं चलाना चाहता। एकाधिक कॉन्फिगर फ़ाइलों का उपयोग करते समय, यह टाइपिंग, स्क्रिप्टिंग या अन्य लंबी मील लाइनों को अलियासिंग करने की आवश्यकता होगी। अगर मैं ऐसा करना चाहता था कि मैं कंपोज़ का इस्तेमाल नहीं करूंगा, तो मैं सिर्फ अपने कंटेनर (या पाइथन स्क्रिप्ट उन्हें) खोल दूंगा ... हो सकता है कि कंटेनर कॉन्फ़िगरेशन को स्टोर करने के लिए एक एकीकृत YAML फ़ाइल जोड़ें ... प्रतीक्षा करें ... मैं डॉन मेरे कंटेनर पर डेटाबेस माइग्रेशन चलाने के लिए docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate जैसा कुछ भी नहीं करना चाहते हैं। विकल्प /bin/true कमांड के रूप में उपयोग करना है और docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate' कुछ ऐसा करना है जो या तो सुरुचिपूर्ण नहीं है। इसलिए विन्यास में कहीं एक समय संग्रहित किया जाना मेरे लिए बहुत उपयोगी होगा। विकल्प 2, 3 और 4 में से कोई भी मेरे लिए काम करेगा।

मैं आपको सुझाव देना चाहता हूं कि आप dobi पर एक नज़र

रचना लंबे समय से चलने वाली सेवाओं को शुरू करने के लिए डिज़ाइन की गई है जो "पर्यावरण" बनाती हैं।
dobi अनुक्रमिक प्रोजेक्ट बिल्ड टैक पर केंद्रित है।

जिन चीजों की आप तलाश कर रहे हैं (शेल चलाना, यूनिट टेस्ट चलाना, माइग्रेशन चलाना) सभी प्रोजेक्ट कार्य हैं, इसलिए वे डॉबी मॉडल में बहुत बेहतर हैं।

dobi और कम्पोज़ का काम एक साथ करना, आप एक कम्पोज़ रिसोर्स का उपयोग करके dobi से कम्पोज़ लॉन्च कर सकते हैं।

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

जिसे आप उपयोग करके चला सकते हैं:

dobi dev-environment

यहां कंपोज़ इंटीग्रेशन और रनिंग डीबी माइग्रेशन का एक उदाहरण है: https://github.com/dnephin/dobi/tree/master/examples/init-db-with-rails

वर्कफ़्लोज़ के कई उदाहरण हैं (जिनमें परीक्षण चलाना, एक इंटरैक्टिव शेल शुरू करना, रिलीज़ करना और न्यूनतम चित्र बनाना) यहाँ हैं: http://dnephin.github.io/dobi/examples.html

2 के लिए +1)। हमारे दृष्टिकोण में, एक-बंद आदेशों की तरह असामान्य usecases के बारे में सोचना और चर्चा करना अनावश्यक है, लेकिन हम केवल वास्तविक सेवाओं को बनाना चाहते हैं और उपयोग के लिए तैयार हैं, लेकिन आवश्यकता होने पर मांग शुरू की जा सकती है (और डिफ़ॉल्ट उपभोग नहीं करते हैं) संसाधन)।

"असामान्य usecases"? क्या आप डेटाबेस माइग्रेशन चलाते हैं? क्या आप इकाई परीक्षण चलाते हैं? क्या आप लिंट चलाते हैं? webpack?

हां, मैं दौड़ता हूं, लेकिन मेरी राय में कंटेनरों के अंदर इसे हासिल और नियंत्रित किया जा सकता है। लेकिन मैं आपके विचार या मांगों को कम नहीं करना चाहता हूं, आइए इस चर्चा को तेज न करें। आवश्यक रूप से डॉकटर रचना पर हमारी आवश्यकताएं संघर्ष में नहीं हैं।

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

उन्हें कार्य, आज्ञा, जो भी कहें, लेकिन मैं थोड़े इसके बिना SOL हूं।

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

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

वॉल्यूम डेटा का बैक-अप करने में सक्षम होने के लिए, हमने आवश्यक डेटा को टारगेट करने के लिए एक बिजीबॉक्स कंटेनर के साथ जाने का निर्णय लिया, लेकिन इसे लचीला होना चाहिए और केवल वही वॉल्यूम करना चाहिए जो डेवलपर्स बैक-अप चाहते हैं। अंत में, हमें हर वॉल्यूम को अलग से बैक-अप करने में सक्षम होना चाहिए। इसे प्राप्त करने के लिए, हमने अपने सभी docker-compose.yml में 3 सेवाओं को जोड़ा

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

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

यह यहाँ छोटे हैक्स से भरा है, लेकिन हमें आसानी से docker-compose up backup चलाने की अनुमति देता है, ताकि हम अपने बैकअप को होस्ट के / बैकअप / नवीनतम पर संग्रहीत कर सकें और वहाँ से हम अपना वर्जनिंग / प्रूनिंग लॉजिक चला सकें।

मुझे आशा है कि यह किसी ऐसे व्यक्ति को प्राप्त करने में मदद कर रहा है जो ... कुछ ऐसा ही करने की कोशिश कर रहा है, लेकिन अंत में, केवल उन 2 सेवाओं को बूट नहीं करने के लिए docker- रचना करने में सक्षम होने के नाते, हमें एक 3 की आवश्यकता नहीं होगी और हमारे docker-compose को जटिल करना होगा आदेशों।

विकास में, हमारे पास वर्तमान में 4 डॉकटर-कंपोज्ड फाइलें हैं:

• docker-compose.yml : हमारे ऐप को पूरी तरह से संचालित करने के लिए आवश्यक कोर सेवाओं को परिभाषित करता है, जैसे कि redis, MySQL, php-fpm, Laravel कतार प्रोसेसर, nginx, Solr
• docker-compose-utils.yml : देव कार्यों को चलाने के लिए आवश्यक उपयोगिता सेवाओं को परिभाषित करता है, जैसे gulp, npm, कारीगर (Laravel), संगीतकार, रेडिस-क्ली, आमतौर पर उपरोक्त सेवाओं के साथ चलते हैं
• ऊपर की सेवाओं के लिए पर्यावरण और वॉल्यूम को परिभाषित करने के लिए 2 और डॉकटर-कंपोज़ करें

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

हम macOS, विंडोज और लिनक्स पर विकसित होते हैं। इसके अलावा, हमारे कई देव कार्यों के लिए कुछ प्रकार के मानकीकरण की आवश्यकता होती है (जैसे एक DB माइग्रेशन बनाना, एक कंपोज़र / कारीगर / npm कमांड को अपने तर्कों के साथ चलाना), इसलिए मैंने एक जीरो-इंस्टॉल क्रॉस के रूप में schmich/runx बनाया- हमारे सामान्य विकास कार्यों को बंडल करने के लिए प्लेटफ़ॉर्म टास्क रनर।

उदाहरण के लिए, यह रनएक्स माइग्रेट कहती है docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table चलाने के लिए, या हमारे पुराने JS निर्भरता को देखने के लिए रनिंग npm को पुराना बनाएं ।

मैंने ऊपर उल्लिखित dobi उपयोग नहीं किया है, लेकिन runx भावना में समान लगता है, हालांकि एक डॉकर वातावरण के अनुरूप है। अंततः, मैं हर जगह निर्भरता से बचना चाहता हूं, जहां बिल्कुल आवश्यक हो: स्वयं सेवाओं के लिए, और विकास में आवश्यक उपयोगिता लिपियों के लिए।

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

चूँकि noboby ने .env फ़ाइलों का उपयोग करके उपयोग किए जाने वाले मामलों पर टिप्पणी की है, यहाँ मेरा है:

मेरे पास 4 कंपोज़ फाइलें हैं: docker-compose.yml, docker-compose.local.yml, docker-compose.prod.yml और docker-compose.ci.yml। प्रत्येक वातावरण के लिए मेरे पास एक अलग .env है:

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

और इसी तरह...

उपयोगकर्ता और / या स्क्रिप्ट को इस बारे में चिंता करने की ज़रूरत नहीं है कि कौन सी फ़ाइलों का उपयोग करें क्योंकि वातावरण पहले से ही व्यक्तिगत रूप से कॉन्फ़िगर किए गए हैं।

लेकिन मेरे पास अंत में चलाने के लिए एक रखरखाव उदाहरण है, इसे मुख्य docker-compose.yml के अंदर कॉन्फ़िगर नहीं किया जा सकता है और एक समाधान docker-compose.worker.yml बनाने और 3 "-f" विकल्पों के साथ कमांड लाइन निष्पादित करने के लिए होगा। प्रत्येक वातावरण के साथ। यह भी एक प्रयोग करने योग्य विकल्प होने की त्रुटि है।

मुझे जो समाधान मिला वह एक निर्देशिका "कार्यकर्ता" बनाने के लिए था, वहां yml फ़ाइल डालें, ऊपरी .env फ़ाइल को इस निर्देशिका से लिंक करें और खाली docker-compose बनाएं। [ci | स्थानीय | ठेस] .yml फाइलें (अन्यथा मैं होता) COMPOSE_FILE चर के मूल्य को बदलने के लिए)।

यह ठीक काम करता है, लेकिन यह इष्टतम से बहुत दूर है। ओपी का कोई अन्य समाधान बिना किसी गड़बड़ी के ऐसा होगा।

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

इसके लिए मैं वास्तव में चर्चा को यहां से स्थानांतरित करना चाहूंगा _ इसे _ _ पर लागू किया जाना चाहिए और इसे लागू किया जाना चाहिए। क्या हम सभी इस पर सहमत हो सकते हैं ?

_How_ पर के बारे में यह लक्ष्य प्राप्त किया जा सकता है @bfirsh सूचीबद्ध उद्घाटन टिप्पणी में कुछ विकल्प:

1) उपयोगकर्ताओं को एक अलग कम्पोज़ फ़ाइल का उपयोग करने की सलाह देते हैं

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

साथ में, ये सुविधाएँ डेवलपर्स को प्रोजेक्ट पर आरंभ करने के लिए एक सुविधाजनक तरीका प्रदान करती हैं। कम्पोज़ एक सिंगल मशीन पठनीय कम्पोज़ फ़ाइल और कुछ कमांड्स के लिए एक मल्टी-पेज "डेवलपर स्टार्टिंग गाइड" को कम कर सकता है।

किसी स्थानीय सेटअप को शुरू करने के लिए docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init तरह कुछ टाइप करने से मुझे _convenient_ की आवाज़ नहीं आती है, लेकिन कुछ ऐसा भी है जैसे कि _ बहु-पृष्ठ "डेवलपर शुरू करने वाले मार्गदर्शक" _ में पाया जाता है।

और विकल्प 1 बी पर विचार करने के लिए यहां:

उपयोगकर्ताओं को अलग कंपोज़ फ़ाइलों का उपयोग करने के लिए एक रैपर स्क्रिप्ट / उपकरण का उपयोग करने की सलाह दें

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

2) उन्हें डिफ़ॉल्ट रूप से शुरू नहीं करने के लिए सेवाओं में एक विकल्प जोड़ें
3) डिफ़ॉल्ट सेवाओं को परिभाषित करने के लिए एक शीर्ष-स्तरीय कॉन्फ़िगरेशन विकल्प जोड़ें

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

4) एक सेवा की तरह एक चीज़ की अवधारणा जोड़ें, लेकिन केवल एक-बंद आदेश ("स्क्रिप्ट", "कार्य", आदि) के लिए है ...

मुझे लगता है कि विकल्प 4) विकल्प 2 का सिर्फ एक विशेषज्ञता है) या 3) चूंकि वांछित एक-बंद कंटेनरों के ऊपर के अधिकांश उदाहरण मूल रूप से किसी भी अन्य सेवा की तरह परिभाषित किए गए हैं और सामान्य सेवाओं की तरह कम या ज्यादा कुछ नहीं करते हैं - सिवाय इसके कि वे डिफ़ॉल्ट रूप से प्रारंभ नहीं हुआ है। (या मैंने एक "सेवा" के लिए कुछ महत्वपूर्ण अंतर को याद किया)।

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

मैं मानता हूं कि विकल्प 2 शायद सबसे कम आक्रामक है। एकमात्र विशेषता जो मुझे दिखाई देती है कि विकल्प 4 प्रदान कर सकता है, मौजूदा कंटेनरों पर कमांड चलाने की क्षमता है (डॉक निष्पादन तंत्र का उपयोग करके)। उदाहरण के लिए, यदि मैं चाहता हूं कि सभी डेटाबेस माइग्रेशन या यूनिट परीक्षण चलाएं, तो इसके लिए कोई अलग से कंटेनर बनाने का कोई कारण नहीं हो सकता है यदि मेरे पास पहले से ही मेरा ऐप चलाने वाला कंटेनर है। उस ने कहा, कंटेनर हल्के होते हैं और मैं विकल्प 2 से पूरी तरह खुश हूं।

@ माडवॉम्बट I में विकल्प 4 के बारे में समान भावना है, यही कारण है कि मैंने इस उपयोग-केस के लिए एक और विशेषता प्रस्तावित की है: # 4096। यहाँ वर्णित विशेषता के साथ ओवरलैप है, लेकिन मेरा मानना ​​है कि यह अपने आप ही उपयोगी हो सकता है या इसके अतिरिक्त हो सकता है

@ मैथ्रोक ने 4 विकल्प का उल्लेख किया है @acran ने पूछा कि क्या विकल्प 2 और 4 के बीच कोई महत्वपूर्ण अंतर था। हालांकि, मैं वास्तविक जीवन के उपयोग के मामले में नहीं आता, जहां आप विशेष रूप से एक कमांड चलाना चाहते हैं मौजूदा कंटेनर उद्देश्य के लिए एक और समान कंटेनर लाने के बजाय। कुछ सेवा या कुछ अन्य सीमित संसाधनों के लिए सीमित निरंतर कनेक्शन के साथ कुछ परिदृश्य हो सकता है जो पहले से ही मौजूदा कंटेनरों द्वारा उपयोग किया जा रहा है, लेकिन मैं एक के बारे में नहीं सोच सकता।

एकमात्र विशेषता जो मुझे दिखाई देती है कि विकल्प 4 प्रदान कर सकता है, मौजूदा कंटेनरों पर कमांड चलाने की क्षमता है (डॉक निष्पादन तंत्र का उपयोग करके)।

यह वास्तव में एक नया उपयोग मामला है जो सेवाओं से अलग एक नई शीर्ष-स्तरीय अवधारणा को पेश करने (और आवश्यकता) को उचित ठहराएगा। लेकिन जब तक कमांडों को पहले से मौजूद सर्विस कंटेनर के भीतर docker exec चलाने की जरूरत नहीं है, तब तक मौजूदा सर्विस कॉन्सेप्ट पर्याप्त होना चाहिए।

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

निकटतम मामला जो मैं सोच सकता हूं वह कुछ ऐसा है जैसे कंटेनर के भीतर एक कॉन्फिग फाइल को बदलना और एप्लिकेशन द्वारा फिर से लोड करना; # 4096 से @mathroc के उदाहरण का उपयोग

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

हालांकि इस मुद्दे से संबंधित, # 4096 में इसके स्वयं के उपयोग के मामले हैं और शायद विकल्प 4) को सर्वश्रेष्ठ रूप से वहां स्थानांतरित किया जा सकता है?

यह चर्चा का एक साल हो गया है और हमें लगता है कि आगे कोई निर्णय नहीं होगा। @ बफिश को बस एक स्टाइल

+1

+1, यह एक बहुत ही उपयोगी सुविधा होगी।

और विकल्प 2 के लिए एक और +1, auto-start: false या enabled: false जैसे कुछ के साथ।

मेरा उपयोग-मामला सेवाओं का विस्तार कर रहा है। ऐसी सेवाओं का विस्तार करना संभव नहीं है जिनके पास depends_on सेट है, इसलिए मैं जो करना चाहता हूं वह एक सेवा टेम्पलेट को परिभाषित करना है, और फिर इसमें से कई सेवाओं का विस्तार करना है। जाहिर है, टेम्पलेट का निर्माण किया जाना चाहिए, लेकिन ऑटोमैगिकल रूप से नहीं चलना चाहिए।

मैंने अपना खुद का समाधान बनाया, उपयोग करने के लिए स्वतंत्र हो।
यह अभी भी बीटा में है :)

https://github.com/jonathanborges/picles-docker

यहां बहुत सारे शानदार विकल्प। फीचर की आवश्यकता वास्तविक है।

विकल्प 2 स्पष्ट रूप से अधिक लोकप्रिय है, घटनाएँ:

1 -> 4
2 -> 52
3 -> 3
4 -> 10

विकल्प 2 के लिए एक और 2

हम इसे प्रारंभिक एंट्रीपॉइंट या कमांड के साथ "टूल" सेवा में काफी आसानी से संभाल सकते हैं जो केवल रिटर्न देता है। फिर हम इस सेवा को एक वैकल्पिक कमांड के साथ चलाते हैं जो हम चाहते हैं (उदाहरण के लिए परीक्षण या डेटा को सीड)। उदाहरण के लिए

docker-compuse up -d
docker-compose run tools tests

हां, उपकरण सेवा docker-compose ps में "रोका" के रूप में दिखाई देगी। यदि यह अस्वीकार्य है, तो मैं https://github.com/docker/compose/pull/2051 कार्यों से बहु-फ़ाइल विकल्प चुनता हूं। जैसे

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

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

व्यक्तिगत रूप से मेरा मानना ​​है कि पर्याप्त वर्कअराउंड्स हैं (जैसे कि ऊपर दो, आपके एंट्रीपॉइंट / कंटेनर और / या शेल अलियास / हेल्पर के साथ मल्टीफ़ाइल दृष्टिकोण का उपयोग करके रचनात्मक हो रही है), और रचना को सरल रखा जा सकता है।

@briceburg ऊपर चर्चा देखें: यहाँ मुद्दा एक लापता कार्यक्षमता के बारे में नहीं है जो किसी अन्य तरीके से नहीं किया जा सकता है। वहाँ _are_ workarounds के लिए लगभग सब कुछ लोगों को प्राप्त करना चाहते हैं। लेकिन वे कामचोर और गंदे हैक्स के बजाय डॉकटर-कम्पोज़ के एक नॉर्माले उपयोग के मामले में हैं।

यह सुविधा के बारे में है, cli पर हाथ से docker-compose -f docker-compose.yml -f docker-compose-tools.yml up टाइप करने के बारे में नहीं है, यह याद रखने के बारे में नहीं है कि क्या यह docker-compose run tools tests या docker-compose run utils tests या यहां तक ​​कि भरोसा करना होगा _multi- पेज "डेवलपर गाइड शुरू कर रहा है" _ लेकिन इसके बजाय डेवलपर के लिए एकीकृत और सरल इंटरफ़ेस है।

फिर, @bfirsh CCing, @dnephin: सकता है आप इस मुद्दे को _any_ प्रतिक्रिया प्रदान करें? क्या कोई उम्मीद है कि हम docker-compose लिए आने वाले रोडमैप पर ऐसा कुछ देख सकते हैं ??

एक सरल वातावरण के लिए @briceburg शायद एक समाधान स्वीकार्य है, लेकिन कभी-कभी यह नहीं है। मेरा सेटअप देखें:

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

मेरे पास 8 कंपोज़ फाइल्स हैं (जो कि मैं कई कॉम्बिनेशन में इस्तेमाल करता हूं) इसके अलावा worker डायरेक्टरी में है, जहां मैं 'default by default' स्टार्ट नहीं करता। worker निर्देशिका (माता-पिता से जुड़ी एक .env फ़ाइल के साथ और माता-पिता के अनुपालन के लिए कुछ खाली कम्पोज़ फ़ाइलें .env COMPOSE_FILE चर) मेरा वर्कअराउंड है, लेकिन जब हमारे पास इसका समाधान होगा तो मेरा जीवन बहुत आसान हो जाएगा। इस मुद्दे।

@vipseixas को फ़ाइल प्रविष्टि से इस समाधान की

ज्यादातर मामलों में आप सुनिश्चित करने के लिए स्वास्थ्य की जाँच करता निर्भर सेवाएं / कंटेनरों पर पारित परीक्षण निष्पादित करने से पहले चाहता हूँ - उदाहरण के जेनकींस के लिए उत्तर प्रदेश और (पर कनेक्शन को स्वीकार: 8080 या जो कुछ भी) चल रहा है इससे पहले कि इन परीक्षणों को अंजाम। पूर्व में मैंने इसके लिए डॉकटराइजेशन का उपयोग किया था।

अगर मैं चांदी की गोली का प्रस्ताव रखता था, तो यह पर्यावरण चर (जैसे DOCKER_COMPOSE_PROFILE = "परीक्षण") के माध्यम से एक रचना प्रोफ़ाइल की स्थापना करने की अनुमति होगी, और सेवाओं को एक प्रोफ़ाइल पर निर्भर होने की अनुमति देने के लिए - जहां सभी डिफ़ॉल्ट "डिफ़ॉल्ट" पर जाएं “प्रोफाइल या जो भी हो। मैं उन सेवाओं को भी सुनिश्चित करूंगा जो किसी अन्य सेवा पर निर्भर हैं, उन सेवाओं पर भी निर्भर हैं_ HEALTHCHECK। तो कुछ ऐसा है

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

विकल्प 2 के लिए +1।

यहां कई लोगों ने दिलचस्प नई सुविधाओं का प्रस्ताव दिया है, लेकिन यहां मुद्दे का मूल क्या है? मैं इसे यथासंभव सरल रखने के लिए मतदान करता हूं।

जैसा कि आज यह खड़ा है, हम मानते हैं कि हमारे docker-compose.yml में सभी सेवाओं को docker-compose up पर लाया जाएगा। हम सभी अपने स्वयं के कस्टम बूटस्ट्रैप स्क्रिप्ट्स, मेकफाइल्स, बिल्ड टूल्स इत्यादि के साथ काम कर रहे हैं, और सौभाग्य से डॉकटर-कंपोज़ और डॉकटर दोनों ही व्यक्तिगत कंटेनरों के प्रबंधन के लिए एक व्यापक एपीआई का खुलासा करते हैं, जब किचन सिंक 'ऊपर' है।

मेरी एकमात्र आवश्यकता, मुझे इस चर्चा में लाने वाली मूल आवश्यकता है, यह निर्दिष्ट करना कि जिन सेवाओं को मैंने परिभाषित किया है, उनमें से कोई भी चीज ऐसी नहीं है जिसे मैं डिफ़ॉल्ट रूप से 'अप' चाहता हूं, जो भी कारण हो।

हम सभी के लिए सबसे सरल संभव विशेषता क्या है जो "हो जाती है"? यह docker-compose.yml विनिर्देशन के लिए एक छोटा सा अद्यतन है ( @bfirsh मूल विचार संख्या 2) जिसमें एक सेवा autostart: false निर्दिष्ट कर सकती है

मैं वोट देता हूं: "केवल अमेरिका के लिए काम करो, धन्यवाद।" हम मतदान करते हैं, हमें अब कम से कम एक उत्तर की आवश्यकता है। 4 भगवान!

हम सभी के लिए सबसे सरल संभव विशेषता क्या है जो "हो जाती है"? यह docker-compose.yml विनिर्देशन ( @bfirsh मूल विचार संख्या 2) के लिए एक छोटा सा अद्यतन है, जिसमें एक सेवा ऑटोस्टार्ट निर्दिष्ट कर सकती है: असत्य

यह किसी भी अन्य विकल्प की तुलना में बेहतर है :)

यह बहुत आसान हैं।
scale: 0
https://github.com/docker/compose/issues/1661

@ आकर्षित-आर क्या?

@ jonathanborges1542 यह docker-compose scale servname=2 । docker-compose.yml फ़ाइल में कोई समान नहीं है।

@ आकर्षित-आर scale: 0 वर्तमान में डॉकटर डेमॉन को सेवा के लिए सभी कंटेनरों में SIGTERM / SIGKILL भेजने के लिए कहता है। यह किसी भी रखरखाव की नौकरी को मार देगा, भले ही उसने अभी तक अपना काम पूरा नहीं किया हो। वह अपेक्षित व्यवहार है। इसे बदलना एक अधिभार का एक बुरा मामला होगा जो अभी एक स्पष्ट व्यवहार है।

@gittycat मैं समझता हूं, लेकिन हम यहां जो चाहते हैं वह "

मैं एक साल से अधिक समय से इस विषय का अनुसरण कर रहा हूं (अधिकांश पोस्ट डॉकटर की ओर हैं)।
मेरा मानना ​​है कि एक नया शीर्ष स्तर "नौकरी" "सेवाओं", "वॉल्यूम" और "नेटवर्क" के साथ रहना सबसे अच्छा विकल्प है। ऊपर की ओपी सूची में वह विकल्प 4 है।
यह डॉकर रेपो पर एक प्रस्ताव भी है।
https://github.com/docker/docker/issues/23880

@briceburg

फ़ाइल प्रविष्टि से इस समाधान की पवित्रता का अनुमान लगाना कठिन है

इरादा सिर्फ यह दिखाने के लिए था कि मेरे पास कई फ़ाइल संयोजन हैं और कई "-f" विकल्पों का उपयोग करके मैन्युअल रूप से किया जाने वाला त्रुटि है।

मैं केवल यह सुझाव दे रहा हूं कि आप एक डिफ़ॉल्ट एंट्रीपॉइंट / कमांड का उपयोग करें जो उन सेवाओं के लिए कुछ भी नहीं करता है जिन्हें आप ऑटोस्टार्ट नहीं करना पसंद करते हैं।

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

अगर मैं चांदी की गोली का प्रस्ताव देता, तो यह पर्यावरण चर (जैसे DOCKER_COMPOSE_PROFILE = "परीक्षण") के माध्यम से एक रचना की रूपरेखा तैयार करने की अनुमति देता

यह सबसे अच्छा समाधान होगा। लेकिन मुझे नहीं लगता कि डेवलपर्स जटिलता को बढ़ाने के लिए इच्छुक हैं ...

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

+1 @ ड्रू-आर # 1661

क्या यह मुद्दा किसी बिंदु पर लागू होने जा रहा है या यह केवल कुछ ऐसा है जो देवों की रचना नहीं करना चाहता है? यह जानना अच्छा होगा ताकि समुदाय दूसरे समाधान की तलाश शुरू कर सके।

वैसे मैं विकल्प 2 के लिए मतदान करता हूं।

धन्यवाद

विकल्प 2 के लिए +1।
क्या यह स्पष्ट निर्भरता का सम्मान करेगा ... links आदि?

अगर मैं निर्दिष्ट कर रहा हूं कि कौन सी सेवा docker-compose up [service] साथ लाने के लिए है तो यह दुर्लभ है कि मैं सेवा के अलावा किसी भी सेवा को शुरू करना चाहता हूं और यह निर्भरता है।

विकल्प के लिए एक और वोट 2. इसके लिए एक पीआर भी है (https://github.com/docker/compose/pull/3047) जो @acran बनाने के लिए पर्याप्त था, इसलिए

यदि रचना करने वाले देवता ऐसा नहीं करना चाहते हैं, तो उन्हें इसे एक बार और सभी के लिए बताना चाहिए और फिर टिकट को बंद करना चाहिए और टिप्पणियों को रोकने के लिए इसे लॉक करना चाहिए।

@msabramo रचनाकार मूल रूप से

अनुरोध को docker engine repo https://github.com/docker/docker/issues/23880 पर ट्रैक किया गया है
यहीं से फैसला / काम आएगा।

मेरा सुझाव है कि इस मुद्दे को बंद किया जाए।

@gittycat के पास अभी भी यह विकल्प हो सकता है कि वह किसी सेवा को शुरू करने के लिए इंजन को बताए या नहीं। यह अभी भी एक बहुत ही मान्य अनुरोध है।

मैं प्रोडक्शन पर काम कर रहा हूं, बहुत सारी समस्याएं हैं। तब मैं योनि में प्रवास करता हूं।

2 के लिए एक और वोट

2 और 4 के लिए एक और वोट।

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

सेटअप और / या परीक्षणों के लिए एक सरल आदेश होने से चीजें बहुत अधिक साफ हो जाएंगी।

2 के लिए एक और वोट!

मैंने इस सूत्र को पढ़ा था लेकिन एक नया पोस्ट बनाने का फैसला किया (https://github.com/docker/compose/issues/4650), जो बंद हो गया और मुझे यहाँ भेजा गया। जिस बिंदु पर मैं बनाना चाहता था वह यह है कि इस थ्रेड में अधिकांश चर्चाओं में चल रहे कंटेनरों को निष्क्रिय करने की चिंता है, मेरा उपयोग मामला तीसरे राज्य का है: कंटेनर बनाना।

मैं न केवल एक कंटेनर को चलाने से रोकना चाहूंगा, बल्कि पहले कभी भी कंटेनर को बनाने में सक्षम नहीं होगा (मेरे उपयोग के मामले में मेरे पास एक उपयोगकर्ता-संचालित प्रक्रिया है जो इसे पूरा करती है)

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

क्या आप इतने दयालु होंगे कि अपने मुद्दे पर अधिक जानकारी दे सकें?

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

@ekkis का सुझाव है कि आप # 963 पर एक नज़र डालते हैं, जो आप देख रहे हैं उससे संबंधित लगता है।

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

विकल्प 2 के लिए +1

: +1: इस सुविधा पर किसी भी अनुमान पर एक प्रश्न के साथ विकल्प # 2 के लिए? सबसे अच्छा समाधान क्या है? जहाँ तक मैं कल्पना कर सकता हूँ मेरी सभी सेवाओं को सूचीबद्ध करने की आवश्यकता है:

docker-compose up service1 service2 service3

... और उन लोगों को छोड़ दें जिन्हें मैं डिफ़ॉल्ट रूप से शुरू नहीं करना चाहता

क्या किसी भी तरह से हम खुले स्रोत समुदाय में इस सुविधा का योगदान करने में मदद कर सकते हैं जो भारी अनुरोध है?

विकल्प 2 के लिए +1।
'चरण' को निर्दिष्ट करने का एक तरीका बहुत अच्छा होगा। कहते हैं, सेवा केवल उत्पादन में चलेगी।

विकल्प 2 के लिए +1।

विकल्प 2 के लिए वोट करें

up कमांड फ़िल्टर करना सही होगा - docker-compose up service1 service3

: +1: विकल्प 2 और 4 के लिए

इस बिंदु पर यह स्पष्ट विकल्प 2 लगता है कि उपयोगकर्ता क्या चाहते हैं। ऐसा करने के लिए अगले चरण क्या हैं?

यहां विकल्प 2 के लिए +1, इस मुद्दे पर आया, जिससे उम्मीद है कि यह कार्यक्षमता पहले से मौजूद है।

विकल्प 2 पर +1

... और विकल्प 2 के लिए एक और +1

विकल्प 2 के लिए +1

विकल्प 2 :-) के लिए +1

विकल्प 2 और 4 के लिए +1

नमस्ते,
+1 विकल्प 2

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

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

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

विकल्प 2 के लिए बेशक +1000

+1 विकल्प 2

अगर मुझे विकल्प 2 के लिए वोट दिया जाए तो क्या इससे कोई फर्क पड़ेगा? 'लगता नहीं है कि यह होगा।

यहाँ टिप्पणियाँ देर से ही सही, और कोई नई प्रतिक्रिया सामने नहीं आई हैं, जो मुझे इस धागे को लॉक करने पर विचार कर रही है। कृपया यहां बातचीत करते समय नागरिक रहें।

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

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

@jimzucker नहीं - क्योंकि यहाँ समस्या कार्यान्वयन नहीं है; इसका एक बुनियादी कार्यान्वयन आपके औसत डेवलपर के लिए आधा दिन लेगा। हम यहां जिस चीज के बारे में चिंतित हैं वह एक मौलिक डिजाइन मुद्दा है।

1. एक सेवा क्या है? डिजाइन द्वारा, एक सेवा एक स्पष्ट रूप से परिभाषित, लंबे समय से चलने वाली प्रक्रिया है जो एक अनुप्रयोग बनाने के लिए अन्य सेवाओं के साथ बातचीत करती है। यह वह मूल धारणा है, जिसके तहत कम्पोज़ संचालित होता है और यह हमारे डिजाइन को सबसे अधिक निर्देशित करता है, यदि हम उन सभी विशेषताओं को लागू नहीं करते हैं, जो लागू होती हैं।
2. उस परिभाषा के अनुसार, "एक सेवा जो कि डिफ़ॉल्ट रूप से शुरू नहीं होती है" वास्तव में एक सेवा नहीं है [1] - यह एक पूर्व-परिभाषित कार्य से अधिक है, कंटेनर में चल रहा है और आवेदन पर काम कर रहा है , बल्कि
3. इसलिए इसे सेवा कहना गलत (मूल रूप से डिजाइन द्वारा) गलत है। उस बिंदु पर हमें आपकी रचना फ़ाइल में एक नई प्रकार की परिभाषा बनाने पर विचार करने की आवश्यकता है (मैं इसे संक्षिप्तता के लिए "कार्य" कहूंगा, सटीक शब्दावली यहां कोई मायने नहीं रखती है)।
4. चूंकि कार्य स्वाभाविक रूप से कम चलने वाली प्रक्रियाएं हैं, इसलिए वे सेवाओं की तुलना में विकल्पों के एक अलग सेट का उपयोग करते हैं। उदाहरण के लिए, हम यह बता सकते हैं कि कार्यों को बंदरगाहों को उजागर करने की आवश्यकता नहीं है [2]। दूसरी ओर, सीआईडी ​​फ़ाइल जैसा एक विकल्प जो सेवाओं के लिए ज्यादातर व्यर्थ है, कार्यों के लिए वास्तव में उपयोगी हो सकता है।
5. अब, अधिकांश परियोजनाओं में, कार्यों में निर्भरता श्रृंखला होती है (इसीलिए पारंपरिक, गैर-कंटेनर दुनिया में, हमारे पास मेकफाइल्स हैं) - इसलिए हमें समानतावाद के साथ, और बताने में सक्षम होने के लिए निर्भरता श्रृंखलाओं के कम से कम एक बुनियादी कार्यान्वयन की आवश्यकता है। अगर उस एक JAR निर्माण कार्य में हमेशा 10 मिनट लगते हैं तो वास्तव में उसे फिर से चलाने की आवश्यकता होती है।
6. फिर, कुछ सेवाएं वास्तव में शुरू करने में सक्षम होने से पहले चलने वाले कार्यों पर निर्भर करती हैं, एक और स्तर की जटिलता को जोड़ते हुए कि हम कैसे निर्भरता की गणना और संभाल करते हैं।
7. और कुछ कार्यों को चलाने के लिए कुछ सेवाओं की आवश्यकता होती है (जैसे डेटाबेस माइग्रेशन)।

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

उम्मीद है कि यह चीजों को थोड़ा और स्पष्ट करता है। मुझे पता है कि लोग इस थ्रेड पर प्रतिक्रिया (या इसके अभाव) से परेशान और निराश हैं, और मुझे यकीन नहीं है कि यह किसी भी तरह से कम हो जाएगा, लेकिन यह है।

[१] कुछ लोग "वैकल्पिक सेवाओं" के लिए इच्छुक का उल्लेख करते हैं, लेकिन यह इस धागे में वर्णित सबसे आम उपयोग मामला नहीं है। अधिकांश लोग "कार्य" सुविधा चाहते हैं, जहां तक ​​मैं बता सकता हूं।
[२] मुझे यकीन है कि कोई व्यक्ति ऐसे कार्य के उदाहरण के साथ विरोधाभास करेगा, जिसे बंदरगाहों को उजागर करने की आवश्यकता है, जो केवल यह दिखाने के लिए जाएगा कि प्रत्येक सेट पर कौन से विकल्प लागू करने का अभ्यास तुच्छ नहीं है।
[३] और इस समय मेरा मतलब "मैं" है, क्योंकि मैं इस समय सक्रिय रूप से docker-compose काम कर रहा हूं।

@ पिंडली- मुझे बिंदु दिखाई देता है। जो मैं कर रहा हूं वह आपके चरणों में "वैकल्पिक सेवाएं" है और इसके लिए उपयोग के मामले हैं, न कि कार्यों के विचार से, क्या हम किसी तरह से इस बात पर सहमत हो सकते हैं कि हम उस बिंदु को कैसे आगे बढ़ा सकते हैं जैसे कि मैं उस धागे का हिस्सा था जिसे मैं चैंपियन बनाने की कोशिश कर रहा हूं और उस रास्ते पर मेरे टिकट स्पष्ट रूप से इस धागे के पक्ष में बंद हुए। अगर हम उन बिंदुओं से अलग हो सकते हैं जिन्हें आपने स्पष्ट रूप से 'कार्यों' के रूप में परिभाषित किया है तो हम कुछ हद तक आगे बढ़ सकते हैं। जब लोग मेरे पढ़ने में विकल्प 2 के लिए +1 कर रहे हैं तो यह वैकल्पिक सेवा के लिए है। इस ऑफ़लाइन चर्चा के लिए खुश और हम फिर मंच पर आ सकते हैं, मैं [email protected] पर

@ पिंडली- आपकी बात # 2 गलत है। एक सेवा एक सेवा है चाहे वह चल रही हो। ऐसे अनगिनत उपयोग के मामले हैं, जहां निर्भरता उपलब्ध नहीं होने पर निर्भर सेवाएं व्यवहार को संशोधित करेंगी, इसलिए आपकी एप्लिकेशन परत को, सभी समय पर "सभी सेवाओं" की आवश्यकता नहीं होनी चाहिए।

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

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

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

वास्तव में, एक साधारण बूलियन क्षेत्र के साथ हम .env फ़ाइल से सेवाओं को आसानी से अक्षम / अक्षम कर सकते हैं और यमल फ़ाइल को संपादित करने से बच सकते हैं।

@ekkis मुझे लगता है कि आप कुछ हद तक गलती-सहिष्णुता और

हर कोई: कृपया ध्यान रखें कि यदि आपके आवेदन के लिए कुछ सेवाएं वैकल्पिक हैं, तो वर्तमान सुविधाओं के साथ इसे संभालना पहले से ही संभव है। ऐसा करने का अनुशंसित तरीका एक अलग कंपोज़ फ़ाइल है जिसमें -f फ्लैग का उपयोग करके शामिल या शामिल नहीं किया जा सकता है। वे इस विकल्प को जोड़ने के लिए बहुत सम्मोहक तर्क नहीं हैं।

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

क्या कोई ऐसी फॉर्म है जिसे कोर टीम इस LMK में योगदान को स्वीकार करने के लिए तैयार होगी।

@ शशीन , मैंने गलती या सहिष्णुता या डिस्पेंसबिलिटी का कोई संदर्भ नहीं दिया। मैंने केवल एक "सेवा" की परिभाषा के बारे में एक बिंदु बनाया है, अर्थात् कि सेवा चलती है या नहीं यह परिभाषा में निहित नहीं है

@ shin- मैं दृढ़ता से हूं : _by default_ को शुरू नहीं किया जा रहा है, सेवा होने की परिभाषा का उल्लंघन नहीं करता है, इसलिए आपकी बात 2. एक धारणा है जो _nuallyly_ true नहीं है और इसलिए लगातार बिंदु हैं क्योंकि वे आधारित हैं 2 की धारणा।

उदाहरण के लिए: जब मैं mysql DB का उपयोग करके एक एप्लिकेशन विकसित करता हूं तो मैं आमतौर पर एक अतिरिक्त _service_ phpmyadmin परिभाषित करता हूं। यह एक सच्ची सेवा है: लंबे समय तक चलने, उजागर बंदरगाह, अन्य सेवाओं पर निर्भर।
लेकिन मैं नहीं चाहता कि यह सेवा _by default_ लेकिन केवल _on मांग_ / विकास में शुरू हो।
वर्तमान में मुझे इस सेवा को अतिरिक्त docker-compose.yml में लगाकर और इसे docker-compose प्रदान करके शुरू करने का एहसास है - जैसा आपने ऊपर बताया है।

तो, हां, इसे प्राप्त करने के पहले से ही संभव तरीके हैं; यह सेवाओं को कई फाइलों में विभाजित करके या केवल docker-compose अलावा किसी अन्य टूल का उपयोग करके हो। लेकिन जैसा कि मैंने पहले ही ऊपर लिखा है : यह मुद्दा पूरी तरह से नई सुविधा / कार्यक्षमता या एक नई अवधारणा (यानी _tasks_) के बारे में नहीं है, बल्कि सुविधा के बारे में है, विशेष रूप से विकास के वातावरण में ।
docker-compose -f docker-compose.yml -f docker-compose-tools.yml up टाइप करना कुछ भी है लेकिन सुविधाजनक है और इसलिए docker-compose अपने स्वयं के वादों को पूरा नहीं

साथ में, ये सुविधाएँ डेवलपर्स को प्रोजेक्ट पर आरंभ करने के सुविधाजनक तरीका प्रदान करती हैं। कम्पोज़ एक सिंगल मशीन पठनीय कम्पोज़ फ़ाइल और कुछ कमांड्स के लिए मल्टी-पेज "डेवलपर स्टार्टिंग गाइड" को सकता है ।

कौन सी सेवाओं को शुरू करने के लिए या कौन सा yml फ़ाइलों का उपयोग करने के लिए किस माहौल में आमतौर पर _multi- पृष्ठ में पाया जा सकता है "डेवलपर गाइड शुरू कर रहा है [s]" _ - अगर सभी पर पाया जाए ...

इसलिए मेरी राय में और जैसा कि @jimzucker ने लिखा था कि यहां + 1s वास्तव में कार्यों की एक नई अवधारणा के बजाय "वैकल्पिक सेवाओं" के लिए हैं। कम से कम उन सभी को एक साधारण बूलियन के साथ बंद करना बेहतर है, जिसे डिफ़ॉल्ट रूप से शुरू किया जाना है या नहीं।

जैसा कि मेरा पीओसी आवश्यक कोड परिवर्तन दिखाता है - "वैकल्पिक सेवाओं" के लिए - काफी प्रबंधनीय है और यहां अधिकांश लोगों के लिए सुविधा का एक बड़ा लाभ प्रदान करता है। विकल्प 2 - एक सेवा को वैकल्पिक करने के लिए "_possibility के रूप में चिह्नित करने के लिए वैकल्पिक_" - इस मुद्दे को हल करने के लिए एक उचित समझौता है।

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

@shin , @acran के बिंदु के ऊपर जोड़ने के लिए, मैं केवल कुछ सेवाओं का निर्माण करने के लिए नामों का उपयोग करके अन्य सेवाओं द्वारा चलाया जाएगा। इस बात पर विचार करें कि हर बार जब मैं "अप" करता हूं, तो मुझे project_app_1 , project_otherapp_1 नाम की "सेवाओं" का एक गुच्छा मिलता है, सुविधाजनक होगा

@acran

क्या आप इस बात पर सहमत नहीं होंगे कि उपयोगकर्ताओं को वैकल्पिक के रूप में सेवाओं को चिह्नित करने की संभावना है - लेकिन वे अभी भी सेवाएं हैं - इससे उन्हें बहुत मदद मिलेगी?

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

जब "सेवाओं को वैकल्पिक के रूप में चिह्नित करना / डिफ़ॉल्ट रूप से शुरू नहीं करना" कम हो जाता है तो क्या यह मुद्दा / इसके लिए एक पुल अनुरोध स्वीकार और विलय होगा?

ऊपर देखें - जैसे ही यह सुविधा उपलब्ध हो जाती है, लोग इसका उपयोग अपने इच्छित उद्देश्य के अलावा अन्य चीजों के लिए करना शुरू कर देंगे, और हमसे उम्मीद करेंगे कि हम इसका समर्थन करने के लिए एक नई सुविधा लागू करें। इसके अलावा cc @jimzucker ; मैं वर्तमान में एक ऐसे कार्यान्वयन के बारे में नहीं सोच सकता जो इस परिदृश्य को सामने आने से रोके। अगर मैं कर सकता था, तो यह मुद्दा बहुत पहले बंद हो जाता।

@ekkis यदि आप कभी भी उन सेवाओं को स्वयं शुरू नहीं करना चाहते हैं, तो वास्तव में उन्हें एक अलग फाइल में अलग करना एक मुद्दा क्यों है? मैं वास्तव में उलझन में हूं कि यहां ऐसा क्यों है।

@ शिन अगर एक डॉकटर-कंपोज.आईएमएल का उपयोग सेवा बनाने के लिए किया जा सकता है, तो यह इस प्रक्रिया को केंद्रीकृत करने में सबसे उपयोगी उपकरण है। यह वास्तव में समझ में आता है कि मैं (सशर्त) इसे चलाने से पहले एक सेवा का निर्माण कर सकता हूं, और मैं उस कार्यक्षमता की सराहना करता हूं

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

स्पष्ट रूप से मुझे यकीन नहीं है कि मैं समझता हूं कि इस साधारण पैच पर आपत्ति क्या है। यह मेरे लिए बहुत उपयोगी होगा

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

@ नली

आपके उदाहरण में, बस एक docker-compose.phpmyadmin.yml है, जिसे वैकल्पिक रूप से शामिल किया जा सकता है, कोई अधिक बोझ या जटिल नहीं है (निर्देश "डेवलपर गाइड" के संदर्भ में) मुख्य परिवेश के अंदर एक सेवा को बदलने / सेवा को संशोधित करने की तुलना में।

वास्तव में मैंने अभी तक यहाँ पर्यावरण चर को शामिल करने के बारे में नहीं सोचा था। मेरा वांछित वर्कफ़्लो "वैकल्पिक सेवाएं" अंत में अनुमति देगा:

• मैं एक नई परियोजना की प्रतिलिपि / क्लोन करता हूं
• मैं देख रहा हूँ कि इसमें एक (एकल) docker-compose.yml फ़ाइल है, इसलिए मुझे पता है, मुझे बस docker-compose up चलाना है और एप्लिकेशन बनाया और चला रहा है
• अब मैं विकास उद्देश्यों के लिए वैकल्पिक सेवाओं में से एक शुरू करना चाहता हूं (जैसे अतिरिक्त डीबगिंग, phpMyAdmin)। मुझे केवल docker-compose up phpmyadmin ।

मेरे लिए यह कई docker-compose.yml फ़ाइलों का उपयोग करने की तुलना में _much_ अधिक सुविधाजनक है, और जैसा कि मैं यहां अन्य अधिकांश लोगों के लिए भी समझता हूं। यहां "वैकल्पिक सेवाएं" होने का लाभ है

• डेवलपर को कई फ़ाइलों के बीच कुछ भी डुप्लिकेट नहीं करने या ध्यान से विचार करने के लिए कि कौन सी फ़ाइल में कौन सी परिभाषाएं डालनी हैं, लेकिन केवल एक सेवा पर एक बूलियन ध्वज ( auto_up: false ) सेट करने के लिए
• उपयोगकर्ता को यह जानने / याद रखने की आवश्यकता नहीं है कि किन सेवाओं के लिए कौन सी फाइलें शामिल हैं: क्या मुझे चलाने की आवश्यकता है
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up या भी
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ?
  
  
• इसके बजाय उपयोगकर्ता को केवल _know_ की आवश्यकता होती है, यह है कि phpmyadmin नामक एक सेवा है और उपयोगकर्ता तुरंत जानता है कि इसे कैसे शुरू किया जाए।

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

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

वैकल्पिक के रूप में _service_ को चिह्नित करने की सुविधा के साथ हम अभी भी उस कटौती के दाईं ओर हैं। "प्रति से फ़ीचर लागू करने के लिए बहुत जटिल नहीं है, लेकिन यह _might_ उपयोगकर्ताओं को इसे गलत तरीके से उपयोग करने के लिए लुभाता है" वर्तमान में एकमात्र वास्तविक (हालांकि वैध!) तर्क इस सुविधा के खिलाफ खड़ा है, इसे लागू नहीं करने के कारण के रूप में काफी असंतोषजनक है - कम से कम के लिए वे उपयोगकर्ता जो इसे सही तरीके से उपयोग करते हुए बहुत सुविधा प्राप्त कर सकते हैं ™।

मैं वर्तमान मास्टर के लिए अपने पुल अनुरोध # 3047 को रिबास करने के लिए तैयार हूं और इसके लिए किसी भी आवश्यक पॉलिशिंग को स्वीकार करने के लिए करता हूं, कृपया मुझे बताएं;)

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

मैं एक docker-compose कांटा का उपयोग करने के लिए इच्छुक हूं जो इस सुविधा को इस विलक्षण सुविधा के लिए लागू करता है।

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

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

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

@ पिंडली- अगर डॉक-कंपोज़ को मेकफाइल के रूप में इस्तेमाल नहीं किया जाना चाहिए, तो उसे मेकफाइल कार्यक्षमता प्रदान नहीं करनी चाहिए। अगर यह मुझे अपनी परियोजनाओं (ब्रावो!) का निर्माण करने की अनुमति देता है, तो यह स्थिति लेने के लिए कि यह एक makefile नहीं है, बहुत ही चमकदार है

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

यह मेरे लिए केवल एक छोटी सी जलन है, मुझे मैन्युअल रूप से सामान का एक गुच्छा मारना होगा जो बिना किसी अच्छे कारण के पैदा हो जाता है। समय के साथ-साथ मैं अपनी सेवाओं को बढ़ाता हूं। दूसरों के लिए यह एक बाधा हो सकती है, जलन गंभीरता में भिन्न होगी

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

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

@rysiekpl यह एक समस्या है जिसे हम एक अलग तरीके से हल कर रहे हैं, देखें https://github.com/docker/cli/pull/452 (एक बार सिंटैक्स जानबूझ कर दिया गया है, तो यह कंपोज़ और v2 में अपना रास्ता बना लेगा कुंआ)

@ क्रेन्डर्स मुझे लगता है कि यह एक गलत <img> टैग को स्पष्ट रूप से बंद नहीं किया गया है और हमारे विशिष्ट ब्राउज़र को इसका समर्थन करना चाहिए या नहीं।

इसके अलावा, अपनी बात:

लेकिन यह अंतर कहीं स्पष्ट या प्रलेखन में उजागर नहीं है। और न ही यह कहीं भी इंगित किया गया है कि अस्थायी कार्यों की कताई के लिए डॉक का उपयोग नहीं किया जाना है।

यह वास्तव में https://docs.docker.com/compose/overview/ पेज (जोर मेरा) का पहला पैराग्राफ है:

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

@ekkis मुझे वास्तव में खुशी है कि

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

आप अपने कॉन्फ़िगरेशन से सभी सेवाओं को बनाते और शुरू करते हैं।

और मुझे लगता है कि हमारा विवाद यह है कि "बनाना और / या शुरू करना" पढ़ना चाहिए, हालांकि भाषा के प्रति निष्पक्ष रहने के लिए किसी को OR का संकेत नहीं देना चाहिए क्योंकि यह AND में निहित है। दूसरे शब्दों में, यह सच है कि आप दोनों एक सेवा बना सकते हैं और शुरू कर सकते हैं लेकिन इसका कोई निहितार्थ नहीं है कि यह दोनों करना चाहिए

हम सभी जानते हैं कि उन अनुप्रयोगों का क्या होता है जो बहुत सी चीजें करने की कोशिश करते हैं

हां, मैं सराहना कर सकता हूं कि आप डोमेन की सीमाओं का प्रबंधन कर रहे हैं

मुझे नहीं लगता कि मैं "सत्तावादी" था

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

एक बिदाई के रूप में मैंने पूछा कि आप पुन: समीक्षा करेंगे https://github.com/docker/compose/issues/4650 जो इस धागे पर अनुरोध के समान नहीं है (जैसा कि आपने इसे बंद करते समय संकेत दिया था) लेकिन मेरा उपयोग समायोजित करता है मामला, अर्थात् कि यहां चर्चा की जा रही ध्वज द्विआधारी नहीं है, लेकिन त्रिशूल है

मुझे वास्तव में कई फ़ाइलों को परिभाषित करने का विचार पसंद है। हालांकि मूल सहित मल्टी -f सभी फाइलें कुल ओवरकिल लगती हैं।

वास्तव में एक अधिक व्यावहारिक तरीका है, जो मेरे लिए काम करता है (नीचे पीएस देखें): वह सभी सेवा डालें जो आप docker-compose.override.yml में नहीं चलाना चाहते हैं। और सामान्य स्टार्टअप के लिए docker compose -f docker-compose.yml up उपयोग करें (ध्यान दें कि यह एक बार का कमांड है)। लगातार सभी कॉलों पर ओवरराइड को खटारा किया जाएगा ...

कुल मिलाकर यह सब बहुत अकल्पनीय है और थोड़ा असंतुष्ट है। एक अतिरिक्त जोड़ना:

• सेवाओं को अक्षम करने का एक विकल्प विशेष रूप से अधिक जटिल ओवरराइड के लिए समझ में आता है

• -f विकल्प न्यूनतम है, लेकिन बहुत सहज नहीं है, एक और -F <name> विकल्प जो बस अतिरिक्त ओवरराइड जोड़ता है, बहुत स्वागत योग्य होगा (यानी docker- रचना।.yml। एक विकल्प का उपयोग किया जाएगाएक निर्देशिका के रूप में जिसमें सभी .yml फाइलें खट्टी हैं: एक साथ सहानुभूति के साथ यह /etc/apache/sites.available -> /etc/apache/sites.enabled समान शक्तिशाली होगी।

दूसरी ओर: कोई भी इस व्यवहार का अनुकरण करने के लिए अपने शेल के लिए एक उपमा आवरण स्क्रिप्ट (फ़ंक्शन) प्रदान कर सकता है ...

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

दूसरा विकल्प जिसके लिए विकल्प 2 बहुत अच्छा है:

मान लीजिए कि आपके पास एक ही प्रोजेक्ट पर काम करने वाले लोगों की टीम है। उनमें से कुछ के पास AWS प्रबंधित सेवाओं तक पहुंच है, लेकिन उनमें से कुछ को स्थानीय कंटेनरों के रूप में संबंधित संसाधनों को चलाने की आवश्यकता है। इसलिए मेरे वर्कफ़्लो के आधार पर, मैं या तो _always_ या _never_ को अपने कंपोज़ नक्षत्र में Redis और MySQL कंटेनरों की आवश्यकता होगी।

मैं फ्लैट-आउट स्थिति में जा रहा हूं कि कई कंपोज़ फ़ाइलों का प्रबंधन इस उपयोग के मामले के लिए बेवकूफ है। ओवरलैप की मात्रा हास्यप्रद है। कई फाइलों को बनाए रखना एक फुटगन है - वे _will_ सिंक से बाहर निकलते हैं और भ्रम पैदा करते हैं। मैं स्पष्ट रूप से थोड़ा हैरान हूँ कि किसी ने भी _any_ उपयोग के मामले में उस विकल्प को गंभीरता से लिया।

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

पूरी तरह से @campadrenalin से सहमत हैं।

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

OT:

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

क्या यह सुविधा लंबे समय से उपलब्ध नहीं है? Https://docs.docker.com/compose/compose-file/#variable -substeration देखें। मैं .env फ़ाइल का उपयोग करके हमारे कंपोज़ देव वातावरण के अनुकूलन की अनुमति देने के लिए इसका उपयोग कर रहा हूं - जैसे स्रोत कोड स्थान, पोर्ट मैपिंग आदि। चूंकि फ़ाइल संस्करण 2.1 की रचना भी शैल-शैली परिवर्तनीय डिफ़ॉल्ट ( ${VARIABLE:-default} / ${VARIABLE-default ) समर्थित है।

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

मुझे यह लगता है - शायद स्वर में थोड़ा कठोर है, लेकिन संक्षेप में मान्य है - @rysiekpl द्वारा बहुत अच्छा सारांश।
तो, @ shin-, क्या हम इस मुद्दे के बारे में किसी निर्णय के करीब आए? क्या इसे केवल बंद करना है या विकल्प 2 के लिए PR को लागू करना / स्वीकार करना है?

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

जैसा कि docker-compose में वैसे भी docker stack के पक्ष में दीर्घकालिक रूप से गिराया जा रहा है, मेरा सुझाव है कि हर कोई नए v3 प्रारूप और जितनी जल्दी हो सके docker stack टूल ले जाए।

एक झुंड पर स्टैक का उपयोग करना (यहां तक ​​कि 1 नोड पर), आप इसे निर्दिष्ट कर सकते हैं:

        deploy:
            mode: replicated
            replicas: 0

शून्य प्रतिकृतियां होना अनिवार्य रूप से सेवा को चलाने से रोकती है।

यदि आप पर्यावरण चर प्रतिस्थापन लागू करना चाहते हैं, तो आपको उस yml को उत्पन्न करने के लिए कुछ अन्य टूल की आवश्यकता होगी, जैसे कि एनवीएसयूबीस्ट।

आप अपने yml में प्लेसहोल्डर का उपयोग कर सकते हैं:

        deploy:
            mode: replicated
            replicas: ${R}

और इसे इस तरह से प्रोसेस करें:

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

तो, अगर docker-compose लंबे समय में अपदस्थ होने जा रहा है, तो वास्तव में पुल अनुरोध को विलय करने में समस्या क्या है docker-compose डोडो का रास्ता चल रहा है, तो "कोई अजीब सुविधाओं का अनुरोध कैसे करेगा" एक वास्तविक समस्या है?

जैसा कि डॉकटर-कंपोज लंबे समय तक डॉक स्टैक के पक्ष में गिरा हुआ लगता है

इसलिए, यदि लंबे समय में डॉकटर-कंपोज को अपदस्थ किया जा रहा है

रुको, वाट? docker-compose उनके विकास वर्कफ़्लो के लिए बहुत से लोगों के लिए केंद्रीय है, जिन्हें शायद ही एक झुंड प्रबंधक की आवश्यकता होती है। क्या आप इस संबंध में डोकर के कुछ आधिकारिक बयान पर मुझे इशारा कर सकते हैं?

मैं इसे गलत पढ़ रहा हूं, लेकिन ऐसा लगता है कि डॉक झुंड और डॉक स्टैक कसकर डूकर क्लाउड सेवाओं के साथ हैं। क्या ये चीजें स्टैंडअलोन, ऑफलाइन सिस्टम पर कॉन्फ़िगर करने योग्य हैं?

क्या ये चीजें स्टैंडअलोन, ऑफलाइन सिस्टम पर कॉन्फ़िगर करने योग्य हैं

हाँ, आप उन्हें ऑफ़लाइन उपयोग कर सकते हैं।

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

या शायद मैं सब कुछ गलत समझ रहा हूँ ...?

विकल्प 2 पर +1!
और मुझे लगता है कि झुंड स्टैक के पक्ष में रचनाकार की बूंद समुदाय के लिए एक बड़ी कमी होगी। डॉकटर रचना इतनी सरल और प्रयोग करने में आसान है !!

@tberne मैं इससे सहमत हूँ। docker-compose सरल है और सरल एक अच्छी बात है। हमें इसे बनाए रखने के लिए मतदान करना चाहिए

हे, क्या एक व्यापक चर्चा! इस टिप्पणी पर ज्यादा ध्यान न दें, सिर्फ मेरे दो सेंट।

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

मेरा वर्तमान समाधान कुछ डॉक-कम्पोज़ यामल्स बनाना और कुछ बैश रैपिंग स्क्रिप्ट लिखना है जो डॉकटर-कम्पोज़ को हाथ से नहीं चलाना है।

उदाहरण के लिए, मैं ऐसे कंटेनर चलाता हूं जो एक वेबसाइट चलाते हैं ( ./docker/scripts/up स्क्रिप्ट):

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

बड़ा +1 या तो विकल्प 2 या 3 के लिए।

विकल्प 2 या 3 के लिए +1।

इसके अलावा प्रस्तावित "समूह" अवधारणा दिलचस्प लगती है!

विकल्प 2 के लिए +1

_ इतने सारे +1 on option x , कि मुझे मूल कथन भी नहीं मिल रहा है। कृपया पोस्ट के बदले प्रतिक्रिया बटन का उपयोग करें ।_

एक नया विचार जोड़ने के लिए:

क्या हम केवल 0 लिए एक डिफ़ॉल्ट पैमाना सेट नहीं कर सकते?

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

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

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

विकल्प 2 या 4 के लिए +1

यदि वर्तमान में इस सुविधा को जोड़ने की कोई योजना नहीं है, तो मैं चाहता हूं कि किसी रचना में ऐसी सेवाओं (या कार्यों) को चलाने का तरीका docker-compose के डॉक्स में लिखा हो।

यह एक पुराना धागा है, और मैं मानता हूं कि docker-compose _services के बारे में परवाह नहीं करेगा जो start_ से नहीं चलेंगे।

लेकिन मैं आमतौर पर test सेवा भी जोड़ता हूं, इसलिए यहां मैंने जो किया है:

1. सेवा के entrypoint को ओवरराइड करें।

2. नए entrypoint , अगर कोई tty उपलब्ध है ( docker-compose run डिफ़ॉल्ट रूप से --tty का उपयोग करता है जबकि up नहीं करता है)।

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   यह हमेशा tty ( docker-compose up , उदाहरण के लिए) के बिना चलने पर सेवा से बाहर कर देगा, जबकि अभी भी docker-compose run साथ अपेक्षित है।

@paulodiovani यह एक समाधान की तुलना में हैक की तरह दिखता है।

एक सुविधा अनुरोध के लिए +1।
हैक्स जैसे कि कमांड होने से कुछ भी मतलब नहीं है, भले ही कंटेनर न चले, इसे अभी भी बनाया जाना है, आरंभिक आदि।

मैंने अपनी परियोजना में एक सरल बैश स्क्रिप्ट प्रदान करके इसे हल किया है जो उपलब्ध तर्कों के आधार पर उपयुक्त docker-compose कमांड को कॉल करता है।

अब अगर मैं ./docker-compose.sh -e testing up करता हूं, तो परिणाम वही है जैसे मैंने docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ।
अगर मैं सिर्फ ./docker-compose.sh up हूं, तो मुझे आपकी अपेक्षा के अनुसार नियमित docker-compose up ।

इसलिए, मेरे -e ${environment} विकल्प ( --env लिए एक छोटा) मूल रूप से -f docker-compose.yml -f docker.compose.${environment}.yml लिए एक उपनाम है। यह docker-compose.yml आधार / डिफ़ॉल्ट रचना फ़ाइल और docker-compose.testing.yml इसके एक्सटेंशन की तरह फ़ाइलें होने का परिणाम है।

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

Envsubst के लिए कोई ज़रूरत नहीं है, डॉक-कम्पोज़ कॉन्फिगर वातावरण चर करता है और फिर डॉक स्टैक इसे स्टड से लेता है:

docker-compose config | docker stack deploy --prune --compose-file -

आइए आप docker-compose .env प्रतिस्थापन का उपयोग करें।

@kogli मुझे लगता है कि यहां समस्या एक विकल्प चुनने की है। सभी के पेशेवरों और विपक्ष हैं। जैसा कि मैंने पहले कहा था:

हर समाधान कुछ उपयोग मामलों के लिए बेहतर होगा, और दूसरों के लिए बदतर (या यहां तक ​​कि बेकार)। अगर कुछ लागू किया जाता है, तो यह हमेशा के लिए होता है, इसलिए मेरा मानना ​​है कि वे इसके साथ अपना समय लेने में बुद्धिमान हैं।

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

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

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

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

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

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

यह सुविधा लागू होने में एक दिन की तरह लगता है क्योंकि यह वास्तव में सरल है। हालाँकि, 2 साल की चर्चा के बाद, अभी भी कुछ भी नहीं है। उदास।

@rubycut हाँ, यह तब होता है जब तथाकथित "उच्च सिद्धांतों" को प्रयोज्य और उपयोगकर्ता-मित्रता से लिया जाता है। मैं पूरी तरह से समझता हूं कि देवता अतार्किक विशेषताओं वाले उत्पाद को रोकना नहीं चाहते हैं। हालांकि, यह विशेष रूप से अत्यधिक अनुरोधित सुविधा वास्तव में समझ में आता है। यह दुखद है जब डेवलपर्स को लगता है कि वे अपने उपयोगकर्ताओं से बेहतर जानते हैं। (फिर, वे आमतौर पर करते हैं। लेकिन हमेशा नहीं। इस बार नहीं।)

@rubycut टॉक सस्ता है, मुझे कोड दिखाओ। यदि आप कर सकते हैं, तो अपना पीआर भेजें, यदि आप नहीं कर सकते, तो बस रिपोर्ट करें और प्रतीक्षा करें।

@wangwenpei क्या तुम मुझसे मजाक कर रहे हो? सबसे पहले, आप इस परियोजना के अनुरक्षक नहीं हैं। यदि अनुचर इस विचार को स्वीकार करते हैं, और "सहायता चाहते हैं" टैग लगाते हैं, तो मुझे यकीन है कि कोई व्यक्ति पुल अनुरोध में योगदान दे सकता है। लेकिन उन्होंने कहा कि उन्हें कोई दिलचस्पी नहीं है। तो, परेशान क्यों अनुरोध को खींच लेगा अगर इसे स्वीकार नहीं किया जाएगा।

बस FYI करें, "कोड" पहले से ही है: # 3047

@wangwenpei अच्छी तरह से, # 3047, पुल अनुरोध है ...
अभी दो वर्षों में इस पर कम से कम कुछ प्रतिक्रिया मिलने का इंतजार है। इसे हाल ही में बंद कर दिया गया था

https://github.com/docker/compose/issues/1896#issuecomment -322285976 पर प्रकाश डाला गया कारणों के लिए

जो मुझे काफी ईमानदार बनाता है क्योंकि https://github.com/docker/compose/issues/1896#issuecomment -322285976 में दिए गए तर्क किसी भी तरह से पुल अनुरोध के साथ संबंधित नहीं हैं:

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

मैं दावे को सच होने के लिए By that definition, a "service that is not started by default" is not really a service नहीं देखता हूं। एक सेवा जो डिफ़ॉल्ट रूप से शुरू नहीं होती है, वह केवल एक ऐसी सेवा है जो डिफ़ॉल्ट रूप से शुरू नहीं होती है, इससे अधिक कुछ नहीं, इस बिंदु पर कुछ भी कम नहीं है। डिफ़ॉल्ट रूप से शुरू किया जा रहा है या सेवा के लंबे समय तक चलने या नहीं होने के बारे में कुछ भी नहीं कहता है, आवेदन का हिस्सा है या नहीं, यह केवल कहता है कि डिफ़ॉल्ट रूप से शुरू नहीं किया जाना है।

और यह भी बिल्कुल वही है जो पुल अनुरोध में बदलाव करता है: डिफ़ॉल्ट रूप से या शुरू होने वाली सेवा को चिह्नित करने की क्षमता जोड़ें।
ऐसा करने के लिए कार्यों के रूप में एक नई अवधारणा शुरू करने की आवश्यकता नहीं है। वास्तव में https://github.com/docker/compose/issues/1896#issuecomment -322285976 में अन्य सभी तर्क 2 के झूठे आधार का पालन करते हैं और इस तरह पुल अनुरोध पर लागू नहीं होते हैं जो कुछ भी करने की कोशिश नहीं करता है। अन्य।

पूर्णता के लिए:

[१] कुछ लोग "वैकल्पिक सेवाओं" के लिए इच्छुक का उल्लेख करते हैं, लेकिन यह इस धागे में वर्णित सबसे आम उपयोग मामला नहीं है। अधिकांश लोग "कार्य" सुविधा चाहते हैं, जहां तक ​​मैं बता सकता हूं।

हां, एक-बंद कार्यों के उदाहरण थे, लेकिन आपकी परिभाषा के अनुसार _real_ सेवाओं के
_Also_ के लिए इसका उपयोग करने में सक्षम होने के कारण मैं इसके विरुद्ध एक वैध तर्क के रूप में स्वीकार नहीं कर सकता। पहले से docker-compose.yml में एप्लिकेशन का एक अनिवार्य हिस्सा नहीं है।

वास्तव में यह भी सुझाए गए वर्कअराउंड में से एक है! बस _tasks_ को एक अलग docker-compose.yml में विभाजित करें।
आपके द्वारा बताए गए अन्य वर्कअराउंड का उपयोग आपकी स्वयं की होम-निर्मित (प्लेटफ़ॉर्म-डिपेंडेंट) लिपियों का उपयोग करने के लिए है, जो डॉकटर-कम्पोज़ के स्व-घोषित उद्देश्य का पूरी तरह विरोधाभासी है, मेरी टिप्पणी ऊपर देखें, या बस किसी अन्य टूल पर स्विच करने के लिए, यानी पूरी तरह से फेंक दें अच्छी तरह से काम कर रहे टूलकिन को सुविधा में यह एक छोटी सी सुविधा प्राप्त करने के लिए जिसे आसानी से आपके वर्तमान टूलचिन (डॉकटर-कम्पोज़) में लागू किया जा सकता है।

एकमात्र वास्तविक तर्क विकल्प 2 के सबसे बुनियादी कार्यान्वयन के खिलाफ लाया गया है - अर्थात _some way_ होने के कारण docker-compose डिफ़ॉल्ट रूप से किसी विशेष सेवा को शुरू नहीं करने के लिए, और इससे अधिक, कोई नई अवधारणा या कुछ भी नहीं - क्या यह है कि यह हो सकता है be_somehow_ का दुरुपयोग _some_ उपयोगकर्ताओं द्वारा किया जाता है।
लेकिन इसके लिए मांग और यहां लाए गए वैध उपयोग के मामलों की तुलना में यह तर्क काफी कमजोर है ...

@ नली

लेकिन यह भी क्योंकि हम [3] को लागू करने या बनाए रखने के लिए केवल समय या संसाधन नहीं है, जो इस सुविधा को लोगों के लिए वास्तव में उपयोगी बनने की आवश्यकता होगी।
[३] और इस समय मेरा मतलब "मैं" है, क्योंकि मैं इस समय केवल सक्रिय रूप से डॉकटर-कंपोज़ पर काम कर रहा हूँ।

एक तरफ यह बताते हुए कि केवल एक सक्रिय अनुरक्षक है, जबकि दूसरी तरफ सिर्फ पुल अनुरोधों की अनदेखी है और इसलिए किसी भी अवसर को बर्बाद करने का अवसर प्राप्त करने के लिए अन्य डेवलपर्स को परियोजना में अनपेक्षित मिल सकता है, ऐसा कुछ नहीं है जो मैं समझ सकता हूं।
# 3047 में प्रदान किए गए कोड परिवर्तन पहले से ही _do_ एक ऐसी सुविधा को लागू करते हैं, जो _truly के लिए उपयोगी [कई] लोगों के लिए होगी - शायद _all_ _their_ के _all_ वाले लोग नहीं, बल्कि यहां के अधिकांश लोग।

सभी अतिरिक्त आवश्यकताएं - पूरी तरह से नई अवधारणाओं, नई निर्भरता प्रबंधन, एक cmake -समान जटिलता के साथ पेश करने के लिए - बस एक झूठे आधार का पालन करें!

मैं इस मुद्दे पर अभी कुछ दिन पहले आया था क्योंकि मैं इस तरह की सुविधा की तलाश में था।

चूंकि यह दुर्भाग्य से कार्यान्वित नहीं किया गया है, और जो मैं इकट्ठा कर सकता हूं, वह आधिकारिक तौर पर समर्थित विकल्प है कई यमाल फ़ाइलों का उपयोग करना।

ठीक है, मुझे डिफ़ॉल्ट रूप से नहीं चलने वाली प्रत्येक सेवा के लिए एक अतिरिक्त सेटिंग वाली सभी सेवाओं के लिए एक यमल फ़ाइल का उपयोग करने की तुलना में डिफ़ॉल्ट रूप से नहीं चलने वाली सेवाओं के लिए कई yaml फ़ाइलों का उपयोग करने का विचार मिलता है।

तो, यहाँ मेरा +1 है।