🐐 ⤵️ 🦎 पाइरेसी की भावना में कुबेरनेट्स: माइक्रोसर्विस के लिए हमारा रास्ता और कार्यान्वयन के लिए तैयार टेम्पलेट 👩🏿 👩🏿‍🤝‍👩🏾 🐪

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

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

यह लेख Mail.ru Cloud Solutions द्वारा @Kubernetes सम्मेलन में एक वीडियो प्रस्तुति पर आधारित हैयदि आप पढ़ना नहीं चाहते हैं, तो आप देख सकते हैं ।

हम कुबेरनेट्स से पहले कैसे रहते थे: देव सर्वर, नंगे धातु और Ansible

हम निरंतर परिवर्तनों और प्रयोगों के एक मोड में रहते थे और रहते थे: एवी परीक्षण, विभिन्न परिकल्पनाओं का परीक्षण। हम नई सेवाओं को लॉन्च करते हैं, फिर, अगर कुछ काम नहीं करता है, तो हम इसे काट देते हैं।

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

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

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

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

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

हम कुबेरनेट्स में कैसे आए और इस पर बुनियादी ढांचे का निर्माण किया

जाहिर है, कोई भी ऐसा नहीं रह सकता है, ऑर्केस्ट्रेशन की आवश्यकता है। हमने इसे 2017-2018 में समझा था, तब यह स्पष्ट नहीं था कि यह ऑर्केस्ट्रा कहां मिलेगा। कुबेरनेट्स अभी शुरुआत कर रहे थे, HashiCorp घुमंतू, Rancher, OpenShift थे। हमने खानाबदोश की कोशिश की, यह बुरा नहीं था, लेकिन हम खानाबदोश रचना को फिर से लिखना नहीं चाहते थे।

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

और फिर Kubernetes एक सेवा के रूप Mail.ru बादल समाधान मंच पर दिखाई दिया Mail.ru बादल कंटेनरों। हमने पहले ही अमेजन से अपना S3 स्टोरेज स्थानांतरित कर दिया है, हमने K8 को भी आजमाने का फैसला किया है। हमने क्लाउड में एक क्लस्टर तैनात किया, सब कुछ काम किया।

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

VMware में प्रत्येक डेवलपर का अपना मिनिक्यूब होता है, जिसके साथ वह काम करता है। हम MCS क्लाउड में कुबेरनेट्स में नई परियोजनाएं शुरू करते हैं, हम प्रबंधित MySQL को भी तैनात करते हैं, जो तुरंत S3 में सभी दास, प्रतिकृति और बैकअप के साथ आता है।

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

कैसे एक प्रौद्योगिकी चिड़ियाघर के साथ रहते हैं और पीड़ित नहीं है

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

सामान्य तौर पर, हमारे पास दो नियम हैं:

dockerize: कंटेनर होने चाहिए;
अवलोकन: ये कंटेनर अवलोकन योग्य होने चाहिए।

चिड़ियाघर के साथ सादृश्य जारी रखने के लिए: कोशिकाएं हैं, और यह इतना महत्वपूर्ण नहीं है कि इन कोशिकाओं में कौन बैठता है। मुख्य बात यह है कि पानी और भोजन नियमित रूप से, स्वचालित रूप से और समान रूप से पहुंचते हैं, और सेवाओं के "महत्वपूर्ण उत्पाद", अर्थात, लॉग कहीं केंद्रित होते हैं।

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

इस सब के साथ विकास और परीक्षण कैसे करें

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

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

ZFS में स्नैपशॉट हैं, एक एपीआई डेवलपर डेटाबेस को दो सेकंड में उत्पादन से सीधे रोल कर सकता है। ऑटोटेस्ट्स के साथ, एक ही कहानी: हम एपीआई द्वारा शुरू करते हैं, और सब कुछ काम करता है।

यह वही है जो विकास प्रवाह आज की तरह दिखता है:

डेवलपर खुश है, DevOps और व्यवस्थापक खुश हैं क्योंकि सभी प्रक्रियाएं समान, दोहराने योग्य और एकीकृत हैं। लेकिन एक बात है।

स्तरित परत प्रणाली

जैसा कि लिनुस टॉर्वाल्ड्स ने कहा: "बात सस्ती है। मुझे कोड दिखाओ। ” इसलिए, हम एक बहु-स्तरीय परत प्रणाली का उपयोग करते हैं। तुच्छ परतें हैं: देव, मंच, ठेस, जो सभी के लिए ध्यान में रखते हैं जो सीआई / सीडी बनाने जा रहे हैं।

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

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

K8s-helm रिपॉजिटरी कैसे काम करती है

जैसा कि मैंने कहा, हमारे पास देव, ठेस और मंच की स्पष्ट परतें हैं, प्रत्येक सेवा से एक यमल फ़ाइल है, जब हमने एक नई सेवा देखी, तो फ़ाइल जोड़ें।

इसके अतिरिक्त सबसे दिलचस्प के साथ एक डैडी dev.server है। उदाहरण के लिए मदद करने वाली बैश स्क्रिप्ट हैं, एक नया उपयोगकर्ता बनाएं: अपने हाथों से 100 सेवाएं न बनाएं और याम्ल फ़ाइलों में न भरें, लेकिन बस एक कमांड में चलाएं। यह वह जगह है जहाँ इन सभी yaml फ़ाइलों को उत्पन्न किया जाता है।

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

नतीजतन, प्रक्रिया तीन टीमों को उबालती है:

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

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

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

K8s-helm असेंबली

रिपॉजिटरी स्वयं अतिरिक्त रूप से संकलित है और इसे CI / CD प्रक्रियाओं में बनाया गया है। यहां कुछ खास नहीं है - बस सर्टिफिकेट और हेल्म के साथ कुबेकल।

परियोजना में, यह इस तरह दिखता है:

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

इसके बाद CI, यहाँ .drone.yml आता है, लेकिन GitLab या कहीं और के बारे में एक ही बात होगी।

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

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

हमारे अन्य संबंधित लेख:

यह बात पहली बार Mail.ru Cloud Solutions द्वारा @Kubernetes सम्मेलन में की गई थी। अन्य प्रदर्शनों का एक वीडियो देखें और Tele.ru इवेंट घोषणाओं के लिए साइन अप करें Mail.ru समूह पर Kubernetes के आसपास ।

पाइरेसी की भावना में कुबेरनेट्स: माइक्रोसर्विस के लिए हमारा रास्ता और कार्यान्वयन के लिए तैयार टेम्पलेट