वितरण साधनांची उत्क्रांती किंवा डॉकर, डेब, जार आणि बरेच काही याबद्दलचे विचार

कसे तरी एका क्षणी मी डॉकर कंटेनर आणि डेब पॅकेजेसच्या स्वरूपात वितरणाबद्दल एक लेख लिहिण्याचा निर्णय घेतला, परंतु जेव्हा मी प्रारंभ केला, तेव्हा काही कारणास्तव मला पहिल्या वैयक्तिक संगणक आणि अगदी कॅल्क्युलेटरच्या दूरच्या काळात परत नेले गेले. सर्वसाधारणपणे, डॉकर आणि डेबच्या कोरड्या तुलनेऐवजी, आम्हाला उत्क्रांती विषयावर हे विचार मिळाले, जे मी तुमच्या विचारार्थ सादर करतो.

कोणतेही उत्पादन, मग ते कोणतेही असो, ते कोणत्याही प्रकारे उत्पादन सर्व्हरवर पोहोचले पाहिजे, कॉन्फिगर केलेले आणि लॉन्च केले पाहिजे. हा लेख त्याबद्दलच असेल.

मी एका ऐतिहासिक संदर्भात विचार करेन, "मी जे पाहतो तेच मी गातो," मी पहिल्यांदा संहिता लिहायला सुरुवात केली तेव्हा मी काय पाहिले आणि आता मी काय निरीक्षण करतो, या क्षणी आपण स्वतः काय आणि का वापरत आहोत. लेख पूर्ण अभ्यासाचे ढोंग करत नाही, काही मुद्दे चुकले आहेत, काय होते आणि आता काय आहे हे माझे वैयक्तिक मत आहे.

तर, जुन्या काळात... मला आढळलेली डिलिव्हरीची सर्वात जुनी पद्धत म्हणजे टेप रेकॉर्डरच्या कॅसेट टेप्स. माझ्याकडे BK-0010.01 संगणक होता...

कॅल्क्युलेटरचे युग

नाही, अगदी पूर्वीचा क्षण होता, कॅल्क्युलेटर देखील होता MK-61 и MK-52.

तेव्हा मी होते MK-61, नंतर प्रोग्राम हस्तांतरित करण्याचा मार्ग म्हणजे बॉक्समधील कागदाचा एक सामान्य तुकडा ज्यावर एक प्रोग्राम लिहिलेला होता, जो आवश्यक असल्यास, तो स्वहस्ते चालविण्यासाठी, कॅल्क्युलेटरमध्ये लिहिलेला होता. जर तुम्हाला खेळायचे असेल (होय, या अँटेडिलुव्हियन कॅल्क्युलेटरमध्ये देखील गेम होते) - तुम्ही खाली बसा आणि कॅल्क्युलेटरमध्ये प्रोग्राम प्रविष्ट करा. साहजिकच, कॅल्क्युलेटर बंद केल्यावर, कार्यक्रम विस्मृतीत नाहीसा झाला. कागदावर वैयक्तिकरित्या लिहिलेल्या कॅल्क्युलेटर कोड व्यतिरिक्त, कार्यक्रम "रेडिओ" आणि "युवकांसाठी तंत्रज्ञान" मासिकांमध्ये प्रकाशित केले गेले आणि त्या काळातील पुस्तकांमध्ये देखील प्रकाशित झाले.

पुढील बदल कॅल्क्युलेटर होता MK-52, यात आधीपासून गैर-अस्थिर डेटा संचयनाचे काही स्वरूप आहे. आता गेम किंवा प्रोग्राम मॅन्युअली एंटर करावा लागत नव्हता, परंतु बटणांसह काही जादुई पास केल्यानंतर, तो स्वतःच लोड झाला.

कॅल्क्युलेटरमधील सर्वात मोठ्या प्रोग्रामचा आकार 105 चरणांचा होता आणि MK-52 मधील स्थायी मेमरीचा आकार 512 चरणांचा होता.

तसे, जर या कॅल्क्युलेटरचे चाहते असतील जे हा लेख वाचत असतील, तर लेख लिहिण्याच्या प्रक्रियेत मला Android साठी कॅल्क्युलेटर एमुलेटर आणि त्यासाठीचे प्रोग्राम दोन्ही सापडले. भूतकाळात पुढे!

• Android साठी इम्युलेटर MK-61
• MK-61 साठी प्रोग्राम कॅटलॉग

MK-52 बद्दल एक लहान विषयांतर (विकिपीडियावरून)

MK-52 ने Soyuz TM-7 अंतराळयानातून अवकाशात उड्डाण केले. ऑन-बोर्ड कॉम्प्युटर अयशस्वी झाल्यास लँडिंग ट्रॅजेक्टोरीची गणना करण्यासाठी याचा वापर केला जाणार होता.

52 पासून, Electronika-Astro स्मृती विस्तार युनिटसह MK-1988 नेव्हीगेशनल कॉम्प्युटिंग किटचा भाग म्हणून नौदलाच्या जहाजांना पुरवले गेले आहे.

पहिले वैयक्तिक संगणक

चला काळाकडे परत जाऊया BC-0010. हे स्पष्ट आहे की तेथे अधिक मेमरी होती आणि कागदाच्या तुकड्यातून कोड टाइप करणे यापुढे पर्याय नव्हता (जरी सुरुवातीला मी तेच केले, कारण दुसरे कोणतेही माध्यम नव्हते). टेप रेकॉर्डरसाठी ऑडिओ कॅसेट हे सॉफ्टवेअर साठवण्याचे आणि वितरित करण्याचे मुख्य माध्यम बनत आहेत.

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

विश्वसनीय आणि मोठ्या स्टोरेज मीडियाचा उदय

नंतर, फ्लॉपी डिस्क दिसू लागल्या, कॉपी करण्याची प्रक्रिया सरलीकृत केली गेली आणि विश्वासार्हता वाढली.
परंतु जेव्हा पुरेसे मोठे स्थानिक स्टोरेज HDD च्या स्वरूपात दिसतात तेव्हाच परिस्थिती नाटकीयरित्या बदलते.

वितरणाचा प्रकार मूलभूतपणे बदलत आहे: इंस्टॉलर प्रोग्राम दिसतात जे सिस्टम कॉन्फिगर करण्याची प्रक्रिया व्यवस्थापित करतात, तसेच काढून टाकल्यानंतर साफ करतात, कारण प्रोग्राम्स केवळ मेमरीमध्ये वाचले जात नाहीत, परंतु आधीपासूनच स्थानिक स्टोरेजमध्ये कॉपी केले जातात, ज्यामधून आपल्याला आवश्यक असल्यास अनावश्यक गोष्टी साफ करण्यास सक्षम व्हा.

त्याच वेळी, पुरवलेल्या सॉफ्टवेअरची जटिलता वाढत आहे.
वितरणातील फायलींची संख्या काही ते शेकडो आणि हजारोपर्यंत वाढते, जेव्हा भिन्न प्रोग्राम समान डेटा वापरतात तेव्हा लायब्ररी आवृत्त्या आणि इतर आनंदांमधील संघर्ष सुरू होतो.

त्या वेळी, लिनक्सचे अस्तित्व माझ्यासाठी अद्याप खुले नव्हते; मी एमएस डॉस आणि नंतर विंडोजच्या जगात राहत होतो आणि बोरलँड पास्कल आणि डेल्फीमध्ये लिहिले होते, कधीकधी C++ कडे पहात होतो. अनेक लोकांनी तेव्हा उत्पादने वितरीत करण्यासाठी InstallShield वापरले. ru.wikipedia.org/wiki/InstallShield, ज्याने सॉफ्टवेअर उपयोजित आणि कॉन्फिगर करण्याच्या सर्व नियुक्त कार्यांचे यशस्वीरित्या निराकरण केले.

इंटरनेट युग

हळूहळू, सॉफ्टवेअर सिस्टमची जटिलता अधिक जटिल होत आहे; मोनोलिथ आणि डेस्कटॉप ऍप्लिकेशन्समधून वितरित सिस्टम, पातळ क्लायंट आणि मायक्रोसर्व्हिसेसमध्ये संक्रमण होते. आता तुम्हाला फक्त एक प्रोग्रामच नव्हे तर त्यांचा एक संच कॉन्फिगर करणे आवश्यक आहे आणि जेणेकरून ते सर्व एकत्र कार्य करतील.

संकल्पना पूर्णपणे बदलली, इंटरनेट आले, क्लाउड सेवांचे युग आले. आतापर्यंत, केवळ प्रारंभिक टप्प्यात, वेबसाइट्सच्या स्वरूपात, कोणीही विशेषतः सेवांचे स्वप्न पाहिले नाही. परंतु अनुप्रयोगांचा विकास आणि वितरण या दोन्ही बाबतीत हा एक टर्निंग पॉइंट होता.

माझ्यासाठी, मी लक्षात घेतले की त्या क्षणी विकासकांच्या पिढ्यांमध्ये बदल झाला होता (किंवा ते फक्त माझ्या वातावरणात होते), आणि अशी भावना होती की एका क्षणी सर्व चांगल्या जुन्या वितरण पद्धती विसरल्या गेल्या आणि सर्वकाही अगदी सुरुवातीपासूनच सुरू झाले. सुरुवात: सर्व डिलिव्हरी गुडघ्याच्या स्क्रिप्ट्समध्ये केली जाऊ लागली आणि अभिमानाने त्याला “कंटिन्युअस डिलिव्हरी” म्हणत. खरं तर, अराजकतेचा काळ सुरू झाला आहे, जेव्हा जुने विसरले जाते आणि वापरले जात नाही आणि नवीन अस्तित्वात नाही.

मला आठवते जेव्हा आमच्या कंपनीत मी तेव्हा काम केले होते (मी नाव देणार नाही), मुंग्याद्वारे बांधण्याऐवजी (मावेन अद्याप लोकप्रिय नव्हते किंवा अजिबात अस्तित्वात नव्हते), लोकांनी फक्त IDE मध्ये जार गोळा केले आणि शांतपणे वचनबद्ध केले. ते SVN मध्ये. त्यानुसार, तैनातीमध्ये SVN वरून फाइल पुनर्प्राप्त करणे आणि SSH द्वारे इच्छित मशीनवर कॉपी करणे समाविष्ट होते. हे खूप सोपे आणि अनाड़ी आहे.

त्याच वेळी, PHP मध्ये साध्या साइट्सची डिलिव्हरी अगदी प्राथमिक पद्धतीने FTP द्वारे लक्ष्य मशीनवर दुरुस्त केलेली फाइल कॉपी करून केली गेली. काहीवेळा असे नव्हते - कोड उत्पादन सर्व्हरवर थेट संपादित केला गेला होता आणि कुठेतरी बॅकअप असल्यास ते विशेषतः आकर्षक होते.

RPM आणि DEB पॅकेजेस

दुसरीकडे, इंटरनेटच्या विकासासह, UNIX सारखी प्रणाली अधिकाधिक लोकप्रियता मिळवू लागली, विशेषतः, त्यावेळी मला रेडहॅट लिनक्स 6, अंदाजे 2000 चा शोध लागला. साहजिकच, सॉफ्टवेअर वितरीत करण्यासाठी काही माध्यमे देखील होती; विकिपीडियानुसार, मुख्य पॅकेज व्यवस्थापक म्हणून RPM आधीच 1995 मध्ये, RedHat Linux 2.0 च्या आवृत्तीमध्ये दिसून आले. आणि तेव्हापासून आणि आजपर्यंत, ही प्रणाली RPM पॅकेजेसच्या स्वरूपात वितरित केली गेली आहे आणि बर्‍यापैकी यशस्वीरित्या अस्तित्वात आहे आणि विकसित होत आहे.

डेबियन कुटुंबाच्या वितरणाने समान मार्गाचा अवलंब केला आणि डेब पॅकेजच्या स्वरूपात वितरण लागू केले, जे आजपर्यंत अपरिवर्तित राहिले आहे.

पॅकेज मॅनेजर तुम्हाला सॉफ्टवेअर उत्पादने स्वतः वितरीत करण्यास, इन्स्टॉलेशन प्रक्रियेदरम्यान कॉन्फिगर करण्याची, वेगवेगळ्या पॅकेजेसमधील अवलंबित्व व्यवस्थापित करण्याची, उत्पादने काढून टाकण्याची आणि विस्थापन प्रक्रियेदरम्यान अनावश्यक वस्तू साफ करण्याची परवानगी देतात. त्या. बर्‍याच भागासाठी, इतकेच आवश्यक आहे, म्हणूनच ते अक्षरशः अपरिवर्तित अनेक दशके टिकले.

क्लाउड कंप्युटिंगने पॅकेज मॅनेजर्सना केवळ भौतिक माध्यमांतूनच नव्हे, तर क्लाउड रिपॉझिटरीजमधूनही इन्स्टॉलेशन जोडले आहे, परंतु मूलभूतपणे थोडे बदल झाले आहेत.

हे लक्षात घेण्यासारखे आहे की सध्या डेबपासून दूर जाण्याच्या आणि स्नॅप पॅकेजेसवर स्विच करण्याच्या दिशेने काही हालचाली आहेत, परंतु नंतर त्याबद्दल अधिक.

त्यामुळे, क्लाउड डेव्हलपर्सची ही नवीन पिढी, ज्यांना DEB किंवा RPM दोन्हीही माहीत नव्हते, त्यांनीही हळूहळू वाढ केली, अनुभव मिळवला, उत्पादने अधिक गुंतागुंतीची झाली आणि FTP, बॅश स्क्रिप्ट्स आणि तत्सम विद्यार्थी हस्तकलेपेक्षा काही अधिक वाजवी वितरण पद्धती आवश्यक होत्या.
आणि इथेच डॉकर चित्रात येतो, व्हर्च्युअलायझेशन, संसाधन सीमांकन आणि वितरण पद्धतीचे मिश्रण. हे आता फॅशनेबल आणि तरुण आहे, परंतु प्रत्येक गोष्टीसाठी ते आवश्यक आहे का? हा रामबाण उपाय आहे का?

माझ्या निरिक्षणांवरून, डॉकरला बर्‍याचदा वाजवी निवड म्हणून प्रस्तावित केले जात नाही, परंतु फक्त कारण, एकीकडे, समाजात याबद्दल चर्चा केली जाते आणि ज्यांनी ते प्रस्तावित केले त्यांनाच ते माहित आहे. दुसरीकडे, बर्याच भागांसाठी ते चांगल्या जुन्या पॅकेजिंग सिस्टमबद्दल मूक आहेत - ते अस्तित्वात आहेत आणि शांतपणे आणि लक्ष न देता त्यांचे कार्य करतात. अशा परिस्थितीत, खरोखर दुसरा पर्याय नाही - निवड स्पष्ट आहे - डॉकर.

आम्ही डॉकरची अंमलबजावणी कशी केली आणि परिणामी काय घडले याचा माझा अनुभव सांगण्याचा मी प्रयत्न करेन.

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

सुरुवातीला, बॅश स्क्रिप्ट होत्या ज्या आवश्यक मशीनवर जार संग्रहण तैनात करतात. ही प्रक्रिया जेनकिन्सने व्यवस्थापित केली होती. हे यशस्वीरित्या कार्य केले, कारण जार संग्रहण स्वतःच वर्ग, संसाधने आणि अगदी कॉन्फिगरेशन असलेली असेंब्ली आहे. जर तुम्ही त्यात सर्वकाही जास्तीत जास्त ठेवले तर ते स्क्रिप्टमध्ये विस्तारित करणे तुम्हाला आवश्यक असलेली सर्वात कठीण गोष्ट नाही

परंतु स्क्रिप्टचे अनेक तोटे आहेत:

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

नक्कीच, आपण एक अत्याधुनिक स्क्रिप्ट लिहू शकता, परंतु, मी वर लिहिल्याप्रमाणे, ही विकासाची वेळ आहे, आणि कमीत कमी नाही, आणि आपल्याला माहित आहे की, नेहमीच पुरेसा वेळ नसतो.

हे सर्व स्पष्टपणे या उपयोजन पद्धतीच्या अनुप्रयोगाची श्रेणी फक्त सोप्या प्रणालींपर्यंत मर्यादित करते. हे बदलण्याची वेळ आली आहे.

गोदी कामगार

काही क्षणी, ताज्या मिडल्स आमच्याकडे येऊ लागल्या, कल्पनांनी चिडून आणि डॉकरबद्दल बडबड करत. बरं, हातात ध्वज - चला करूया! दोन प्रयत्न झाले. दोघेही अयशस्वी ठरले - समजूया, मोठ्या महत्त्वाकांक्षेमुळे, परंतु वास्तविक अनुभवाच्या अभावामुळे. सक्ती करणे आणि कोणत्याही प्रकारे ते पूर्ण करणे आवश्यक होते का? हे संभवनीय नाही - योग्य साधने वापरण्यापूर्वी संघाने आवश्यक स्तरावर उत्क्रांत होणे आवश्यक आहे. याव्यतिरिक्त, रेडीमेड डॉकर प्रतिमा वापरताना, आम्हाला अनेकदा असे आढळले की नेटवर्क योग्यरित्या कार्य करत नाही (जे डॉकरच्या ओलसरपणामुळे झाले असावे) किंवा इतर लोकांच्या कंटेनरचा विस्तार करणे कठीण होते.

आम्हाला कोणत्या गैरसोयींचा सामना करावा लागला?

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

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

सराव दर्शविल्याप्रमाणे, प्रत्यक्षात हे आवश्यक नाही, डेब पॅकेज 90% प्रकरणांमध्ये पुरेसे आहे.

चांगला जुना डेब कधी अयशस्वी होतो आणि आम्हाला खरोखर डॉकरची कधी गरज आहे?

आमच्यासाठी, हे पायथनमध्ये सेवा तैनात करत होते. मशीन लर्निंगसाठी बरीच लायब्ररी आवश्यक आहे आणि ऑपरेटिंग सिस्टमच्या मानक वितरणामध्ये समाविष्ट नाही (आणि तेथे काय चुकीच्या आवृत्त्या होत्या), सेटिंग्जसह हॅक, एकाच होस्ट सिस्टमवर राहणाऱ्या वेगवेगळ्या सेवांसाठी वेगवेगळ्या आवृत्त्यांची आवश्यकता यामुळे हे, की हे परमाणु मिश्रण वितरित करण्याचा एकमेव वाजवी मार्ग डॉकर होता. डॉकर कंटेनर एकत्र करण्याची श्रम तीव्रता हे सर्व अवलंबित्वांसह स्वतंत्र डेब पॅकेजेसमध्ये पॅक करण्याच्या कल्पनेपेक्षा कमी असल्याचे दिसून आले आणि खरं तर त्यांच्या योग्य मनातील कोणीही हे हाती घेणार नाही.

दुसरा मुद्दा जिथे आम्ही डॉकर वापरण्याची योजना आखतो तो म्हणजे निळ्या-हिरव्या उपयोजन योजनेचा वापर करून सेवा तैनात करणे. परंतु येथे मला जटिलतेत हळूहळू वाढ करायची आहे: प्रथम, डेब पॅकेजेस तयार केले जातात आणि नंतर त्यांच्याकडून डॉकर कंटेनर तयार केला जातो.

स्नॅप पॅकेजेस

स्नॅप पॅकेजेसकडे परत जाऊया. ते प्रथम अधिकृतपणे उबंटू 16.04 मध्ये दिसले. नेहमीच्या deb पॅकेजेस आणि rpm पॅकेजेसच्या विपरीत, snap मध्ये सर्व अवलंबित्वे असतात. एकीकडे, हे आपल्याला लायब्ररी संघर्ष टाळण्यास अनुमती देते, दुसरीकडे, परिणामी पॅकेज आकाराने मोठे आहे. याव्यतिरिक्त, हे सिस्टमच्या सुरक्षिततेवर देखील परिणाम करू शकते: स्नॅप वितरणाच्या बाबतीत, समाविष्ट केलेल्या लायब्ररीतील सर्व बदलांचे पॅकेज तयार करणार्‍या विकसकाद्वारे परीक्षण करणे आवश्यक आहे. सर्वसाधारणपणे, सर्वकाही इतके सोपे नसते आणि सार्वत्रिक आनंद त्यांचा वापर करून मिळत नाही. परंतु, तरीही, हा एक पूर्णपणे वाजवी पर्याय आहे जर तोच डॉकर केवळ पॅकेजिंग साधन म्हणून वापरला गेला आणि आभासीकरणासाठी नाही.

परिणामी, आम्ही आता deb पॅकेजेस आणि डॉकर कंटेनर दोन्ही वाजवी संयोजनात वापरतो, जे कदाचित, काही प्रकरणांमध्ये आम्ही स्नॅप पॅकेजसह बदलू.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

डिलिव्हरीसाठी तुम्ही काय वापरता?

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

• FTP वर व्यक्तिचलितपणे कॉपी करा

• deb पॅकेजेस

• rpm पॅकेजेस

• स्नॅप पॅकेजेस

• डॉकर-प्रतिमा

• आभासी मशीन प्रतिमा

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

• कठपुतळी

• उत्तरदायी

• इतर

109 वापरकर्त्यांनी मतदान केले. 32 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com