compose 🚀 - Yaml कॉन्फ़िगरेशन में `copy` जोड़ें

यहाँ copy का शब्दार्थ क्या है? क्या हम उस होस्ट से फाइल कॉपी कर रहे हैं जहां docker-compose नए चल रहे कंटेनर में docker cp का उपयोग करके चलाया जाता है?

prologic 7 जुल॰ 2015

AFAIK ऐसा करने का वर्तमान तरीका _no_ है:

देख:

`` `#! बाश
$ डॉकटर cp -h

उपयोग: docker cp [विकल्प] कंटेनर: पथ HOSTDIR | -

होस्ट पर एक HOSTDIR में कंटेनर पर एक PATH से फ़ाइलों / फ़ोल्डरों को कॉपी करें
कमांड चलाना। STDOUT को डेटा को टार फाइल के रूप में लिखने के लिए '-' का प्रयोग करें।

--help = गलत प्रिंट उपयोग
`` `

prologic 7 जुल॰ 2015

यहाँ नकल का शब्दार्थ क्या है? क्या हम होस्ट से फाइल कॉपी कर रहे हैं, जिसमें docker-cose का उपयोग करते हुए नए रनिंग कंटेनर से चलाया जाता है?

हाँ

AFAIK ऐसा करने का कोई वर्तमान तरीका नहीं है:

मैं देखता हूं कि docker cp कमांड ऐसा करने में असमर्थ है। फिर भी यह मेजबान की ओर से कंटेनर डेटा तक पहुंच संभव है (जो मैं बदसूरत हूँ)

http://stackoverflow.com/a/24805696/210090

riquito 7 जुल॰ 2015

👍1

हाँ, मैं वकालत नहीं करने जा रहा हूँ हम ऐसा करते हैं। इससे डॉकर के बारे में बहुत सी बातें और धारणाएँ टूटेंगी। यह अंतर्निहित भंडारण ड्राइवर पर भी अत्यधिक निर्भर है जिसका उपयोग किया जा रहा है। डॉकर का अर्थ अज्ञेय से है। मुझे लगता है कि हम आपकी समस्या का एक अलग समाधान _should_ :)

prologic 7 जुल॰ 2015

अब जब कि डोकर-1.8 के माध्यम से एक कंटेनर में प्रतिलिपि के लिए समर्थन जोड़ा docker cp के लिए और झुंड-0.4.0-rc2 जोड़ा समर्थन docker cp , उसे लिखें स्तर पर इस मुद्दे को फिर से बहुत अच्छा होगा। यहां उपयोग का मामला है (जो कि हम वास्तव में _almost_ उत्पादन में अब क्या करते हैं दर्पण):

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

docker cp समर्थन करने से हमारे सिस्टम परिनियोजन विधि में कस्टम कॉन्फ़िगरेशन फ़ाइल सिंक को हटाने की अनुमति मिलेगी और कॉन्फ़िगरेशन परिवर्तन इंजेक्ट होने पर बेहतर नियंत्रण की अनुमति होगी (क्योंकि volume: लाइनों में उल्लिखित फ़ाइलों को बदलने वाले किसी भी व्यक्ति को प्रभावित कर रहे हैं। सभी पूर्व में तैनात कंटेनर (और जो भी समय आंतरिक कार्यान्वयन फिर से पढ़े गए कॉन्फ़िगरेशन कहा जाता है, शायद केवल अगले कंटेनर पुनरारंभ होता है, शायद जब कंटेनर के अंदर विभिन्न उपकरण शुरू होते हैं; जो अप्रत्याशित हो सकता है) और भविष्य (जो अपेक्षित है)।

OTOH, (जैसा कि ऊपर उल्लेख किया गया है) शायद हमें build: उपयोग करना चाहिए। यहाँ नकारात्मक पक्ष यह है कि हमें प्रति तैनाती कंटेनर प्रकार के लिए एक अतिरिक्त डॉकरफाइल लिखना होगा। एक CI निर्मित छवियों के लिए और दूसरा स्थिर विन्यास फाइल इंजेक्टर के लिए। copy: की रचना हाल ही में docker cp बड़े बदलावों के द्वारा समर्थित है जो बड़े करीने से हमें इस सभी दोहराव से बचने की अनुमति देगा।

ljrittle 16 अग॰ 2015

👍9

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

dnephin 25 अग॰ 2015

बिस्तर docker-machine docker-machine scp वैसे भी है जो आप मशीन की तैयारी के साथ कर सकते हैं; और फिर आप सामान्य मात्रा में docker या docker-compose होस्ट कर सकते हैं

prologic 25 अग॰ 2015

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

ljrittle 26 अग॰ 2015

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

prologic 26 अग॰ 2015

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

ljrittle 26 अग॰ 2015

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

ljrittle 26 अग॰ 2015

"क्या आप वैसे भी झुंड के माध्यम से बहुत नोड पर एक डेटा वॉल्यूम कंटेनर को तैनात नहीं कर सकते हैं, जैसे आप किसी अन्य कंटेनर एएलए शेड्यूलिंग रणनीति के साथ कर सकते हैं?"
हम्म, अगर मुझे पता है कि मेरे झुंड का आकार 10 नोड है; क्या मैं डेटा वॉल्यूम कंटेनर को केवल एक पॉलिसी के साथ 10 आकार का हो सकता हूं, जो किसी दिए गए डॉक इंजन नोड पर कोई डुप्लिकेट की अनुमति नहीं है? समस्या (जब तक कि मैंने कुछ याद नहीं किया है) यह है कि उदाहरण के लिए कंटेनरों को उस डेटा वॉल्यूम के लिए कोई भी तरीका नहीं है - जो मेल खाते इंडेक्स के साथ कंटेनर से --volume से है। दोस्तों, मैं इस समस्या को 2 महीने से देख रहा हूँ। मैं जो सबसे अच्छा कर सकता था वह एक ऐसी स्क्रिप्ट तैयार करना है जो docker-machine scp का उपयोग करता है। लेकिन यह कॉन्फ़िगरेशन फ़ाइल को संपादित करने के बाद और docker-compose up से पहले एक मैन्युअल चरण है। इसके लिए यह भी आवश्यक है कि व्यक्ति झुंड की टारगेट मशीनों पर सटीक रास्ता लिख सके, जैसे कि docker-compose.yml (यानी यह एक बड़ी हैक की तरह महक)।

ljrittle 26 अग॰ 2015

👍1

शायद कारखाने में मेरे प्रयास डॉकटर मशीनों की कताई की इस प्रक्रिया को स्वचालित करने में मदद कर सकते हैं और "सही" डेटा के साथ झुंड के यात्रियों को इस्तेमाल करने के लिए तैयार बैठे हैं? (_albeit यह अभी भी प्रारंभिक विकास में है और मैं इसे docker-machine और docker-compose एक ही setp_0 में संयोजित करने के लिए उपयोग कर रहा हूँ।

prologic 26 अग॰ 2015

copy एक ऑपरेशन है, सेवा कॉन्फ़िगरेशन का हिस्सा नहीं है, इसलिए यह कंपोज़ फ़ाइल में नहीं है।

डॉकर 1.9 एक नया वॉल्यूम एपी जोड़ रहा है, और वॉल्यूम ड्राइवर पहले से ही हैं। वॉल्यूम वास्तव में इसका समर्थन करने का सही तरीका है। आसपास फ़ाइलों की प्रतिलिपि बनाने का प्रयास नहीं किया जा रहा है।

सलाह के लिये धन्यवाद! लेकिन मुझे नहीं लगता कि यह वास्तव में रचना के डिजाइन के साथ फिट बैठता है।

dnephin 16 अक्तू॰ 2015

👎40 😕13

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

क्या होगा अगर कोई सिर्फ एक कॉन्फ़िगरेशन फ़ाइल की प्रतिलिपि बनाना चाहता है? (एक डॉकटर झुंड के लिए, तो volume_from काम नहीं करेगा)

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

मुझे हर बार छवियों का उपयोग करना, निर्माण करना, खींचना होता है, जबकि कोई आवश्यकता नहीं होती है और सिर्फ कॉपी कमांड बहुत तैनाती और समय की बचत करेगा

dutgcom 7 मार्च 2016

👍80

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

johnculviner 14 अप्रैल 2016

एक ही मुद्दे पर मार। मैं एन अलग-अलग सेवाओं के लिए एक डॉकरीफाइल का पुन: उपयोग कर रहा हूं और मैं अपनी कॉपी कमांड के साथ एन अलग डॉकफेराइल बनाना नहीं चाहता हूं या केवल इसके लिए एक वॉल्यूम बनाना चाहता हूं।

unleashed 9 मई 2016

Btw मैं वर्तमान में sed कमांड की दर्जनों लाइनें चलाकर हल कर रहा हूं - http://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

शायद इष्टतम समाधान नहीं है, लेकिन यह देखते हुए काम करता है कि डॉक-कम्पोज़ नकल फ़ाइलों का समर्थन नहीं करता है।

Btw बढ़ते और पाठ्यक्रम की नकल संभव है, लेकिन यह ऑटोमैटाइजेशन डॉकटर-कंपोज ऑफर के खिलाफ जाता है - अगर मैं मैन्युअल रूप से डॉकटर-कंपोज का उपयोग नहीं करूंगा, तो क्या मैं सब कुछ नहीं करना चाहूंगा?

dutgcom 9 मई 2016

👍2

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

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

दिन के अंत में उपरोक्त दृष्टिकोण सब कुछ स्क्रिप्टेड, आलंबनपूर्ण और सबसे महत्वपूर्ण रूप से स्रोत नियंत्रण में जाँच करने की अनुमति देता है।

johnculviner 9 मई 2016

👍11

@dnephin ऊपर के कुछ लोगों ने CP के उपयोग के मामले को कॉन्फ़िगरेशन का हिस्सा होने का सुझाव दिया, क्या यह इस धारणा पर फिर से विचार करेगा कि CP केवल संचालन के लिए है न कि कॉन्फ़िगरेशन के लिए।

एक सरल उदाहरण एक कंटेनर बना रहा है, कॉन्फ़िगरेशन को कॉपी किए जाने के बाद कंटेनर को सही स्थान पर कॉपी करना, कंटेनर को शुरू करना।

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

ColinHebert 20 जून 2016

👍23

निश्चित रूप से बहुत मददगार होगा। मैं अब वापस डेटाबेस के रूप में छवि के साथ काम कर रहा हूं और मैं इसे फिर से बनाना नहीं चाहता, बस /docker-entrypoint-initdb.d फ़ोल्डर में एक स्क्रिप्ट को अपडेट करने के लिए।

dmikov 15 अग॰ 2016

👍35

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

ctindel 1 दिस॰ 2016

👍20

इस मुद्दे को फिर से खोला जाना चाहिए, जैसा कि @ctindel ने उल्लेख किया है।

NicklasWallgren 11 दिस॰ 2016

👍6

समस्या फिर से होने के लिए +1

metmajer 18 दिस॰ 2016

👍7

साथ ही खोलने के लिए +1।

lhridley 21 दिस॰ 2016

👍7

फिर से खोलने के लिए +1।

ghalusa 29 दिस॰ 2016

👍4

फिर से खोलने के लिए +1।

dixiedream 30 दिस॰ 2016

👍4

फिर से खोलने के लिए +1।

pbrueske 2 जन॰ 2017

👍3

फिर से खोलने के लिए +1।

AnthonyWC 6 जन॰ 2017

👍3

फिर से खोलने के लिए +1।

GeekHare 9 जन॰ 2017

👍3

फिर से खोलने के लिए +1।

BorzdeG 9 जन॰ 2017

👍3

केवल-पढ़ने की मात्रा के साथ क्या गलत है?

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

michaelarnauts 9 जन॰ 2017

😕2 👍2

@michaelarnauts देखना यह ।

koooge 11 जन॰ 2017

👍 फिर से खोलने के लिए

tonivj5 11 जन॰ 2017

👍1

फिर से खोलने के लिए +1।

nguyenphuocpham 23 जन॰ 2017

फिर से खोलने के लिए +1।

andresgaragiola 27 जन॰ 2017

फिर से खोलने के लिए +1

Orfen-0 30 जन॰ 2017

फिर से खोलने के लिए +1

ericlery 5 फ़र॰ 2017

फिर से खोलने के लिए +1

jayaskren 14 फ़र॰ 2017

फिर से खोलने के लिए +1

matthewh 16 फ़र॰ 2017

फिर से खोलने के लिए +1

legovaer 17 फ़र॰ 2017

👍2

फिर से खोलने के लिए +1

QuackMartins 22 फ़र॰ 2017

यहाँ कम्पोज़ में एक कॉपी की अनुमति के लिए मेरा तर्क है।

मेरे पास एक एप्लिकेशन है जो कई कंटेनरों पर चलता है। तर्क के लिए, आइए हम सभी अपाचे चलाते हैं। उन सभी के पास "/ var / www / partX" जैसी चीजों की ओर इशारा करते हुए DocumentRoot परिभाषाएँ हैं। Dockerfile अपाचे कॉन्फ़िगरेशन की सामग्री के बारे में कुछ नहीं जानता है, और Compose / var / www / partX के लिए वॉल्यूम संदर्भ को परिभाषित करता है। यह विकास के लिए बहुत अच्छा काम करता है, क्योंकि मैं कंटेनर सामग्री को संशोधित किए बिना कोड को डीबग और ट्विक कर सकता हूं।

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

मेरी प्राथमिकता डॉकफाइल्स के एक सेट को बनाए रखना और कंपोज़ फ़ाइल पर ऑर्केस्ट्रेशन करना होगा। कम्पोज़ वह होगा जहाँ मैं परिभाषित करता हूँ कि क्या मैं एक साझा वॉल्यूम के रूप में / var / www / partX सेट करने जा रहा हूँ या यदि मैं कंटेनर में फ़ाइलों की प्रतिलिपि बना रहा हूँ।

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

ऐसा लगता है कि मैं डॉकरफिले की परिभाषाओं में परिवर्तन करके फाइलों को सशर्त रूप से कॉपी कर सकता हूं, लेकिन ऐसा लगता है कि डॉकर ब्रह्मांड में मेरे सभी डॉकर लॉजिक को अधिक "लॉजिकल" हैंडल करते हैं, और कंपोज ऐसा करने के लिए एक लॉजिकल जगह की तरह लगता है।

jasonterando 23 फ़र॰ 2017

👍14

फिर से खोलने के लिए +1।

ugurcanlacin 24 फ़र॰ 2017

+1। में एक विन्यास फाइल कॉपी करने के लिए बहुत मददगार होगा docker-compose.yml के बजाय फ़ाइल Dockerfile ।

kalinchuk 28 फ़र॰ 2017

+1। बस इसमें भाग गया सेवा के लिए एक कॉन्फ़िगर फ़ाइल की आपूर्ति करने की कोशिश कर रहा है। रीड-ओनली वॉल्यूम एक विकल्प की तरह लगता है, लेकिन इसे कॉपी करेगा।

DimYurich 1 मार्च 2017

बस एक वॉल्यूम बढ़ाना चाल कर सकता है:

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

raszi 2 मार्च 2017

👍1

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

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

jasonterando 2 मार्च 2017

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

raszi 2 मार्च 2017

👍5

फिर से खोलने के लिए +1।

MeGaPk 23 मार्च 2017

+1

axklim 10 अप्रैल 2017

वॉल्यूम के बिना पुन: खोलने या विभिन्न समाधान के लिए +1।

वर्तमान में कंटेनर के मुख्य एप्लिकेशन को चलाने से पहले कॉन्फ़िगरेशन फ़ाइलों में पार्स करने के लिए docker-entrypoint.sh में docker-compose.yml और j2 में पर्यावरण चर का उपयोग करें। मेरे लिए काम करता है, हालांकि यह एक कस्टम छवि है और यह पहले से उपलब्ध पूर्ण चित्रों के साथ बॉक्स से बाहर का उपयोग नहीं किया जा सकता है।

burningalchemist 10 अप्रैल 2017

👍3

+1

budzek 23 अप्रैल 2017

+1

patrickjm 28 अप्रैल 2017

+1

b0laj1 4 मई 2017

+1

mizanRahman 4 मई 2017

+1

oiwn 10 मई 2017

+1

Snake-Tn 11 मई 2017

+1

nubitech 14 मई 2017

+1

storytime 18 मई 2017

+1

mmontossi 23 मई 2017

फिर से खोलने के लिए +1

पर्यावरण चर पर आधारित एक विन्यास के बजाय प्रत्येक कंटेनर के लिए एक अलग yaml फ़ाइल होने की संभावना को जोड़ने के लिए

jeroiraz 23 मई 2017

+1 बहुत आवश्यक सुविधा

ecoulon 26 मई 2017

+1, सुविधा के लिए अच्छा है!

damianvalderrama-olx 26 मई 2017

+1

andreymaznyak 3 जून 2017

+1

vlean 5 जून 2017

+1

jjortega 5 जून 2017

+1

konstan 7 जून 2017

+1 फिर से खोलना। बुकमार्क

hieudang9 21 जून 2017

+1 यह एक बहुत जरूरी फीचर है।

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

shatil 22 जून 2017

+1

christabone 12 जुल॰ 2017

+1

MichalKalita 14 जुल॰ 2017

+1

omani 17 जुल॰ 2017

+1

OlegVorobyov 17 जुल॰ 2017

+1

jabberwockyS 19 जुल॰ 2017

+1

Julien00859 19 जुल॰ 2017

+1

kolyaflash 24 जुल॰ 2017

+1

ikrauchanka 24 जुल॰ 2017

👍1

+1

che 24 जुल॰ 2017

👍1

+1 को फिर से खोलने के लिए क्योंकि यह एक बहुत ही उपयोगी सुविधा होगी

ghost 25 जुल॰ 2017

👍1

हो सकता है कि https://github.com/jwilder/dockerize का टेम्प्लेट फीचर आपकी कुछ मदद कर सके

Julien00859 25 जुल॰ 2017

👍1

+1

BlueHotDog 30 जुल॰ 2017

👍1

+1

hubun 4 अग॰ 2017

+1

sylvain261 7 अग॰ 2017

+1

tindleaj 8 अग॰ 2017

+1

vegasbrianc 8 अग॰ 2017

इस मुद्दे को फिर से खोलने के लिए +1

zmellal 9 अग॰ 2017

+1

leshcat 9 अग॰ 2017

डॉकटर रहस्यों का उपयोग करें, इस उदाहरण में सर्वर सर्टिफिकेशन और कॉन्फिग फ़ाइल को कॉपी करने के लिए नगनेक्स इमेज के साथ रहस्यों का उपयोग किया जाता है
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secret-with-a-nginx-service

zmellal 11 अग॰ 2017

👍1

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

यह आपके द्वारा शामिल की जाने वाली प्रत्येक कॉन्फ़िगरेशन फ़ाइल के लिए एक वॉल्यूम बढ़ते मेजबान की धड़कन करता है।

washtubs 15 अग॰ 2017

जैसा कि पहले कहा गया था:

...
मात्रा:
- ./nginx/default.conf:/etc/nginx/conf.d/default। conf: ro
- ./nginx/nginx.conf:/etc/nginx/nginx conf: ro
...

Oleffka 18 अग॰ 2017

👍3

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

मुझे लगता है कि नकल को docker build प्रक्रिया के समान मॉडल किया जा सकता है, जहां Dockerfile को आमतौर पर गिट रिपॉजिटरी में भेज दिया जाता है, साथ ही सभी फाइलों को बिल्ड संदर्भ में भेजने की आवश्यकता होती है। Dockerfile को ऐसी किसी भी चीज़ को भेजने की अनुमति नहीं है जो निर्देशिका संरचना के बाहर मौजूद है, भले ही वह सही तरीके से सम्‍मिलित हो। हम तो लिखें, जहां के साथ एक समान बात हो सकती है src की सूची (और नीचे उन) के लिए प्रतिबंधित है docker-compose.yml । मूल रूप से, वर्कफ़्लो होगा, docker-compose कंटेनर बनाता है, और फिर हर src:dst जोड़ी के लिए, वर्तमान निर्देशिका के तहत src , और इसे अनस्टार्ट किए गए कंटेनर में कॉपी करें, फिर कंटेनर शुरू करें।

वर्तमान में, होस्ट माउंट से बचने के लिए अतिरिक्त Dockerfiles जोड़कर और संशोधित छवियों में conf फ़ाइलों का निर्माण किया जा सकता है, लेकिन यह मेरे लिए ओवरकिल जैसा लगता है, क्योंकि इसमें एक नई छवि को फिर से शामिल करना, या उपयोगकर्ताओं को मजबूर करना शामिल है। अधिक श्रेयस्कर (IMO) image विशेषता के बजाय docker-compose build विशेषता का उपयोग करें। यदि आप पहले से ही अपनी सेवा परिभाषा में build विशेषता का उपयोग कर रहे हैं, और आप इस तरह से काम करना चाहते हैं, तो आपको अत्यधिक मत वाली कॉन्फ़िगरेशन फ़ाइल के साथ अपने अन्यथा अज्ञेय छवि बिल्डर को प्रदूषित करने के लिए मजबूर होना चाहिए जो कि केवल रचना के लिए होना चाहिए और तैनाती की प्रक्रिया।

washtubs 30 अग॰ 2017

👍7

डॉक-कंपोज कॉपी फीचर के लिए +1

paulwilton 6 सित॰ 2017

+1

and1990 15 सित॰ 2017

+1

Xplouder 21 सित॰ 2017

+1

kfrendrich 26 सित॰ 2017

कॉपी के लिए +1।

rajeshkaushik 29 सित॰ 2017

डॉक-कंपोज कॉपी फीचर के लिए +1। मुझे लगता है कि उपरोक्त पक्ष में तर्क सम्मोहक हैं।

PMDubuc 29 सित॰ 2017

कॉपी के लिए +1

ykalinov 4 अक्तू॰ 2017

कॉपी के लिए +1।

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

armadadean 9 अक्तू॰ 2017

+1

spetrashov 11 अक्तू॰ 2017

+1

ekapratama93 13 अक्तू॰ 2017

+1

mrkvost 16 अक्तू॰ 2017

+1

zzart 16 अक्तू॰ 2017

+1

mracos 18 अक्तू॰ 2017

+1

AlecJY 19 अक्तू॰ 2017

+1

petr-stupka 22 अक्तू॰ 2017

+1

meigallodixital 31 अक्तू॰ 2017

+1

sajjaadalipour 7 नव॰ 2017

+1

RW83 14 नव॰ 2017

+1

conker84 19 नव॰ 2017

+1

Nevario 20 नव॰ 2017

+1

marenaso 22 नव॰ 2017

फिर से खोलने के लिए +1

ryshi 27 नव॰ 2017

+1

rhk4360 29 नव॰ 2017

फिर से खोलने के लिए +1

कंटेनर (या स्वयं) के बाद किसी वॉल्यूम पर काम करने वाला एक फ़ीचर कुछ राज्य के काम तक नहीं पहुंचेगा?
यह एक ध्वज की तरह हो सकता है आसानी से, लेकिन इसके बजाय

jonsecchis 7 दिस॰ 2017

👍1

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

scottlindner 13 दिस॰ 2017

+!

atheinzen 19 दिस॰ 2017

+1

virus-warnning 20 दिस॰ 2017

डॉक-कंपोज कॉपी फीचर के लिए +1

ghost 1 जन॰ 2018

+1

afdevries 2 जन॰ 2018

+1

ukbe-aurea 2 जन॰ 2018

मुझे लगने लगा है कि यह व्यर्थ है। डॉकर केवल उन विशेष उपयोग-केस के बारे में सुविधाएँ जोड़ते हैं, जिनके लिए उन्होंने डॉकटर बनाया है - यह उनके उपयोग-केस के बाहर की विशेषताओं में से एक है, इसलिए वे संभवतः इसे कभी नहीं जोड़ेंगे।

stuaxo 2 जन॰ 2018

+1

delcon 3 जन॰ 2018

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

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

shin- 4 जन॰ 2018

👎15 😕2 👍1

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

डॉकिंग लेयरिंग और कैशिंग अन्य चीजों के लिए आसान हैं;

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

यह काम करने के लिए एक बहुत कुछ ले लिया docker का उपयोग करने के लिए MySQL और Apache अलग करने के लिए रचना है, लेकिन मुझे परवाह नहीं है अगर वे सभी एक साथ smooged।

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

stuaxo 4 जन॰ 2018

+1 डॉकटर-कंपोज कॉपी को जोड़ना होगा। यह कंटेनरों में कॉन्फ़िगरेशन फ़ाइलों और अद्यतनों के बहुत आसान प्रवाह की अनुमति देता है।

kingsman142 2 मार्च 2018

Docker cp और docker config का प्रयोग करें

शुक्र पर, २ मार्च २०१, को २१:१९ जेम्स हैन नोटिफिकेशन @github.com पर लिखा:

+1 डॉकटर-कंपोज कॉपी को जोड़ना होगा। यह बहुत आसान प्रवाह के लिए अनुमति देता है
कंटेनर के लिए विन्यास फाइल और अद्यतन।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/docker/compose/issues/1664#issuecomment-370055493 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABOv-q5VO9n9HDvBP6YJ1BCePz5tGu-pks5tabdrgaJpZM4FTTPg
।
>

जेम्स मिल्स / प्रोलोगिक

E: [email protected]
डब्ल्यू: prologic.shortcircuit.net.au

prologic 3 मार्च 2018

डॉक-कंपोज़ कॉपी के लिए +1। यहाँ वर्णित के रूप में फ़ाइलों के लिए प्रतिलिपि बनाने के लिए विचार है

chinmaya-n 22 मार्च 2018

👍3

+1

38leinaD 5 अप्रैल 2018

+1

smaley07 10 अप्रैल 2018

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

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

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

WebMatrixware 20 अप्रैल 2018

👍8

वाह, मैं विश्वास नहीं कर सकता यह अभी तक नहीं किया गया है। मैंने सोचा था कि यह बुनियादी कार्यक्षमता अब तक डूकर-रचना में रही होगी। ओह, ओएसएस परियोजनाओं की सुंदरता ...

इसे docker-compose --force-recreate --rebuild साथ हल किया, अगर वे बदल गए हैं (या ऐसा लगता है) तो यह नई फ़ाइलों को कॉपी करता है। आदर्श नहीं है लेकिन यह काम करता है।

darkguy2008 23 मई 2018

👍2

+1

zeeke 25 मई 2018

+1

elemir 31 मई 2018

+1

avgoeid 7 जून 2018

+1

umedjan 11 जून 2018

+1 यह कम महत्वपूर्ण है जो मुझे पागल कर रहा है, यह सिर्फ एक कॉन्फ़िगरेशन फ़ाइल के लिए वॉल्यूम माउंट करने के लिए मूर्खतापूर्ण लगता है।

ascourtas 15 जून 2018

👍7

+1

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

https://docs.docker.com/compose/compose-file/#configs

हालांकि, मेरा मानना है कि लोग चाहते हैं कि कंटेनर में एक निर्देशिका में होस्ट से फ़ाइलों को मर्ज करने का एक तरीका है जिसमें overwrite if exists , जिस तरह से आप काम करने के लिए एक कॉपी की उम्मीद करेंगे।

यह मेरे लिए अजीब है कि रचना फ़ाइल में volumes कॉन्फ़िगरेशन में nocopy विकल्प है:

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

जो इस तरह वर्णित है:
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

तो यह वास्तव में क्या वांछित है निष्क्रिय करता है?

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

एक ढांचे का एक उदाहरण जो इससे लाभान्वित होगा, वह लारवेल जैसा है। जहां मैं एक ऐसी छवि बनाता हूं, जो अन्य कॉन्फ़िगरेशन (वॉल्यूम, नेटवर्क शेयर, आदि) के साथ लारवेल छप पृष्ठ परोसने में सक्षम होगी, लेकिन कंपोज़ फ़ाइल को होस्ट से कंटेनर के लारवेल रूट पर फ़ाइलों को कॉपी करने के लिए लिखा जाता है ताकि वे हो सकें ओवरराइट।

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

संपादित करें:

परीक्षण के बाद, ऐसा लगता है कि जब आप एक वॉल्यूम माउंट करते हैं, तो उस स्थान पर छवि में मौजूद फ़ाइलों को वॉल्यूम की मूल सामग्री के लिए प्राथमिकता के साथ लगातार वॉल्यूम पर कॉपी किया जाता है। मतलब यह ओवरराइट नहीं है।

मुझे वास्तव में लगता है कि यह वांछित परिणाम के लिए एक समाधान है।

Payden-Pringle 13 जुल॰ 2018

👍3

अरे, दोस्तों, सिर्फ FYI करें, इस मुद्दे पर शीर्ष संदेश पर एक थंब-अप प्रतिक्रिया देना बेहतर है "ऐड" टिप्पणी की तुलना में, क्योंकि मुद्दों को कितने प्रतिक्रियाएं मिली हैं।

su-narthur 9 अग॰ 2018

👍15

+1

sentinel09 17 अक्तू॰ 2018

😕2 👎2

+1 कृपया डॉकटर टीम, अपने समुदाय पर विचार करें।

flavienbwk 5 मार्च 2019

👍4 👎2

@ पिंडली - अभी समस्या यह है कि वॉल्यूम विशेषता एक बाहरी वॉल्यूम से एक कंटेनर में एक एकल फ़ाइल में प्लग करना असंभव बना देती है।

मान लीजिए कि मैं उस फ़ोल्डर में बाकी सब कुछ मिटाए बिना /etc/something/whatever.conf में एक nginx config फ़ाइल प्लग करना चाहता हूं। आप किसी एकल फ़ाइल के लिए एक नामांकित वॉल्यूम नहीं बना सकते हैं (# 30310 को moby / moby देखें), और आप एक एकल फ़ाइल वाली निर्देशिका वॉल्यूम भी नहीं बना सकते हैं, फिर उस विशेष फ़ाइल को कंटेनर में माउंट करें (देखें moby / moby # 32,582)।

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

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

masaeedu 12 मार्च 2019

👍4

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

shin- 12 मार्च 2019

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

masaeedu 12 मार्च 2019

👍2

मैं @masaeedu के साथ

ए) प्रश्न में कंटेनरों को खड़ा करने के लिए किसी तरह की गूढ़ लिपि के काम को एक साथ करने के लिए एक साथ काम करने के लिए (बहुत ही महत्वपूर्ण बात यह थी कि इसे मानकीकृत करने और हमें करने से रोकने के लिए)

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

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

WebMatrixware 12 मार्च 2019

👍13

Compose: Yaml कॉन्फ़िगरेशन में `copy` जोड़ें

सबसे उपयोगी टिप्पणी

सभी 146 टिप्पणियाँ

>

संबंधित मुद्दों