क्या मुझे डॉकफाइल्स या इमेज कमिट का उपयोग करना चाहिए?


81

मैं इन दो विकल्पों के बारे में थोड़ा भ्रमित हूं। वे संबंधित प्रतीत होते हैं। हालांकि, वे वास्तव में संगत नहीं हैं।

उदाहरण के लिए, ऐसा लगता है कि Dockerfiles का उपयोग करने का अर्थ है कि आपको वास्तव में छवियों के लिए प्रतिबद्ध नहीं होना चाहिए, क्योंकि आपको वास्तव में Git में Dockerfile को ट्रैक करना चाहिए और उस पर परिवर्तन करना चाहिए। फिर आधिकारिक क्या है के बारे में कोई अस्पष्टता नहीं है।

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

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

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

अपडेट :

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

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

अपडेट - 2017/7/18 :

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


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

@CharlesDuffy अगर यह SO पर नहीं है तो यह सवाल कहां जाना चाहिए?
डेविड सैंडर्स

1
@CharlesDuffy वैसे, मैं इस बात से सहमत नहीं हूं कि यह एक राय आधारित प्रश्न है। यहां एक सही उत्तर होना चाहिए, यदि एक सही उत्तर नहीं है जो थोड़ा और संदर्भ पर निर्भर करता है। FYI करें, मैंने अपना प्रश्न Serverfault में स्थानांतरित करने के लिए किया था।
डेविड सैंडर्स

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

1
मैं एक ही बात सोच रहा हूँ, और मेरी धारणा (जो पूरी तरह से गलत हो सकती है) यह है कि यह वास्तव में vms के साथ एक ही मामला है -> आप नहीं चाहते कि vm छवि को कैसे बनाया जाए। मेरे मामले में मेरे पास नियमित रूप से .sh स्क्रिप्ट्स हैं, और मैं सोच रहा हूं कि मैं इन्हें बनाए क्यों नहीं रख सकता, डॉक चलाने वाला और इन्हें प्रभावी रूप से कॉल करने का और इस तरह से गोल्डन वर्जन इमेज बनाने का। मेरी स्क्रिप्ट इसे एक स्थानीय पीसी पर स्थापित करने के लिए काम करती है, और इसका कारण मैं डॉकटर का उपयोग करना चाहता हूं, कार्यक्रमों के कई उदाहरणों के टकराव से निपटने के लिए / स्वच्छ फ़ाइल सिस्टम / आदि है
ब्रैडफोर्ड मेडेरोस

जवाबों:


47

Dockerfiles एक उपकरण है जो छवियों को बनाने के लिए उपयोग किया जाता है।

रनिंग docker build .का नतीजा एक कमिट के साथ एक इमेज है, इसलिए डॉकरीफाइल का इस्तेमाल कमिटमेंट बनाने के साथ करना संभव नहीं है । सवाल यह है कि क्या आपको हर बार कुछ भी बदलाव करने के लिए छवि को अपडेट करना चाहिए और इस तरह अपने आप को सुनहरी छवि के अभिशाप के लिए करना चाहिए ?

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


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

7
मैंने अभी उस उदाहरण को नहीं बनाया है ... :-(
आर्थर उल्फेल्ट

22

समाधान के फायदे और असुविधाजनक दोनों को जानना एक अच्छी शुरुआत है। क्योंकि दोनों का मिश्रण संभवतः जाने का एक वैध तरीका है।

Con: गोल्डन इमेज डेड एंड से बचें :

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

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

प्रो: वितरित करने के लिए चालाक उन्नयन

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

दो दुनियाओं में से सर्वश्रेष्ठ पाने की कोशिश करें:

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

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


क्या Docker ने समझदारी से ऐसी छवियों का पुनर्निर्माण नहीं किया है, जिन्हें आप संशोधित Dockerfile से पुनर्निर्माण करने के बाद, एक पूरी नई छवि को खींचने की आवश्यकता नहीं है?
डेविड सैंडर्स

1
@DavidSanders आप पूरी नई छवियां डाउनलोड करके समाप्त नहीं होंगे, आप इस बारे में सही हैं। लेकिन कोई भी प्रारंभिक निर्देश जो परिणामों को बदलता है, पूरी निम्नलिखित परतों को अमान्य कर देगा। कुख्यात रूप से, 'ADD' या कोई भी निर्भरता निर्देश अक्सर निर्देश होते हैं, जो आप अंत में एक नई प्रतिबद्धता के साथ कर सकते हैं, लेकिन यदि आप अपने Dockerfile का पुनर्निर्माण करते हैं, तो यह पूरी नई परतें उत्पन्न करेगा। 'ADD' के आसपास कुछ प्रयास किए गए हैं ताकि अधिक चतुर github.com/docker/docker/issues/880 हो , यह भी देखें, इसी तरह की चिंताओं के बाद jpetazzo.github.io/2013/12/01/docker-python-pip-requirements
vabab
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.