आपूर्ति श्रृंखला का विकास, या डॉकर, डिब, जार और अधिक पर प्रतिबिंब

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

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

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

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

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

नहीं, पहले भी एक बिंदु था, एक एमके -61 और एमके -52 कैलकुलेटर भी था।

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

इंटरनेट का जमाना

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

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

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

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

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

RPM और DEB पैकेज

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अच्छी पुरानी बहस अभी भी विफल है और हमें वास्तव में कब क्या करना चाहिए?

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

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

स्नैप पैकेज

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


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