🥇हेल्म | के साथ कई कुबेरनेट समूहों में एप्लिकेशन तैनात करना प्रोहोस्टर

डेलीमोशन कुबेरनेट्स का उपयोग कैसे करता है: एप्लिकेशन परिनियोजन

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

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

यहां हम बताएंगे कि हम दुनिया भर के कई कुबेरनेट समूहों में अपने एप्लिकेशन कैसे तैनात करते हैं।

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

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

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

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

चार्ट विकास कार्यप्रवाह

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

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

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

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

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

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

चार्ट विकास कार्यप्रवाह का सामान्य विवरण

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

समूहों में अंतर का प्रबंधन करना

क्लस्टरों का संघ

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

समस्या को हल करने के लिए, हमने समूहों को स्वतंत्र रूप से प्रबंधित करना शुरू कर दिया, जिससे प्रक्रिया बहुत सरल हो गई (हमने फेडरेशन के पहले संस्करण का उपयोग किया; दूसरे में कुछ बदल सकता है)।

भू-वितरित मंच

हमारा प्लेटफ़ॉर्म वर्तमान में 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 को अव्यवस्थित करने से बचने के लिए इस तर्क को एक सहायक टेम्पलेट में परिभाषित किया गया है।

आवेदन घोषणा

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

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]: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 की ओर बढ़ रहे हैं

हमारा लक्ष्य

हम चार्ट को उसके द्वारा तैनात एप्लिकेशन के रिपॉजिटरी में वापस करना चाहते हैं।

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

इसके कई फायदे हैं:

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

दो-चरणीय प्रवासन

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

हम एप्लिकेशन परिनियोजन स्थापित करने के लिए एक समान संरचना रखते हैं, लेकिन डेलीमोशनरिलीज़ नामक एक ही ऑब्जेक्ट में।

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 रिलीज़ (सामान्यीकृत चार्ट के बिना)।
एप्लिकेशन के git रिपॉजिटरी में चार्ट।

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

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

स्रोत: www.habr.com

हेल्म के साथ एकाधिक कुबेरनेट क्लस्टर में एप्लिकेशन परिनियोजित करना