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

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

वीएम पर आवेदन तैनात करें

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

ऐसा क्यों किया गया?

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

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

इस सब में हमने क्या फायदे देखे?

1. सबसे पहले, यह काफी सरलता से काम करता है । हर कोई समझता है कि यह परिनियोजन योजना कैसे काम करती है, क्योंकि अधिकांश लोग कभी भी साधारण वर्चुअल सर्वर पर तैनात होते हैं।
2. यह काफी विश्वसनीय है , क्योंकि तैनाती प्रौद्योगिकी सरल है, हजारों कंपनियों द्वारा परीक्षण किया गया है। लाखों सर्वर उस तरह से तैनात हैं। कुछ तोड़ना मुश्किल है
3. और अंत में, हम परमाणु तैनाती प्राप्त कर सकते थे। पुराने संस्करण और नए के बीच स्विच करने के एक ध्यान देने योग्य चरण के बिना, उपयोगकर्ताओं को एक साथ होने वाली तैनाती।

लेकिन इसमें हमने कई कमियाँ भी देखीं:

1. उत्पादन वातावरण, विकास पर्यावरण के अलावा, अन्य वातावरण हैं। उदाहरण के लिए, क्यूए और प्रीप्रोडक्शन। उस समय, हमारे पास कई सर्वर और लगभग 60 सेवाएं थीं। इस कारण से, प्रत्येक सेवा के लिए आवश्यक था कि वह वर्चुअल मशीन के संस्करण को बनाए रखे जो उसके लिए प्रासंगिक था । इसके अलावा, यदि आप पुस्तकालयों को अद्यतन करना चाहते हैं या नई निर्भरताएं स्थापित करना चाहते हैं, तो आपको सभी वातावरणों में ऐसा करने की आवश्यकता है। यह उस समय को सिंक्रनाइज़ करने के लिए भी आवश्यक था जब आप उस समय के साथ अपने आवेदन के अगले नए संस्करण को तैनात करने जा रहे थे जब डेवप्स ने आवश्यक पर्यावरणीय सेटिंग बनाई थी। इस मामले में, ऐसी स्थिति में आना आसान है जहां हमारा पर्यावरण एक पंक्ति में सभी वातावरणों में एक साथ थोड़ा अलग होगा। उदाहरण के लिए, क्यूए वातावरण में पुस्तकालयों के कुछ संस्करण होंगे, और उत्पादन में - अन्य, जो समस्याओं को जन्म देगा।
2. आपके आवेदन की निर्भरता को अद्यतन करने में कठिनाई । यह आप पर नहीं, बल्कि दूसरी टीम पर निर्भर करता है। अर्थात्, devops कमांड से, जो सर्वर को सपोर्ट करता है। आपको उनके लिए एक उपयुक्त कार्य निर्धारित करना चाहिए और इस बात का विवरण देना होगा कि आप क्या करना चाहते हैं।
3. उस समय, हम बड़े बड़े मोनोलिथ को भी विभाजित करना चाहते थे जो हमारे पास अलग-अलग छोटी सेवाओं में थे, क्योंकि हम समझते थे कि उनमें से अधिक से अधिक होगा। उस समय, हमारे पास पहले से ही 100 से अधिक थे। प्रत्येक नई सेवा के लिए एक अलग नई वर्चुअल मशीन बनाना आवश्यक था, जिसकी सेवा और तैनाती भी आवश्यक है। इसके अलावा, आपको एक कार की आवश्यकता नहीं है, लेकिन कम से कम दो। इसके लिए, क्यूए वातावरण अभी भी जोड़ा जा रहा है। यह समस्याओं का कारण बनता है और आपके लिए नए सिस्टम को अधिक कठिन, महंगा और समय लेने वाला बनाता है और लॉन्च करता है ।

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

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

घुमंतू पर स्विच करें

घुमंतू एक HashiCorp उत्पाद है। वे अपने अन्य निर्णयों के लिए भी जाने जाते हैं:



कंसूल सेवा खोज का एक उपकरण है।

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

वैग्रंट आपको विशिष्ट कॉन्फ़िगरेशन फ़ाइलों के माध्यम से स्थानीय रूप से या क्लाउड में वर्चुअल मशीन तैनात करने की अनुमति देता है।

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

घुमंतू को अपनी प्रणाली को पूरी तरह से लागू करने में क्या लगता है?

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

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



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

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

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



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

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



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

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

जब आपके क्लस्टर में घुमंतू सेवा पहले से ही तैनात है, तो यह इस तरह दिखता है।



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

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

मानव संसाधनों के संदर्भ में संक्रमण की लागत क्या थी?

पूरी कंपनी को नोमैड के संक्रमण में लगभग 5-6 महीने लगे। हमने सेवा-कम स्विच किया, लेकिन काफी तेज गति से। प्रत्येक टीम को सेवाओं के लिए अपने स्वयं के कंटेनर बनाने थे।

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

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

घुमंतू को छोड़ने के कारण

खानाबदोश और डॉकटर के रूप में उपयोग करने के लिए स्विच करने से हमें क्या फायदे हुए?

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

लेकिन हमने कई कमियों का भी सामना किया:

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

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

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

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

कुबेरनेट्स जा रहे हैं

मैं कुबेरनेट्स की मूल अवधारणाओं के बारे में थोड़ी बात करूंगा और वे खानाबदोश से कैसे भिन्न होंगे।



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

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

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

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

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

एप्लिकेशन को विकसित करने वाले के दृष्टिकोण से सबसे अच्छी बात यह है कि आप इसे स्वयं प्रबंधित करने में सक्षम हैं। इनग्रेड कॉन्फिगरेशन सेट करके, आप ऐसे API पर आने वाले सभी ट्रैफ़िक को पंजीकृत कंटेनरों में भेज सकते हैं, उदाहरण के लिए, Go पर। लेकिन यह ट्रैफ़िक एक ही डोमेन पर आ रहा है, लेकिन एक अलग URL पर, PHP में लिखे कंटेनरों में भेजा जाना चाहिए, जहाँ बहुत सारे तर्क हैं, लेकिन वे बहुत तेज़ नहीं हैं।

यदि हम इन सभी अवधारणाओं की तुलना खानाबदोश से करते हैं, तो हम कह सकते हैं कि पहले तीन अवधारणाएँ सभी एक साथ सेवा में हैं। और घुमंतू में ही आखिरी अवधारणा गायब है। हमने एक बाहरी बैलेंसर का उपयोग किया है: यह हैप्रोक्सी, नेग्नेक्स, नेग्नेक्स + और इतने पर हो सकता है। क्यूब के मामले में, आपको इस अतिरिक्त अवधारणा को अलग से पेश करने की आवश्यकता नहीं है। हालाँकि, यदि आप अंदर की ओर देखते हैं, तो यह या तो nginx है, या haproxy, या traefik, लेकिन मानो कुबेरनेट्स में बनाया गया है।

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



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

हेल ​​में मुख्य अवधारणाओं

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

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

हेल्म हमारे लिए कुछ अतिरिक्त अवधारणाओं को जोड़ता है।

चार्ट आपकी सेवा का विवरण है। अन्य पैकेज प्रबंधक इसे पैकेज, बंडल या ऐसा कुछ कहेंगे। इसे यहां चार्ट कहा जाता है।

मान वे चर हैं जो आप अपने कॉन्फिग को टेम्प्लेट से बनाने के लिए उपयोग करना चाहते हैं।

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

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



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



इसने हमें क्या दिया?

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

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

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

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

निष्कर्ष

कुबेरनेट्स सेवा घुमंतू की तुलना में अधिक जटिल दिखती है।



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

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

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

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