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

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

वीएम पर एप्लिकेशन तैनात करना

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

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

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

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

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

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

लेकिन इन सबमें हमें कई कमियाँ भी नज़र आईं:

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

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

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

खानाबदोश पर स्विच करें

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

"वाणिज्यदूत" सेवा खोज के लिए एक उपकरण है.

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

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

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

आपको अपने सिस्टम को घुमंतू में तैनात करने की क्या आवश्यकता है?

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

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

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

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

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

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

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

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

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

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

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

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

मानव संसाधनों के संदर्भ में इस परिवर्तन से हमें कितनी लागत आई?

पूरी कंपनी को घुमंतू में बदलने में लगभग 5-6 महीने लगे। हम सेवा-दर-सेवा आधार पर आगे बढ़े, लेकिन काफी तेज़ गति से। प्रत्येक टीम को सेवाओं के लिए अपने स्वयं के कंटेनर बनाने थे।

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

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

घुमंतू को त्यागने के कारण

नोमैड और डॉकर सहित अन्य का उपयोग करके परिनियोजन पर स्विच करने से हमें क्या लाभ मिला?

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

लेकिन हमें कई नुकसान भी झेलने पड़े:

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

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

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

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

कुबेरनेट्स में संक्रमण

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

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

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

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

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

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

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

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

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

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

हेल्म में बुनियादी अवधारणाएँ

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

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

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

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

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

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

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

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

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

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

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

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

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

निष्कर्ष

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

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

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

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

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

स्रोत: www.habr.com