Docker Run से Compose

अनुवाद पूरी तरह यांत्रिक क्यों नहीं है

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

सबसे स्पष्ट उदाहरण detach है। -d लिखने से डेमन को आपका टर्मिनल पकड़े रखने से रोकने के लिए कहा जाता है, जो उस आह्वान की एक विशेषता है, सेवा की नहीं। Compose में इसी इरादे को कमांड लाइन पर docker compose up -d के साथ व्यक्त किया जाता है, इसलिए फ्लैग बस फाइल से गायब हो जाता है। --rm पर भी यही लागू होता है, जो इस विशेष रन के बाद सफाई का अनुरोध करता है; Compose समकक्ष यह है कि जब आप समाप्त कर लें तो docker compose down चलाना।

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

कोटिंग वह जगह है जहाँ रूपांतरण टूटते हैं

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

कनवर्टर इनपुट को वैसे ही टोकनाइज़ करता है जैसे एक शेल करेगा, सिंगल कोट्स, डबल कोट्स, बैकस्लैश एस्केप्स और बैकस्लैश-न्यूलाइन कंटीन्यूएशन्स का सम्मान करता है, ताकि किसी स्क्रिप्ट से सीधे कॉपी किया गया कमांड अपनी संरचना बनाए रखे। यह फिर आउटपुट पर मानों को YAML नियमों के अनुसार फिर से कोट करता है, जो लोगों की अपेक्षा से अधिक मायने रखता है। 8080:80 जैसा पोर्ट मैपिंग YAML में उद्धृत होना चाहिए, क्योंकि बिना उद्धरण के कोलन-सेपरेटेड जोड़ी अस्पष्ट होती है और पुराने पार्सर्स ने ऐतिहासिक रूप से 22:00 जैसे मानों को सैक्सागेसिमल संख्या के रूप में पढ़ा है।

नेटवर्क्स, और वह जो फाइल नहीं जान सकती

नेटवर्क हैंडलिंग वह एक जगह है जहाँ एक वफादार रूपांतरण को फिर भी आपसे एक निर्णय की आवश्यकता होती है। यदि कमांड host, none या bridge में शामिल होता है, तो वह एक मोड है और network_mode बन जाता है। कोई अन्य नाम उस नेटवर्क को संदर्भित करता है जो पहले से मौजूद है, इसलिए सेवा को एक networks एंट्री मिलती है और फाइल उस नेटवर्क को external के रूप में घोषित करती है।

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

बाइंड माउंट्स पर भी वही सावधानी लागू होती है। /srv/site जैसा पथ उस मशीन पर काम करता है जहाँ कमांड लिखा गया था और कहीं और नहीं। एक बार जब सेवा एक फाइल में रहती है जो कमिट और साझा की जाती है, तो सापेक्ष पथ या नामित वॉल्यूम आमतौर पर बेहतर विकल्प होते हैं।