🧛🏻 🕋 🏗️ हेल्म के साथ कई कुबेरनेट समूहों पर अनुप्रयोगों को तैनात करना 🤜🏽 🤽 🚼

कैसे Dailymotion Kubernetes का उपयोग करता है: अनुप्रयोग परिनियोजन

हम Dailymotion में 3 साल पहले उत्पादन में Kubernetes का उपयोग शुरू कर दिया। लेकिन कई समूहों पर एप्लिकेशन को लागू करना अभी भी एक खुशी है, इसलिए पिछले कुछ वर्षों में हमने अपने टूल और वर्कफ़्लो में सुधार करने की कोशिश की है।

इसकी शुरुआत कहां से हुई

यहाँ हम दिखाते हैं कि कैसे हम दुनिया भर के कई कुबेरनेट समूहों पर अपने आवेदन तैनात करते हैं।

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

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

चलिए मुद्दे पर आते हैं।

नोट। जब आप इसे पढ़ते हैं, तो पहले हेल्म 3 रिलीज उम्मीदवार की घोषणा की जा चुकी है। मुख्य संस्करण में पहले से मौजूद कुछ समस्याओं को हल करने के लिए डिज़ाइन किए गए सुधारों का एक पूरा सेट है।

चार्ट डेवलपमेंट वर्कफ़्लो

अनुप्रयोगों के लिए, हम शाखा का उपयोग करते हैं, और हमने चार्ट के लिए एक ही दृष्टिकोण लागू करने का निर्णय लिया।

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

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

विभिन्न वातावरण में चार्ट रिपॉजिटरी

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

इसके अलावा, हमारी छोटी पायथन लिपि Kubernetes के खिलाफ Kubernetes ऑब्जेक्ट को Kubernet के साथ OpenAPI विशिष्टताओं की जाँच करती है, उन्हें चार्टमेमुसेम पर प्रकाशित करने से पहले।

सामान्य चार्ट विकास वर्कफ़्लो

गुणवत्ता नियंत्रण (लिंट, यूनिट-टेस्ट) के लिए gazr.io विनिर्देशन के अनुसार पाइपलाइन कार्य की स्थापना।
पायथन टूल्स के साथ एक डॉकटर छवि प्रस्तुत करना जो हमारे अनुप्रयोगों को तैनात करता है।
शाखा के नाम से पर्यावरण की स्थापना।
Kubval के साथ yaml Kubernetes फ़ाइलों की जाँच करें।
चार्ट और उसके मूल चार्ट के चार्ट को स्वचालित रूप से बढ़ाएं (चार्ट जो चार्ट में परिवर्तित होने पर निर्भर करता है)।
चार्टम्यूजियम को एक चार्ट सबमिट करना जो उसके पर्यावरण से मेल खाता है

क्लस्टर अंतर प्रबंधन

क्लस्टर फेडरेशन

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

समस्या को हल करने के लिए, हमने स्वतंत्र रूप से समूहों का प्रबंधन करना शुरू किया, जिसने प्रक्रिया को बहुत सरल कर दिया (हमने महासंघ के पहले संस्करण का इस्तेमाल किया; दूसरे में, कुछ बदल सकता था)।

जियो वितरित मंच

अब हमारा प्लेटफ़ॉर्म 6 क्षेत्रों में वितरित किया गया है - 3 स्थानीय स्तर पर और 3 क्लाउड में।

वितरित की गई तैनाती

ग्लोबल हेल्म वैल्यूज़

4 वैश्विक हेल्म मूल्य आपको समूहों के बीच के अंतर को निर्धारित करने की अनुमति देते हैं। हमारे सभी चार्ट के लिए, न्यूनतम चूक हैं।

global: cloud: True env: staging region: us-central1 clusterName: staging-us-central1

वैश्विक मूल्य

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

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

यहाँ एक ठोस उदाहरण दिया गया है:

 {{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}} {{- define "graphql.hpaReplicas" -}} {{- if eq .Values.global.env "prod" }} {{- if eq .Values.global.region "europe-west1" }} minReplicas: 40 {{- else }} minReplicas: 150 {{- end }} maxReplicas: 1400 {{- else }} minReplicas: 4 maxReplicas: 20 {{- end }} {{- end -}}

हेल्म टेम्पलेट उदाहरण

इस तर्क को हेल्पर टेम्प्लेट में परिभाषित किया गया है ताकि कुबेरनेट्स यम्ल को रोकना न पड़े।

आवेदन की घोषणा

हमारे परिनियोजन उपकरण कई YAML फ़ाइलों पर आधारित हैं। निम्नलिखित एक उदाहरण है कि कैसे हम एक सेवा और उसके स्केलिंग टोपोलॉजी (प्रतिकृतियों की संख्या) को एक क्लस्टर में घोषित करते हैं।

 releases: - foo.world foo.world: # Release name services: # List of dailymotion's apps/projects foobar: chart_name: foo-foobar repo: git@github.com:dailymotion/foobar contexts: prod-europe-west1: deployments: - name: foo-bar-baz replicas: 18 - name: another-deployment replicas: 3

सेवा परिभाषा

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

जेनकिंस तैनाती कदम

रहस्यों के बारे में क्या?

सुरक्षा के संदर्भ में, हम विभिन्न स्थानों के सभी रहस्यों पर नज़र रखते हैं और उन्हें पेरिस में अद्वितीय वॉल्ट भंडार में संग्रहीत करते हैं।

हमारे परिनियोजन उपकरण वॉल्ट से रहस्यों के मूल्यों को निकालते हैं और जब तैनाती का समय आता है, तो उन्हें हेल्म में डालें।

ऐसा करने के लिए, हमने तिजोरी में और हमारे अनुप्रयोगों की आवश्यकता वाले रहस्यों के बीच मानचित्रण निर्धारित किया:

 secrets: - secret_id: "stack1-app1-password" contexts: - name: "default" vaultPath: "/kv/dev/stack1/app1/test" vaultKey: "password" - name: "cluster1" vaultPath: "/kv/dev/stack1/app1/test" vaultKey: "password"

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

 apiVersion: v1 data: {{- range $key,$value := .Values.secrets }} {{ $key }}: {{ $value | b64enc | quote }} {{ end }} kind: Secret metadata: name: "{{ .Chart.Name }}" labels: chartVersion: "{{ .Chart.Version }}" tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}" type: Opaque

समस्याएं और सीमाएँ

कई रिपॉजिटरी के साथ काम करें

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

सारांशित चार्ट का प्रबंधन करना परेशानी भरा है

जैसा कि हमने पहले ही कहा, निर्भरता को परिभाषित करने और कई अनुप्रयोगों को जल्दी से लागू करने के लिए जेनेरिक चार्ट बहुत सुविधाजनक हैं। लेकिन हम सामान्यीकृत चार्ट में शामिल एप्लिकेशन को लागू करने से पहले हर बार सभी --reuse-values को पारित करने से बचने के लिए उपयोग करते हैं।

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

एकाधिक कॉन्फ़िगरेशन फ़ाइलों को अद्यतन करना

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

जेनकिन्स की अनुमति भी वॉल्ट में बढ़ाई गई

अब हमारे पास एक AppRole है जो वॉल्ट के सभी रहस्यों को पढ़ता है।

रोलबैक प्रक्रिया स्वचालित नहीं है

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

हम GitOps की ओर बढ़ रहे हैं

हमारा लक्ष्य

हम उस अनुप्रयोग के भंडार में चार्ट को वापस करना चाहते हैं जिसे वह तैनात करता है।

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

कई फायदे हैं:

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

दो चरण का प्रवास

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

हम अनुप्रयोग परिनियोजन को कॉन्फ़िगर करने के लिए समान संरचना बनाए रखते हैं, लेकिन DailymotionRelease नामक एक ही ऑब्जेक्ट में।

 apiVersion: "v1" kind: "DailymotionRelease" metadata: name: "app1.ns1" environment: "dev" branch: "mybranch" spec: slack_channel: "#admin" chart_name: "app1" scaling: - context: "dev-us-central1-0" replicas: - name: "hermes" count: 2 - context: "dev-europe-west1-0" replicas: - name: "app1-deploy" count: 2 secrets: - secret_id: "app1" contexts: - name: "default" vaultPath: "/kv/dev/ns1/app1/test" vaultKey: "password" - name: "dev-europe-west1-0" vaultPath: "/kv/dev/ns1/app1/test" vaultKey: "password"

1 प्रति आवेदन (सामान्यीकृत चार्ट के बिना)।
गिट एप्लिकेशन रिपॉजिटरी में चार्ट।

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

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

हेल्म के साथ कई कुबेरनेट समूहों पर अनुप्रयोगों को तैनात करना