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

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

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

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

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

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

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

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

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

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

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

• एंड्रॉइड के लिए एम्यूलेटर एमके-61
• एमके-61 के लिए कार्यक्रम सूची

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

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

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

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

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

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

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

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

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

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

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

इंटरनेट युग

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

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

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

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

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

आरपीएम और डीईबी पैकेज

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

डेबियन परिवार के वितरण ने एक समान मार्ग का अनुसरण किया और डिबेट पैकेज के रूप में डिलीवरी लागू की, जो आज तक अपरिवर्तित बनी हुई है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्नैप पैकेज

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

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

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

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

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

• एफ़टीपी पर मैन्युअल रूप से कॉपी करें

• डिबेट पैकेज

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

• स्नैप पैकेज

• डॉकर-छवियां

• वर्चुअल मशीन छवियाँ

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

• कठपुतली

• ansible

• अन्य

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

स्रोत: www.habr.com