डिलीवरी टूल का विकास, या डॉकर, डेब, जार और बहुत कुछ पर विचार

एक समय पर मैंने डॉकर कंटेनरों और डेब पैकेजों के रूप में डिलीवरी के बारे में एक लेख लिखने का फैसला किया, लेकिन जब मैंने शुरुआत की, तो किसी कारण से मैं पहले व्यक्तिगत कंप्यूटरों और यहां तक ​​कि कैलकुलेटर के दूर के समय में चला गया। सामान्य तौर पर, डॉकर और डेब की सूखी तुलना के बजाय, मुझे विकास के विषय पर ये विचार मिले, जिन्हें मैं आपके निर्णय के लिए प्रस्तुत करता हूं।

किसी भी उत्पाद को, चाहे वह कोई भी हो, किसी न किसी तरह उत्पाद सर्वर तक पहुंचना ही होगा, कॉन्फ़िगर होना होगा और लॉन्च होना होगा। यह लेख इसी विषय पर होगा।

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

तो, पुराने अच्छे दिनों में... मुझे याद है कि वितरण की सबसे प्रारंभिक विधि टेप रिकार्डर से टेप भेजना था। मेरे पास एक कंप्यूटर था BK-0010.01...

कैलकुलेटर का युग

नहीं, इससे भी पहले एक क्षण था, एक कैलकुलेटर भी था MK-61 и MK-52.

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

अगला संशोधन एक कैलकुलेटर था MK-52इसमें पहले से ही गैर-वाष्पशील डेटा भंडारण की कुछ झलक मौजूद है। अब किसी गेम या प्रोग्राम को मैन्युअल रूप से दर्ज करना आवश्यक नहीं था, बल्कि बटनों के साथ कुछ जादुई पास करने के बाद, यह स्वयं लोड हो जाता था।

कैलकुलेटर में सबसे बड़े प्रोग्राम का आकार 105 स्टेप्स का था, और एमके-52 में स्थायी मेमोरी का आकार 512 स्टेप्स का था।

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

• MK-61 एमुलेटर के लिए Android
• एमके-61 के लिए कार्यक्रमों की सूची

एमके-52 के बारे में एक छोटा सा विषयांतर (विकिपीडिया से)

एमके-52 सोयूज टीएम-7 अंतरिक्ष यान से अंतरिक्ष में उड़ा। इसका उद्देश्य ऑन-बोर्ड कंप्यूटर के खराब हो जाने की स्थिति में लैंडिंग पथ की गणना करने के लिए इसका उपयोग करना था।

52 से, इलेक्ट्रोनिका-एस्ट्रो मेमोरी विस्तार इकाई के साथ एमके-1988 को नेविगेशनल कंप्यूटिंग किट के भाग के रूप में नौसेना के जहाजों को आपूर्ति की जाती रही है।

पहला पर्सनल कंप्यूटर

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

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

विश्वसनीय और बड़े भंडारण मीडिया का उदय

बाद में फ्लॉपी डिस्क आने लगीं, नकल प्रक्रिया सरल हो गई और विश्वसनीयता बढ़ गई।
लेकिन स्थिति में आमूलचूल परिवर्तन तभी आता है जब HDD के रूप में पर्याप्त रूप से बड़े स्थानीय भण्डारण उपलब्ध हो जाते हैं।

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

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

उस समय, अस्तित्व का रहस्य मेरे सामने प्रकट नहीं हुआ था। Linuxमैं एमएस डीओएस की दुनिया में रहता था और बाद में, Windowsऔर उन्होंने बोर्लैंड पास्कल और डेल्फी में लिखा, कभी-कभी सी++ में भी हाथ आजमाया। उस समय, कई लोग उत्पादों को डिलीवर करने के लिए InstallShield का उपयोग करते थे। ru.wikipedia.org/wiki/InstallShield, जिसने सॉफ्टवेयर की तैनाती और कॉन्फ़िगरेशन के सभी कार्यों को काफी सफलतापूर्वक हल किया।

इंटरनेट युग

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

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

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

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

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

RPM और DEB पैकेज

दूसरी ओर, इंटरनेट के विकास के साथ, यूनिक्स जैसी प्रणालियाँ तेजी से लोकप्रिय होने लगीं; विशेष रूप से, उसी समय मैंने रेडहैट के बारे में जाना। Linux 6, लगभग 2000 के आसपास। स्वाभाविक रूप से, वहाँ सॉफ़्टवेयर वितरित करने के कुछ साधन भी थे। विकिपीडिया के अनुसार, मुख्य पैकेज मैनेजर के रूप में आरपीएम 1995 में रेडहैट संस्करण में दिखाई दिया था। Linux 2.0. तब से, सिस्टम को आरपीएम पैकेज के रूप में वितरित किया जा रहा है और यह लगातार प्रगति कर रहा है।

परिवार का वितरण Debian उन्होंने भी इसी तरह का रास्ता अपनाया और डिलीवरी को डेब पैकेज के रूप में लागू किया, जो आज तक अपरिवर्तित है।

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

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

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

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

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

मैं अपना अनुभव साझा करने का प्रयास करूंगा कि हमने डॉकर को कैसे क्रियान्वित किया और परिणाम क्या रहे।

स्व-लिखित स्क्रिप्ट

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

लेकिन स्क्रिप्ट के कई नुकसान हैं:

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

बेशक, आप एक परिष्कृत स्क्रिप्ट लिख सकते हैं, लेकिन, जैसा कि मैंने ऊपर लिखा है, इसे विकसित करने में समय लगता है, और कम से कम नहीं, और, जैसा कि हम जानते हैं, इसके लिए कभी भी पर्याप्त समय नहीं होता है।

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

डाक में काम करनेवाला मज़दूर

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

हमें किन असुविधाओं का सामना करना पड़ा?

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

दूसरी ओर, एक ही डेब के माध्यम से जार आर्काइव के रूप में स्प्रिंग सेवा को तैनात करना बदतर क्यों है? क्या संसाधन पृथक्करण वास्तव में आवश्यक है? क्या सेवाओं को अत्यधिक सीमित कंटेनर में ठूंसकर ऑपरेटिंग सिस्टम के सुविधाजनक उपकरणों को खोना उचित है?

जैसा कि अभ्यास से पता चला है, वास्तव में यह आवश्यक नहीं है; डेब पैकेज 90% मामलों में पर्याप्त है।

अच्छा पुराना डेब कब विफल हो जाता है और हमें वास्तव में डॉकर की आवश्यकता कब होती है?

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

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

स्नैप पैकेज

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

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

आप डिलीवरी के लिए क्या उपयोग करते हैं?

• स्व-लिखित स्क्रिप्ट

• FTP पर मैन्युअल रूप से कॉपी करें

• डेब पैकेज

• आरपीएम पैकेज

• स्नैप पैकेज

• डॉकर छवियाँ

• ओब्राज़ी वर्चुअल मशीन

• संपूर्ण HDD को क्लोन करें

• कठपुतली

• ansible

• अन्य

109 उपयोगकर्ताओं ने मतदान किया। 32 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com