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

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

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

मुझे फ़ाइल से प्रोजेक्ट नाम को कॉन्फ़िगर करने का विचार पसंद है। मुझे लगता है कि (# 45) में भी इसी तरह की चर्चा हुई। .fig/project-name में प्रोजेक्ट का नाम होने से ऐसा लगता है कि यह वास्तव में बहुत सारी छोटी फ़ाइलों को जन्म देगा। मुझे लगता है कि इसे fig.yml खुद में डालना आसान होगा (जैसे कि यह # 45 में सुझाया गया है, और docker एक प्रस्ताव प्रस्तुत करता है)।

इसे एक अलग निर्देशिका और फ़ाइल में डालने के क्या फायदे हैं?

इसे एक अलग फाइल में डालने के कई कारण हैं, मैं इसके पीछे अपनी सोच को समझाने की कोशिश करूँगा;

• उस नाम को संरक्षित करने के लिए जिसका उपयोग _start_ प्रोजेक्ट के लिए किया गया था (यानी, --project-name=foobar ), जो स्वचालित प्रोजेक्ट-नाम से भिन्न हो सकता है।
• एक ही सर्वर पर चल रहे एक प्रोजेक्ट के कई उदाहरण या _versions_ होने के बाद, उनके बिना एक-दूसरे का विरोध किए बिना
• या, संक्षेप में, .fig/project-name परियोजना के _that उदाहरण_ का नाम रखता है।

शायद फ़ाइल को instance-name या समान कहा जाना चाहिए।

मुझे फ़ाइल से प्रोजेक्ट नाम को कॉन्फ़िगर करने का विचार पसंद है

हालाँकि इस प्रस्ताव के साथ _possible_ यह करने के लिए ( project-name फ़ाइल मैन्युअल रूप से बनाकर), मेरा प्राथमिक उपयोग मामला _fig_ फ़ाइल का उपयोग करने के लिए उस नाम को बनाने के लिए था।

वास्तव में छोटी फ़ाइलों का एक बहुत कुछ करने के लिए नेतृत्व करेंगे।

सच है, विकल्प .fig निर्देशिका को छोड़ना है, हालांकि, अगर भविष्य में अतिरिक्त चीजों की आवश्यकता होती है, तो अतिरिक्त फ़ाइल (ओं) को आपकी परियोजना की जड़ को अव्यवस्थित किए बिना जोड़ा जा सकता है। Git इसे समान करता है और मुझे लगता है कि यह एक साफ दृष्टिकोण है।

मुझे लगता है कि यह सिर्फ अंजीर में डाल देना आसान होगा

मुझे लगता है कि दोनों विकल्प पूरक हो सकते हैं; यदि नाम फ्लैग या env- वेरिएबल द्वारा ओवरराइड नहीं किया गया है तो fig.yml को डिफ़ॉल्ट के रूप में उपयोग करें। उस नाम को रखें जो वास्तव में .fig/project-name अंदर _start_ प्रोजेक्ट के लिए उपयोग किया जाता है

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

जिज्ञासु; आप कई परियोजनाओं का प्रबंधन कैसे करते हैं? यानी cd project-a && fig ps तो cd project-b fig <something> ?

आपकी प्रतिक्रिया के लिए धन्यवाद!

जिज्ञासु; आप कई परियोजनाओं का प्रबंधन कैसे करते हैं?

मैं आमतौर पर fig python-tox fig से चलाता हूं, जो मुझे पर्यावरण सेट करने देता है, इसलिए मैं इसे वास्तव में अपने शेल में सेट नहीं कर रहा हूं। मैं भी tmux का उपयोग करता हूं, इसलिए मेरे पास हर प्रोजेक्ट के लिए एक अलग शेल है।

मुझे लगता है कि दोनों विकल्प पूरक हो सकते हैं

कूल, मैं सहमत हूं।

मुझे नहीं पता कि अगर मैं .fig/instance-name बनाम .fig-instance.yml बेचा जाता हूं, जिसमें कोई भी उदाहरण विशिष्ट ओवरराइड हो सकता है, लेकिन मुझे लगता है कि यह एक मामूली बात है।

प्रोजेक्ट-नाम की सोच; अगर मैं आपकी स्थिति को सही ढंग से समझता हूं, तो यह महत्वपूर्ण है कि _images_ पर नियंत्रण किया जा सके, जैसे myapp:build12345 , या _containers_ के नाम भी? बस अपनी स्थिति के लिए एक "महसूस" पाने के लिए।

"यादृच्छिक" प्रोजेक्ट-नामों के पीछे मेरा विचार यह था कि जब तक अंजीर एक परियोजना के लिए कंटेनरों का पता लगाने में सक्षम होता है, तब तक अच्छे दिखने वाले नाम महत्वपूर्ण नहीं होते हैं। यदि मैं, एक उपयोगकर्ता के रूप में, अपने सेवा-नाम (जैसे fig stop web ) के माध्यम से सेवाओं के कंटेनर तक पहुंच सकता हूं, तो वास्तविक कंटेनर का नाम मायने नहीं रखता।

यहां तक ​​कि यह भी सोचा गया है कि अंजीर .fig निर्देशिका के अंदर एक स्थानीय भंडारण में आईडी द्वारा कंटेनरों का ट्रैक रख सकता है (जो बहुत सारे चलने वाले कंटेनरों के साथ मशीनों पर एक प्रदर्शन लाभ हो सकता है)। लेकिन यह वास्तव में एक अलग मुद्दे के लिए कुछ है।

fig init माध्यम से "प्रोजेक्ट-नेम" फ़ाइल या "स्पष्ट रूप से" "स्पष्ट रूप से" बनाने पर कोई विचार? शायद अगर मेरे पास आने वाली छुट्टियों के दौरान कुछ समय हो तो मैं थोड़ा प्रयोग कर सकता हूं (पायथन में कुछ भी कोडित नहीं किया गया है, इसलिए यह _really_ प्रयोगात्मक :) होगा

निर्मित होने वाली छवियों पर नियंत्रण रखने में सक्षम होना महत्वपूर्ण है, जैसे myapp: build12345 , या कंटेनरों के नाम भी?

मुझे लगता है कि छवि वास्तव में महत्वपूर्ण है, लेकिन यह सुनिश्चित करने में सक्षम है कि कंटेनर नाम साझा संघर्ष पर भी वास्तव में महत्वपूर्ण नहीं है। मैं देखता हूं कि यह प्रस्ताव वास्तव में उस मुद्दे से निपटने के लिए है।

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

• पुराने कंटेनरों को हटाने के लिए स्क्रिप्टों की सफाई करें, यह पहचानने में सक्षम हों कि किस परियोजना ने एक कंटेनर बनाया
• डिबगिंग / निरीक्षण कंटेनर

ये दोनों अभी बहुत आसान हैं क्योंकि मुझे पहले से ही पता है कि कंटेनर का नाम क्या होगा। अगर मुझे एक नाम ढूंढना है तो यह कुछ हद तक शामिल है।

यहां तक ​​कि सोच रहा है कि अंजीर .fig निर्देशिका के अंदर एक स्थानीय भंडारण में आईडी द्वारा कंटेनरों का ट्रैक रख सकता है

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

"अनुमानित रूप से" प्रोजेक्ट-नेम फ़ाइल या "स्पष्ट रूप से" अंजीर इनिट के माध्यम से बनाने पर कोई विचार?

मुझे लगता है कि स्पष्ट रूप से अधिक पीछे संगत होगा। मैं एक fig init से बचना चाहूंगा जब तक कि बिल्कुल आवश्यक न हो। आधार का उपयोग करने के बजाय, मैं इसे <basename>-<4 digit random id> का प्रोजेक्ट नाम बनाते हुए देख सकता था

मैं केवल यह कह सकता हूं कि अगर अंजीर यादृच्छिक नाम उत्पन्न करना शुरू कर देता है तो मैं इससे दूर हो जाऊंगा क्योंकि मैं एक ही होस्ट पर 1000+ कंटेनर चलाता हूं और जब मैं उन्हें किसी भी नाम से पहचानता हूं तो यह मेरे लिए कुछ भी नहीं है।

@ फ्रैंक- dspeed अपने उपयोग-मामले को जोड़ने के लिए धन्यवाद। अगर मैं सही ढंग से समझता हूं, तो आप अंजीर के साथ अपने कंटेनरों को _start_, लेकिन _ "Docker के माध्यम से सीधे" प्रबंधित करें ", उसके बाद नामकरण सम्मेलन का उपयोग करना जो अंजीर का उपयोग करता है?

शायद यह आपके लिए भी रूचिकर है: https://github.com/docker/docker/pull/9882 - मेटा-डेटा होने से कंटेनरों की पहचान करने के अधिक तरीके मिलेंगे, न केवल उनका नाम।

आह हाँ, मैंने इस तरह के प्रस्तावों को बहुत कुछ किया है उदाहरण के लिए बस नई छतों को जोड़ना और लेकिन मैं उस मामले में बस एक ईएनवी को जोड़ने के साथ समाप्त हो गया और फिर मेरे पास है कि कॉस्टयूम फ़िल्ड के रूप में मैं इसे पार्स कर सकता हूं: डार्ट:

मुझे लगता है कि परियोजना के नाम की अस्पष्टता को प्रबंधित करना अंजीर की जिम्मेदारी नहीं होनी चाहिए।

जब मैंने आपके प्रस्ताव को सही ढंग से समझा, तो एक यादृच्छिक नाम की पीढ़ी FIG_PROJECT_VARIABLE और --project-name -पोज़िशन को बेकार कर देगी। जो 'अस्थायी' सेवाओं के लिए उपयोगी है।

मुझे लगता है कि परियोजना के नाम की अस्पष्टता को प्रबंधित करना अंजीर की जिम्मेदारी नहीं होनी चाहिए।

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

जब मैंने आपके प्रस्ताव को सही ढंग से समझा, तो यादृच्छिक नाम की पीढ़ी FIG_PROJECT_VARIABLE और --project-name-option को बेकार कर देगी। जो 'अस्थायी' सेवाओं के लिए उपयोगी है।

उपरोक्त चर्चा के बाद, मुझे लगता है कि कुछ इस तरह से काम करेगा

• यदि --project-name प्रदान किया जाता है, तो उस का उपयोग करें (और .project-name लिखें / अपडेट करें? निश्चित नहीं है?)
• कोई --project-name प्रदान नहीं किया गया है, लेकिन FIG_PROJECT_NAME है, FIG_PROJECT_NAME (और .project-name लिखने / अपडेट करें?)
• उपरोक्त में से कोई नहीं, लेकिन .project-name सेट है, .project-name
• इनमे से कोई भी नहीं; एक _random_ नाम बनाएँ और इसे .project-name लिखें

किसी के दृष्टिकोण से जो उन लिपियों में अंजीर का उपयोग करता है जो एक नाम का ध्यान रखते हैं और इसे अंजीर में पास करते हैं, परियोजना में एक नाम संग्रहीत करते हैं (जो मेरे मामले में है लेकिन टेम्पलेट नहीं है) कोई मतलब नहीं है।

और फिर भी, मुझे यह बहुत सहज लगा कि निर्देशिका नाम का उपयोग परिणामी कंटेनरों के नाम पर किया जाता है जब मैं सिर्फ fig up भागता था।
और कहते हैं, आप docker ps -a , यह बहुत उपयोगी नहीं होगा यदि यह यादृच्छिक नामों से भरा हो।

एक विकल्प --random-name आपकी स्थिति में मदद करेगा?
इसके अलावा, मुझे लगता है कि कुछ नामस्थान को प्रतिबिंबित करने के लिए [a-zA-Z0-9_].* प्रीपेन्ड करने की क्षमता व्यापक तैनाती के लिए उपयोगी होगी।

ऐसे informations को स्टोर करने के लिए fig.yml का उपयोग करने के बारे में क्या है?

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

और BC रखने के लिए, लिखें / project.py :: from_config

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

@jderusse मैं कुछ के लिए बहुत पसंद हूँ जैसा आपने सुझाया है। हो सकता है कि आप अपने प्रस्ताव को # ४५ में जोड़ना चाहें क्योंकि इस पर चर्चा करने के लिए यह बेहतर जगह है?

वैसे भी इस टिकट पर संकल्प लेने के लिए? ऐसा लगता है कि प्रस्तावित # 1233 आपको दोनों दुनिया का सर्वश्रेष्ठ देता है, जिससे उपयोगकर्ता किसी भी पश्चगामी संगतता को न तोड़ते हुए इच्छित कार्रवाई का निर्णय ले सकता है।

मूल रूप से मैं docker-compose.yml में नाम चाहता था, लेकिन इसके बारे में अधिक सोचने के बाद, मुझे वास्तव में एक अलग फाइल का विचार पसंद है।

यदि आप चाहते हैं तो एक अलग फ़ाइल आपको संस्करण नियंत्रण से बाहर रखने का विकल्प देती है (उन मामलों के लिए जहां आप चाहते हैं कि प्रत्येक उपयोगकर्ता एक अलग प्रोजेक्ट नाम रखने में सक्षम हो)।

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

मैं इस बात से सहमत हूं कि dnephin ने क्या कहा। कैसे एक फ़ाइल के बारे में .docker-compose ? हम वहां सभी कमांड लाइन तर्कों के लिए डिफ़ॉल्ट विकल्प सूचीबद्ध कर सकते हैं।

@dnephin sgtm

@mikehaertl मैंने अपने उदाहरण में .docker-compose फ़ोल्डर का उपयोग किया, लेकिन एक फ़ाइल भी काम कर सकती है, यह इस बात पर निर्भर करता है कि हम कितनी जानकारी संग्रहीत करना चाहते हैं

@thaJeztah ओह, ठीक है, क्षमा करें। मैंने यह खो दिया।

@mikehaertl ने सिर्फ .fig से .docker-compose ;-) तक उनका नाम बदला;

सही :)

वास्तव में मैं एक साधारण फ़ाइल पसंद करूंगा। कैसे ini शैली के बारे में? शीर्ष पर वैश्विक विकल्प, एक अनुभाग में विशिष्ट विकल्प चुनें:

project-name = blabla

[build]
no-cache

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

• नेटवर्क नाम (उपयोगकर्ता प्रोजेक्ट नाम से भिन्न नेटवर्क नाम चाहते हैं। हमारे पास इसके लिए पहले से ही एक अनुरोध है।)
• ग्राहक एपीआई संस्करण
• मेजबान मेजबान
• डिफ़ॉल्ट मान

अब जब हम कई कम्पोज़ फ़ाइलों का समर्थन करते हैं, तो कॉन्फ़िगरेशन के रूप में उपयोग करने के लिए कंपोज़ फ़ाइलों के पथों को शामिल करना भी दिलचस्प हो सकता है।

ग्राहक एपीआई संस्करण

संभवतः docker_host ?

यह एक अच्छा की तरह लगता है (जोड़ा)

मैं बस इस समस्या में भाग गया।

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

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

यहाँ भी, मैंने Makefile लक्ष्यों के साथ एक समान समस्या हल की। लेकिन फिर भी, जब आप कस्टम पर अमल करना चाहते हैं docker-compose आदेश, आप का उपयोग करने की आवश्यकता है -p customname ।

अभी मैं एक दूसरे के कंटेनरों पर कदम रखने से /home/alice/myproject और /home/bob/myproject में docker-compose setups को रोकने का तरीका जानने की कोशिश कर रहा हूँ। क्या केवल अंतिम निर्देशिका नाम के बजाय पूर्ण फ़ाइल पथ से कंटेनर नामों को प्राप्त करने का एक तरीका है?

@ क्रिस-मार्टिन यह केवल एक समाधान है ...

alias docker-compose="docker-compose -p ${PWD}"

हालांकि, परियोजना के नामों में से / स्ट्रिप्स-रचना करते हैं, हालांकि?

क्या यह प्रलेखित है कि परियोजना के नामों में किन वर्णों की अनुमति है?

मैंने अपनी निर्देशिका संरचना को बदलने और प्रोजेक्ट रूट में docker-compose.yml डालने का काम किया, जो कि एक पर्याप्त पर्याप्त बदलाव है

यह कुछ सुरक्षा प्रदान करता है, यदि आप अपने सभी git रिपॉजिटरी को एक ही डायरेक्टरी (जैसे, $ HOME, या $ HOME / प्रोजेक्ट्स) में डालते हैं, लेकिन यदि आप किसी अन्य संरचना (जैसे, एक डायरेक्टरी प्रति संगठन) का उपयोग करते हैं, तो यह परेशानी में पड़ जाता है। अक्सर करते हैं), या यदि आपकी मशीन boot2docker का उपयोग करती है, जो एक ही बॉक्स पर उपयोगकर्ताओं के बारे में जानकारी लीक करने की प्रवृत्ति रखती है, जब तक कि आप यह सुनिश्चित करने के लिए सावधान न हों कि docker- मशीन आपको अलग-अलग VM देता है।

मुझे लगता है कि # 2294 या सिर्फ डॉकटर-मशीन के साथ अधिक स्वच्छ रहने से मेरी समस्याएं भी ठीक हो जाएंगी।

मैं इसे प्रोजेक्ट रूट में डालने की भी सिफारिश करूंगा और इसका एक अलग फ़ोल्डर नाम होगा।

मेरे मामले में मैं प्रारंभिक परियोजना का नाम निर्धारित करना चाहूंगा क्योंकि मेरे पास AWS पर एक साझा मशीन है और हालांकि मेरे पास docker-compose.yml है जो रूट में उपयोगकर्ता एक रिपॉजिटरी को एक अलग नाम के साथ निर्देशिका में क्लोन कर सकता है। यदि वर्तमान में ऐसा होता है तो वे कंटेनरों को शुरू करने / रोकने के मुद्दों में भाग लेते हैं।

नए v2 सिंटैक्स को इस तरह लागू किया जा सकता है जैसे कि https://github.com/docker/compose/issues/745#issuecomment -74028861 में उल्लिखित है

यह वास्तव में सिर्फ एक container_name_prefix , है ना?

@ schmunk42

यह वास्तव में सिर्फ एक कंटेनर_नाम_प्रूफ है, है ना?

इसे volume_name_prefix , image_name_prefix और network_name_prefix रूप में भी उपयोग किया जाता है, इसलिए मेरा अनुमान है कि project_name अधिक सामान्य शब्द है।

.docker-compose docker-compose.override.yml । इसके अलावा, हम एक और कॉन्फ़िगरेशन प्रारूप (जैसे ini) क्यों पेश करते हैं, जब हम पहले से ही YAML मिला है?
इसलिए मैं @JoseusEarl के उपयोग के मामले को सक्षम करने के लिए # 745 (टिप्पणी) में @jderusse के सुझाव के पक्ष में project_name कुंजी docker-compose.yml जोड़ने के पक्ष में हूं।

उपयोगकर्ता-विशिष्ट अनुकूलन पहले से ही docker-compose.override.yml का उपयोग करके और .gitignore माध्यम से इसे छोड़कर लागू किया जा सकता है।
यदि कोई तीसरा स्पष्ट उपयोगकर्ता-विशिष्ट ओवरराइड फ़ाइल वांछित है, तो मैं .docker-compose.local-override.yml सुझाव

YAML की संरचना के बारे में, मैं एक नई शीर्ष-स्तरीय कुंजी बनाने का सुझाव दूंगा जिसका नाम project , जिसमें project_name , और भविष्य में अन्य चर हो सकते हैं। यह शीर्ष-स्तरीय नाम स्थान को प्रदूषित करने से बचता है। उदाहरण देकर स्पष्ट करने के लिए:

project:
  project_name: "your-project"
  network_prefix: "abc"

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

• पहला मामला है "नेटवर्क को केवल एक अनूठा नाम दें, लेकिन मुझे परवाह नहीं है कि कौन सा वास्तव में है"। इस मामले के लिए, project_name पर्याप्त है।
• अन्य मामले नेटवर्क हैं जो बाहरी सिस्टम द्वारा संदर्भित होते हैं। इस मामले में, नेटवर्क नामों को स्पष्ट रूप से निर्दिष्ट करना संभवतः वैसे भी बेहतर है।

ऊपर प्रस्तावित सुझाव मुझे अच्छा लगता है, मैं मानता हूं कि हम कोई अतिरिक्त कॉन्फिग फाइल नहीं लाना चाहते हैं

इस मुद्दे की अवधारणा पर +1
लेकिन हमारे रेपो में एक और फ़ाइल जोड़ने के बजाय docker-compose.yml में एक कुंजी का उपयोग करने पर भी +1।

पहले की टिप्पणियों को सम्‍मिलित करने के लिए: परियोजना के नाम के लुकअप अनुक्रम का एक प्रस्ताव इस प्रकार होगा; पहले की वस्तुएं बाद के लोगों से पूर्वता लेती हैं:

1. यदि निर्दिष्ट हो तो --project-name उपयोग करें
2. निर्दिष्ट करने पर COMPOSE_PROJECT_NAME उपयोग करें।
3. का प्रयोग करें project_name से कुंजी docker-compose.yml (या जहाँ भी उस सेटिंग संग्रहीत किया जाता है)।
4. प्रोजेक्ट डायरेक्टरी के basename का उपयोग करें

मैं 2 बनाम 3 की प्राथमिकता के बारे में अनिश्चित हूं:

• --project-name साथ संगति के लिए, COMPOSE_PROJECT_NAME निश्चित रूप से project_name: ओवरराइड करना चाहिए।
• लेकिन: COMPOSE_PROJECT_NAME project_name: से अधिक पूर्वता लेना पर्यावरण के परिवर्तन के कारण गलत प्रोजेक्ट नाम का गलती से उपयोग करना संभव बनाता है; यह डीबग करना कठिन हो सकता है। हो सकता है कि चेतावनी संदेश इस मामले में समस्या हो?

बीसी रखने के लिए डिफ़ॉल्ट मूल्य %(project_name)s_%(service_name)s_%(instance_number)s साथ एक नई संपत्ति container_name_pattern के बारे में क्या है
यह पैरामीटर हमें इसे hardcodedproject_%(service_name)s_%(instance_number)s बदलने और निश्चित रूप से इस समस्या को हल करने के लिए स्वतंत्र करता है

मैं 10 मिनट के लिए इस कार्यक्षमता को देखने के बाद सिर्फ इस मुद्दे पर आया हूं।

पहली चीज़ जो मैंने लिखी थी वह कम्पोज़ फ़ाइल संदर्भ दस्तावेज़ में सही कुंजी के लिए खोज रहा था, इसलिए project_name 1 के लिए +1 docker-compose.yml में कुंजी

: +1: @ cr7pt0gr4ph7 रणनीति के लिए

@ Cr7pt0gr4ph7 रणनीति के लिए +1

रचना में पर्यावरण प्रतिस्थापन के लिए वाक्यविन्यास है। परियोजना के नाम के लिए एक पर्यावरण चर का उपयोग करने के बजाय, शायद लोग इसकी देखभाल स्वयं करते हैं?

दूसरी ओर, docker मशीन यह तय करने के लिए अंत का उपयोग करती है कि किस मशीन पर एक कम्पोज़ बिल्ड बनाया जाएगा, इसलिए हो सकता है कि परियोजना का नाम और लक्ष्य समान रूप से काम करें। हम्म, यह एक कठिन है।

https://github.com/docker/compose/issues/745#issuecomment -182296139 सही लगता है। वातावरण चर कंपोज़ फ़ाइल में मान पर पूर्ववर्तीता लेगा, जो एक डिफ़ॉल्ट के रूप में कार्य करता है (यह मानकर कि प्रोजेक्ट नाम कंपोज़ फ़ाइल में है)।

कुछ पर विचार करने के लिए, क्या होता है जब आप एकाधिक कंपोज़ फ़ाइलों का उपयोग करते हैं जो प्रत्येक प्रोजेक्ट नाम को परिभाषित करते हैं?

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

हो सकता है कि एक चेतावनी उचित हो, या हो सकता है कि हम इसे पूरी तरह से अनदेखा कर दें (क्योंकि किसी विकल्प या पर्यावरण चर को सेट करके मान को अनदेखा किया जा सकता है)।

कुछ पर विचार करने के लिए, क्या होता है जब आप एकाधिक कंपोज़ फ़ाइलों का उपयोग करते हैं जो प्रत्येक प्रोजेक्ट नाम को परिभाषित करते हैं?

यदि आप docker-compose -f compose1.yml -f compose2.yml up जैसा कुछ करते हैं और दोनों फाइलें प्रोजेक्ट नाम को परिभाषित करती हैं, तो प्रयुक्त नाम compose2.yml से होना चाहिए।

मुझे लगता है कि हर कोई एक समाधान पर है जो मुझे पहले से पसंद है: -) I do project_name -

HTTP 500 आंतरिक सर्वर त्रुटि पृष्ठों में मेरी परियोजना में, मैं डेवलपर को बताता हूं कि समस्या को कैसे ठीक किया जाए या उसका निवारण कैसे किया जाए, उदाहरण के लिए मैं उसे बताता हूं कि वह / वह zcat database-dump.tgz | docker exec -i projectname_db_1 psql यदि सर्वर ने नोट किया कि कोई PostgreSQL डेटाबेस नहीं है; उपयोगकर्ता बनाया गया है - और फिर मैं स्वयं projectname का चयन करना चाहता हूं, अन्यथा मदद संदेशों को कंसोल में कॉपी-पेस्ट नहीं किया जा सकता है।

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

@ Cr7pt0gr4ph7 रणनीति के लिए +1

किसी मुद्दे को खोलने से पहले कुछ खोजने की कोशिश की क्योंकि मुझे कुछ भी नहीं मिला।
+1 project_name के लिए docker.compose.yml फ़ाइल में। V2 के साथ मुझे लगता है कि यह अधिक से अधिक समझ में आता है।

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

यह पर्यावरण चर के लिए विन्यास सेटिंग्स को ओवरराइड करने के लिए और कॉन्फ़िगरेशन सेटिंग्स और पर्यावरण चर को ओवरराइड करने के लिए कमांड लाइन तर्क के लिए बहुत सामान्य व्यवहार है।
क्या हम वास्तव में उसके लिए एक चेतावनी है? ऐसा नहीं है कि कोई भी गलती से COMPOSE_PROJECT_NAME नामक एक पर्यावरण चर बना लेगा।

क्या ऐसा पीआर बनाना ठीक रहेगा जो इसे प्राप्त करने के लिए project_name docker-compose.yml का उपयोग करता है? या क्या हम project_name मूल्य को पिछले yml फ़ाइल से तुरंत उपयोग करने जैसा अतिरिक्त सामान चाहते हैं?

इस बारे में कैसा है?

version: "2"
project:
    default_name: "app"

मैं इस प्रारूप के लिए अपना कार्यान्वयन (https://github.com/docker/compose/pull/3118) बदल दूंगा। लेकिन मुझे यकीन नहीं है कि project अनुभाग की कोई आवश्यकता है ...।

+1 इस सुविधा को देखने के लिए उत्सुक रहें

@timgriffiths , ऐसा लगता है कि यह नवीनतम RC में आपकी परियोजना में एक पर्यावरण फ़ाइल जोड़कर संभव है:

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

@deizel तो मैंने पर्यावरण फ़ाइल को देखा, लेकिन मुझे अभी भी लगता है कि

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

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

आपके मामले में @edevenport आप नामित संस्करणों के बाहरी विकल्प का उपयोग कर सकते हैं:

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

धन्यवाद @fesor - मुझे और विस्तार में जाना चाहिए था। मैं वास्तव में इस तरह के एक विन्यास का उपयोग करके चमकता हुआ वॉल्यूम बढ़ा रहा हूं:

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

इस मामले में, होस्ट पर media projectname_media media हो जाता है और तब तक माउंट करने में विफल रहता है जब तक कि प्रोजेक्ट नाम के साथ समय से पहले glusterfs वॉल्यूम नहीं बनता है। मैंने सोचा था कि मेजबान पर glusterfs संस्करणों को मैन्युअल रूप से बढ़ते हुए और docker-compose फ़ाइल में external का उपयोग कर रहा हूं, लेकिन मुझे समय से पहले सभी नोड्स पर मैन्युअल रूप से ऐसा नहीं करना होगा।

@ साभार मैं समझता हूँ कि। लेकिन आप केवल docker volume create साथ इस वॉल्यूम को मैन्युअल रूप से जोड़ सकते हैं और इसका उपयोग कर सकते हैं:

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

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

@timgriffiths का मामला कुछ अधिक जटिल है, और इसमें कोई वर्कअराउंड नहीं है। मैं केवल docker-compose आसपास साधारण रैपर का उपयोग करता हूं ताकि परियोजना के नाम याद न रहें।

@fesor इसलिए हमने वर्णनात्मक फ़ोल्डर नामों में

@timgriffiths मैंने एक PR (https://github.com/docker/compose/pull/3118) बनाया - शायद इससे मदद मिलेगी। यदि आपके पास एकाधिक कंपोज़ फ़ाइलें हैं तो यह आपके मामले को संभालती नहीं है।

@fesor कि पीआर सही होगा क्या यह विलय होने की संभावना है?

अब कम्पोज़ पर्यावरण फ़ाइल प्रदान करता है, इसलिए परियोजना का नाम वहां रखा जा सकता है।

@mkuzmin यह दुखद है कि COMPOSE_FILE लेकिन COMPOSE_OVERRIDE_FILE ।

@fesor AFAIK आप कई फाइलें निर्दिष्ट कर सकते हैं

@ schmunk42 मैं या तो प्रोजेक्ट का नाम निर्दिष्ट कर सकता हूं। लेकिन इससे समस्या हल नहीं होती है। मैं स्क्रिप्ट को कुछ इस तरह से रखना चाहता हूं:

docker-compose up -d

के बजाय

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

COMPOSE_PROJECT_NAME ऊपर के उदाहरण में CI द्वारा निर्दिष्ट किया गया है। और .env फ़ाइल जैसी सुविधा शांत है लेकिन ... प्रोजेक्ट नाम की दृढ़ता के मामले में बेकार है।

मैं .env DRY env वैरिएबल का उपयोग करता हूं (और docker- रचना के लिए <1.7 मेरे पास सरल आवरण है), लेकिन यह किसी भी अन्य मुद्दों को हल नहीं करता है। @timgriffiths पहले से ही झुंड क्लस्टर पर तैनाती के साथ मामले पर बताया।

COMPOSE_FILE=one.yml:two.yml एकाधिक फ़ाइलों को सेट करने का तरीका है। तो बस $COMPOSE_FILE में ओवरराइड फ़ाइल शामिल करें

@dnephin ने उस सुविधा को याद किया, अच्छा।

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

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

जबकि .env साथ वर्कअराउंड अच्छा है, यह प्रयोग करने योग्य नहीं है ( .env फ़ाइल आपके एप्लिकेशन द्वारा पहले से ही उपयोग की जा सकती है)। और यह अभी भी एक समाधान है।

और मैंने अन्य नए मुद्दों को भी देखा है जो परियोजना के नाम से संबंधित हो सकते हैं नवीनतम संस्करण (# 3966)।

तो वास्तव में समस्या क्या है?

क्या docker-compose.yml फ़ाइलों के लिए एक साधारण नए कॉन्फ़िगरेशन निर्देश को जोड़ना वास्तव में इतना कठिन है?

नहीं! इस मुद्दे को लागू करने में कभी कठिनाई नहीं हुई।

जबकि .env साथ वर्कअराउंड अच्छा है, यह प्रयोग करने योग्य नहीं है ( .env फ़ाइल आपके एप्लिकेशन द्वारा पहले से ही उपयोग की जा सकती है)। और यह अभी भी एक समाधान है।

यह एक समाधान नहीं है, यह एक समाधान है! .env फ़ाइल में पर्यावरण चर शामिल हैं जिन्हें कम्पोज़ द्वारा पढ़ा जाना है। यदि आपके पास पर्यावरण चर हैं जो आपके एप्लिकेशन द्वारा पढ़े जाने हैं, तो उन्हें एक अलग फ़ाइल में डालें ( app.env ) और env_file विकल्प का उपयोग करके इसे संदर्भ दें।

तो वास्तव में समस्या क्या है?

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

एक डॉकटर-कम्पोज़.माइल फ़ाइल में प्रोजेक्ट का नाम जोड़ने से यह कम पोर्टेबल हो जाता है,

क्या यह वैकल्पिक नहीं हो सकता है? व्यक्तिगत रूप से मैं अपने docker-compose.yml में कभी भी जांच नहीं करता हूं, लेकिन केवल अपने रेपो में docker-compose-example.yml आपूर्ति करता हूं जो स्थानीय रूप से ट्विक करता है। उदाहरण के लिए, विकास के दौरान मैं अपने कंटेनर में कुछ अतिरिक्त env var या मैप जोड़ सकता हूं। हमें परियोजना का नाम निर्दिष्ट करने का विकल्प भी क्यों नहीं दिया जाए?

अपने तर्क के बाद, आपको सभी network विकल्पों को .env स्थानांतरित करना चाहिए क्योंकि वे आमतौर पर पोर्टेबल नहीं होते हैं और आपके होस्ट मशीन के नेटवर्क सेटअप पर निर्भर करते हैं।

एक और तरीका रखो: क्या परियोजना का नाम इतना खास बनाता है? पहले से ही docker-compose.yml में कई अन्य विकल्प हैं जो वास्तव में पोर्टेबल नहीं हैं। क्यों नहीं डेवलपर को अपने उपयोग के मामले में सबसे अच्छा चुनने का विकल्प दिया जाए?

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

मुझे लगता है कि गोद लेने के लिए यहां एक परियोजना का नाम विकल्प लागू करना महत्वपूर्ण है। यह एकल डेवलपर्स को फेंक सकता है जो "स्केलेबल प्रोजेक्ट नाम कॉन्फ़िगरेशन रणनीति" के बारे में परवाह नहीं करते हैं।

एक डॉकटर-कंपोज़.आईएमएल फ़ाइल में प्रोजेक्ट का नाम जोड़ने से यह कम पोर्टेबल हो जाता है, जो ऐसी कोई चीज नहीं है जिसे हम प्रोत्साहित करना चाहते हैं। अब जब डॉकटर-कम्पोज़िट.मैएल के पोर्टेबिलिटी का त्याग किए बिना परियोजना के नाम को लगातार निर्दिष्ट करने का एक तरीका (.env) है, तो इसे कॉन्फ़िगरेशन विकल्प के रूप में जोड़ने का मामला कमजोर है। यह प्राथमिक कारण है कि यह समस्या आगे नहीं बढ़ी है।

docker-compose.yml लिए प्रोजेक्ट का नाम जोड़ने से यह कम पोर्टेबल कैसे हो जाता है?

IMHO यह वास्तव में विपरीत है, जैसा कि # 3966 @mikehaertl द्वारा बनाया गया है। यह समस्या स्पष्ट रूप से दिखाती है कि परियोजना का नाम docker-compose.yml में संग्रहीत नहीं होना वास्तव में चीजों को कम पोर्टेबल बनाता है (जैसा कि: एक ही मशीन से शुरू की गई अन्य रचना परियोजनाओं के साथ टकराव की एक बड़ी संभावना है) क्योंकि कंपोज़ एक सम्मेलन पर निर्भर करता है कंटेनर फ़ोल्डर का नाम जो बहुत से लोग, कम से कम शुरू में नहीं जानते होंगे।

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

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

क्लोन रेपो
docker- रचना करना

मेरा वर्कअराउंड अभी भी उस फ़ाइल को बनाना है जो @ schmunk42 ने प्रस्तावित किया है।

कंटेनर को परियोजना के नाम की परवाह नहीं करनी चाहिए। पर्यावरण चर का उपयोग केवल मेजबान की देखभाल के लिए एक तंत्र के रूप में क्यों किया जाता है?

मैं docker-compose.yml फ़ाइल में इसके लिए समर्थन देखना पसंद करूंगा। यदि किसी को पर्यावरण चर के माध्यम से इसे सेट करने की आवश्यकता है, तो इसे .env फ़ाइल (यदि होस्ट पर सीधे सेट नहीं किया गया है) के भीतर और docker-compose.yml फ़ाइल में चर प्रतिस्थापन के माध्यम से उपयोग किया जा सकता है।

यदि नामित कंटेनरों को अनुमति दी जाती है तो नामित परियोजनाओं को अनुमति क्यों नहीं दी जाएगी?

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

कंटेनर नाम में परिवर्तनीय प्रतिस्थापन काम में आता है, जिसमें उपसर्ग के रूप में $ COMPOSE_PROJECT_NAME है। वैसे मैं .env- फ़ाइल समाधान को समझता हूं, लेकिन यह एक (CI) परिनियोजन वातावरण में इसे "डेवलपर के अनुकूल" नहीं बनाता है।

एक अलग-अलग डॉक-कंपोज के डॉकटर-कम्पोजिट किल कंटेनर होने से क्योंकि कोई-पी या एनवायरनमेंट वेरिएबल सेट नहीं था और आपने "डॉकटर" सबफ़ोल्डर में डॉकटर-कंपोज़ बनाया, यह मेरी राय में एक महत्वपूर्ण बग है।

गंभीर तैनाती में त्रुटि के लिए बस बहुत जगह है। बस प्रोजेक्ट का नाम निर्दिष्ट करना न भूलें, चाहे वह -p, .env या कहीं और हो: आप कुछ समय के लिए ऑफ़लाइन जाते हैं जब तक आप नोटिस नहीं करते कि क्या हुआ। इससे भी बदतर: टकराव सेवा ऑफ़लाइन हो जाती है, न कि आप जिस पर काम कर रहे हैं। आपका दिन शुभ होगा :(

@dnephin वास्तव में आखिरकार इसे लागू करने के लिए

हो सकता है कि मैं यहां केवल वही हूं, जिसे इससे कुछ चिंता है, लेकिन फिर भी।
हमारे सेटअप में, हम केवल .env और app.env फ़ाइलों को परिवेशों को बदलने के लिए संशोधित करते हैं, लेकिन यह कई फ़ाइलों के होने और yml फ़ाइलों को मर्ज करने पर निर्भर करता है।

यदि यह लागू हो जाता है, तो कृपया बीसी के बारे में सोचें।

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

@ schmunk42 हम यह नहीं कह रहे हैं, कि .env सुविधा को हटा दिया जाना चाहिए। यदि आप .env में अपनी परियोजना का नाम रखना पसंद करते हैं, तो बस इसे docker-compose.yml में कॉन्फ़िगर न करें।

लेकिन अन्य लोग इसे अपने docker-compose.yml में पसंद करते हैं क्योंकि यहां चर्चा स्पष्ट रूप से दिखाई देती है। वे ऐसा करने में सक्षम होना चाहिए, अगर वे चाहते हैं। यह एक वैकल्पिक विशेषता है। यदि दोनों कॉन्फ़िगर किए गए हैं, तो एक साधारण सम्मेलन को परिभाषित करने का मामला क्या है।

कृपया, नाम वाली परियोजनाओं को जोड़ें। उदाहरण:
एक परियोजना:
docker-compose up --build --remove-orphans

• nginx
• स्थिर सामग्री
  परियोजना दो:
  docker-compose up --build --remove-orphans
• nginx
• स्थिर सामग्री

जब परियोजना दो शुरू होती है, तो यह परियोजना के कंटेनरों को 137 (कोड 128 + स्तर 9) से बाहर निकलने के साथ मार देती है।

अब मुझे दर्जनों डेड कंटेनर रखने से खुद को बचाने के लिए docker system prune चलाना होगा और हर दिन नेटवर्क का पुनर्निर्माण करना होगा।

export COMPOSE_PROJECT_NAME=somethingnew

क्या कोर टीम का कोई व्यक्ति शायद समझा सकता है कि यह सुविधा क्या है? यह बहुत निराशाजनक है, कैसे चीजें हैं जो ठीक करने के लिए बहुत आसान हैं बिना किसी अच्छे कारण के अवरुद्ध हैं।

अब तक का एकमात्र तर्क docker-compose.yml पोर्टेबल रखने का था। इसका कोई मतलब नहीं है, क्योंकि

• कंपोज़र फ़ाइल में प्रोजेक्ट का नाम स्वचालित रूप से इसे पोर्टेबल नहीं बनाता है
• सभी को इसकी आवश्यकता भी नहीं है
  
  
  
  • हमारे पास पहले से ही अन्य विकल्प हैं जो पोर्टेबिलिटी को उसी तरह से सीमित कर सकते हैं: networks , port , ...
  
  

यह सभी बहुत विशिष्ट उपयोग के मामले पर निर्भर करता है। लेकिन सिर्फ इसलिए कि कुछ लोग यह विकल्प नहीं चाहते हैं, इसका मतलब यह नहीं होना चाहिए कि हर किसी को उनकी राय का पालन करना चाहिए!

@mikehaertl आपके पास पहले से ही लगातार प्रोजेक्ट नाम हैं। बस .env फ़ाइल रखो और वहाँ COMPOSE_PROJECT_NAME चर सेट करें। मुझे अब कंपोज फाइल में प्रोजेक्ट के नाम का कोई फायदा नजर नहीं आ रहा है।

@fesor I आम तौर पर न ही .env फ़ाइल संस्करण-नियंत्रण में होती हैं क्योंकि उनमें मशीन / पर्यावरण-विशिष्ट सेटिंग्स होती हैं - यही कारण है कि मैं docker-compose.yml फ़ाइल में प्रोजेक्ट नाम को कॉन्फिगरेबल होते देखना चाहता हूँ ।

@fesor : मुझे लगता है कि @thasmo इस पर सही है। परियोजना का नाम compose.yml फ़ाइल में निर्दिष्ट होने का विकल्प होना चाहिए क्योंकि यदि यह परियोजना का उपयोग करने वाले सभी डेवलपर्स के लिए प्रासंगिक है, तो यह संस्करण नियंत्रण में होना चाहिए।

@fesor मुझे खेद है, लेकिन मुझे नहीं लगता कि व्यक्तिगत प्राथमिकता एक वास्तविक तर्क है। असली सवाल यह नहीं है कि हम .env या पर्यावरण चर का उपयोग क्यों नहीं करना चाहते हैं। यह दूसरा तरीका है: इसे उस कॉन्फ़िगरेशन फ़ाइल में क्यों नहीं रखा गया, जहां यह है?

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

और फिर से: कोई भी आपसे पुराने विकल्प को नहीं छीन रहा है - हम केवल अंततः इस अतिरिक्त विकल्प को चाहते हैं। वह केवल उचित है।

@dnephin : ऐसा लगता है जैसे आप और बाकी सभी इस मुद्दे के cr7pt0gr4ph7 के शोधन में बताए गए समाधान से खुश हैं।

क्या आप एक पुल अनुरोध स्वीकार करने के लिए तैयार होंगे जो इसे लागू करता है, या क्या आप इसे बनाए रखने वालों में से किसी एक को लिखना चाहते हैं?

@ cr7pt0gr4ph7

@dnephin @fesor * compose.yml में प्रोजेक्ट का नाम एक एकीकृत कॉन्फ़िगरेशन स्कीमा की सुविधा देता है

यह मेरे लिए स्पष्ट नहीं है कि परियोजना का नाम क्यों मायने रखता है। कॉन्फ़िगरेशन फ़ाइल का कोई भी भाग किसी विशेष प्रोजेक्ट नाम पर निर्भर नहीं होना चाहिए।

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

जब डिफ़ॉल्ट सही नहीं होता है, तो डेवलपर के पास इसे ओवरराइड करने का एक तरीका है ( -p , या COMPOSE_PROJECT_NAME ), जो या तो उपनाम हो सकता है या .env फ़ाइल में डाला जा सकता है ।

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

मैं चाहता था कि 1 डायरेक्टरी में 4 कम्पोज़ फाइल्स हों। यहां डिफ़ॉल्ट रूप से निर्देशिका नाम गलत है। एकमात्र विकल्प मेरे पास है .env जो केवल 1 डायरेक्टरी में 1 कंपोज फाइल के लिए काम करता है।

_ तब मैंने COMPOSE_PROJECT_NAME और -p: _ को नियमबद्ध किया
COMPOSE_PROJECT_NAME और -p मेरी राय में उत्पादन में नहीं बचा है क्योंकि आपको उन्हें सेट करना याद रखना है। या एक स्टार्टअप स्क्रिप्ट बनाएं और याद रखें कि सीधे डॉक कंपोज़ का उपयोग न करें। जब व्यक्ति A इस तंत्र पर निर्भर करता है और व्यक्ति B यह नहीं जानता है, तो यह एक निश्चित विफलता है।
(मैंने पहले ही इसे ऊपर विस्तृत कर दिया है)

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

यह मेरे लिए स्पष्ट नहीं है कि परियोजना का नाम क्यों मायने रखता है। कॉन्फ़िगरेशन फ़ाइल का कोई भी भाग किसी विशेष प्रोजेक्ट नाम पर निर्भर नहीं होना चाहिए।

यह मेरे लिए एक से अधिक बार हुआ, कि मैंने एक मेजबान पर एक 'डॉक-कंपोज़ डाउन' किया था - और एक अलग कंटेनर नीचे चला गया था जिसे मैं चाहता था! सिर्फ इसलिए कि मुझे याद नहीं था, कि .env फ़ाइल में भी कॉन्फ़िगरेशन था।

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

हो सकता है कि यह आपके लिए सच myapp/app/docker-compose.yml जैसी है। तो मेरे सभी ऐप डायरेक्टरी नाम app शेयर करते हैं। और मेरे पास एक होस्ट पर 1 से अधिक कंटेनर हैं।

जब डिफ़ॉल्ट सही नहीं होता है, तो डेवलपर के पास इसे (-p, या COMPOSE_PROJECT_NAME) को ओवरराइड करने का एक तरीका होता है, जो या तो उपनाम हो सकता है या .env फ़ाइल में डाला जा सकता है।

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

हमें बार-बार पूछने और हमारे जवाबों को नजरअंदाज करने के बजाय, कोई आखिर प्रतिरोध का औचित्य क्यों नहीं कर सकता। और नहीं: "... लेकिन मुझे इसकी आवश्यकता नहीं है" एक वैध तर्क नहीं है!

@dnephin मेरे पास अपने स्वयं के गिट docker नामक एक सबफ़ोल्डर में डाल देता हूं (बिल्ड संदर्भ सिर्फ .. हो जाता है , सभी सुंदर काम करता है)।

एक ही सर्वर पर कई प्रोजेक्ट चलाने के लिए, मुझे वर्तमान में प्रत्येक रेपो में docker/.env.dist और cp docker/.env.dist docker/.env बाद git clone । अन्यथा, परियोजना का नाम सिर्फ docker , जो मुझे स्पष्ट रूप से नहीं चाहिए। कुछ मामलों में .env में पासवर्ड आदि होते हैं, इसलिए .env.dist नकल करना वैसे भी आवश्यक है, लेकिन ज्यादातर मामलों में .env मौजूद हैं, क्योंकि COMPOSE_PROJECT_NAME को परिभाषित करने का कोई तरीका नहीं है। docker-compose.yml ।

मैं समझता हूं कि कंटेनरों को शुरू करने और बंद करने में गड़बड़ियां हो सकती हैं यदि उसी COMPOSE_PROJECT_NAME का उपयोग docker-compose.yml अंदर दो बार किया जाए, लेकिन यह पहले से ही हो रहा है अगर मैं .env.dist को कॉपी करना भूल .env फ़ाइलों में एक ही नाम निर्दिष्ट करता हूं। मेरे लिए यह आदर्श होगा यदि मैं default_compose_project_name docker-compose.yml में default_compose_project_name परिभाषित कर सकूं और फिर .env में मान को ओवरराइड कर दूं, मान लें कि मैं किसी प्रोजेक्ट की स्टेजिंग कॉपी चलाना चाहता हूं । यह 100% ईसा पूर्व होगा, लेकिन अधिक सुविधाजनक होगा।

मैंने अतीत में यह कहा है, .env मेरे लिए कोई विकल्प नहीं है क्योंकि यह आमतौर पर रेपो का हिस्सा नहीं है जिसे हम सभी साझा करते हैं।

हो सकता है, इसका मूल कारण यह हो, मैंने उस फ़ाइल से पहले docker-compose "अपहृत" किया था और हमें अपना सामान app.env बदलने के लिए मजबूर किया गया था।

शायद docker-compose.env सही विकल्प होता।

एफडब्ल्यूआईडब्ल्यू: हम उत्पादन में केवल .env फ़ाइलों को बदल रहे हैं, yml फ़ाइलों को जरूरत पड़ने पर docker-compose.override.yml साथ मिला दिया जाता है।

एक समाधान यह भी है कि आपकी yml फ़ाइलों को एक तरह से परिभाषित किया जाए, ताकि वे .env फ़ाइल के बिना शुरू न हों, उदा। एक चर image: $IMAGE ।

यह मेरे 4 docker के लिए एक वर्कअराउंड है- @ schmunk42 के ऊपर 1 डायरेक्टरी केस में फाइल तैयार करें? वास्तव में?

@RobIsHere लेकिन आपको -f का उपयोग करने की आवश्यकता है, है ना?

इस टिप्पणी में @dnephin के जवाब में:

यह मेरे लिए स्पष्ट नहीं है कि परियोजना का नाम क्यों मायने रखता है।

यह मायने रखता है क्योंकि यह डॉकर कंटेनरों के नाम को प्रभावित करता है जो docker-compose प्रबंधित करता है। यदि आप परियोजना का नाम सेट करना भूल जाते हैं, तो docker-compose ps को उन कंटेनरों को नहीं मिलेगा जो आपने docker-compose --project-name <project_name> up -d <container_name> साथ बनाए हैं।

इसके अलावा, जब आप वैश्विक कमांड docker ps चलाते हैं, तो प्रोजेक्ट का नाम उन कंटेनरों की सूची में शामिल होगा जो चल रहे हैं, इसलिए आप जानते हैं कि वे कहाँ से आए थे। उदाहरण के लिए, यदि आप एक बार में कई कोड परियोजनाओं का परीक्षण कर रहे हैं जो सभी MySQL का उपयोग करते हैं, और उनमें से प्रत्येक के पास mysql कंटेनर है, तो docker ps कंटेनर की अस्पष्ट सूची दिखाएंगे। तो, एक ही मशीन पर चलने वाली कई डॉकरों परियोजनाओं के संदर्भ में परियोजना का नाम महत्वपूर्ण है।

कॉन्फ़िगरेशन फ़ाइल का कोई भी भाग किसी विशेष प्रोजेक्ट नाम पर निर्भर नहीं होना चाहिए।

डॉकर कंपोज़ प्रोजेक्ट_ से जुड़े अन्य वेरिएबल _every की तुलना में प्रोजेक्ट का नाम अलग जगह पर रखने से कोई मतलब नहीं है।

परियोजना के नाम का एकमात्र महत्वपूर्ण गुण यह है कि यह किसी अन्य परियोजना के नाम के साथ संघर्ष नहीं करता है, जो वास्तव में इसे docker-compose.yml फ़ाइल में डालने के खिलाफ एक तर्क है।

मेरे पहले पैराग्राफ में बताए गए कारणों के लिए, यह _ "प्रोजेक्ट नाम का केवल महत्वपूर्ण गुण" _ नहीं है। यह आसानी से उपयोग और समझ के लिए है।

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

नॉन-डिफॉल्ट मामले में जहां एक डेवलपर docker डायरेक्टरी में _all_ संबंधित डॉकर फाइलें डालता है, जो कि डॉकर प्रोजेक्ट को व्यवस्थित करने के लिए एक पूरी तरह से उचित तरीका है, प्रोजेक्ट नाम सेट करने वाला जादू परस्पर विरोधी प्रोजेक्ट नाम पैदा करेगा। तो वही संघर्ष जो आप उल्लेख करते हैं, इस विशेष मामले में होते हैं। आपको प्रोजेक्ट-नेम टकराव के खिलाफ डेवलपर की रक्षा करने की आवश्यकता नहीं है, जब वे स्पष्ट रूप से वैसे भी प्रोजेक्ट का नाम सेट कर रहे हों।

जब डिफ़ॉल्ट सही नहीं होता है, तो डेवलपर के पास इसे (-p, या COMPOSE_PROJECT_NAME) को ओवरराइड करने का एक तरीका होता है, जो या तो उपनाम हो सकता है या .env फ़ाइल में डाला जा सकता है।

पर्यावरण चर सेट करना जटिलता का एक अतिरिक्त स्तर है जो आवश्यक नहीं है। जब आप संस्करण नियंत्रण के साथ डेवलपर्स के बीच एक परियोजना साझा कर रहे हैं, तो यह केवल फ़ाइलों का उपयोग करने के लिए समझ में आता है। प्रत्येक आह्वान के साथ कमांड-लाइन परम शामिल करना थकाऊ और त्रुटि-प्रवण है। और .env फ़ाइल को संस्करण नियंत्रण में साझा नहीं किया जा सकता है क्योंकि इसमें _user-specific_ चर सम्‍मिलित हैं, न कि _project-specific_ वाले। इसलिए, प्रोजेक्ट नाम सेट करने के मौजूदा तरीके अपर्याप्त हैं।

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

सभी चर जो docker-compose के कामकाज को प्रभावित करते हैं, उसी स्थान पर docker-compose.yml फ़ाइल होनी चाहिए। प्रोजेक्ट नाम सेट करने के वर्तमान तरीके अनावश्यक जटिलता का परिचय देते हैं।

इस मुद्दे पर सदस्यता लिए गए सभी लोग इन बिंदुओं से सहमत हैं।

docker-config.yml में प्रोजेक्ट का नाम सेट करने की क्षमता को जोड़ने से किसी भी मौजूदा कार्यक्षमता के साथ भी संघर्ष नहीं होगा। इसे लागू नहीं करने का कोई कारण नहीं है।

@ schmunk42 पिछली बार जब मैंने जाँच की थी,

मैंने पाया कि जब डॉकर को अपनाया गया था तो यह एक असली स्टबलिंग ब्लॉक था, क्योंकि @RobIsHere दिखाता है। मेरी सभी परियोजना निर्देशिका myapp/htdocs/docker-compose.yml प्रारूप में हैं। डॉकटर को अपनाने के शुरुआती दिनों में मैंने गलती से अन्य कंटेनरों को नष्ट कर दिया था, जिनका मैं इरादा नहीं करता था। यह बेहतर होता अगर डॉकटर नाम दिया जाता है, लेकिन यह मेरे मामले में फ़ोल्डर नाम का उपयोग करते हुए बेतरतीब ढंग से प्रोजेक्ट करता है।

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

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

ऐसे मामले जहां डिफ़ॉल्ट उपयुक्त नहीं हैं:

• एक ही निर्देशिका में कई कंपोज़ फाइलें (पहले से ही आपको चलाने के लिए -f निर्दिष्ट करने की आवश्यकता है)
• सभी परियोजनाओं के लिए समान निर्देशिका नाम का उपयोग करना (मुझे लगता है कि इसके लिए आपको -f निर्दिष्ट करना होगा, संभव है कि एक अद्वितीय निर्देशिका नाम का उपयोग करना संभव हो)।

@dnephin मैं दत्तक ग्रहण के लिए एक कम संभव ठोकर।

@dnephin आपको इस टिप्पणी में ये चिंताएँ भी थीं:

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

इस तरह की पूर्ववर्ती स्थिति का प्रोजेक्ट-नाम रिज़ॉल्यूशन ऑर्डर सेट करने से उस समस्या का समाधान हो जाएगा (बड़ी संख्या छोटी हो गई है)

1. docker-compose.yml
2. COMPOSE_PROJECT_NAME पर्यावरण चर
3. --project-name कमांड-लाइन विकल्प

पिछली बार जब मैंने जाँच की थी, तो हमें हमारे .env फ़ाइल का नाम चुनने की अनुमति नहीं थी।

@fiveanddone AFAIK आप ऐसा नहीं कर सकते हैं, लेकिन यह भी समस्या को आगे

Phd5 के साथ हमारे मामले में, हमने एप्लिकेशन (ऐप) को src/ और .env स्थानांतरित कर दिया है, जो केवल "नियंत्रण-पर्यावरण-फ़ाइल" है, मैंने यहां यह समझाने की कोशिश की।
मुझे यह पसंद नहीं है और मैंने इसे अपने दम पर नहीं बदला है। मुझे पता है कि बहुत सारी परियोजनाओं के लिए यह संभव नहीं हो सकता है।
लेकिन आपके docker-compose.yml के समान स्तर पर आपके एप्लिकेशन से .env होने से यह बहुत अधिक कष्टप्रद हो जाता है, क्योंकि a) आपको अपने "कंट्रोल-एनवायरनमेंट" में वैरिएबल मिलते हैं, जो वहां नहीं हैं और b) आपको अपने कंटेनर में इन चरों को अग्रेषित करना होगा, अगर आपको वहां उनकी आवश्यकता है और ग) आप अपने app.env फ़ाइल में उन्हें ओवरराइड / बदल नहीं सकते हैं।

@dnephin पसंदीदा env फ़ाइल के रूप में docker-compose.env परिचय देने के बारे में क्या है और .env उपयोग एक कमबैक के रूप में करते हैं। आपने fig.yml एक बार के साथ ऐसा ही किया।

मुझे नहीं लगता है कि सभी के लिए समस्या को ठीक करता है। .env फ़ाइल का नामकरण मुझे एक अलग मुद्दे की तरह लगता है।

मुझे लगता है कि समस्या की जड़ यह है:

docker-compose up का मूल डिज़ाइन एक एकल (संक्षिप्त) कमांड होना था जिसे आप सेवाओं को चलाने के लिए चला सकते हैं। डेवलपर्स से यही उम्मीद की जाती है। हालाँकि यह व्यवहार कुछ उपयोगकर्ताओं ( इन मामलों में ) के लिए प्राप्त नहीं किया जा सकता है।

समस्या के आसपास काम करने के बहुत सारे तरीके हैं, लेकिन कोई भी ऐसा नहीं है जो सभी के लिए काम करता हो।

मुझे लगता है कि वरीयता का क्रम (उच्चतम से निम्नतम तक) कुछ इस तरह का होना चाहिए:

1. --project-name (हमेशा ओवरराइड)
2. COMPOSE_PROJECT_NAME पर्यावरण चर
3. उपयोगकर्ता द्वारा परिभाषित एक डिफ़ॉल्ट, किसी भी संस्करण फ़ाइल से अलग
4. परियोजना द्वारा परिभाषित एक डिफ़ॉल्ट, जिसे अंदर चेक किया जा सकता है
5. निर्देशिका नाम (डिफ़ॉल्ट जब कुछ भी निर्दिष्ट नहीं है)

(3) .docker/project-name फ़ाइल के साथ प्राप्त किया जा सकता है (जैसा कि ओपी में प्रस्तावित है)
(4) docker-compose.yml फ़ाइल में एक फ़ील्ड के साथ प्राप्त किया जा सकता है

यह दुर्भाग्यपूर्ण है कि परियोजना के नाम को निर्धारित करने के लिए कई अलग-अलग तरीके होने की आवश्यकता है।

3 के बारे में @dnephin , उपयोगकर्ता को एक डिफ़ॉल्ट सेट करने देता है, जो कि env vars के लिए है, एक फ़ाइल बनाने की कोई आवश्यकता नहीं है

हम्म ... और क्या होगा अगर हम समस्या को थोड़ा सामान्य करते हैं और default_environment अनुभाग docker-compose.yml ? इस तरह हम याम्ल में एक विशेष क्षेत्र को प्रस्तुत किए बिना COMPOSE_PROJECT_NAME स्थापित करने में सक्षम होंगे, लेकिन अन्य डिफ़ॉल्ट चर को भी परिभाषित करने में सक्षम होंगे, जो पूरी फ़ाइल में कहीं और मौजूद होने की संभावना है। यह उन मामलों की संख्या को कम करेगा जब .env.dist को .env कॉपी करने की आवश्यकता होगी और ऐसा करने के लिए भूलने की लागत कम होगी।

उपयोग उदाहरण:

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

यह यम बहुत हद तक मेरे समान है - यह एक विज़ स्केच का वर्णन करता है, जिसमें हमेशा web नामक एक सेवा होती है, लेकिन एक मिनी एपीआई सर्वर और एक डेटाबेस के साथ एक कंटेनर भी हो सकता है। यह माना जाता है कि https://github.com/jwilder/nginx-proxy सब कुछ के सामने बैठता है और वास्तविक पोर्ट्स 80 और 443 को सुनता है।

फिलहाल, कोई फर्क नहीं पड़ता कि मैं किसी स्थानीय मशीन पर हूं या किसी दूरस्थ सर्वर पर, मुझे .env बनाए रखने के लिए याद रखने की आवश्यकता है और यह भी सुनिश्चित करने के लिए कि _all_ पर्यावरण चर वहां सेट हैं। यदि, मान लें, मैं SUBDOMAIN भूल गया हूं, तो कंटेनर शुरू हो जाता है, लेकिन वेब सर्वर टूटा रहता है।

मेरे निपटान में default_environment अनुभाग के साथ, मैं अपने सभी उत्पादन चर एक फ़ाइल में रख सकता था और मुझे सर्वर पर .env.dist प्रतिलिपि नहीं बनानी पड़ेगी। स्थानीय मशीन पर, ऊपर के उदाहरण में मैं सिर्फ .env में एक एकल चर डालूँगा, जो ROOT_HOST=example.com.dev (या शायद मैं export ROOT_HOST=example.com.dev bash प्रोफाइल में भी हो सकता हूँ? )

संक्षेप में, default_environment अनुभाग docker-compose.yml न केवल उस समस्या को हल कर सकते हैं जिस पर हम वर्तमान में चर्चा कर रहे हैं, बल्कि कुछ अतिरिक्त अच्छी चाल को भी सक्षम कर सकते हैं, जबकि 100% BC और समझने में आसान है!

WDYT?

यह अच्छा लगता है, यह कुछ परिदृश्यों में मेरे काम आ सकता है।

हालांकि, ध्यान रखें कि उपरोक्त (गर्म) चर्चा के प्रकाश में, आपकी
समाधान मोटे तौर पर इसका अनुवाद करता है: “इसके बजाय एक नई फ़ाइल जोड़ने के लिए
yml, कैसे के बारे में हम एक नया खंड जोड़ते हैं? ” :)

Tue पर, 28 फरवरी, 2017, 00:02 अलेक्जेंडर कचकेव नोटिफिकेशन @github.com
लिखा था:

हम्म ... और क्या होगा अगर हम समस्या को थोड़ा सामान्य करते हैं और बस परिचय देते हैं
default -env अनुभाग docker-compose.yml में। इस तरह हम परिभाषित करते हैं
COMPOSE_PROJECT_NAME yaml में एक विशेष फ़ील्ड प्रस्तुत किए बिना, लेकिन
अन्य डिफ़ॉल्ट चर को भी परिभाषित करने में सक्षम होगा, जो होने की संभावना है
पूरे फाइल में कहीं और मौजूद है। इससे केस की संख्या कम हो जाएगी
जब .env.dist को .env और भूलने की लागत की नकल करने की आवश्यकता हो
ऐसा कम होगा।

उपयोग उदाहरण:

~ / परियोजनाओं / नमूने / स्केच-42 / डोकर / डोकर-compose.yml

संस्करण 2"
default_env:
SUBDOMAIN = स्केच-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = स्केच-42
सेवाएं:
वेब:
निर्माण:
संदर्भ: ../
dockerfile: docker / Dockerfile
वातावरण:
- VIRTUAL_HOST = $ {SUBDOMAIN}। $ {ROOT_HOST}, www। $ {SUBDOMAIN}। $ {ROOT_HOST
- VIRTUAL_PORT = 80
- VIRTUAL_NETWORK = प्रॉक्सी
- LETSENCRYPT_HOST = $ {SUBDOMAIN}। $ {ROOT_HOST}}, www। $ {SUBDOMAIN}। $ {ROOT_HOST}
- LETSENCRYPT_EMAIL = व्यवस्थापन @ $ {ROOT_HOST}
पुनरारंभ: हमेशा
नेटवर्क:
- प्रॉक्सी

नेटवर्क:
प्रॉक्सी:
बाहरी:
नाम: प्रॉक्सी

यह याम्ल बहुत ही समान है जो मेरे पास बहुत बार है - यह एक विज़ का वर्णन करता है
स्केच, जिसमें हमेशा एक सेवा होती है जिसे वेब कहा जाता है, लेकिन इसका बैकअप भी लिया जा सकता है
एक मिनी एपीआई सर्वर और एक डेटाबेस के साथ शायद एक कंटेनर द्वारा। यह माना जाता है
वह https://github.com/jwilder/nginx-proxy सामने बैठकर सुनता है
असली बंदरगाहों के लिए 80 और 443।

फिलहाल, कोई फर्क नहीं पड़ता कि मैं स्थानीय मशीन पर हूं या रिमोट सर्वर पर,
मुझे बनाए रखने के लिए याद रखने की जरूरत है। Iv और यह भी सुनिश्चित करने के लिए कि सभी
पर्यावरण चर वहाँ स्थापित कर रहे हैं। अगर, हम कहते हैं, मैं भूल गया हूँ
SUBDOMAIN, कंटेनर प्रारंभ हो जाता है, लेकिन वेब सर्वर टूटा रहता है।

मेरे निपटान में default_env अनुभाग के साथ, मैं अपना सारा उत्पादन कर सकता था
जगह में चर और मुझे सर्वर पर .env.dist की प्रतिलिपि नहीं बनानी होगी।
स्थानीय मशीन पर मैं सिर्फ एक चर .env में डालूंगा, जो होगा
ROOT_HOST = example.com.dev (या शायद मैं निर्यात भी कर सकता था
ROOT_HOST = example.com.dev इन बैश प्रोफाइल?)

संक्षेप करने के लिए, docker-compose.yml में default_env सेक्शन ही नहीं
अब हम जिस समस्या पर चर्चा करते हैं, उसे हल करें, लेकिन कुछ और अच्छे उपयोग को भी सक्षम कर सकते हैं
परिदृश्यों!

WDYT?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/docker/compose/issues/745#issuecomment-282885661 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAQJJZumr10j3i17gPxrSyA-n8CwvsXTks5rg1X_gaJpZM4DLBNs
।

Docker-compose.yml के अंदर "project_name" होने से हमारी समस्या हल हो जाएगी।
हमारे पास कई परियोजनाओं को संभालने वाले एक मानकीकृत पेड़ के साथ एक मोनोलिथ रेपो है, जो इस तरह से कम या ज्यादा दिखता है:

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

यह स्पष्ट रूप से वास्तविक दुनिया की तुलना में अधिक जटिल है, इसलिए हम सिर्फ "प्रोजेक्टा / प्रोजेक्टबी" फ़ोल्डर में डॉक-कंपोज.आईएमएल फाइल को स्थानांतरित नहीं कर सकते हैं।

हमारे पास एक CLI है जो रूट से पूछती है कि कौन से प्रोजेक्ट्स बूट करना है, और चूंकि प्रोजेक्ट का नाम सीधे docker_compose.yml के पैरेंट फोल्डर पर निर्भर करता है, हम संघर्षों का सामना कर रहे हैं।

जैसा कि हम अपने आप को docker-compose कमांड नहीं लिखते हैं (हमारे CLI स्क्रिप्ट के अंदर लिपटे हुए), हम मैन्युअल रूप से कमांड में "-p" arg नहीं जोड़ सकते हैं।
हमारे लिए एक समाधान हमेशा CLI स्क्रिप्ट के अंदर एक project_name उत्पन्न करना होगा, इसलिए हम हमेशा एक "-p" करते हैं, जब निरपेक्ष_पथ पर आधारित डॉकटर-कंपोज़ कहते हैं, लेकिन यह अजीब लगता है।

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

एक सेवा के लिए docker-compose.yml फ़ाइल (स्केलिंग को अक्षम करना) में "container_name" को परिभाषित करना क्यों संभव है, लेकिन docker-compose.yml फ़ाइल के लिए "project_name" को उसी स्तर पर परिभाषित नहीं किया जा सकता है, जैसे कि "संस्करण" / "सेवाएं" / "नेटवर्क" / "वॉल्यूम"?

यह scale के उपयोग के साथ आवश्यक लगता है ताकि कंटेनर के नाम स्पष्ट हों। (उदा <project_name>_<container_name>_1 )।

यह डीएनएस के लिए कंटेनर नाम का उपयोग करते समय मदद करेगा।

यहाँ उम्मीद है कि यह किया गया था। निराश होकर छोड़ दिया। 3 साल +

हाँ, यह डॉकर की सबसे बेवकूफ प्रयोज्य समस्याओं में से एक है और यह अनफ़िल्टर्ड हो जाती है।

हमने डेवलपर्स के साथ बहस करने में इतना समय बिताया, और भले ही सर्वसम्मति थी, फिर भी कोई प्रवेश नहीं था कि यह एक बुरा डिजाइन है।

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

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

आज मैं एक और docker-compose परियोजना के साथ अभी तक एक और .env फ़ाइल स्थापित कर रहा था ताकि परियोजना को लगातार नाम दिया जा सके। इसलिए मैंने सोचा कि मैं इस मुद्दे की जाँच करूँ क्योंकि यह कुछ साल था जब से मैंने आखिरी जाँच की थी। लेकिन यहाँ तक कुछ भी नया नहीं है जहाँ तक मैं देख सकता हूँ? मुझे लगता है कि मुझे .env वर्कअराउंड का उपयोग करना होगा। मेरे लिए, yaml फ़ाइल में एक प्रोजेक्ट का नामकरण ऐसा लगता है कि आप कर सकते हैं सबसे बुनियादी चीज है, लेकिन मुझे लगता है कि इस बारे में कुछ है जो मुझे समझ में नहीं आता है क्योंकि यह अभी तक हल नहीं हुआ है।

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

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

मेरा अनुमान है कि टीम इस मुद्दे की अनदेखी कर रही है। डॉक डेवलपर्स को समझाने की कोशिश करना इसे हल्का करने के लिए एक वास्तविक दर्द हो सकता है।

स्पष्ट तर्क कुछ अजीब तर्क के साथ गिने जाते हैं जो बहुत मायने नहीं रखते हैं। असली दुनिया के उपयोगकर्ताओं की राय है कि सभी एक ही कारण के लिए यहाँ आते हैं। यह शर्मनाक है।

मैं नहीं चाहता कि मेरे CI जॉब्स में लगातार "फिगर आउट" होना चाहिए कि प्रोजेक्ट का नाम क्या होना चाहिए - इसे स्पष्ट रूप से docker-compose.yml में बताया जाना चाहिए ताकि मेरी जॉब्स इसे निकाल सकें और इसका उपयोग कर सकें।

क्या आपके पास समस्या है कि आपके स्टैक को "build1234" नाम दिया गया है और / या आप किसी अन्य स्थान पर स्टैक के नाम का उपयोग कैसे करना चाहेंगे, जैसे docker exec build1234_myservice script.sh ?

किसी भी उपयोग के मामले में फिट नहीं हो सकता है, लेकिन यह कहा होने के लिए ...

हमारे सेटअप में हम केवल (क्लोन) परियोजना की स्थापना करते समय .env फाइलें बदलते हैं। यदि हमें परिवर्तन या एक गतिशील कॉन्फ़िगरेशन की आवश्यकता है, तो हम .env docker-compose.yml से चर का पुनः उपयोग करते हैं। एक फायदा यह है कि अगर कोई वैरिएबल गुम है तो डॉकटर-कंपोज आपको चेतावनी देता है (या फेल हो जाता है)।

मैं आपको यह नहीं बताना चाहता कि आपको अपने वर्कफ़्लोज़ को बदलना होगा, क्योंकि मैं भी इस मुद्दे से नाराज़ था।
यह मूल रूप से कुछ ऐसा है, हम docker-compose.yml को स्रोत-कोड में परिवर्तन की तरह मानते हैं, जबकि .env पूरी तरह से कॉन्फ़िगरेशन है। लेकिन मैं यह भी मानता हूं कि docker-compose.yml में कई विकल्प हैं, जैसे network जो कि अत्यधिक परियोजना पर निर्भर हैं। वापस ऊपर आ रहा है; मैं नेटवर्क के लिए .env चर परिभाषित करूंगा। 🤐

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

मैंने अपनी स्थिति के बारे में कुछ और सोचा। मुझे वास्तव में परियोजना का नाम निर्धारित करने में कोई समस्या नहीं है, और वास्तव में मैं -p <project_name> ध्वज के साथ ऐसा करता हूं, जिससे सीआई में स्टैक के अनूठे उदाहरणों को अलग करना और समवर्ती रूप से कई ढेर चलाना संभव हो जाता है ज़रूरी। केवल उस CI चेन को उस प्रोजेक्ट का नाम पता होना चाहिए ताकि वह ऑटो-जेनरेट या रैंडम (लेकिन ज्ञात) हो सके, कोई समस्या नहीं। मुझे डिफ़ॉल्ट नाम को ओवरराइड करने के लिए पर्यावरण चर का उपयोग करने में भी कोई समस्या नहीं है, हालांकि मुझे .env ट्रिक गैर-स्पष्ट लगती है।

हालाँकि ऐसी अन्य स्थितियाँ हैं जहाँ परियोजना के _default name_ को स्पष्ट रूप से परिभाषित किया जाना उपयोगी है। तो यह मूल नाम को इस नाम के स्रोत के रूप में क्यों लेता है? यह, मेरे लिए, यहाँ कमजोर बिंदु है। इसे कहीं से भी लिया जा सकता है - एक मूल निर्देशिका का चुनाव बस मनमाना और बिना किसी कारण के लगता है (जैसे लगभग सभी परियोजनाओं में, docker-compose.yml फ़ाइल एक उपनिर्देशिका में docker कहलाती है)। तो अगर यह मनमाना होने जा रहा है, तो इसे कहीं और स्पष्ट करें, जैसे कि yml फ़ाइल, बाहरी निर्देशिका-प्रभाव बनाने के बजाय मूल निर्देशिका नामों को प्रभावित करके, जो कई मामलों में निर्देशिका की सामग्री से पूरी तरह से स्वतंत्र होना चाहिए (वर्षों के आधार पर) पुन: प्रयोज्य संसाधनों के साथ काम करने का अनुभव)।

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

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

क्या आप लोग या तो सिर्फ इस बग को बंद कर देंगे, जिसकी आप परवाह नहीं करते या अविश्वसनीय रूप से सरल चीज़ को लागू करना चाहते हैं, जो हम चाहते हैं? यह 2.86 साल बाद है। बर्तन से उतर जाओ। अपने फैसले खुद करें या अपनी गलतियों को ठीक करें। हालाँकि आप इसे देखना चाहते हैं। ज्यादा से ज्यादा कुछ न करें।

@ मतमन और उनकी टिप्पणी देने वाले सभी लोग अंगूठा-अप:

क्या आप लोग या तो सिर्फ इस बग को बंद कर देंगे, जिसकी आप परवाह नहीं करते या अविश्वसनीय रूप से सरल चीज़ को लागू करना चाहते हैं, जो हम चाहते हैं? यह 2.86 साल बाद है। बर्तन से उतर जाओ। अपने फैसले खुद करें या अपनी गलतियों को ठीक करें। हालाँकि आप इसे देखना चाहते हैं। ज्यादा से ज्यादा कुछ न करें।

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

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

CLI arg:

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

असफल।

Env फ़ाइल:

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

असफल।

Yml फ़ाइल में प्रोजेक्ट नाम के साथ प्रस्तावित समाधान:

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

वाह!

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

ओ /

"आप लोग" कौन हैं?

@benjaminwood यह इस परियोजना के अनुरक्षक है। आपका तर्क समझ में आता है अगर हम एक जटिल बदलाव की बात कर रहे हैं और किसी को भी ऐसा करने का समय नहीं मिलेगा।

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

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

आइए इसे अन्य बिंदु से देखें।

यदि मैं docker-compose.yml फ़ाइल वाले फ़ोल्डर में हूं, तो मुझे यह कैसे पता चलेगा कि मेरे स्टैक का कौन सा प्रोजेक्ट नाम है?
यह एक काफी बुनियादी सवाल है, लेकिन इसका कोई आसान जवाब नहीं है।

वर्तमान में यह प्राथमिकता द्वारा क्रमबद्ध है:

• -p
• आपके पर्यावरण से COMPOSE_PROJECT_NAME का मूल्य
• आपके .env फ़ाइल से COMPOSE_PROJECT_NAME का मूल्य
• वर्तमान निर्देशिका नाम

शैतान का वकील होने के लिए, पहले से ही भ्रमित करने वाले सेटअप में 5 वें को क्यों जोड़ा जाए?

उस के निर्णय के बावजूद, वर्तमान नाम के बारे में "सूखा-चल" जानकारी होनी चाहिए। यदि स्टैक नहीं चल रहा है, तो न तो docker-compose config , और न ही docker-compose ps है।
शायद docker-compose create वर्तमान में सबसे अच्छा उपलब्ध विकल्प है, लेकिन एकदम सही है।

docker-compose config --project-name तरह कम से कम कुछ होना चाहिए। वर्तमान में मुझे उपरोक्त स्थानों को जानने और उन्हें सही क्रम में जांचने की आवश्यकता है।

अगर मैं docker-compose.yml फ़ाइल वाले फ़ोल्डर में हूं, तो मुझे कैसे पता चलेगा कि मेरे स्टैक में किस प्रोजेक्ट का नाम है?

अभी तक फिर से: यदि आप इसका उपयोग नहीं करना चाहते हैं तो इसका उपयोग न करें! यदि आप अपने समाधान से खुश हैं - आपके लिए अच्छा है !! आपके लिए कुछ भी नहीं बदलेगा, इसलिए आप बिल्कुल भी भ्रमित नहीं होंगे!

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

शैतान का वकील होने के लिए, पहले से ही भ्रमित करने वाले सेटअप में 5 वें को क्यों जोड़ा जाए?

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

वर्तमान में मुझे उपरोक्त स्थानों को जानने और उन्हें सही क्रम में जांचने की आवश्यकता है।

आप अपने प्रोजेक्ट का डॉकटर नाम क्यों नहीं जानते हैं और यह आपके लिए भी प्रासंगिक क्यों है? और अगर आप इसे इतना भ्रमित करते हैं तो आप अपनी सभी परियोजनाओं में एक ही तंत्र का उपयोग क्यों नहीं करते हैं?

अभी तक फिर से: यदि आप इसका उपयोग नहीं करना चाहते हैं तो इसका उपयोग न करें! यदि आप अपने समाधान से खुश हैं - आपके लिए अच्छा है !! आपके लिए कुछ भी नहीं बदलेगा, इसलिए आप बिल्कुल भी भ्रमित नहीं होंगे!

मेरा प्रश्न एक नई सुविधा का उपयोग करने के बारे में नहीं था, लेकिन एक मौजूदा एक की कमी थी। परियोजना का नाम एक और केवल प्रासंगिक जानकारी है जो कंटेनर के एक निश्चित सेट को शुरू करने और रोकने के लिए docker-compose का उपयोग करता है।
इस थ्रेड में लोग गलत कंटेनरों को मारने की शिकायत करते हैं, क्योंकि प्रोजेक्ट का नाम स्टैक का हिस्सा नहीं है ।

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

यदि आप इसे जोड़ते हैं तो लोग गलत कंटेनरों को मारने की शिकायत करेंगे, क्योंकि यह स्टैक का हिस्सा है, क्योंकि यह पहले से डायरेक्टरी नाम का उपयोग कर रहा था।

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

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

आप अपने प्रोजेक्ट का डॉकटर नाम क्यों नहीं जानते हैं और यह आपके लिए भी प्रासंगिक क्यों है?

क्योंकि मैं आमतौर पर निर्देशिका नाम का उपयोग करता हूं, लेकिन कभी-कभी .env में एक कस्टम मूल्य - यह प्रासंगिक है क्योंकि परियोजना का नाम उन कंटेनरों को परिभाषित करता है जिन पर कार्रवाई की जाती है।

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

यह आपके पहले स्टैक को मार देगा, yml फ़ाइल में प्रोजेक्ट नाम के साथ समान होगा।

और अगर आप इसे इतना भ्रमित करते हैं तो आप अपनी सभी परियोजनाओं में एक ही तंत्र का उपयोग क्यों नहीं करते हैं?

मैं करता हूं, मैं केवल डिफ़ॉल्ट docker-compose सुविधाओं का उपयोग कर रहा हूं; अधिकांश समय निर्देशिका नाम ठीक है, लेकिन अगर मुझे इसका नाम बदलने की आवश्यकता है, लेकिन कंटेनरों के एक ही सेट के साथ काम करना जारी रखना चाहता हूं तो मैं .env फ़ाइल जोड़ता हूं।

यदि आप इसे जोड़ते हैं तो लोग गलत कंटेनरों को मारने की शिकायत करेंगे, क्योंकि यह स्टैक का हिस्सा है, क्योंकि यह पहले से डायरेक्टरी नाम का उपयोग कर रहा था।

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

और अगर वे करते हैं, तो भी सब कुछ ठीक है। मुझे यह नहीं सूझ रहा कि आप यहाँ कौन सी समस्या का निर्माण करने की कोशिश करें आप चीजों को ओवरकॉम्प्लिकेट कर रहे हैं।

यदि आप उन सभी विकल्पों को मिलाते हैं जहां एक परियोजना का नाम कॉन्फ़िगर किया जा सकता है, तो मैं कहूंगा कि यह आपकी समस्या है। आपको ऐसा बिल्कुल नहीं करना चाहिए।

प्राथमिकता ट्री में 4 में से 3 विकल्प बेकार हैं, जब आपके पास एक डायरेक्टरी में कई नाम की कंपोज़ फाइलें होती हैं। मुझे उपनिर्देशिका बनाने के लिए मत कहो, क्योंकि मैं अभी भी उनके बीच एक .env फ़ाइल साझा करता हूं।

मुझे उपनिर्देशिका बनाने के लिए मत कहो, क्योंकि मैं अभी भी उनके बीच एक .env फ़ाइल साझा करता हूं।

आप किसी एप्लिकेशन को विशिष्ट साझा करते हैं .env में इस्तेमाल फ़ाइल env_file ?
या एक docker-compose का उपयोग करता है?
या आप उन्हें मिलाते हैं?

इसका कोई मतलब नहीं है। अगर कोई परियोजना का नाम docker-compose.ym में नहीं जोड़ता है, तो कुछ भी नहीं बदलेगा।

यह समस्या नहीं है, लेकिन जब इसे व्यवहार में भारी बदलाव से जोड़ा जाएगा।

जब हम एक अस्थायी उदाहरण (यानी अपग्रेड के परीक्षण के लिए) के लिए एक नई निर्देशिका के लिए एक स्टैक की नकल करते हैं, तो हमें docker-compose.yml को छूने की आवश्यकता नहीं है। लेकिन अगर यह स्टैक का हिस्सा है, तो हमें यह तय करने की आवश्यकता होगी कि क्या हम इसे .env साथ ओवरराइड करते हैं या क्या हम इसे docker-compose.yml में बदलते हैं।

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

मेरे पास एक सामान्य एकल .env फ़ाइल है, जिसे 4 कम्पोज़ फाइल्स (उसी डायरेक्टरी में) नाम दिया गया है। कोई पर्यावरण चर। कोई शेल स्क्रिप्ट नहीं। मैं सिर्फ कंपोज का उपयोग करता हूं।

मैं इसे पसंद करूंगा

docker-compose -f service1.yml up -d

इसके बजाय यह इस तरह से अधिक है

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

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

क्या आप प्रति सेवा एक फ़ोल्डर का उपयोग नहीं कर सकते हैं और अभी भी शीर्ष फ़ोल्डर में .env फ़ाइल है?

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

बस फ़ाइल (-path) में प्रोजेक्ट-नाम लिखें name

मैं हार मानता हूं। यह स्पष्ट है कि इसके लिए ग्राहक-आधार बदल गया है।

मुझे बताएं कि आपके द्वारा किए गए प्रस्ताव में क्या गलत है।

शुरुआत में मेरी भी यही चिंता थी, लेकिन हमने अपनी वर्कफ़्लोज़ को उपलब्ध सुविधाओं के साथ समायोजित कर लिया है।

मुझे गलती से पिछले 2 वर्षों में हमारी टीम के किसी एक व्यक्ति द्वारा स्टैक को मारना याद नहीं है। हम इस तरह से लगभग 1.000 कंटेनरों और 1.000 के स्वचालित या मैनुअल रिडेपल्मेंट्स के साथ 200 स्टैक्स चला रहे हैं।

मैं वास्तव में यहां शामिल नहीं होना चाहता ... लेकिन मैं विरोध नहीं कर सकता।

एक "समाधान" के बीच एक बहुत महत्वपूर्ण अंतर है जिस तरह से चीजें अब हैं, और "सही" समाधान ने मौजूद संभावनाओं को दिया। इस मुद्दे को जिस पर ध्यान केंद्रित किया

@ schmunk42 & @mikehaertl

मुझे याद नहीं है कि पिछले 2 वर्षों में हमारी टीम के किसी एक व्यक्ति द्वारा गलती से ढेर को मार दिया

मुझे पूछना है। मैं देख रहा हूँ कि आप दोनों कोडमेक्स org का हिस्सा हैं । क्या आप सहकर्मी हैं? आश्चर्य की बात है कि अगर आप दो पर्दे के पीछे घूम रहे हैं तो आश्चर्य होगा।

वर्तमान में यह प्राथमिकता द्वारा क्रमबद्ध है:

1. -p का मान
2. आपके वातावरण से COMPOSE_PROJECT_NAME का मान
3. आपकी .env फ़ाइल से COMPOSE_PROJECT_NAME का मान
4. वर्तमान निर्देशिका नाम

शैतान का वकील होने के लिए, पहले से ही भ्रमित करने वाले सेटअप में 5 वें को क्यों जोड़ा जाए?

जैसा कि मैंने देखा कि समस्या _every एकल मूल्य_ है जो वर्तमान में उपयोग के लिए उपलब्ध है _environment-specific_ है। परियोजना-विशिष्ट विकल्प प्रदान करने का कोई तरीका नहीं है।

1 + 2। आदेश को लागू करने वाले उपयोगकर्ता द्वारा मैन्युअल रूप से प्रदान किया जाना चाहिए।

1. _Could_ को साझा किया जाना चाहिए, लेकिन व्यवहार में .env को अनदेखा किया जाना चाहिए और अच्छे कारण के लिए साझा नहीं किया जाना चाहिए। (मैं .env.example साझा करके इसके आसपास काम करता हूं, लेकिन इसके लिए अभी भी एक अतिरिक्त मैनुअल कदम की आवश्यकता है।)
2. प्रभावी रूप से यादृच्छिक है, और उपयोगकर्ता / पर्यावरण-विशिष्ट है। (मैं इसे एक कमबैक के रूप में भी देखता हूं, क्योंकि _needs_ एक परियोजना का नाम है। यह एक बहुत अच्छी गिरावट नहीं है, क्योंकि विभिन्न निर्देशिकाओं में परियोजनाएं हो सकती हैं, जिनका नाम संघर्ष होगा।)

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

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

@joshuajabbour

1. साझा किया जा सकता है, लेकिन व्यवहार में .env को अनदेखा नहीं किया जाना चाहिए और अच्छे कारण के लिए साझा नहीं किया जाना चाहिए।

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

1. प्रभावी रूप से यादृच्छिक है, और उपयोगकर्ता / पर्यावरण-विशिष्ट है।

यह docker-compose.yml में एक मूल्य से अधिक या कम यादृच्छिक नहीं है, आपको एक फ़ाइल के रूप में एक फ़ोल्डर के रूप में स्टैक कॉन्फ़िगरेशन को देखने की आवश्यकता है। यदि आप ऐसा करते हैं, तो आप या तो .env या सबफ़ोल्डर नाम में हो सकते हैं।

मेरे पास आप सभी के लिए एक अंतिम विकल्प है:

docker stack deploy -c docker-compose.yml the-project-name

(*) केवल झुंड मोड में उपलब्ध है

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

धन्यवाद @ schmunk42 मेरा मानना ​​है कि आपको लगता है कि आपने इस धागे में प्रदर्शित सभी मजबूत रायों के बीच चीजों को काफी अच्छी तरह से संभाला है।

यह हमारे सेटअप में संभावित त्रुटियों का एक बड़ा स्रोत पेश करेगा।

वहाँ रगड़ है। मुद्दे को बंद करें।

यह आपके सेटअप पर निर्भर करता है, हमने अपनी सभी परियोजना रिपॉजिटरी में इसे अनदेखा कर दिया है। लेकिन हम इसे हमारे मंचन और उत्पादन स्टैक-केवल रिपॉजिटरी में अनदेखा नहीं करते हैं।

तो यह सुविधा हर कोई चाहता है कि इसे पेश नहीं किया जाना चाहिए क्योंकि यह आपकी असामान्य रिपॉजिटरी वास्तुकला को तोड़ देगा?

आप नाम पर साझा करेंगे तो docker-compose.yml आप भी प्रतिबद्ध कर सकते हैं .env (इस फ़ाइल केवल डोकर-लिखें आदेश के लिए है - और कुछ नहीं)।

ठीक है, अगर मेरे .env फ़ाइल में एकमात्र चीज़ COMPOSE_PROJECT_NAME , तो हाँ। लेकिन यह कई अन्य _secure_ चर के साथ आबाद है जो मुझे प्रतिबद्ध नहीं चाहिए। और मैं environment संपत्ति का उपयोग करके उन्हें docker-compose में आयात करता हूं। यह वही है जो .env फाइलें आम तौर पर ...

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

@ schmunk42 आप जो कहते हैं, "मुझे नई सुविधाएँ नहीं चाहिए, क्योंकि दूसरी बात यह है कि मुझे अपना प्रोजेक्ट सेटअप अब समझ में नहीं आया है"।

गंभीरता से? यह आपका तर्क है कि आप हर किसी को क्यों चाहते हैं, जिसे इसके बिना इसकी आवश्यकता है?

बस रिकॉर्ड के लिए: मैं यहाँ भी हूँ। बेझिझक मुद्दे को बंद करें। यहां चर्चा निरर्थक हो गई है।

तो यह सुविधा हर कोई चाहता है कि इसे पेश नहीं किया जाना चाहिए क्योंकि यह आपकी असामान्य रिपॉजिटरी वास्तुकला को तोड़ देगा?

मैं अपनी चिंताओं को व्यक्त कर रहा हूं कि यह त्रुटियों के अतिरिक्त स्रोतों को पेश कर सकता है।

ठीक है, अगर मेरी .env फ़ाइल में एकमात्र चीज COMPOSE_PROJECT_NAME है, तो हाँ। लेकिन यह कई अन्य सुरक्षित चर के साथ आबाद है जो मुझे प्रतिबद्ध नहीं चाहिए। और मैं उन्हें पर्यावरण संपत्ति का उपयोग कर docker- रचना में आयात करता हूं।

एक का प्रयोग करें secrets.env उन लोगों के लिए और के माध्यम से इसे आयात env_file ।
यह आपके वर्कफ़्लो को कैसे प्रभावित करेगा?

यह वह है जो .env फाइलें आम तौर पर ...

सच ... लेकिन मुझे लगता है कि समस्या यह है कि docker-compose hijacks .env फ़ाइल है।

यदि आप docker-compose.yml जैसे IMAGE_VERSION docker-compose.yml के शीर्ष स्तरों में उपयोग किए गए इन चरों को सेट कर सकते हैं, तो docker-compose.env कैसे होगा?

मैंने कभी भी COMPOSE_COMMAND_ENV_FILENAME=.env का प्रस्ताव देने की हिम्मत नहीं की - अब तक :)

मुझे अभी भी समझ नहीं आ रहा है कि यह आपके सेटअप को कैसे तोड़ देगा ...

यह सच है कि यह तुरंत नहीं टूटता है, लेकिन यह केवल मेरे पहले बिंदु के बारे में है - और भी अधिक विकल्पों को पेश करना।

कई फ़ाइलों का उपयोग करने के बारे में सोचें -f docker-compose.A.yml -f docker-compose.B.yml , मान लें कि आपकी परियोजना है और निर्देशिका द्वारा परियोजना-नाम पर निर्भर है (हम ऐसा करते हैं, क्योंकि हम इसे नियंत्रित करते हैं!), जबकि बी एक है! project_name: extra साथ अतिरिक्त सेवाओं का सेट, गलती से एक फ़ोल्डर में परीक्षण करते समय पेश किया गया था जिसमें .env फ़ाइल थी, जिसने COMPOSE_PROJECT_NAME=testing साथ प्रोजेक्ट-नाम को ओवरवोट किया।

लेकिन अब कोई भी परियोजना, जिसे .env फ़ाइल के बिना शुरू किया गया है, का नाम extra । 💥

हम कई स्तरों पर फ़ाइलों का विलय कर रहे हैं, जिसमें कई *.env फाइलें शामिल हैं, यह एक बहुत ही मान्य उपयोग-मामला है।

गंभीरता से? यह आपका तर्क है कि आप हर किसी को क्यों चाहते हैं, जिसे इसके बिना इसकी आवश्यकता है?

चेतावनी: थोड़ा ऑफ-टॉपिक, लेकिन अभी भी docker संबंधित ...

• "मुझे नहीं लगता कि हमें वास्तव में इसकी आवश्यकता है"
• "नेकसेरी की तुलना में अधिक परतें हैं। अधिक जटिलता"

@ मइकेहर्टल मुझे वास्तव में आश्चर्य है कि आप इसे इस तरह से देखते हैं;)

दोस्तों,

हमने इस थ्रेड में जोशीली चर्चा पर उठाया है (आप में से उन लोगों को धन्यवाद जिन्होंने इसे नागरिक और सौहार्दपूर्ण रखा है!) और जबकि हम अभी भी मौलिक रूप से मानते हैं कि प्रोजेक्ट का नाम किसी कंपोज़ फ़ाइल के अंदर नहीं है, हम साथ आए थे। हम निम्न पीआर के साथ एक उचित मध्य-मैदान मानते हैं: # 5378। इसने कहा, हम इस पर आपकी प्रतिक्रिया की सराहना करेंगे कि यह आपकी आवश्यकताओं का उत्तर देता है।

यहाँ है जिस्ट:

• आप अपनी रचना फ़ाइल के अंदर x-project-name प्रविष्टि जोड़ सकते हैं। इस कुंजी को डिफ़ॉल्ट रूप से अनदेखा किया जाता है।
• जब आपके वातावरण में COMPOSE_X_PROJECT_NAME (या .env फ़ाइल) सेट किया जाता है, तो Compose आपकी Compose फ़ाइल के अंदर x-project-name प्रविष्टि से प्रोजेक्ट का नाम पुनः प्राप्त करने का प्रयास करेगा।
• इस विकल्प में COMPOSE_PROJECT_NAME और --project-name से कम प्राथमिकता है

इस संबंध में किसी भी प्रश्न या चिंताओं को संबोधित करने में खुशी।

@ shin- तो COMPOSE_X_PROJECT_NAME को सुविधा को सक्रिय करने के लिए 1 सेट करना होगा?

यदि हां, तो COMPOSE_ENABLE_X_PROJECT_NAME भी सोचने के लिए एक नामकरण हो सकता है, लेकिन ये सिर्फ मेरे 2 सेंट हैं - मैं इसे वैसे भी उपयोग नहीं करूंगा $

@ schmunk42 कोई भी "सत्य-वाई" मूल्य काम करेगा , लेकिन हां, यह विचार है।

@ मटसमैन कूल, उपयोगी, क्रियात्मक प्रतिक्रिया के लिए धन्यवाद।

इसके बजाय आप हमें बता रहे हैं कि हमें अंतिम उपयोगकर्ताओं को एक चर सेट करने या एक परम को कॉल करने के लिए बताना होगा, आप हमें बता रहे हैं कि हमें अंत उपयोगकर्ताओं को एक चर सेट करने या एक परम को कॉल करने के लिए बताना होगा।

ईमानदारी से, और वास्तव में कुछ भी नहीं के लिए, मैं कल्पना नहीं कर सकता कि आपने किसी भी तरह से इसका समाधान कैसे माना है।

@ शिन- मैं बताता हूँ कि यह परिवर्तन कैसे कोई उपयोगी अंतर नहीं करता है:

प्रॉजेक्ट फ़ाइल में प्रोजेक्ट नाम की तलाश करने में सक्षम करने के लिए एक पर्यावरण चर सेट करना

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

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

प्रॉजेक्ट फ़ाइल में प्रोजेक्ट नाम की तलाश करने में सक्षम करने के लिए एक पर्यावरण चर सेट करना

यह नहीं है, आप इस सेटिंग को एक बार, विश्व स्तर पर अपने वातावरण में कर सकते हैं - आपको हर प्रोजेक्ट में ऐसा करने की आवश्यकता नहीं है।

यह नहीं है, आप इस सेटिंग को एक बार, विश्व स्तर पर अपने वातावरण में कर सकते हैं - आपको हर प्रोजेक्ट में ऐसा करने की आवश्यकता नहीं है।

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

कंपोज़ फ़ाइल में प्रोजेक्ट का नाम रखने के सबसे महत्वपूर्ण लक्ष्यों में से प्रत्येक को सुनिश्चित करना है कि कंपोज़ प्रोजेक्ट के साथ क्या करना है, संस्करण नियंत्रण में संग्रहीत हो जाता है।

@ योहेय
यह विशेष रूप से उन लोगों की मदद करने का इरादा है, जिनके पास एक ही निर्देशिका में कई कंपोज़ फाइलें हैं, जिनके लिए .env फ़ाइल समाधान विकल्प नहीं है। यदि यह हमेशा आपकी परियोजनाओं के लिए होना चाहिए, तो इसे आपके .env फ़ाइल में सेट करना आसान है, आपकी .profile , या कहीं और जो x-project-name करेगी हमेशा ली जाएगी खाते में।

इसके बजाय आप हमें बता रहे हैं कि हमें अंतिम उपयोगकर्ताओं को एक चर सेट करने या एक परम को कॉल करने के लिए बताना होगा, आप हमें बता रहे हैं कि हमें अंत उपयोगकर्ताओं को एक चर सेट करने या एक परम को कॉल करने के लिए बताना होगा।

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

यदि आप ऐसा करते हैं, तो आप पूरी तरह से असंबंधित परियोजनाओं में अवांछित व्यवहार कर सकते हैं।

क्या आप एक उदाहरण दे सकते हैं? मैं अपने शेल में COMPOSE_X_PROJECT_NAME सेट करके किसी भी अवांछित व्यवहार के बारे में नहीं सोच सकता।

कंपोज़ फ़ाइल में प्रोजेक्ट का नाम रखने के सबसे महत्वपूर्ण लक्ष्यों में से प्रत्येक को सुनिश्चित करना है कि कंपोज़ प्रोजेक्ट के साथ क्या करना है, संस्करण नियंत्रण में संग्रहीत हो जाता है।

आप उसके लिए .env उपयोग क्यों नहीं कर सकते? संस्करण नियंत्रण में .env का भंडारण करने से किसी को मना नहीं किया (हाँ, यह आम नहीं है)।

हमारे पास शुरू में .env थे। आपने पूरी बातचीत को स्पष्ट रूप से याद किया है।

@ मत्समान आपको गंभीरता से अपना रवैया

कुछ भ्रम को स्पष्ट करने के लिए

आप पहले से ही ऐसा कर सकते थे

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

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

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

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

यदि यह उनमें से नहीं है, तो कृपया स्पष्ट करें।

यह तब भी भ्रम पैदा करेगा जब एक डेवलपर संस्करण नियंत्रण से एक परियोजना को खींचता है और पर्यावरण चर सेट करना भूल जाता है।

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

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

दुर्भाग्य से यह मेरे लिए या तो उन कारणों के लिए मदद नहीं करेगा जो मैंने पहले ही एक साल पहले उल्लेख किया है।

एक समाधान जिसमें पर्यावरणीय चर शामिल होते हैं, उन्हें उन उपयोगकर्ताओं की आवश्यकता होती है जिन्हें यह जानना आवश्यक है कि उन्हें पहली जगह में कैसे बनाया जाए। मुझे पता है कि यह विश्वास करना कठिन लग सकता है, लेकिन हर कोई टर्मिनल के अंदर काम नहीं करता है। दोबारा, रिपॉजिटरी में .env डालना मेरे लिए कोई विकल्प नहीं है।

डोकर-रचना की सुंदरता up । उस कॉल को सेटअप करने के तरीके के बारे में निर्देश नहीं।

@fiveanddone

दोबारा, रिपॉजिटरी में .env डालना मेरे लिए कोई विकल्प नहीं है।

क्या आप उस पर विस्तार कर सकते हैं? मैं आपको कम तकनीकी ज्ञान वाले उपयोगकर्ताओं पर पूरी तरह से सुनता हूं, लेकिन अगर वे कोड या पर्यावरण के साथ बातचीत करने के लिए नहीं हैं, तो यह परियोजना के साथ .env फ़ाइल शामिल करने का मुद्दा क्यों है?

@ पिंडली- हाँ, कोई बात नहीं।

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

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

कम तकनीकी डेवलपर्स के लिए जो शायद बस कुछ सीएसएस बदलना चाहते हैं, एप्लिकेशन .env फ़ाइल के बिना ठीक काम करता है। यह मानते हुए कि वे हर प्रोजेक्ट फ़ोल्डर का नाम समान नहीं रखते हैं। :)

यह बहुत अधिक प्रतीत नहीं हो सकता है, लेकिन जब आप कई डेवलपर्स और डिजाइनरों के साथ काम कर रहे हैं जो देश भर में हैं - बेहतर सरल।

डॉकर ने मेरे जीवन को बहुत आसान बना दिया है और मैं इस परियोजना के लिए सुपर आभारी हूं, लेकिन मैं इस धागे के आसपास की निराशाओं से संबंधित हो सकता हूं।

@fiveanddone अंतर्दृष्टि के लिए धन्यवाद! इसलिए अगर इसके बजाय .env फ़ाइल को docker-compose.env (या समान) कहा जाता, तो क्या इससे आपकी चिंता कम होती?

@ नली

हां, यह मेरे उपयोग के मामलों के लिए होगा।

क्या Env फाइल डोकर कम्पोज द्वारा अपने आप लोड की जाती है?

यदि नहीं, तो docker-compose.env स्वचालित रूप से लोड किया जा सकता है?

@nhooey env फ़ाइल स्वचालित रूप से भरी हुई है यदि इसे .env नाम दिया गया है। और आप व्यक्तिगत रूप से प्रत्येक सेवा के लिए env फ़ाइल भी निर्दिष्ट कर सकते हैं। डॉक्स देखें।

अगर यह नाम है। env फ़ाइल अपने आप लोड हो जाती है। और आप व्यक्तिगत रूप से प्रत्येक सेवा के लिए env फ़ाइल भी निर्दिष्ट कर सकते हैं। डॉक्स देखें।

यहाँ नाइटपिकर नहीं होना चाहिए, लेकिन यह वास्तव में सही नहीं है। और IMHO पूरे विषय की गलतफहमी का सबसे बड़ा स्रोत है।

कोई भी .env चर के किसी भी कंटेनर / सेवा के माध्यम से पारित नहीं किया जाता है, यदि आप इसे स्पष्ट रूप से आगे नहीं करते हैं , तो या तो उपयोग करके

env_file: 
  - .env

या

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

.env फ़ाइल स्वचालित रूप से भरी हुई है, हाँ, लेकिन आगे के कॉन्फ़िगरेशन के बिना यह केवल इन कंपोज़ CLI वातावरण चर पर लागू होता है।

मैं दृढ़ता से नाम बदलने का docker-compose.env डिफ़ॉल्ट रूप से और उससे भी बेहतर - इसके लिए एक चर है , इसलिए इसका उपयोग BC- तरीके में सिर्फ एक ENV-var की स्थापना के साथ किया जा सकता है।

(आप में से उन लोगों को धन्यवाद जिन्होंने इसे दीवानी और सौहार्दपूर्ण रखा!)

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

यदि प्रोजेक्ट का नाम कंपोज़ फ़ाइल में है, तो कोई भी दो प्रोजेक्ट एक ही नाम का उपयोग कर सकते हैं, जिससे विरोध हो सकता है, जो दोनों प्रोजेक्ट्स को तोड़ देगा।

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

@ पिंडली- यह आम तौर पर सहमत होने के रूप में लगता है, कि docker-compose.yml हमेशा एक परियोजना का हिस्सा है और परियोजना भंडार में रहता है। मैं कहूंगा कि यह सच नहीं है। हम में से कुछ docker-compose.yml साझा नहीं करते हैं, लेकिन स्थानीय अनुकूलन (जैसे विकास सेटिंग्स, प्रयास, आदि) के साथ अपने स्थानीय संस्करण को रखना चाहते हैं।

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

यहाँ एक सुझाव दिया गया है: परियोजना के नाम के लिए दो अन्य विकल्पों को जोड़ने और .env V4 में docker-compose.yml कैसे? एक project_name docker-compose.yml , दूसरा एक फ़ाइल .dockerproject जिसमें केवल नाम शामिल है और कभी भी भंडार को प्रस्तुत

यहाँ पूर्वता के लिए मेरा सुझाव है (सबसे पहले):

• -p CLI तर्क
• .dockerproject फ़ाइल
• project_name docker-compose.yml (यदि docker-compose.yml परियोजना के साथ वितरित किया गया है, तो बचा जाना चाहिए)
• COMPOSE_PROJECT_NAME पर्यावरण से
• COMPOSE_PROJECT_NAME .env (पदावनत)
• निर्देशिका का नाम

इस तरह से अंत उपयोगकर्ता हमेशा .dockerproject में एक प्रोजेक्ट नाम को ओवरराइड कर सकते हैं, भले ही किसी ने इसे वितरित docker-compose.yml में हार्डकोड किया हो।

अद्यतन: मैं .dockerenv या docker.env उपयोग करने के बजाय .dockerproject साथ भी रह सकता था। लेकिन इस समस्या को हल करने के लिए इसकी उच्च प्राथमिकता होनी चाहिए, कि कुछ को docker-compose.yml में हार्डकोड प्रोजेक्ट नामों को ओवरराइड करने की आवश्यकता है।

नमस्ते,

सबसे पहले, इस मामले को देखने के लिए @dnephin और @

मैंने निम्नलिखित उपयोग-मामले के लिए परीक्षण प्रोजेक्ट पर PR 5378 को मान्य किया है: A default project name defined by the project, that can be checked in (https://github.com/docker/compose/issues/745#issuecomment-282858900)। इसके लिए मैंने विभिन्न संभावनाओं को दर्शाते हुए एक git रेपो बनाया: https://github.com/estarter/compose_745

मैंने PR # 5378 को आंशिक रूप से उपयोग-मामले को कवर करते हुए पाया। समस्या यह है कि समाधान के लिए COMPOSE_X_PROJECT_NAME env वैरिएबल की आवश्यकता होती है। संभव समाधान:

1. प्रोजेक्ट के फ़ोल्डर में env वैरिएबल जारी रखें। मैंने .env फ़ाइल की कोशिश की, लेकिन यह तब काम नहीं करता है जब डॉकटर-कंपोज़ को किसी अन्य स्थान से कॉल किया जाता है ( कमांड्स उदाहरण देखें, फ़ाइलों को लिखें )
2. COMPOSE_X_PROJECT_NAME विश्व स्तर पर परिभाषित करें (.profile या समकक्ष)। यह काम करेगा, लेकिन यह परियोजना में निर्दिष्ट नहीं किया जा सकता है, अर्थात यह हमारे उपयोग-केस defined by the project, that can be checked in लिए समाधान नहीं है
3. क्या कोई और विकल्प है?

उम्मीद है कि मैं यहां इस्तेमाल किए जाने वाले मामले का वर्णन करने में कामयाब रहा।

प्रिय अनुरक्षकों, कृपया विचार करें कि PR-5369 द्वारा उपयोग-केस को कैसे हल किया जाता है जो डॉकटर-कम्पोज़ फ़ाइल में वैकल्पिक project_name संपत्ति का परिचय देते हैं। यह संपत्ति कम प्राथमिकता लेती है लेकिन पर्यावरण या कार्यशील निर्देशिका पर निर्भर नहीं करती है।

1. क्या कोई और विकल्प है?

यह विकल्प docker-compose --project-directory <PATH> (वैकल्पिक कार्य निर्देशिका निर्दिष्ट करें)। .env फ़ाइल के साथ भी काम करना चाहिए।

मिश्रण में एक और बारीक उपयोग के मामले को जोड़ने के लिए:
मेरे उपयोग के मामले में, मेरे पास दो रिपॉजिटरी हैं, एक मुख्य परियोजना के लिए (एक का उपयोग / निर्माण करने के लिए / तैनाती) और एक के लिए devops (Dockerfile की, docker-compose.yml, आदि)
हमारे वर्तमान सेटअप में, मुख्य प्रोजेक्ट रेपो रूट पर है। / और डेवोप्स रेपो की जाँच एक उपनिर्देशिका के लिए की जाती है।

इस सेटअप में .env फ़ाइल का उपयोग करने से काम नहीं होता है क्योंकि यह होना चाहिए:

उस फ़ोल्डर में रखा जाता है जहाँ docker-compose कमांड निष्पादित होती है (करंट वर्किंग डायरेक्टरी)।
(डॉक्टर रेफरी)

जो काम नहीं करता है, क्योंकि यह इस प्रकार है: docker-compose -f devops/docker-compose.yml
बेशक, हम -p पैरामीटर को यहां जोड़ सकते हैं, जो कि हम वर्तमान में उपयोग कर रहे हैं, लेकिन यह मानवीय त्रुटि से ग्रस्त है जैसा कि ऊपर संदर्भित किया गया है।

यदि .env (या प्रस्तावित docker-compose.env) फ़ाइल को उसी निर्देशिका से पढ़ा जा सकता है जहाँ docker-compose.yml रहता है, तो प्रोजेक्ट नाम को परिभाषित करना मेरे लिए काम करेगा।

Docker-compose.yml के अंदर env_file निर्देश का उपयोग करने से काम नहीं चलता, क्योंकि उन env var को केवल कंटेनर के अंदर ही लगाया जाता है, कंटेनरों के निर्माण के लिए नहीं।

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

यह विकल्प docker-compose --project-directory है(एक वैकल्पिक कार्य निर्देशिका निर्दिष्ट करें)। .Env फ़ाइल के साथ भी काम करना चाहिए।

@ schmunk42 एक अच्छा शॉट हो सकता है, लेकिन --project-directory .env फ़ाइल के लिए काम नहीं करता है। मैंने निम्न के रूप में कोशिश की है, .env फ़ाइल को अनदेखा कर दिया गया है ( परियोजना फ़ाइलें ):

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

आगे बढ़ते हुए, मैं उन टिप्पणियों को हटा रहा हूँ जो रचनात्मक तरीके से बातचीत में योगदान नहीं करती हैं। मुझे बच्चों के साथ बातचीत करने में कोई दिलचस्पी नहीं है।

एक बसने योग्य .env नाम होने पर
एक पर्यावरण परिवर्तनीय पदनाम के साथ समस्या जो .env का उपयोग करने के लिए है, यह अनिवार्य रूप से एक परिपत्र निर्भरता है। हमें एक अपवाद पेश करना होगा जिस तरह से पर्यावरण चर की व्याख्या की जाती है, जो समझदार होने के साथ-साथ स्वाभाविक रूप से प्रति-सहज है।

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

Compose फ़ाइल में project_name जोड़ने पर
हमने कई बार पहले ही इस पर अपना रुख दोहराया है - उन बदलावों का विरोध करने वाले कुछ कारणों के लिए डैनियल की नवीनतम टिप्पणी देखें। ऐसा नहीं है कि यह मुश्किल है। ऐसा नहीं है कि हमने इसके बारे में नहीं सोचा। हमने इसका मूल्यांकन करने में बहुत समय बिताया है, और हमें लगता है कि परियोजना की गुणवत्ता इसे (इस रूप में) जोड़ने का औचित्य सिद्ध करने के परिणामस्वरूप बहुत अधिक भुगतना होगा। वास्तविक रूप से कहे तो, # 5378 शायद सबसे अच्छी रियायत है जिसके लिए हम इस तरह से काम कर सकते हैं जो ऑप्ट-इन और बैकवर्ड-कम्पेटिबल है (EDIT: बेशक, मैं उन सुझावों के लिए खुला हूँ जो इन मापदंडों के भीतर उस प्रस्ताव को बेहतर बनाते हैं)

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

सभी ने कहा कि, क्या कोई ऐसा है जिसके लिए docker-compose.env + # 5378 संतोषजनक समाधान नहीं होगा? मैं समझता हूं कि यह आपका पसंदीदा समाधान नहीं हो सकता है, लेकिन मैं पूछ रहा हूं कि क्या यह उचित रियायतें दे सकता है जो आप सामना कर सकते हैं।

सभी एक तरफ मजाक कर रहे हैं ...

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

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

मुझे उम्मीद है कि यह रचनात्मक रहा है।

@estarter मैं इसे एक बग

वास्तव में मैं यह .env डायरेक्टरी में PR_5378 साथ काम करने की उम्मीद करूँगा:

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Compose फ़ाइल में project_name जोड़ने पर

@ पिंडली- ऐसा लगता है, निर्णय पहले से ही किया गया है। लेकिन मैं अभी भी पृष्ठभूमि को समझने की कोशिश करता हूं। मैंने पहले भी यह पूछा है और कभी कोई जवाब नहीं मिला (जो कि एक कारण है कि चर्चा मुझे इतना परेशान करती है)।

क्या आप कृपया मुझे यह समझने में मदद कर सकते हैं कि हमारे पास container_name और यहाँ तक कि network docker-compose.yml क्यों हैं? पहला संभावित संघर्षों का भी स्रोत हो सकता है। और बाद वाला अत्यधिक मेजबान विशिष्ट है। आपके तर्क के बाद उन दोनों (और अन्य) को भी नहीं होना चाहिए। मैं project_name का अंतर देखने में विफल हूं।

कृपया, इस प्रश्न को फिर से अनदेखा न करें।

@ माइकल-के क्या आप project_name container_name ? यदि आप ऐसा कह रहे हैं, तो मैं आपको सूचित करना चाहूंगा कि एक परियोजना में कई कंटेनर शामिल हो सकते हैं। या मैंने तुम्हें गलत समझा है?

जबकि network , यह आवश्यक रूप से होस्ट-विशिष्ट नहीं है। ऐसे कई मामले हैं जब एक परियोजना को एक केंद्रीय पृथक नेटवर्क की आवश्यकता होती है जिसमें एक कंटेनर दूसरे नेटवर्क के साथ बातचीत करता है। और इसके विन्यास docker-compose.yml में संग्रहीत हैं।

@AyushyaChitransh आपने गलत समझा। सवाल यह है: container_name , network और दूसरों के docker-compose.yml project_name होने की अनुमति क्यों नहीं होनी चाहिए? वे सभी संघर्ष या मेजबान विशिष्ट कॉन्फ़िगरेशन के लिए समान क्षमता साझा करते हैं जिन्हें साझा नहीं किया जाना चाहिए।

@ आनंद मुझे इस अवसर के बारे में पता है। साथ ही, कंटेनर के नामों के बारे में भी बताया जा सकता है, लेकिन हमारे पास कंपोज फाइल में कंटेनर का नाम सेट करने का अवसर है, है ना?

हां, लेकिन मुझे नहीं लगता कि इसे जोड़ना एक अच्छा विचार था।

संबंधित चर्चा से डॉकटर-कंपोज़ फ़ाइल में नेटवर्क नाम निर्दिष्ट करें ।

@estarter मैं इसे एक बग

@ schmunk42 मैं देख रहा हूं कि अनुरक्षक इससे अवगत हैं - जोफ्री की टिप्पणी में On --project-directory # 4709, # 4933 और # 4841

वास्तव में मुझे उम्मीद है कि यह निर्देशिका PR_5378 में .env फ़ाइल के साथ काम करेगा:
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

आपने मान लिया कि --project-directory -f पैरामीटर को प्रभावित करता है।
वास्तव में यह मामला नहीं है, यह कमांड IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

यह बहुत अच्छा है कि --project-directory -f को प्रभावित नहीं कर रहा है - अन्यथा कल्पना करें कि क्या एक दुःस्वप्न --project-directory का उपयोग करेगा और सभी अलग-अलग निर्देशिकाओं में कई डॉकटर-कंपोज़ फाइलें।

मैं एक समस्या के हल के रूप में किसी चीज़ पर इतना विचार-विमर्श करके बहुत हैरान हूं।

यह पूर्वता का क्रम है जिसे मैं देखने के लिए उपयोग कर रहा हूं:

1. हार्ड कोडित
2. cli विकल्प
3. वातावरण
4. project.rc
5. डिफ़ॉल्ट रूप से

project_name वर्तमान में हमारे पास कोई विकल्प # 1 या विकल्प # 4 नहीं है। यह मूलभूत समस्या है जिसका लोग सामना कर रहे हैं और एक पिछड़े संगत तरीके से हल करना आसान लगता है।

हमें लगता है कि पवित्रता के बारे में दार्शनिक तर्क दिए जा रहे हैं जो शायद सहायक न हों। दूसरी ओर एक बहुत ही सामान्य OSS कैस्केडिंग कॉन्फ़िगरेशन योजना का उपयोग करना, बहुत सहायक है।

हमें लगता है कि पवित्रता के बारे में दार्शनिक तर्क दिए जा रहे हैं जो शायद सहायक न हों।

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

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

क्या आप कृपया मुझे यह समझने में मदद कर सकते हैं, कि हमारे पास क्यों कंटेनर_नाम और यहां तक ​​कि नेटवर्क भी docker-compose.yml में है? पहला संभावित संघर्षों का भी स्रोत हो सकता है। और बाद वाला अत्यधिक मेजबान विशिष्ट है। आपके तर्क के बाद उन दोनों (और अन्य) को भी नहीं होना चाहिए। मैं Project_name का अंतर देखने में विफल रहा।

container_name , उस विकल्प को परियोजना के जीवनकाल में बहुत पहले पेश किया गया था। जैसा कि @ schmunk42 ने बताया, अगर हम इसे फिर से करना चाहते हैं, तो यह निश्चित रूप से कल्पना में नहीं होगा। इसका लगातार दुरुपयोग हुआ है और वर्षों से यह उपयोगकर्ताओं के लिए अनगिनत मुद्दों का स्रोत रहा है।
network , मुझे पूरी तरह से यकीन नहीं है कि यह आपके दिमाग में कैसे तुलना करता है?

विकल्प # 4 के बारे में मैंने क्या उल्लेख किया है? मैंने स्थानीय निर्देशिका विशिष्ट सेटिंग्स के लिए .docker-compose शुरू करने की कुछ बातचीत देखी। यह _x_ वातावरण के झंडे (जो अभी भी पर्यावरण प्रबंधन की आवश्यकता है) को पेश करने के लिए बहुत बेहतर (imo) होगा।

यह इस तरह होगा:

# <my-project-dir>/.docker-compose
project_name: foobar

उपरोक्त पर्यावरण चर विकल्प से अलग है और पूर्ववर्ती सूची में कम है।

यह मेरे उपयोग के मामले को अच्छी तरह से हल करता है और सूची से एक और मानक कॉन्फ़िगरेशन पथ को टिक करता है।

@thedeeno हमारे दिमाग में, COMPOSE_PROJECT_NAME .env फ़ाइल के अंदर पहले से ही पूरा होता है (उसी प्राथमिकता क्रम के साथ जैसा कि आपकी रूपरेखा में होगा)। हालाँकि, हमने आपको .env नाम के खराब विकल्प के रूप में सुना है , यही कारण है कि हम विकल्प के रूप में docker-compose.env विचार कर रहे हैं। क्या वह काम तुम्हारे लिये होगा?

हमारे दिमाग में, .env फ़ाइल के अंदर COMPOSE_PROJECT_NAME पहले से ही पूरा करता है

@ पिंडली- यह वह जगह है जहाँ हम असहमत हैं। मुझे नहीं लगता कि यह करता है।

मैं व्यक्तिगत रूप से प्यार करता हूं कि हम .env फ़ाइल का स्रोत हैं। यह स्थानीय रहस्यों और अन्य स्थानीय हार्डवेयर विशिष्ट कॉन्फ़िगरेशन को डालने के लिए एक बहुत ही पारंपरिक स्थान है।

यह number 3 ऊपर, पर्यावरण आधारित कॉन्फ़िगरेशन के साथ सहायता के लिए बहुत अच्छा काम करता है।

जब हम पर्यावरण को परियोजना का नाम नहीं देना चाहते हैं तो यह हमें पलायन नहीं देता ( number 4 )।

मेरे मामले में हमारे डेवलपर्स के पास अपना .env फ़ाइल होगी (VC नहीं)। इसमें docker-compose.yaml इंजेक्शन के लिए रहस्य शामिल हैं। इसे प्रेम करें।

हम नहीं चाहते हैं कि डेवलपर्स को परियोजना के नाम पर नियंत्रण हो, हालांकि, चूंकि यह कुछ टूलिंग के लिए दृढ़ता से युग्मित है। चूंकि .env संस्करण नियंत्रण में नहीं है, इसलिए हमें अपने डेवलपर्स को मैन्युअल रूप से COMPOSE_PROJECT_NAME इस दृष्टिकोण के साथ सेट करना होगा; और यह _ बात है_ दूसरों की तरह नहीं, क्योंकि यह कोई रहस्य नहीं है।

तो दुःख की बात है, बस .env के डिफ़ॉल्ट स्रोत पथ को बदलने से हमें यहाँ मदद नहीं मिलेगी। हम वास्तव में प्यार करते हैं कि .env स्वचालित रूप से sourced है। हम इस तरह से परियोजना का नाम निर्दिष्ट नहीं करना चाहते हैं।

मैं अपने अभ्यास से एक usecase दिखाता हूँ:

मैं छवि संस्करण को निर्दिष्ट करने के लिए .env फ़ाइल का उपयोग कर रहा हूं, और अजीब सीड / ऑक / पर्ल / जो कुछ भी पार्सिंग से बचने के लिए, मैं सिर्फ CI में मूल्य को अधिलेखित करता हूं:

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

बाद में docker-compose.yml , छवि के रूप में निर्दिष्ट किया गया है:

    image: my.registry.example.net/app:${APP_VERSION}

अब अगर मुझे उस तरह के अधिक चर की आवश्यकता है, तो मुझे कुछ पार्स करने की ज़रूरत है, जब तक कि कई .env फ़ाइलों का समर्थन नहीं किया जाता है।

इसलिए, शायद "निर्देशिका" समर्थन भी जोड़ते हैं, जैसे: docker-compose.env.d/* या .docker-compose.env.d/* या docker-compose.d/* ।

लेकिन इस तरह के ग्लोब तुरंत एडिटर बैकअप की समस्याएँ पैदा कर सकते हैं ( *~ , *.bak ) इसके बजाय कुछ एक्सटेंशन का उपयोग करना बेहतर है: docker-compose.env.d/*.sh

... लेकिन फिर, शायद यह docker-compose.yml .env में लोड कर रहा है या चिकन-अंडे की समस्या को पेश करेगा, जो इसे कॉन्फ़िगर करने योग्य है? मैं नहीं जानता कि कैसे विन्यास पार्सर काम करता है :)

थोड़ा सा अपमानजनक, लेकिन COMPOSE_PROJECT_NAME env पूरी तरह से नियंत्रण उपसर्ग की अनुमति नहीं देता है, यह अभी भी A-Za-z0-9_ से मिलान करने के लिए छीन लिया जाएगा ... मैं अपने उपसर्ग में - का उपयोग करना चाहता था। (मुझे यह नहीं मिल रहा है कि मैंने इसे अभी कहां रिपोर्ट किया है, लेकिन इसे संबोधित नहीं किया गया है)

यह उन्हीं पात्रों को अनुमति देने के लिए तर्कसंगत होगा जो खुद को सीमित करते हैं।

@glensc पर्यावरण का प्रबंधन करने के लिए बहुत सारे बुनियादी ढांचे हैं। मुझे व्यक्तिगत रूप से ऐसा नहीं लगता है कि docker-compose की जिम्मेदारी है।

केवल एक चीज जो मैंने देखी है, वह है अन्य प्रोजेक्ट की स्वतः स्रोत .env

@glensc @thedeeno तो आदर्श रूप से, हमारे पास दो *.env फाइलें होंगी, एक का मतलब अन्य उपयोगकर्ताओं के साथ साझा करना होगा, और एक निजी रखा गया था, बाद वाले ओवरराइडिंग के साथ जब दोनों एक ही संस्करण को परिभाषित करते हैं?

मैंने पिछले हफ्ते अपनी टिप्पणी में विन्यास .env नामों को संबोधित किया।

एक सार्वजनिक docker-compose.env (जबकि अभी भी निजी .env सोर्सिंग ऑटो) हमारे लिए बहुत अच्छा काम करेगा!

हम इसे एक आर सी फ़ाइल की तरह मानते हैं और इसे स्रोत नियंत्रण में करते हैं।

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

@thedeeno @glensc आप एक यूज़-केस देना जहां एक निजी ENV फ़ाइल सार्वजनिक एक में मानों को ओवरराइड की जरूरत को खुश कर सकता है?

रहस्यों को docker-compose.env में परिभाषित नहीं किया जाना चाहिए, क्योंकि वे कंटेनरों में ऑटो-फॉरवर्ड नहीं होंगे। आप तब भी .env फ़ाइल का उपयोग कर सकते हैं और इसके साथ जो चाहें कर सकते हैं। लेकिन यह मुझे docker-compose और स्टैक में कंटेनरों के लिए सेटिंग्स को मिक्स करने के लिए भ्रमित करता है।

@ schmunk42 मेरे पास वह उपयोग-मामला नहीं है, इसलिए मुझे वहां बहुत मदद नहीं मिलेगी। मुझे सिर्फ project_name संस्करण नियंत्रण करने की आवश्यकता है। docker-compose.env हल करता है।

मुझे यकीन नहीं है कि मैं आपके दूसरे पैराग्राफ का पालन करूंगा। हम रहस्य के लिए .env करते हैं और मैन्युअल रूप से उन्हें docker-compose.yaml में इंजेक्ट करते हैं।

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -34965962

यह सिर्फ इसलिए है क्योंकि केवल ${variables} image मूल्य के लिए ${variables} परिभाषित करने के लिए जगह .env फ़ाइल लगती है।

@ एलगेंस एग्री !

लेकिन इसके बजाय, मैं yml फ़ाइलों के लिए वर्तमान ओवरराइड सुविधा के साथ संरेखित करने के लिए docker-compose.override.env का प्रस्ताव दूंगा।

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

मुझे यकीन नहीं है कि मैं आपके दूसरे पैराग्राफ का पालन करूंगा। हम रहस्यों के लिए .env का उपयोग करते हैं और मैन्युअल रूप से उन्हें docker-compose.yaml में इंजेक्ट करते हैं।

@thedeeno मुझे लगता है कि आप यह कर रहे हैं:

environment:
  - ${SECRET_VAR_FROM_DOTENV}

जो docker-compose.override.env साथ भी संभव होना चाहिए। या आप कर सकते हैं:

env_file:
  - .env

क्या आप छोड़ने का सुझाव दे रहे हैं। अधिक विशिष्ट-रचना के पक्ष में
पथ?

अगर हम .env की स्वचालित सोर्सिंग को छोड़ देते हैं तो यह मेरे पर नकारात्मक प्रभाव डालेगा
टीम के वर्कफ़्लो। हम अन्य टूलिंग के लिए इस फाइल पर भरोसा करते हैं। हम अंत करेंगे
हमारे रहस्यों को दो में डाल दें (.env और यह अन्य फ़ाइल जो आप सुझा रहे हैं)
स्थानों पर अगर docker-compose देखना बंद कर देता है।

Thu, Nov 23, 2017 को 1:15 पूर्वाह्न टोबियास मंक नोटिफिकेशन @github.com पर
लिखा था:

@glensc https://github.com/glensc सहमत हो गए!

लेकिन इसके बजाय, मैं docker-compose.override.env को इसके साथ संरेखित करने का प्रस्ताव दूंगा
yml फ़ाइलों के लिए वर्तमान ओवरराइड सुविधा।

डोकर-compose.env
डोकर-compose.override.env
डोकर-compose.override.yml
डोकर-compose.yml

मुझे यकीन नहीं है कि मैं आपके दूसरे पैराग्राफ का पालन करूंगा। हम रहस्यों के लिए .vv का उपयोग करते हैं और
मैन्युअल रूप से उन्हें docker-compose.yaml में इंजेक्ट करें।

@thedeeno https://github.com/thedeeno मुझे लगता है कि आप यह कर रहे हैं:

वातावरण:

• $ {} SECRET_VAR_FROM_DOTENV

जो docker-compose.override.env के साथ भी संभव होना चाहिए। या आप
कर सकता है:

env_file:

• .env

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/docker/compose/issues/745#issuecomment-346538315 , या मूक
सूत्र
https://github.com/notifications/unsubscribe-auth/AAFIdxtbI7y3wW2TFa401Go6Msj0gC74ks5s5Q1vgaJpZM4DLBNs
।

क्या आप छोड़ने का सुझाव दे रहे हैं। अधिक विशिष्ट-रचना के पक्ष में
पथ?

जरूरी नहीं कि, BC docker-compose अभी भी .env लग सके, यदि अन्य नहीं मिले, तो fig.yml एक बार भी। हालांकि निम्नलिखित मामलों को तय करना मुश्किल हो सकता है:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

अंतिम मामले में .env उपयोग नहीं किया जाएगा, लेकिन मैं पहले दो को संभालने के लिए कैसे अनिच्छुक हूं, क्योंकि कुछ उपयोगकर्ता ओवरराइड के रूप में .env करेंगे, दूसरों को एक वापसी के रूप में।

मेरे लिए .env सभी मामलों में उपयोग किया जाना चाहिए। यह विशेष अर्थ वाली फाइल है
व्यापक पारिस्थितिकी तंत्र में।

आपके तीसरे मामलों में यह सबसे कम पूर्वता वाली फ़ाइल है।

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

यदि एक कॉन्फ़िगरेशन फ़ाइल टेबल से दूर है और मेरी प्रतिबद्ध करने का एक तरीका है
इस env झरने के साथ project_name आप के बारे में ले जा रहे हैं, मैं खुशी से इसका उपयोग करूँगा
हालांकि!

Thu, Nov 23, 2017 को 1:31 AM टोबियास मंक नोटिफिकेशन @github.com पर
लिखा था:

क्या आप छोड़ने का सुझाव दे रहे हैं। अधिक विशिष्ट-रचना के पक्ष में
पथ?

जरूरी नहीं है, ई.पू. के लिए डूको-कंपोज़ अभी भी देख सकते हैं
अन्य नहीं पाए जाते हैं, जैसा कि एक बार अंजीर के साथ होता है। हालांकि यह हो सकता है
निम्नलिखित मामलों को तय करने के लिए मुश्किल:

.env
डोकर-compose.env

.env
डोकर-compose.override.env

.env
डोकर-compose.env
डोकर-compose.override.env

.env का उपयोग अंतिम मामले में नहीं किया जाएगा, लेकिन मुझे पता नहीं है कि कैसे संभालना है
पहले दो के लिए, क्योंकि कुछ उपयोगकर्ता ओवरराइड के रूप में .vv का उपयोग करेंगे, दूसरों को एक के रूप में
मैदान छोड़ना।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/docker/compose/issues/745#issuecomment-346539891 , या मूक
सूत्र
https://github.com/notifications/unsubscribe-auth/AAFId95kZQIsiWp488JyPQOtGJju0OPbks5s5RFbgaJpZM4DLBNs
।

नेटवर्क के लिए, मुझे पूरी तरह से यकीन नहीं है कि यह आपके दिमाग में कैसे तुलना करता है?

@ नली

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

मुझे लगता है कि मैं इसे गलत कर रहा हूं, क्योंकि मैंने अपने रेपो को कभी भी docker-compose.yml किया। इसमें हमेशा अत्यधिक होस्ट विशिष्ट सेटिंग्स होती हैं। यह उत्पादन में विकास में काफी भिन्न सामग्री हो सकती है।

मैं "4 project.rc" का प्रशंसक हूं, हालांकि मैं शायद एक अलग प्रारूप के बजाय docker-project.yaml जैसे कुछ का उपयोग करूंगा। यह वही है जो मूल मुद्दे का वर्णन करता है। जहाँ तक मुझे प्रोजेक्ट नाम को कंपोज़ फ़ाइल में रखने के बारे में कोई भी चर्चा करने का सवाल है, एक अलग मुद्दे में होना चाहिए।

मुझे अपनी परियोजना के नाम को स्रोत नियंत्रण के लिए प्रतिबद्ध करने का एक तरीका है।

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

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

my_project_network_on_my_localhost मुझे गलत लगता है।

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

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

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

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

क्योंकि यह हमारे मामले में एक फ़ोल्डर में है, हम कुछ ऐसा कर सकते हैं

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

परीक्षण के लिए ... या यह

(cd production && docker-compose logs -f --tail 100)

उत्पादन के लिए (बोनस: आप किसी अन्य मशीन को इंगित करने के लिए DOCKER_HOST उत्पादन में परिभाषित कर सकते हैं, लेकिन केवल docker-compose )।

लेकिन हाँ, यह एक फ़ोल्डर है, एक फ़ाइल नहीं है - और काम करने के लिए दो जगहों पर cp .env-dist .env आवश्यकता होती है, अन्यथा यह एक अवैध रचना फ़ाइल के साथ विफल हो जाती है। वास्तव में, मैं सिर्फ इस IMHO स्वच्छ वर्कफ़्लो को साझा करना चाहता था।

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

@dnephin कारण हैं।

हां आसपास काम हैं। पूछना इसे और अधिक सुविधाजनक और पूर्वानुमान योग्य बनाना है।

यहां एक उदाहरण है जहां एक हार्ड-कोडित परियोजना का नाम मदद करता है: ट्रैफिक का डॉकर कॉन्फ़िगरेशन निम्न प्रारूप में कंटेनरों के लिए मेजबान नियम बनाने में चूक करता है: <service>.<project>.<domain> । इस स्वरूपण को बदलना आसान नहीं है। हमारे डेवलपर्स के लिए यह बहुत फायदेमंद है कि वे हमारे डॉकटर-कंपोज़ सेवाओं के लिए एक ही fqdns का उपयोग करें। यदि हम शून्य-कॉन्फ़िगरेशन सेटअप का उपयोग कर सकते हैं तो यह बहुत अच्छा होगा, क्योंकि यह निरंतरता की गारंटी देने का एकमात्र तरीका है: ए) उन्हें अपने क्लोन बी के लिए एक विशिष्ट निर्देशिका नाम का उपयोग करने के लिए मजबूर करता है) मैन्युअल रूप से ट्रैफिक के नियमों को निर्दिष्ट करता है। दोनों चूसते हैं।

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

दोस्तों, इतनी सारी चर्चा ... क्या स्थिति है, क्या मैं अपने .docker-compose फ़ाइल में डिफ़ॉल्ट प्रोजेक्ट नाम सेट कर सकता हूँ?
या अभी भी इस धागे में अधिक चर्चा की आवश्यकता है?

docker-compose.yml फ़ाइल में प्रोजेक्ट का नाम रखने से अन्य उपकरण, जैसे PyCharm, के साथ उपयोग करने पर बहुत अधिक समझ में आता है।

यह एक ही YAML फ़ाइल में संग्रहीत करना बहुत अच्छा होगा, लेकिन यदि आवश्यक हो तो संभवतः ओवरराइड कर सकता है।

मुझे लगता है कि इस मुद्दे का मूल तथ्य यह है कि डिफ़ॉल्ट परियोजना का नाम बस है (क्या मुझे _naively_?) वर्तमान निर्देशिका के आधार नाम के रूप में लिया जाना चाहिए। यह फ़ाइल सिस्टम नाम स्थान (पदानुक्रमित) को एक फ्लैट एक पर प्रभावी ढंग से संपीड़ित कर रहा है, जो कि नाम संघर्ष के कारण समस्याग्रस्त है। उदाहरण के लिए, यह ~/fooproject/master और ~/barproject/master में सेवाएँ चलाने वाले लोगों के लिए समस्याएँ पैदा करता है।

मुझे लगता है कि परियोजना के नाम महत्वहीन हैं। तो शायद डॉकटर-कंपोज़िंग को मज़बूत बनाने का एक तरीका यह है कि प्रोजेक्ट नाम के ठिकानों को पूरे रास्ते पर बनाया जाए (यानी home_flaviovs_fooproject_master )?

मैं हालांकि, लगातार विचार पसंद करता हूं। Git के लिए परियोजना का नाम देने में सक्षम होना इस तरह का एक सामान्य उपयोग मामला है। शायद एक पढ़ने .env.default से पहले फ़ाइल .env इस के लिए एक सरल उपाय है (जो BTW देखभाल करेगा लंबे समय से # 210 के साथ-साथ)?

मैंने अपने स्वयं के फ़ंक्शन के साथ डॉकटर-कम्पोज़ बाइनरी लपेटकर इसे हल किया ताकि मैं फ़ंक्शन को कहीं से भी कॉल कर सकूं। यह .env फ़ाइल को लोड करता है और कहीं भी सही डॉकटर-कंपोज़ फ़ाइल का उपयोग करता है।

जाहिर है आप इसे प्रति प्रोजेक्ट या कुछ और करने के लिए बढ़ा सकते हैं। मुझे लगता है कि इसमें कमियां हो सकती हैं, लेकिन मैंने उन्हें बाहर नहीं निकाला है।

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

मुझे छवियों के टकराने की समस्या है, और यह वास्तव में अजीब लग रहा है कि मैं docker-compose.yml में project_name सेट नहीं कर सकता क्योंकि यह बहुत तार्किक और आगे के समाधान को रोकता है। वास्तव में पहली जगह में प्रोजेक्ट फ़ोल्डर से नाम लेना एक बुरा विचार था। कई मामलों में प्रोजेक्ट फोल्डर / होम / प्रोजेक्ट 1 / रिपॉजिटरी, / होम / प्रोजेक्ट 2 / रिपॉजिटरी इत्यादि जैसे हो सकते हैं, इस मामले में डॉकटर ने रिपॉजिटरी_एप्प की तरह ही इमेज के नाम तैयार किए हैं।

@ देवता आप docker-compose.yml में छवि नाम सेट कर सकते हैं, बस image और build ।

तो ... अब एक ही नाम वाले फ़ोल्डर पर परियोजनाओं द्वारा कैसे अलग किया जाता है?

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

शायद यह पहले से ही प्रस्तावित था। लेकिन version: 4 में ब्रेकिंग परिवर्तन क्यों नहीं किया गया और docker-compose.yml से प्रोजेक्ट का नाम सेट करने की अनुमति देने के लिए कुछ नए कीवर्ड जोड़ें?

मेरी .docker- रचना / प्रोजेक्ट-नाम काम नहीं किया ...
--प्रोजेक्ट-नाम काम किया

मैं docker-compose.yml में भी प्रोजेक्ट नाम सेट करना चाहूंगा।

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

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

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

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

अगर मैं projectname docker-compose.yml और docker-compose.adhoc.yml निर्दिष्ट कर सकता हूं - तो मैं उन्हें ढांचा बना सकता हूं, लेकिन मैं चाहता हूं (यहां तक ​​कि उन्हें अलग-अलग रेपो में भी डाल सकता हूं) और अभी भी बिना उन्हें निष्पादित किए लगातार अतिरिक्त कमांड लाइन तर्क निर्दिष्ट करें या पर्यावरण चर को चारों ओर घुमाएं।

यह मेरे लिए एक वास्तविक समस्या है, क्योंकि यह नामकरण संघर्ष का कारण बनता है

मेरे पास संरचना में कई परियोजनाएं हैं

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

अब जब मैं एक प्रोजेक्ट में डॉकटर-कंपोज शुरू करता हूं, तो यह backend_default नेटवर्क तैयार करता है और पहले से तैयार किए गए कंटेनरों को backend_ साथ नाम नहीं दिया जाता है। अब अगर मैं दूसरे प्रोजेक्ट को शुरू करना चाहता हूं, तो मेरे पास है सही फ़ोल्डर में वापस जाने के लिए और संघर्षों को रोकने के लिए पहले docker-compose down चलाएं - अन्यथा यह एक ही नेटवर्क में नए कंटेनरों को शुरू करेगा, और फिर उन्हें बंद करने पर, यह अनाथों के बारे में शिकायत करेगा, जब कोई नहीं हैं।

मेरे लिए भी एक मुद्दा है। मेरे पास कई परियोजनाएं हैं, और डायनेमिक डेमो के लिए एक मशीन, एक शाखा प्रति स्टैंड पर डॉक-कंपोज़ का उपयोग करें।

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

इसलिए "स्वामी" और "देव" परियोजनाओं के बीच संघर्ष कर रहे हैं। एक .docker-compose फ़ाइल को हल कर सकता है।

@simplesmiler खुद को दोहराने के जोखिम में, एक .env पहले ही हल कर लेता है ।

@ shin- .env का उपयोग अक्सर उन संस्करणों के लिए किया जाता है जो संस्करण नियंत्रण में नहीं हैं।

क्या @simplesmiler चाहता है रखने _while संस्करण नियंत्रण करने के लिए इस परियोजना का नाम प्रतिबद्ध करने के लिए एक रास्ता है .env बाहर संस्करण control_।

जहां तक ​​मैं बता सकता हूं कि इसे आसानी से करने का कोई तरीका नहीं है।

@thedeeno यह नहीं है कि उनके पद क्या कहते हैं। क्या आप एक साथ काम कर रहे हैं? यदि नहीं, तो हमें यह नहीं मानना ​​चाहिए कि किसी और के उपयोग का मामला स्पष्ट रूप से लिखे जाने से परे है।

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

काश हम एक साथ काम करते, हालांकि हम कुछ कॉफी हड़प सकते थे। मुझे आशा है कि आपको नहीं लगता कि मैं यहाँ एक झटका हूँ।

शायद मैं इस धागे को गलत तरीके से याद कर रहा हूं: क्या .env अनदेखा करते हुए प्रोजेक्ट नाम को संस्करण नियंत्रण के लिए प्रतिबद्ध करने का कोई तरीका है?

क्या .env को नजरअंदाज करते हुए परियोजना के नाम को संस्करण नियंत्रण के लिए प्रतिबद्ध करने का कोई तरीका है? या यह अभी भी एक लापता क्षमता है?

फिलहाल नहीं। जैसा कि मैंने कुछ महीने पहले ^ 1 में उल्लेख किया है, इस योजना में एक द्वितीयक env फ़ाइल के रूप में docker-compose.env होना है जिसे संस्करण नियंत्रण में शामिल किया जा सकता है। यह कुछ हद तक प्राथमिकताओं की सूची से नीचे गिर गया है, लेकिन मुझे उम्मीद है कि जल्द ही यह मिल जाएगा।

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

यह तो बहुत अच्छी खबर है! PR की स्वीकृति?

मैंने बहुत पहले उम्मीद छोड़ दी थी लेकिन चलो इसे एक और कोशिश देते हैं:

मुझे लगता है कि कई लोग अभी भी यह समझने में असफल हैं कि हमें इस सेटिंग के लिए दूसरी फाइल बनाए रखने के लिए क्यों मजबूर किया जाता है।

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

यह तार्किक रूप से भी कोई मतलब नहीं है: docker-compose.yml में इस सेटिंग की कमी इतनी स्पष्ट है कि मैं यह भी विश्वास नहीं कर सकता था कि जब यह मैनुअल में देखा गया तो यह विकल्प गायब है। आपके सेटअप के लगभग प्रत्येक और हर पहलू को वहां कॉन्फ़िगर किया जा सकता है। मेरे लिए यह विन्यास तर्क में इतना स्पष्ट विराम है।

मुझे लगता है कि कोई कह सकता है, (लगभग) docker-compose.yml में सभी सेटिंग्स प्रोजेक्ट नाम से "स्कोप" हैं।

जैसा कि # 4841 में सुझाया गया है, जिसमें .env फ़ाइल का उपयोग करने का एक विकल्प (अर्थात --env-file ) बहुत उपयोगी होना चाहिए।

@roipoussiere पर देखें https://github.com/docker/compose/issues/4841#issuecomment -414543951

धन्यवाद @ schmunk42
लेकिन इसका मतलब है कि मुझे एक पदानुक्रम बनाना होगा:

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

इसके बजाय कुछ आसान की तरह:

.
├── a.env
├── b.env

हाँ, यह भी देखें https://github.com/docker/compose/issues/745#issuecomment -345054893 - आपको इसे एक नई विंडो में खोलने की आवश्यकता हो सकती है, क्योंकि यह कभी-कभी यहां छिपा होता है : nerd_face:

मैं --env-file प्रस्ताव रखता हूं। बस उसी के लिए टिकट बनाया। यदि आप इस विकल्प को चाहते हैं तो इसे पसंद करें।

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

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

लेकिन मान लीजिए कि आप स्ट्राइप के साथ काम कर रहे हैं, जो आपको टेस्ट कीज़ और लाइव कीज़, AKA की अनुमति देता है। कुंजी के 2 सेट के साथ काम करने के लिए। विकास में यह आपके लिए परीक्षण कुंजियों का उपयोग करने के लिए बहुत सामान्य होगा, और उत्पादन में आप लाइव कुंजियों का उपयोग करके समाप्त हो जाएंगे।

इसका मतलब है कि आप गुप्त मूल्यों से निपटने के लिए .env उपयोग स्वयं नहीं कर सकते क्योंकि आपके पास प्रत्येक वातावरण में अलग-अलग कुंजियाँ होंगी, और आप अपनी फ़ाइल चलाने के बीच मूल्यों को अपनी फ़ाइल में बदलना नहीं चाहते हैं देव या ठेस में अनुप्रयोग (कि पागल और सुपर त्रुटि प्रवण होगा)।

आप जो कर रहे हैं, संभव है कि दोनों .env और .env.prod फ़ाइल बनाएँ और दोनों को संस्करण नियंत्रण से अनदेखा करें। इस तरह से आपके पास विकास में आपकी परीक्षा / देव कुंजियाँ हो सकती हैं और फिर संदर्भ दें कि आपके विकास रचना में env_file ।

लेकिन तब उत्पादन में आप दोनों .env और .env.prod अपनी उत्पादन रचना फ़ाइल में देखें।

लेकिन क्या आप देखते हैं कि यह कहां जा रहा है? अभी Docker Compose में आपको वैकल्पिक env_file फाइलें नहीं हैं। यदि फ़ाइल मौजूद नहीं है, तो जैसे ही आप डॉकर कंपोज़ को चलाने का प्रयास करेंगे, डॉकटर कंपोज़ को झटका लगने वाला है।

इसलिए यदि आप env_file साथ इसका उपयोग करने की योजना बनाते हैं, तो आपको अंत में .env फ़ाइल की आवश्यकता होती है और यह स्ट्राइप तक सीमित नहीं है। बहुत सारे वेब फ्रेमवर्क में कुछ सेटिंग्स होती हैं जो पर्यावरण विशिष्ट होती हैं लेकिन विकास और उत्पादन दोनों में बदल जाती हैं (यानी SERVER_NAME फ्लास्क के साथ)।

तो इसका मतलब है कि हम .env_example फ़ाइल जैसी कुछ चीज़ों तक सीमित हैं जिन्हें आप संस्करण नियंत्रण के लिए प्रतिबद्ध करते हैं और यह अपेक्षित है कि अंतिम उपयोगकर्ता उस फ़ाइल का नाम बदलकर .env , और फिर इस फ़ाइल के अंदर होगा हमारे पुराने दोस्त COMPOSE_PROJECT_NAME ।

जो अब सवाल उठाता है। क्या हमें वास्तव में परियोजना के नाम को स्थापित करने के वैकल्पिक तरीके की आवश्यकता है? मुझे विश्वास नहीं है कि हम करते हैं, लेकिन मुझे यकीन है कि एक कस्टम प्रोजेक्ट नाम सेट करना किसी भी परियोजना में एक अच्छा विचार है, या कम से कम फ़ोल्डर नाम के अलावा कुछ और है क्योंकि आप आसानी से नाम संघर्षों में भाग सकते हैं।

क्या कुछ रोड मैप पर यह समस्या है?

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

हमारे मामले में, हम अपने makefile में COMPOSE_PROJECT_NAME बनाकर इस डॉक्यू-कंपोज़ की सीमा के आसपास पहुँच सकते हैं।

मैं इस विन्यास को यमल के ही भीतर से देखना चाहूंगा।

क्या यह अभी भी खुला है? हे भगवान...

सदस्यता ली। मैं यह भी चाहता हूं कि कम्पोज यामल फाइल पर प्रोजेक्ट का नाम सेट कर सके।

यह हमेशा के लिए ले रहा है

इस सुविधा के लिए बहुत उपयोगी होगा

मैं जिस प्रोजेक्ट पर काम कर रहा हूं, उसमें इस फीचर का बहुत स्वागत होगा

ठीक है, इसलिए इस लंबे धागे से हम यह निष्कर्ष निकाल सकते हैं कि परियोजना का नाम docker-compose.yml फ़ाइल में नहीं होगा, क्योंकि मुख्य डेवलपर्स इसके विरूद्ध हैं और ऐसे किसी भी पुल अनुरोध का विलय नहीं करेंगे।

इसलिए, क्या हम इस प्रस्ताव के शीर्ष पर मूल प्रस्ताव पर वापस जा सकते हैं: परियोजना-नाम को लगातार बनाए रखने के लिए। फ़ाइल का उपयोग करना .docker- रचना या निर्देशिका .docker- रचना मेरे लिए ठीक लगता है। लेकिन यह अच्छा होगा अगर हम आखिरकार इसे लागू करने पर कुछ प्रगति कर सकें।

मैं विकल्पों की उस सूची में एक ENV चर जोड़ूंगा।

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

विभिन्न परियोजनाओं के बीच यम फ़ाइलों को साझा करने के दर्शन के लिए यम विरोधाभासों की सामग्री के बजाय ईएनवी होने से। वास्तव में यह आधिकारिक रूप से प्रलेखित है: https://docs.docker.com/compose/extends/ (उदाहरण के लिए "उदाहरण usecases" देखें)। यदि आप एकल बेस याम फाइल का उपयोग करते हैं, और फिर देव, परीक्षण और ठेस के लिए फ़ाइलों को ओवरराइड करते हैं, और भगवान को पता है कि और क्या है, तो इसे उसी प्रोजेक्ट नाम के तहत चलाने या ENV / cli द्वारा प्रोजेक्ट नाम सेट करने का कोई मतलब नहीं है। यह केवल N * N संयोजन बनाएगा जबकि N मान्य हैं।

मैंने इनमें से कई चर्चाओं को ट्रेस किया है और YML फ़ाइल में प्रोजेक्ट नाम को चाहने वाले लोगों की टिप्पणियों का TON देखा है। लेकिन 1 एकल टिप्पणी यह ​​नहीं समझाती है कि ऐसा क्यों नहीं किया जाना चाहिए। ये चर्चाएँ बहुत पहले की हैं।

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

एक सुरुचिपूर्ण समाधान container_name संपत्ति में प्लेसहोल्डर का उपयोग करने के लिए हो सकता है (और वॉल्यूम, नेटवर्क, जैसे अन्य गतिशील नामकरण ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

ऐसे कॉन्फ़िगरेशन के साथ, कोई भी उपयोग कर सकता है

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

संपादित करें: यह एक सही समाधान नहीं है, क्योंकि यह उन लोगों के लिए संघर्ष करेगा जो समान फ़ोल्डर नाम के भीतर 2 प्रतिष्ठित परियोजना का उपयोग करते हैं

@jderusse

एक सुरुचिपूर्ण समाधान container_name संपत्ति में प्लेसहोल्डर का उपयोग करने के लिए हो सकता है (और वॉल्यूम, नेटवर्क, जैसे अन्य गतिशील नामकरण ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

ऐसे कॉन्फ़िगरेशन के साथ, कोई भी उपयोग कर सकता है

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

संपादित करें: यह एक सही समाधान नहीं है, क्योंकि यह उन लोगों के लिए संघर्ष करेगा जो समान फ़ोल्डर नाम के भीतर 2 प्रतिष्ठित परियोजना का उपयोग करते हैं

मैं यह भी कर रहा हूं और सोचा था कि यह संघर्ष की समस्या को ठीक करेगा, हालांकि हमें अभी भी .env फ़ाइल पर कुछ अद्वितीय मूल्य के लिए COMPOSE_PROJECT_NAME चर सेट करने की आवश्यकता है।

इस बिंदु पर, मैं वास्तव में केवल इस कारण को समझना चाहता हूं कि अनुचर समाधानों को अस्वीकार कर रहे हैं। समाधान के लिए पहले से ही एक अनुरोध है।

एक बार जब हम जानते हैं कि क्या गलत है, तो हम इसे ठीक करने पर काम कर सकते हैं। इस बिंदु पर, मुझे "अस्वीकृत" के अलावा कोई प्रतिक्रिया नहीं दिखाई देती है।

हमारे पास ये 2 टिप्पणियाँ हैं:

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

लेकिन मुझे उन टिप्पणियों को पढ़ते हुए भी स्वीकार करना चाहिए, मुझे पूरी तरह से समझ में नहीं आया कि क्यों न केवल प्रोजेक्ट_नाम को यमल फ़ाइल में जोड़ा जाए। उन लोगों के लिए जो यह सोचते हैं कि यह उनके docker-compose.yaml फाइलों को कम सामान्य बनाता है, उन्हें बस नाम यमल फ़ाइल में नहीं डालना चाहिए, लेकिन कृपया हममें से बाकी लोगों के पास ऐसा करने का विकल्प है।

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

मुझे जो कुछ भी दिखाई दे रहा है उसे संक्षेप में बताने का प्रयास करता हूं। यह नीचे स्पष्ट करने के लिए किसी भी मदद की सराहना की जाएगी।

(1) YML फ़ाइल में प्रोजेक्ट का नाम जोड़ने से प्रोजेक्ट को पुन: उपयोग योग्य बनाया जा सकता है क्योंकि यह एक YML फ़ाइल को एक से अधिक प्रोजेक्ट नाम के साथ चलाने से रोकेगा, या कम से कम जटिल होगा।
(2) "परियोजना की गुणवत्ता इसे जोड़ने के औचित्य के परिणामस्वरूप बहुत अधिक पीड़ित होगी (इस रूप में)"
(3) "यदि प्रोजेक्ट का नाम कम्पोज़ फाइल में है तो कोई भी दो प्रोजेक्ट एक ही नाम का उपयोग कर सकते हैं, जिससे विरोध पैदा होगा, जो दोनों प्रोजेक्ट को तोड़ देगा।"

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

(4) पिछड़े संगत तरीके से कार्यान्वयन (मूल्यों की पूर्वता / व्यवस्था)

(1) YML फ़ाइल में प्रोजेक्ट का नाम जोड़ने से प्रोजेक्ट को पुन: उपयोग योग्य बनाया जा सकता है क्योंकि यह एक YML फ़ाइल को एक से अधिक प्रोजेक्ट नाम के साथ चलाने से रोकेगा, या कम से कम जटिल होगा।

फिर भी, आधार और फ़ाइल में कॉन्फ़िगरेशन को विभाजित करने और विरासत में प्राप्त करने का आधिकारिक तरीका है - https://docs.docker.com/compose/extends/। एक बेस कॉन्फिग में प्रोजेक्ट का नाम सेट नहीं कर सका।

मेरे लिए मैं जिस प्राथमिक उपयोग के मामले की तलाश कर रहा हूं, वह परियोजना के कई उदाहरणों को स्थानीय रूप से चलाने की क्षमता है (देव, परीक्षण वातावरण आदि)।

हो सकता है कि समाधान यह हो कि आप परियोजना का नाम या तो स्पष्ट रूप से तय कर सकते हैं या पथ-प्रदर्शक हो सकते हैं।

अगर मैंने स्पष्ट रूप से my-project तरह yaml फ़ाइल में प्रोजेक्ट का नाम सेट किया है, तो किसी प्रोजेक्ट के एक ही उदाहरण के लिए चीजों को सरल कर सकता है या जहाँ मैं कुछ ऐसा करता हूँ जैसे कि docker फ़ोल्डर में मेरे सभी docker फ़ाइलों को जोड़ना कई परियोजनाओं में।

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

लेकिन यह एक ही परियोजना के कई उदाहरणों के साथ मदद नहीं करता है, इसलिए पथ के साथ कुछ करने के बारे में कैसे

project_name: ../(*) एक ही उदाहरण के साथ

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

इसी तरह project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

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

केवल आधा-मजाक: इसका मतलब है कि मेरे docker-compose.yml में एक निश्चित नाम को कॉन्फ़िगर करने के लिए मैं जो नाम चाहता हूं उसके साथ एक फ़ाइल बनाऊंगा और फिर project_name: name-of-the-file-named-like-the-name-i-want सेट करूंगा?

वर्तमान में मेरे पास एक ही निर्देशिका में docker-compose फ़ाइलों का भार है। dc-work.yml , dc-server.yml , आदि, कि सभी अलग-अलग, असंबंधित सेवाओं को लोड करते हैं।

जब मैं docker-compose up dc-A.yml भागता हूं, और फिर docker-compose up dc-B.yml चलाता हूं, तो डॉकर ने मुझे नंगा कर दिया है कि अनाथ सेवाएं चल रही हैं (निश्चित रूप से वहाँ नहीं हैं, यह शापित प्रोजेक्ट नाम के कारण है)।

क्या वास्तव में इसे हल करने का कोई तरीका नहीं है? प्रत्येक dc-A|B|C|etc.yml फ़ाइल को अपनी निर्देशिका में स्थानांतरित करना, और फिर मेरी सभी सेवाओं को लोड करने के लिए प्रत्येक में अनुरेखण करना समय की वास्तविक बर्बादी की तरह लगता है, या क्या मुझे कुछ याद आ रहा है?

इस समस्या का समाधान क्यों नहीं किया गया? यहाँ पर @ cr7pt0gr4ph7 द्वारा स्पष्ट और सीधा समाधान प्रस्तुत किया गया था: https://github.com/docker/compose/issues/745#issuecomment -182296139। इसे काफी वोट मिले। चर्चा में हर एक चिंता को संबोधित किया गया है। और, सबसे महत्वपूर्ण बात, यह बहुत सारे लोगों के लिए बहुत सारे मुद्दों को हल करता है। क्या देता है?

इस मुद्दे में भी चल रहा है क्योंकि हम एक .docker फ़ोल्डर के साथ एक निश्चित परियोजना निर्देशिका संरचना का उपयोग कर रहे हैं जिसमें सभी docker-संबंधित सामान शामिल हैं, इसलिए मैं बहुत सारे .docker परियोजना नामों के साथ समाप्त कर रहा हूं - मैं एक microservices आर्किटेक्चर पर काम कर रहा हूं। इसलिए यह कई बार सामान्य है ... लेकिन यह छोटी सी चीज, रास्ते में मिलती रहती है -> यह भी, PHPStorm आदि के पास -p / - प्रोजेक्ट- dir तर्क पास करने का विकल्प नहीं है और मैं नहीं कर सकता वास्तव में इसके लिए .env का उपयोग करें क्योंकि, मेरा विश्वास करो, सही मूल्य निर्धारित करना भूल जाएगा ...

डेवलपर्स, कृपया हमें बताएं कि आप इसे कैसे हल करना चाहते हैं।

शायद प्रोजेक्ट-नाम सेट करने के लिए डॉकटर-कंपोज़ फ़ाइल में कोई प्रॉपर्टी जोड़ें?

@AyushyaChitransh

डेवलपर्स, कृपया हमें बताएं कि आप इसे कैसे हल करना चाहते हैं।

यह सबसे अच्छा सारांश है:
https://github.com/docker/compose/issues/745#issuecomment -182296139

खूब चर्चा हुई है। इसके लिए किसी और चर्चा की आवश्यकता नहीं है। परियोजना अनुरक्षकों को केवल थ्रेड्स (बहुवचन) को पढ़ने और आवश्यक करने की आवश्यकता है।

मेरे लिए यह अभी भी है: https://github.com/docker/compose/issues/745#issuecomment -248644429

मेरे लिए यह अभी भी है: # 745 (टिप्पणी)

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

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

@AyushyaChitransh
हम यहाँ वर्णित प्रोजेक्ट नाम सेट करने के लिए तंत्र का उपयोग करना चाहते हैं: https://github.com/docker/compose/issues/745#issuecomment -182296139

1. कमांड लाइन आर्ग।
2. पर्यावरण चर (.env फ़ाइल)
3. सीधे कम्पोज फाइल में
4. फ़ोल्डर की जगह

ऐसा मत सोचो कि इसमें कोई आपत्ति है।

यह पोर्टेबिलिटी के बारे में है, जैसा कि ऊपर उल्लेख किया गया है, किसी तरह container_name का उपयोग करते समय, जो docker-compose.yml का हिस्सा नहीं होना चाहिए। आप मौजूदा सेटिंग्स के साथ एक ही कॉन्फ़िगरेशन का पुन: उपयोग नहीं कर सकते।

यदि आपका वर्कफ़्लो फ़ोल्डर-पथ पर निर्भर है और किसी तरह project-name आपके कॉन्फ़िगर में इंजेक्ट किया जाता है, जैसे। विलय के माध्यम से, कई कम्पोज फाइल, टेम्प्लेट, ... - आप एक ही समस्या के साथ समाप्त हो जाएंगे - मौजूदा स्टैक ओवरराइटिंग।

यह कहने के लिए क्षमा करें, लेकिन इसे wontfix .. के रूप में बंद किया जाना चाहिए .. (संपादित करें) या एक नया MAJOR (!) संस्करण जारी करें

@ schmunk42

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

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

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

वॉन्टिक्स के रूप में इसे बंद करना यह बताए बिना बहुत मददगार नहीं है कि उपरोक्त isnt क्यों काफी अच्छा है .. या एक समाधान के लिए एक मार्ग प्रदान करता है।

मैं नहीं चाहता कि मेरे वर्कफ़्लो (या मेरी पूरी टीम के वर्कफ़्लो) इस बात पर निर्भर रहें कि वे उस फोल्डर का नाम क्या रखते हैं जिसे वे कोड चेक करते हैं।

.Env फ़ाइल सॉल्यूशन के साथ मेरी मुख्य समस्या यह है कि यह फ़ाइल कमांड रन के वर्किंग डायर में होनी चाहिए - जबकि डॉकटर-कंपोज़ पैरेंट डाइरेक्टरी में फाइल को हल करता है। इसलिए, यह आवश्यक हो जाता है कि सभी डेवलपर्स या तो (ए) समान-नामित फ़ोल्डर में कोड की जांच करें (एक कोड रेपो की जड़ में एक docker-compose.yml फ़ाइल मानकर) या (B) केवल docker-compose कमांड चलाएं रेपो के रूट फोल्डर अन्यथा परस्पर विरोधी स्टैक या (सी) बनाते हैं उनके अलग-अलग स्टैक नाम हैं और सभी प्रलेखन और लिपियों को replace stack name here कहने की आवश्यकता है।

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

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

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

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

@ dc-pm ने लिखा: "कुबेरनेट्स को देखते हुए अब डॉकटरों के लिए डेपो तैनाती उपकरण है"

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

सच कहा जाए, तो मेरे विकास के माहौल में कंटेनरों से निपटना दिन-प्रतिदिन बहुत परेशानी भरा है। मैं सिर्फ कार्यक्रम चलाता हूं ...

@ dc-pm ने लिखा:

मुझे विश्वास नहीं हो रहा है कि यह 2020 है और हमने अभी भी इस विशाल उपयोग के मामले को ठीक नहीं किया है।

यह सिर्फ यह नहीं है कि इसे ठीक नहीं किया गया है, लेकिन डेवलपर्स इसे ठीक करने से इनकार करते हैं।

मुझे समस्या है, मुझे संदेह है कि इस सॉफ्टवेयर को विकसित करने वाले किशोरों के पास इस उपयोग के मामले के निहितार्थ को समझने के लिए अनुभव की गहराई नहीं है, या अपने अधिक अनुभवी उपयोगकर्ताओं की विशाल संख्या को सुनने का अनुरोध करते हुए इसे संबोधित किया जाना चाहिए। इस बिंदु पर मुझे संदेह है कि उन्होंने एक से अधिक स्टैक वाले वातावरण में काम किया है, या शायद टीमों में भी। अन्यथा, स्पष्ट रूप से, _this एक पूरी तरह से स्पष्ट वृद्धि होगी! _

कुछ दोस्ताना अनुस्मारक ...
ओपन-सोर्स डेवलपर्स आपके "कर्मचारी / कॉलेज" नहीं हैं, ज्यादातर मामलों में वे ज्यादातर मुफ्त में काम कर रहे हैं।
यदि यह स्पष्ट रूप से आपके लिए एक मुद्दा है, तो समाधानों की जांच करने के लिए कुछ समय लें (और पीआर को धक्का दें)।

दोष देना समाधान नहीं है।

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

जब डेवलपर्स इसके खिलाफ होते हैं तो एक बदलाव को आगे बढ़ाना काफी मुश्किल होता है ...

शनिवार को, 14 मार्च 2020 को 03:19 पर, एंटोनी ग्रेवेलॉट सूचनाएं @github.com
लिखा था:

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

दोष देना समाधान नहीं है।

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

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

@agravelot मुझे लगता है कि कुछ

@agravelot देरी के लिए खेद है। और मैं वास्तव में कई भयानक और प्रतिभाशाली लोगों के प्रति अनादर का मतलब नहीं है जो यहां योगदान करते हैं। लेकिन प्रयास की कमी को दोष देना भी मददगार नहीं है।

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

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

आगे और अधिक रचनात्मक तरीका क्या होगा?

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

हां, देवों को उनकी समीक्षा के साथ जाना चाहिए, या इसे "ठीक नहीं होगा" (संभवत: बहस करते हुए) के रूप में बंद करना चाहिए ... इसे सालों तक खुला रखना, बिना किसी आधिकारिक प्रतिक्रिया के, यह सिर्फ योगदानकर्ताओं का समय बर्बाद कर रहा है (व्यापक अर्थों में) )। यह भी अपमानजनक है, आईएमओ।

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

तो मैं चला:

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

ध्यान दें कि यह "डेटाबेस-देव को फिर से बनाना" कैसे कहता है, जबकि मैं "ठेस" परियोजना में स्थित सेवा का स्पष्ट रूप से उल्लेख कर रहा हूं। वास्तव में मौजूदा कंटेनर को ओवरराइट करता है। डेटाबेस समाप्त हो जाता है और कंटेनर को बाद के साथ बदल दिया जाता है।

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

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

एकल-आदेश परिनियोजन के लिए इतना, क्या एक निरपेक्ष मजाक। मेरी राय में, .yml इस संदर्भ में परियोजना का नाम निर्दिष्ट करने के लिए बहुत अच्छी जगह है।

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

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

इससे कोई मतलब नहीं है कि tbh, ऐसा क्यों होता है। वास्तव में ऐसा क्यों है?

EDIT1: @ डीसी-बजे @CharlieReitzel लगता whatchu? अगर यह अमान्य है तो क्या आप मेरे उपयोग के मामले में कोई टिप्पणी दे सकते हैं, :)
EDIT2: मैंने दोनों कंपोजिट फाइल को अलग-अलग डायरेक्टरी और वॉयला में डाल दिया है

sooo?

रखवाले, यहाँ कोई भी?
6 साल के दौरान डेवलपर्स इंतजार!

नमस्ते! मैंने कंपोज़-स्पेक में एक समस्या पैदा की है कि प्रोजेक्ट-नाम को कंपोज़ स्कीमा में जोड़ा जाए क्योंकि यह नियंत्रित करता है कि हम कंपोज़ फ़ाइल में क्या जोड़ सकते हैं।
एक बार प्रोजेक्ट-नेम प्रॉपर्टी को कंपोज़ स्पेस से जोड़ दिया जाए, तो हम डॉकटर-कंपोज़ में कार्यान्वयन शुरू कर सकते हैं।