सर्वांना नमस्कार! माझे नाव पावेल अगालेत्स्की आहे. मी Lamoda वितरण प्रणाली विकसित करणार्‍या टीममध्ये टीम लीड म्हणून काम करतो. 2018 मध्ये, मी HighLoad++ परिषदेत बोललो आणि आज मला माझ्या अहवालाचा उतारा सादर करायचा आहे.

माझा विषय वेगवेगळ्या वातावरणात प्रणाली आणि सेवा तैनात करण्याच्या आमच्या कंपनीच्या अनुभवाला समर्पित आहे. आमच्या प्रागैतिहासिक काळापासून, जेव्हा आम्ही सर्व सिस्टीम सामान्य व्हर्च्युअल सर्व्हरमध्ये तैनात केल्या होत्या, ज्याचा शेवट Nomad पासून Kubernetes मध्ये तैनातीपर्यंत हळूहळू संक्रमणासह होतो. आम्ही ते का केले आणि प्रक्रियेत आम्हाला कोणत्या समस्या आल्या हे मी तुम्हाला सांगेन.

VM वर अनुप्रयोग तैनात करत आहे

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

हे का केले गेले?

जेव्हा आम्ही आमच्या ऍप्लिकेशनचे नवीन रिलीझ तैनात केले, तेव्हा आम्हाला अखंड रोलआउटची खात्री करायची होती, म्हणजेच वापरकर्त्यांसाठी लक्षणीय परिणाम न होता. Ansible चा वापर करून पुढील संकलित केलेले प्रकाशन टेल टू रोल आउट केले गेल्यामुळे हे साध्य झाले. तेथे, तैनातीमध्ये सामील असलेले लोक तपासू शकतात आणि सर्वकाही ठीक आहे याची खात्री करू शकतात: सर्व मेट्रिक्स, विभाग आणि अनुप्रयोग कार्यरत होते; आवश्यक स्क्रिप्ट लाँच केल्या आहेत. सर्व काही ठीक असल्याची खात्री पटल्यानंतरच वाहतूक सुरळीत करण्यात आली. आधी शेपूट असलेल्या सर्व्हरवर जायला सुरुवात झाली. आणि आमच्या ऍप्लिकेशनची पूर्वीची आवृत्ती असतानाही ते पूर्वी प्रमुख होते ते वापरकर्त्याच्या रहदारीशिवाय राहिले.

त्यामुळे वापरकर्त्यांसाठी ते अखंड होते. कारण स्विचिंग तात्काळ होते, कारण ते फक्त बॅलन्सर स्विच करत आहे. बॅलन्सर परत स्विच करून तुम्ही अगदी सहजपणे मागील आवृत्तीवर परत येऊ शकता. आम्ही हे देखील सत्यापित करू शकतो की अनुप्रयोग वापरकर्ता रहदारी प्राप्त होण्यापूर्वीच उत्पादन करण्यास सक्षम आहे, जे बरेच सोयीस्कर होते.

या सगळ्यात आपल्याला कोणते फायदे दिसले?

1. सर्व प्रथम, ते पुरेसे आहे ते फक्त कार्य करते. अशी उपयोजन योजना कशी कार्य करते हे प्रत्येकाला समजते, कारण बहुतेक लोकांनी नियमित व्हर्च्युअल सर्व्हरवर तैनात केले आहे.
2. हे खूप झाले विश्वासार्हपणे, उपयोजन तंत्रज्ञान सोपे असल्याने, हजारो कंपन्यांद्वारे चाचणी केली जाते. लाखो सर्व्हर अशा प्रकारे तैनात केले जातात. काहीतरी तोडणे कठीण आहे.
3. आणि शेवटी आम्ही मिळवू शकलो अणु उपयोजन. वापरकर्त्यांसाठी एकाच वेळी होणारे उपयोजन, जुन्या आवृत्ती आणि नवीन दरम्यान स्विच करण्याच्या लक्षात येण्याजोग्या टप्प्याशिवाय.

परंतु या सर्व गोष्टींमध्ये आम्हाला अनेक कमतरता देखील दिसल्या:

1. उत्पादन वातावरण, विकासाचे वातावरण या व्यतिरिक्त इतर वातावरणे आहेत. उदाहरणार्थ, qa आणि पूर्वउत्पादन. त्या वेळी आमच्याकडे बरेच सर्व्हर आणि सुमारे 60 सेवा होत्या. या कारणास्तव ते आवश्यक होते प्रत्येक सेवेसाठी, त्याची नवीनतम आवृत्ती ठेवा आभासी यंत्र, आभासी साधन. शिवाय, तुम्हाला लायब्ररी अपडेट करायची असल्यास किंवा नवीन अवलंबित्व स्थापित करायचे असल्यास, तुम्हाला हे सर्व वातावरणात करणे आवश्यक आहे. डेव्हॉप्स आवश्यक पर्यावरण सेटिंग्ज करत असताना तुम्ही तुमच्या अॅप्लिकेशनची पुढील नवीन आवृत्ती डिप्लॉय करणार आहात तेव्हाची वेळ देखील तुम्हाला सिंक्रोनाइझ करणे आवश्यक आहे. या प्रकरणात, अशा परिस्थितीत जाणे सोपे आहे जिथे आपले वातावरण एकाच वेळी सर्व वातावरणात काहीसे वेगळे असेल. उदाहरणार्थ, QA वातावरणात लायब्ररीच्या काही आवृत्त्या असतील आणि उत्पादन वातावरणात वेगळ्या असतील, ज्यामुळे समस्या निर्माण होतील.
2. अवलंबित्व अद्यतनित करण्यात अडचण तुमचा अर्ज. हे तुमच्यावर अवलंबून नाही तर इतर संघावर अवलंबून आहे. बहुदा, सर्व्हरची देखभाल करणार्‍या डेव्हॉप्स टीमकडून. तुम्ही त्यांना योग्य कार्य आणि तुम्हाला काय करायचे आहे याचे वर्णन दिले पाहिजे.
3. त्या वेळी, आम्हाला आमच्याकडे असलेल्या मोठ्या मोठ्या मोनोलिथला वेगळ्या छोट्या सेवांमध्ये विभाजित करायचे होते, कारण आम्हाला समजले होते की त्यापैकी अधिक आणि जास्त असतील. त्या वेळी, आमच्याकडे आधीच त्यापैकी 100 पेक्षा जास्त होते. प्रत्येक नवीन सेवेसाठी, स्वतंत्र नवीन आभासी मशीन तयार करणे आवश्यक होते, ज्याची देखरेख आणि तैनात करणे देखील आवश्यक होते. याव्यतिरिक्त, आपल्याला एका कारची गरज नाही, परंतु किमान दोन. या सगळ्यात भर पडली ती QA वातावरणाची. यामुळे समस्या निर्माण होतात आणि तुमच्यासाठी नवीन प्रणाली तयार करणे आणि चालवणे अधिक कठीण होते. जटिल, महाग आणि लांब प्रक्रिया.

म्हणून, आम्ही ठरवले की नियमित व्हर्च्युअल मशीन तैनात करण्यापासून डॉकर कंटेनरमध्ये आमचे अनुप्रयोग तैनात करणे अधिक सोयीचे असेल. जर तुमच्याकडे डॉकर असेल, तर तुम्हाला क्लस्टरमध्ये ऍप्लिकेशन चालवता येईल अशा सिस्टमची आवश्यकता आहे, कारण तुम्ही फक्त कंटेनर वाढवू शकत नाही. सहसा तुम्हाला किती कंटेनर उचलले जातात याचा मागोवा ठेवायचा आहे जेणेकरून ते आपोआप उचलले जातील. या कारणास्तव, आम्हाला नियंत्रण प्रणाली निवडण्याची आवश्यकता आहे.

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

भटक्या वर स्विच करा

Nomad हे HashiCorp चे उत्पादन आहे. ते त्यांच्या इतर उपायांसाठी देखील ओळखले जातात:

"वाणिज्यदूत" सेवा शोधण्याचे साधन आहे.

"टेराफॉर्म" - सर्व्हर व्यवस्थापित करण्यासाठी एक प्रणाली जी तुम्हाला कॉन्फिगरेशनद्वारे कॉन्फिगर करण्याची परवानगी देते, तथाकथित इन्फ्रास्ट्रक्चर-ए-ए-कोड.

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

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

तुमची सिस्टीम भटक्यांवर तैनात करण्यासाठी तुम्हाला काय आवश्यक आहे?

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

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

हे तुम्हाला किती कंटेनर तैनात करायचे आहे हे सांगण्याची परवानगी देते, कोणत्या प्रतिमांमधून त्यांना तैनात करताना विविध पॅरामीटर्स पास करायचे आहेत. अशा प्रकारे, तुम्ही ही फाईल नोमॅडला फीड करा आणि ती त्यानुसार कंटेनर उत्पादनात लाँच करते.

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

म्हणून, आम्ही ठरवले की आमच्या सर्व कॉन्फिगरेशन फाइल्स एका सामान्य भांडारात उपयोजनासाठी संग्रहित करणे आमच्यासाठी सोयीचे असेल. अशा प्रकारे ते दृश्यमान होते: त्यांची देखभाल करणे सोपे होते आणि आमच्याकडे कोणत्या प्रणाली आहेत हे आम्ही पाहू शकतो. आवश्यक असल्यास, काहीतरी अद्यतनित करणे किंवा बदलणे देखील सोपे आहे. नवीन प्रणाली जोडणे देखील कठीण नाही - तुम्हाला फक्त नवीन निर्देशिकेमध्ये कॉन्फिगरेशन फाइल तयार करण्याची आवश्यकता आहे. त्याच्या आत खालील फाइल्स आहेत: service.hcl, ज्यामध्ये आमच्या सेवेचे वर्णन आहे आणि काही env फाइल्स ज्या या सेवेला, उत्पादनात तैनात केल्या जात आहेत, कॉन्फिगर करण्याची परवानगी देतात.

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

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

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

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

जेव्हा नोमॅड सेवा तुमच्या क्लस्टरमध्ये आधीच तैनात केली जाते, तेव्हा असे दिसते.

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

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

मानवी संसाधनांच्या बाबतीत संक्रमणामुळे आम्हाला किती खर्च आला?

संपूर्ण कंपनीचे भटक्यामध्ये संक्रमण होण्यास सुमारे 5-6 महिने लागले. आम्ही सेवा-दर-सेवा तत्त्वावर, परंतु बर्‍यापैकी वेगवान गतीने गेलो. सेवांसाठी प्रत्येक संघाला स्वतःचे कंटेनर तयार करावे लागले.

आम्ही असा दृष्टिकोन स्वीकारला आहे की प्रत्येक कार्यसंघ त्यांच्या सिस्टमच्या डॉकर प्रतिमांसाठी स्वतंत्रपणे जबाबदार आहे. DevOps तैनातीसाठी आवश्यक असलेल्या सामान्य पायाभूत सुविधा पुरवतात, म्हणजे क्लस्टरसाठीच समर्थन, CI प्रणालीसाठी समर्थन इ. आणि त्या वेळी, आमच्याकडे 60 हून अधिक सिस्टम नोमॅडमध्ये हलविण्यात आले होते, ज्याची रक्कम सुमारे 2 हजार कंटेनर होती.

डिप्लॉयमेंट आणि सर्व्हरशी संबंधित प्रत्येक गोष्टीच्या सामान्य पायाभूत सुविधांसाठी Devops जबाबदार आहे. आणि प्रत्येक डेव्हलपमेंट टीम, त्या बदल्यात, त्याच्या विशिष्ट प्रणालीसाठी कंटेनर लागू करण्यासाठी जबाबदार आहे, कारण तो संघ आहे ज्याला विशिष्ट कंटेनरमध्ये सामान्यतः काय आवश्यक आहे हे माहित आहे.

भटक्यांचा त्याग करण्याची कारणे

नोमॅड आणि डॉकर वापरून डिप्लॉयमेंटवर स्विच केल्याने आम्हाला कोणते फायदे मिळाले?

1. आम्ही समान परिस्थिती प्रदान केली सर्व वातावरणासाठी. विकासामध्ये, QA वातावरण, पूर्व-उत्पादन, उत्पादन, समान कंटेनर प्रतिमा वापरल्या जातात, समान अवलंबनांसह. त्यानुसार, उत्पादनात जे संपेल ते तुम्ही पूर्वी स्थानिक पातळीवर किंवा तुमच्या चाचणी वातावरणात तपासले नाही याची तुम्हाला अक्षरशः कोणतीही शक्यता नाही.
2. आम्हाला देखील आढळले की ते पुरेसे आहे नवीन सेवा जोडणे सोपे. तैनातीच्या दृष्टिकोनातून, कोणतीही नवीन प्रणाली अगदी सोप्या पद्धतीने सुरू केली जाते. फक्त कॉन्फिगरेशन्स संचयित करणार्‍या रेपॉजिटरीमध्ये जा, तेथे तुमच्या सिस्टमसाठी दुसरे कॉन्फिगरेशन जोडा आणि तुम्ही सर्व तयार आहात. डेव्हॉप्सकडून कोणत्याही अतिरिक्त प्रयत्नाशिवाय तुम्ही तुमची प्रणाली उत्पादनासाठी उपयोजित करू शकता.
3. सर्व कॉन्फिगरेशन फाइल्स एका सामान्य भांडारात पुनरावलोकनाधीन असल्याचे निष्पन्न झाले. जेव्हा आम्ही व्हर्च्युअल सर्व्हर वापरून आमची प्रणाली तैनात केली तेव्हा आम्ही Ansible चा वापर केला, ज्यामध्ये कॉन्फिगस एकाच भांडारात होत्या. तथापि, बहुतेक विकसकांसाठी हे कार्य करणे थोडे अधिक कठीण होते. येथे कॉन्फिगन्स आणि कोडचे व्हॉल्यूम जे तुम्हाला सेवा उपयोजित करण्यासाठी जोडणे आवश्यक आहे ते खूपच लहान झाले आहे. शिवाय, डेव्हॉपसाठी ते दुरुस्त करणे किंवा बदलणे खूप सोपे आहे. संक्रमणाच्या बाबतीत, उदाहरणार्थ, Nomad च्या नवीन आवृत्तीमध्ये, ते त्याच ठिकाणी असलेल्या सर्व ऑपरेटिंग फायली घेऊ शकतात आणि मोठ्या प्रमाणात अद्यतनित करू शकतात.

परंतु आम्हाला अनेक तोटे देखील आली:

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

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

त्यामुळे पुढे कुठे जायचे याचा विचार करायचे ठरवले. त्या क्षणी, आम्हाला काय साध्य करायचे आहे याची आम्हाला अधिक जाणीव झाली. उदा: आम्हाला विश्वासार्हता हवी आहे, नोमॅड प्रदान करते त्यापेक्षा थोडी अधिक कार्ये आणि अधिक परिपक्व, अधिक स्थिर प्रणाली हवी आहे.

या संदर्भात, क्लस्टर्स लाँच करण्यासाठी सर्वात लोकप्रिय व्यासपीठ म्हणून आमची निवड कुबर्नेट्सवर पडली. विशेषत: आमच्या कंटेनरचा आकार आणि संख्या पुरेशी मोठी होती. अशा हेतूंसाठी, कुबर्नेट्स ही सर्वात योग्य प्रणाली आहे जी आपण पाहू शकतो.

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

मी तुम्हाला कुबर्नेट्सच्या मूलभूत संकल्पनांबद्दल आणि ते भटक्यापेक्षा कसे वेगळे आहेत याबद्दल थोडेसे सांगेन.

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

समजा तुमच्याकडे एक PHP ऍप्लिकेशन आहे ज्यामध्ये nginx आणि php-fpm - क्लासिक योजना आहे. बहुधा, तुम्ही दोन्ही nginx आणि php-fpm कंटेनर नेहमी एकत्र ठेवू इच्छित असाल. Kubernetes तुम्हाला एक सामान्य पॉड म्हणून वर्णन करून हे साध्य करण्याची परवानगी देतो. भटकंतीला नेमके हेच मिळू शकले नाही.

दुसरी संकल्पना आहे उपयोजन. वस्तुस्थिती अशी आहे की पॉड स्वतःच एक क्षणभंगुर गोष्ट आहे; ती सुरू होते आणि अदृश्य होते. तुम्‍हाला तुमच्‍या आधीचे सर्व कंटेनर आधी मारायचे आहेत, आणि नंतर नवीन आवृत्त्या एकाच वेळी लाँच करायच्या आहेत, किंवा तुम्‍हाला हळुहळू त्‍या रोल आउट करायच्‍या आहेत? ही अशी प्रक्रिया आहे जिला डिप्लॉयमेंटची संकल्पना जबाबदार आहे. तुम्ही तुमचे शेंगा कसे उपयोजित करता, किती प्रमाणात आणि ते कसे अपडेट करायचे याचे ते वर्णन करते.

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

आणि चौथी मूळ संकल्पना आहे प्रवेश. ही एक सेवा आहे जी कुबर्नेट्स क्लस्टरवर चालते. हे बाह्य लोड बॅलन्सर म्हणून कार्य करते जे सर्व विनंत्या घेते. Kubernetes API वापरून, Ingress हे विनंत्या कुठे पाठवायचे हे ठरवू शकते. शिवाय, तो हे अतिशय लवचिकपणे करतो. तुम्ही म्हणू शकता की या होस्टला सर्व विनंत्या आणि अशा आणि अशा URL या सेवेला पाठवल्या जातात. आणि या होस्टला आणि दुसर्‍या URL वर येणार्‍या या विनंत्या दुसर्‍या सेवेला पाठवल्या जातात.

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

जर आपण या सर्व संकल्पनांची भटक्यांशी तुलना केली तर आपण असे म्हणू शकतो की पहिल्या तीन संकल्पना सर्व एकत्र सेवा आहेत. आणि शेवटची संकल्पना नोमॅडमध्येच अनुपस्थित आहे. आम्ही बाह्य बॅलन्सर वापरला: ते हॅप्रॉक्सी, एनजीनक्स, एनजीनक्स+ आणि असेच असू शकते. क्यूबच्या बाबतीत, तुम्हाला ही अतिरिक्त संकल्पना स्वतंत्रपणे सादर करण्याची आवश्यकता नाही. तथापि, जर तुम्ही इंग्रेसला आंतरिकरित्या पाहिले तर ते एकतर nginx, haproxy किंवा traefik आहे, परंतु कुबर्नेट्समध्ये तयार केलेले आहे.

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

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

हेल्ममधील मूलभूत संकल्पना

हेल्म आहे पॅकेज व्यवस्थापक कुबर्नेट्ससाठी. हे प्रोग्रामिंग भाषांमधील पॅकेज व्यवस्थापक कसे कार्य करतात यासारखेच आहे. ते तुम्हाला सेवा संग्रहित करण्याची परवानगी देतात, उदाहरणार्थ, डिप्लॉयमेंट nginx, डिप्लॉयमेंट php-fpm, इंग्रेससाठी कॉन्फिगरेशन, कॉन्फिगमॅप्स (ही एक संस्था आहे जी तुम्हाला तुमच्या सिस्टमसाठी env आणि इतर पॅरामीटर्स सेट करण्याची परवानगी देते) so- चार्ट म्हणतात. त्याच वेळी हेलम कुबर्नेट्सच्या वर चालते. म्हणजेच, ही काही प्रकारची यंत्रणा बाजूला उभी नाही, तर क्यूबच्या आत सुरू केलेली दुसरी सेवा आहे. तुम्ही त्याच्या API द्वारे कन्सोल कमांडद्वारे संवाद साधता. त्याची सोय आणि सुंदरता अशी आहे की जरी हेल्म तुटले किंवा तुम्ही ते क्लस्टरमधून काढून टाकले तरीही तुमच्या सेवा अदृश्य होणार नाहीत, कारण हेल्म मूलत: फक्त सिस्टम सुरू करण्यासाठी काम करते. कुबर्नेट्स स्वतः नंतर सेवांच्या कार्यक्षमतेसाठी आणि स्थितीसाठी जबाबदार आहेत.

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

हेल्म आमच्यासाठी आणखी काही संकल्पना जोडतो.

चार्ट - हे तुमच्या सेवेचे वर्णन आहे. इतर पॅकेज व्यवस्थापकांमध्ये याला पॅकेज, बंडल किंवा तत्सम काहीतरी म्हटले जाईल. इथे त्याला चार्ट म्हणतात.

मूल्ये हे व्हेरिएबल्स आहेत जे तुम्ही टेम्पलेट्समधून तुमची कॉन्फिग्स तयार करण्यासाठी वापरू इच्छिता.

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

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

सराव मध्ये, आम्ही भटक्या पेक्षा काही वेगळ्या पद्धतीने करण्याचे ठरवले. जर Nomad मध्ये दोन्ही डिप्लॉयमेंट कॉन्फिग्स आणि n-व्हेरिएबल्स जे आमची सेवा उपयोजित करण्यासाठी आवश्यक होते ते एकाच रिपॉजिटरीमध्ये संग्रहित केले असल्यास, येथे आम्ही त्यांना दोन वेगळ्या रिपॉझिटरीजमध्ये विभागण्याचा निर्णय घेतला. “डिप्लॉय” रेपॉजिटरी डिप्लॉयमेंटसाठी आवश्यक फक्त एन-व्हेरिएबल्स साठवते आणि “हेल्म” रेपॉजिटरी कॉन्फिगरेशन किंवा चार्ट स्टोअर करते.

याने आम्हाला काय दिले?

आम्ही स्वतः कॉन्फिगरेशन फायलींमध्ये कोणताही संवेदनशील डेटा संचयित करत नाही हे तथ्य असूनही. उदाहरणार्थ, डेटाबेसला पासवर्ड. ते कुबर्नेट्समध्ये गुपिते म्हणून संग्रहित आहेत, परंतु तरीही, तेथे अजूनही काही गोष्टी आहेत ज्यात आम्ही प्रत्येकाला प्रवेश देऊ इच्छित नाही. म्हणून, “डिप्लॉय” रेपॉजिटरीमध्ये प्रवेश अधिक मर्यादित आहे आणि “हेल्म” रेपॉजिटरीमध्ये फक्त सेवेचे वर्णन आहे. या कारणास्तव, लोकांच्या विस्तृत श्रेणीद्वारे सुरक्षितपणे प्रवेश केला जाऊ शकतो.

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

प्रत्येक रेपॉजिटरीमध्ये, आम्ही प्रत्येक सेवेसाठी स्वतंत्र डिरेक्टरीमध्ये विभाग सोडला. म्हणजेच, प्रत्येक निर्देशिकेत संबंधित चार्टशी संबंधित टेम्पलेट्स असतात आणि आमची सिस्टम लॉन्च करण्यासाठी उपयोजित करणे आवश्यक असलेल्या संसाधनांचे वर्णन करतात. आम्ही “डिप्लॉय” रेपॉजिटरीमध्ये फक्त envs सोडले. या प्रकरणात, आम्ही जिंजा वापरून टेम्प्लेटिंग वापरले नाही, कारण हेल्म स्वतःच बॉक्सच्या बाहेर टेम्पलेटिंग प्रदान करते - हे त्याचे मुख्य कार्य आहे.

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

निष्कर्ष

कुबर्नेट्स सेवा नोमॅडपेक्षा अधिक जटिल असल्याचे दिसते.

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

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

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

मार्च २०१८ मध्ये आम्ही Kubernetes वर प्रथम तैनाती केली होती. आणि या काळात आम्हाला त्यात कोणतीही अडचण आली नाही. हे लक्षणीय दोषांशिवाय स्थिरपणे कार्य करते. शिवाय, आम्ही त्याचा आणखी विस्तार करू शकतो. आज आमच्याकडे पुरेशी क्षमता आहे आणि आम्हाला कुबर्नेट्सच्या विकासाची गती खरोखर आवडते. सध्या, 2018 हून अधिक कंटेनर कुबरनेटमध्ये आहेत. क्लस्टर अनेक नोड्स व्यापतो. त्याच वेळी, ते सेवायोग्य, स्थिर आणि अतिशय नियंत्रणीय आहे.

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