हमने कुबेरनेट्स में प्रीपीड को कैसे और क्यों माइग्रेट किया

इस लेख में मैं Kubernetes के लिए पूर्ववर्ती प्रवास करने के हमारे अनुभव का वर्णन करूंगा कि हमने यह कैसे और क्यों किया, हमें किन कठिनाइयों का सामना करना पड़ा और हमें क्या फायदे हुए।

कुबेरनेट्स के लिए कुबेरनेट्स? नहीं, व्यावसायिक आवश्यकताओं!

कुबेरनेट्स के आसपास बहुत अधिक प्रचार है और अच्छे कारण के लिए है। बहुत से लोग कहते हैं कि यह सभी समस्याओं को हल करेगा, कुछ का कहना है कि सबसे अधिक संभावना है कि आपको कुबेरनेट की आवश्यकता नहीं है । पाठ्यक्रम का सच कहीं बीच में है।

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

• जब हमने Skullcandy प्रवाह का उपयोग किया, तो हमारे पास बहुत सी शाखाएं थीं, उन सभी को एक सामान्य शाखा में मिला दिया गया जिसे stage-rc कहा जाता है, जिसे stage-rc तैनात किया गया। क्यूए टीम ने इस वातावरण का परीक्षण किया, परीक्षण के बाद शाखा को मास्टर में और मास्टर को ठेस के लिए तैनात किया गया था। पूरी प्रक्रिया में लगभग 3-4 घंटे लगे और हम दिन में 0 से 2 बार तैनात कर पाए
• जब हमने टूटे हुए कोड को ठिकाने पर तैनात किया, तो हमें नवीनतम रिलीज़ में शामिल सभी परिवर्तनों को वापस करना पड़ा। यह पता लगाना भी मुश्किल था कि किस बदलाव ने हमारे उत्पाद को तोड़ दिया
• हमने अपने एप्लिकेशन को होस्ट करने के लिए AWS इलास्टिक बीनस्टॉक का इस्तेमाल किया। हमारे मामले में प्रत्येक बीनस्टॉक की तैनाती में 45 मिनट का समय लगा ( 90 मिनट में परीक्षण के साथ पूरी पाइपलाइन एक साथ काम करती है)। एप्लिकेशन के पिछले संस्करण में रोलबैक में 45 मिनट का समय लगा

कंपनी में हमारे उत्पाद और प्रक्रियाओं को बेहतर बनाने के लिए, हम चाहते थे:

• एक मोनोलिथ को माइक्रोसर्विस में तोड़ दें
• तेजी से और अधिक बार तैनात करें
• तेजी से वापस रोल करें
• हमारी विकास प्रक्रिया को बदलें क्योंकि हमें लगा कि यह अब प्रभावी नहीं था

हमारी जरूरतें

हम विकास की प्रक्रिया को बदलते हैं

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

• जल्दी और आसानी से तैनात (अधिमानतः कंटेनर)
• मौके पर काम किया
• वे ठेस के समान थे

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

गिट-फ्लो और ट्रंक-आधारित विकास

तेजी से और अधिक बार तैनात करें

नई ट्रंक-आधारित प्रक्रिया ने हमें एक के बाद एक तेजी से मास्टर शाखा में नवाचार देने की अनुमति दी। इससे हमें ठेस में टूटे हुए कोड को खोजने और उसे वापस लाने की प्रक्रिया में बहुत मदद मिली। हालांकि, तैनाती का समय अभी भी 90 मिनट था, और रोलबैक का समय 45 मिनट था, इस वजह से हम दिन में 4-5 बार अधिक तैनात नहीं कर सकते थे।

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

हमारा अगला कदम लोकप्रिय कंटेनर ऑर्केस्ट्रेटर पर शोध करना था:

• AWS ECS
• झुंड
• अपाचे मेसो
• घुमक्कड़
• Kubernetes

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

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

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

कुबेरनेट का उपयोग करना

हमने अवधारणा के प्रमाण के साथ शुरुआत की, एक परीक्षण क्लस्टर बनाया, और हमने जो कुछ भी किया, उसके बारे में विस्तार से दस्तावेज तैयार किया। हमने kops का उपयोग करने का निर्णय लिया, क्योंकि उस समय हमारे क्षेत्र में EKS अभी भी उपलब्ध नहीं था (आयरलैंड में इसे सितंबर 2018 में घोषित किया गया था)।

क्लस्टर के साथ काम करते हुए, हमने क्लस्टर- ऑटोस्कोलर, सर्टिफिकेट -मैनेजर , प्रोमेथियस, हाशिकोर्प वॉल्ट, जेनकिंस के साथ एकीकरण और बहुत कुछ परीक्षण किया। हमने रोलिंग-अपडेट रणनीतियों के साथ "खेला", विशेष रूप से DNS के साथ कई नेटवर्क समस्याओं का सामना किया, और क्लस्टर क्लस्टरिंग में अपने ज्ञान को मजबूत किया।

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

हमने Skullcandy प्रवाह से ट्रंक-आधारित विकास के लिए माइग्रेशन शुरू किया, जहां हमने प्रत्येक पुल अनुरोध के लिए एक गतिशील चरण लॉन्च किया, इससे हमें नई सुविधाओं के लिए डिलीवरी का समय 4-6 से 1-2 घंटे तक कम करने की अनुमति मिली ।

Github हुक ने पुल अनुरोध के लिए गतिशील वातावरण का निर्माण शुरू किया

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

हमें खुशी है कि हमने इसके उपयोग की शुरुआत के 1-2 महीने बाद ही कुबेरनेट्स से लाभ उठाना शुरू कर दिया।

स्टेज और बिक्री समूहों

चरण और उत्पाद समूहों के लिए हमारी सेटिंग:

• कोप्स और कुबेरनेट्स 1.11 (क्लस्टर निर्माण के समय का नवीनतम संस्करण)
• विभिन्न एक्सेस जोन में तीन मास्टर नोड
• समर्पित गढ़, कैलिको सीएनआई के साथ निजी नेटवर्क टोपोलॉजी
• मैट्रिक्स इकट्ठा करने के लिए प्रोमेथियस को पीवीसी के साथ एक ही क्लस्टर में तैनात किया गया है (यह विचार करने योग्य है कि हम लंबे समय तक मैट्रिक्स को स्टोर नहीं करते हैं)
• APM के लिए डेटाडॉग एजेंट
• डेक्स + डेक्स-के -8-ऑथेंटेटर डेवलपर्स को क्लस्टर तक पहुंच प्रदान करने के लिए
• स्‍पॉट क्‍लस्‍टर के लिए नोड्स स्पॉट इंसेंटेंस पर काम करते हैं

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

कुबेरनेट्स के लिए उत्पादन पलायन

चरण और भोजन क्लस्टर तैयार हैं, और हम प्रवास शुरू करने के लिए तैयार हैं। हम निम्नलिखित संरचना के साथ मोनोरपा का उपयोग करते हैं:

 . ├── microservice1 │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── microservice2 │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── microserviceN │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── helm │ ├── microservice1 │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml │ ├── microservice2 │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml │ ├── microserviceN │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml └── Jenkinsfile 

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

helm/ निर्देशिका में मंच और बिक्री के लिए दो अलग-अलग मान-फाइलों के साथ HELM चार्ट हैं। हम मंच पर कई हेल्म चार्ट को तैनात करने के लिए स्केफोल्ड का उपयोग करते हैं। हमने छाता चार्ट का उपयोग करने की कोशिश की, लेकिन इस तथ्य का सामना करना पड़ा कि इसे स्केल करना मुश्किल है।

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

भले ही हम माइक्रोसर्विस में नई सुविधाओं का आयात करें या नहीं, हमारे मामले में सभी मुख्य कार्यक्षमता Django मोनोलिथ में है और यह मोनोलिथ अभी भी इलास्टिक बीनस्टॉक पर काम करती है।

ओस्लो में विग्रलैंड पार्क को माइक्रोसेरो में मोनोलिथ तोड़ दें

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

उसके बाद, हम पूरी तरह से इलास्टिक बीनस्टॉक के उपयोग को छोड़ने में सक्षम थे।

परिणाम

पूर्ण प्रवास में हमें 11 महीने लगे, जैसा कि मैंने ऊपर उल्लेख किया है, हमने 1 वर्ष की समय सीमा को पूरा करने की योजना बनाई है।

वास्तव में, परिणाम स्पष्ट हैं:

• तैनाती का समय 90 मिनट से घटकर 40 मिनट हो गया
• तैनाती की संख्या प्रति दिन 0-2 से बढ़कर 10-15 हो गई (और अभी भी बढ़ रही है!)
• रोलबैक का समय 45 से 1-2 मिनट तक कम हो गया
• हम आसानी से नए microservices को ठेस पहुंचा सकते हैं
• हमने अपनी मॉनीटरिंग, लॉगिंग, सीक्रेट्स मैनेजमेंट की जानकारी दी, उन्हें केंद्रीकृत किया और उन्हें कोड के रूप में वर्णित किया

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