क्या मेरे उपयोग के मामले के लिए डॉकर सही है?


14

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

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

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

टीएल; डीआर: एक वितरित उपकरण के लिए डॉकर बनाम डेब पैकेज जो हमेशा उबंटू को चलाएंगे ताकि प्लेटफॉर्म स्वतंत्रता महत्वपूर्ण न हो।


3
आपके पहले सवाल के लिए बधाई, अच्छी तरह से लिखा गया है और एक व्यावहारिक लक्ष्य के साथ, एक उदाहरण :)
तेनसीबाई

जवाबों:


7

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

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


5

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

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

दूसरा, आपके अपग्रेड परिदृश्य के लिए, आप एक बार में एक मशीन पर कई संस्करण खींच सकते हैं। यदि आप docker pull myapp:2.0थोड़ी देर 1.0दौड़ते हैं, तो आप 2.0बहुत तेज़ी से स्वैप कर सकते हैं । एक पूर्ण ओएस उन्नयन करने की तुलना में बहुत तेजी से सामान्य रूप से ले जाएगा। यदि आप ऑर्केस्ट्रेटर का कई उदाहरणों के साथ ऑर्केस्ट्रेटर का उपयोग करते हैं, तो आप रोलिंग अपग्रेड भी कर सकते हैं जो सेवा को बाधित नहीं करता है।

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

मुख्य नकारात्मक पक्ष यह है कि आपको होस्ट ओएस और कुछ प्रकार के ऑर्केस्ट्रेशन की आवश्यकता है। उस के लिए बहुत सारे विकल्प हैं, लेकिन किसी एक का मूल्यांकन करने के लिए जितना काम करना है, उसे कम मत समझिए, इसे लागू करें और इसे बनाए रखें।


ओपी जो पूछ रहा था, उसका इस से कोई लेना-देना नहीं है।
एड्रियन

1
(ऑफ-टॉपिक टिप्पणी।) हैलो कार्ल, मैंने प्रोग्रामर्स / सॉफ्टवेयर-इंजीनियरिंग में आपके कई योगदानों का आनंद लिया, यह आपको यहां भी देखने के लिए एक खुशी है!
माइकल ले बारबियर ग्रुएनवाल्ड

1

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

Docker को अपनाने के साथ मेरा मुद्दा यह है कि मैं आपको सही सवाल पूछने के लिए नहीं सुनता और आप अपनी सबसे महत्वपूर्ण आवश्यकताओं को संबोधित किए बिना संभवतः अपने जीवन को अधिक जटिल बना सकते हैं।

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

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


1

जबकि कुछ छोटे अतिव्यापी क्षेत्र डॉकर और डेबियन पैकेजिंग सिस्टम अनिवार्य रूप से दो बहुत अलग समस्याओं का समाधान करते हैं :

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

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

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

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

हमारे पास इनमें से हजारों बॉक्स मैदान पर हैं। हम पैकेज की निर्भरता, प्रक्रिया पंजीकरण आदि का प्रबंधन करते हैं, सफलता के अलग-अलग डिग्री के साथ एक डिब पैकेज के माध्यम से।

इससे संबंधित हो सकता है। अपरिवर्तनीय सर्वर पैटर्न समस्या से "उन्नयन इतिहास" की धारणा को अनिवार्य रूप से नष्ट करके त्रुटियों के इस स्रोत को मिटा देता है।

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

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

अब आपके द्वारा वर्णित ठोस समस्या पर विचार करने के लिए, मान लें कि डॉकर के साथ अपरिवर्तनीय सर्वर पैटर्न को लागू करना वास्तव में आप क्या चाहते हैं। चूंकि डॉकर सिस्टम और डेबियन पैकेजिंग सिस्टम पारस्परिक रूप से अनन्य (cf. intro) के बजाय पूरक हैं, फिर भी हमें इस सवाल का समाधान करना होगा कि क्या आपको अपने सॉफ़्टवेयर के लिए डेबियन पैकेज तैयार करना चाहिए।

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


@ टेंसिबाई आप सही हैं, मैंने इस के अनुसार उत्तर को फिर से काम किया।
माइकल ले बारबियर ग्रुएनवाल्ड

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

1
@ तेंसिबाई फिर, एक बहुत ही मान्य बिंदु :)
माइकल ले बारबियर ग्रुएनवाल्ड

0

मुझे लगता है कि यह एक अच्छा विकल्प हो सकता है (आगे के परीक्षण आवश्यक हैं)

आप अपने द्वारा बनाए गए कंटेनर के सभी टैग / संस्करण के साथ एक URL प्रदान कर सकते हैं और ग्राहक उस URL को यह देखने के लिए पढ़ेंगे कि क्या कंटेनर का कोई नया संस्करण है या नहीं।

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

यहां तक ​​कि आप उपयोगकर्ताओं को यह चुनने की संभावना प्रदान कर सकते हैं कि वे किस संस्करण का उपयोग करना चाहते हैं (यदि आप उस संभावना को देना चाहते हैं)।

यह "" केवल एक पैकेज को अपग्रेड करें "" जैसा होगा, केवल कंटेनर के एक नए संस्करण को पुनः प्राप्त करने के बारे में बात करना, बहुत बेहतर है कि डेबियन पैकेज से निपटना;)


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

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

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

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

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

-1

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

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


3
यह वास्तव में जवाब नहीं देता है कि कैसे डॉकर .deb पैकेजों से बेहतर है।
एलेक्सडी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.