🥇 हेल्मको साथ धेरै Kubernetes क्लस्टरहरूमा अनुप्रयोगहरू प्रयोग गर्दै

कसरी डेलीमोशनले कुबर्नेट्स प्रयोग गर्दछ: एप्लिकेसन डिप्लोयमेन्ट

हामीले डेलीमोशनमा 3 वर्ष पहिले उत्पादनमा Kubernetes प्रयोग गर्न थाल्यौं। तर धेरै क्लस्टरहरूमा एप्लिकेसनहरू डिप्लोइ गर्नु रमाइलो छ, त्यसैले विगत केही वर्षहरूमा हामीले हाम्रा उपकरणहरू र कार्यप्रवाहहरू सुधार गर्ने प्रयास गरिरहेका छौं।

कहाँबाट सुरु भयो

यहाँ हामी कभर गर्नेछौं कि हामी कसरी हाम्रा अनुप्रयोगहरू विश्वभरका धेरै Kubernetes क्लस्टरहरूमा तैनात गर्छौं।

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

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

बिन्दुमा पुगौं।

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

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

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

साखा dev विकास क्लस्टरहरूमा परीक्षण गरिने चार्टहरू सिर्जना गर्न प्रयोग गरिन्छ।
जब पुल अनुरोध पेश गरिन्छ मास्टर, तिनीहरू स्टेजिङमा जाँच गरिन्छ।
अन्तमा, हामी शाखामा परिवर्तनहरू कमिट गर्न पुल अनुरोध सिर्जना गर्छौं प्रो र तिनीहरूलाई उत्पादनमा लागू गर्नुहोस्।

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

विभिन्न वातावरणमा चार्ट भण्डारहरू

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

यसबाहेक, हाम्रो सानो पाइथन स्क्रिप्टले Kubernetes ओपनएपीआई स्पेसिफिकेशनहरू प्रयोग गरेर Kubernetes वस्तुहरूलाई मान्य गर्दछ। कुबेवल, Chartmusem मा प्रकाशित गर्नु अघि।

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

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

क्लस्टरहरूमा भिन्नताहरू प्रबन्ध गर्नुहोस्

क्लस्टर महासंघ

एक समय थियो जब हामी प्रयोग गर्थे Kubernetes क्लस्टरहरूको महासंघ, जहाँ Kubernetes वस्तुहरू एकल API अन्त्य बिन्दुबाट घोषणा गर्न सकिन्छ। तर समस्याहरू खडा भयो। उदाहरणका लागि, संघको अन्तिम बिन्दुमा केही Kubernetes वस्तुहरू सिर्जना गर्न सकिएन, यसले सङ्घीय वस्तुहरू र व्यक्तिगत क्लस्टरहरूको लागि अन्य वस्तुहरू कायम राख्न गाह्रो बनाउँछ।

समस्या समाधान गर्न, हामीले क्लस्टरहरू स्वतन्त्र रूपमा व्यवस्थापन गर्न थाल्यौं, जसले प्रक्रियालाई धेरै सरल बनायो (हामीले संघको पहिलो संस्करण प्रयोग गर्यौं; दोस्रोमा केही परिवर्तन भएको हुन सक्छ)।

भू-वितरित प्लेटफर्म

हाम्रो प्लेटफर्म हाल 6 क्षेत्रहरूमा वितरण गरिएको छ - 3 स्थानीय रूपमा र 3 क्लाउडमा।

वितरित परिनियोजन

ग्लोबल हेल्म मानहरू

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

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

विश्वव्यापी मूल्यहरू

यी मानहरूले हाम्रा अनुप्रयोगहरूको सन्दर्भलाई परिभाषित गर्न मद्दत गर्दछ र विभिन्न उद्देश्यका लागि प्रयोग गरिन्छ: अनुगमन, ट्रेसिङ, लगिङ, बाह्य कलहरू, स्केलिंग, आदि।

"Cloud": हामीसँग हाइब्रिड Kubernetes प्लेटफर्म छ। उदाहरण को लागी, हाम्रो API लाई GCP क्षेत्रहरु र हाम्रो डेटा केन्द्रहरुमा तैनात गरिएको छ।
"env": गैर-उत्पादन वातावरणका लागि केही मानहरू परिवर्तन हुन सक्छन्। उदाहरणका लागि, स्रोत परिभाषाहरू र स्वत: स्केलिङ कन्फिगरेसनहरू।
"क्षेत्र": यो जानकारीले क्लस्टरको स्थान निर्धारण गर्न मद्दत गर्दछ र बाह्य सेवाहरूको लागि नजिकैको अन्त्य बिन्दुहरू निर्धारण गर्न प्रयोग गर्न सकिन्छ।
"clusterName": यदि र जब हामी व्यक्तिगत क्लस्टरको लागि मान परिभाषित गर्न चाहन्छौं।

यहाँ एक विशिष्ट उदाहरण हो:

{{/* 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 -}}

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

Kubernetes 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

सेवा परिभाषा

यो हाम्रो परिनियोजन कार्यप्रवाह परिभाषित गर्ने सबै चरणहरूको रूपरेखा हो। अन्तिम चरणले एप्लिकेसनलाई एकै साथ धेरै कार्यकर्ता क्लस्टरहरूमा प्रयोग गर्दछ।

जेनकिन्स तैनाती चरणहरू

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

सुरक्षाको सन्दर्भमा, हामी विभिन्न ठाउँहरूबाट सबै गोप्य कुराहरू ट्र्याक गर्छौं र तिनीहरूलाई एक अद्वितीय भल्टमा भण्डारण गर्छौं वाल्ट पेरिसमा।

हाम्रो डिप्लोयमेन्ट उपकरणले भल्टबाट गोप्य मानहरू निकाल्छ र, जब डिप्लोइमेन्ट समय आउँछ, तिनीहरूलाई हेल्ममा घुसाउनुहोस्।

यो गर्नको लागि, हामीले Vault मा गोप्य र हाम्रा अनुप्रयोगहरूलाई चाहिने गोप्यहरू बीचको म्यापिङ परिभाषित गर्यौं:

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"

हामीले Vault मा गोप्य कुराहरू रेकर्ड गर्दा पालना गर्नुपर्ने सामान्य नियमहरू परिभाषित गरेका छौं।
यदि गोप्य लागू हुन्छ एक विशिष्ट सन्दर्भ वा क्लस्टरमा, तपाईंले एक विशेष प्रविष्टि थप्न आवश्यक छ। (यहाँ सन्दर्भ क्लस्टर १ को गोप्य स्ट्याक-एप१-पासवर्डको आफ्नै मान छ)।
अन्यथा मान प्रयोग गरिन्छ पूर्वनिर्धारित द्वारा.
यस सूचीमा प्रत्येक वस्तुको लागि Kubernetes गोप्य कुञ्जी-मान जोडी सम्मिलित गरिएको छ। त्यसैले, हाम्रो चार्ट मा गोप्य टेम्प्लेट धेरै सरल छ।

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

समस्या र सीमाहरू

धेरै भण्डारहरूसँग काम गर्दै

अब हामी चार्ट र अनुप्रयोगहरूको विकासलाई अलग गर्छौं। यसको मतलब यो हो कि विकासकर्ताहरूले दुई git भण्डारहरूमा काम गर्नुपर्छ: एउटा अनुप्रयोगको लागि, र अर्को Kubernetes मा यसको तैनाती परिभाषित गर्नको लागि। 2 git रिपोजिटरीहरू 2 कार्यप्रवाहहरू हुन्, र यो एक नौसिखियाको लागि भ्रमित हुन सजिलो छ।

सामान्यीकृत चार्टहरू प्रबन्ध गर्नु एक झन्झट हो

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

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

धेरै कन्फिगरेसन फाइलहरू अद्यावधिक गर्दै

जब एक विकासकर्ताले नयाँ अनुप्रयोग थप्छ, उसले धेरै फाइलहरू परिवर्तन गर्नुपर्नेछ: अनुप्रयोग घोषणा, गोप्य सूची, अनुप्रयोगलाई निर्भरताको रूपमा थप्दै यदि यो सामान्य चार्टमा समावेश छ भने।

जेनकिन्स अनुमतिहरू भल्टमा धेरै विस्तारित छन्

अब हामीसँग एउटा छ AppRole, जसले भल्टबाट सबै रहस्यहरू पढ्छ।

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

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

हामी GitOps तिर लागिरहेका छौं

हाम्रो लक्ष्य

हामी चार्टलाई यो डिप्लोय गरिएको अनुप्रयोगको भण्डारमा फर्काउन चाहन्छौं।

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

त्यहाँ धेरै फाइदाहरू छन्:

धेरै स्पष्ट विकासकर्ताको लागि। स्थानीय चार्टमा परिवर्तनहरू कसरी लागू गर्ने भनेर सिक्न सजिलो छ।
सेवा परिनियोजन परिभाषा निर्दिष्ट गर्न सकिन्छ कोड जस्तै ठाउँ सेवा।
सामान्यीकृत चार्टहरू हटाउने प्रबन्ध। सेवाको आफ्नै हेल्म रिलीज हुनेछ। यसले तपाईंलाई अनुप्रयोग जीवनचक्र (रोलब्याक, स्तरवृद्धि) लाई सबैभन्दा सानो स्तरमा व्यवस्थापन गर्न अनुमति दिनेछ, ताकि अन्य सेवाहरूलाई असर नहोस्।
Git को फाइदाहरू चार्ट व्यवस्थापनका लागि: परिवर्तनहरू पूर्ववत गर्नुहोस्, अडिट लग, इत्यादि। यदि तपाईंलाई चार्टमा परिवर्तनलाई पूर्ववत गर्न आवश्यक छ भने, तपाईंले git प्रयोग गरेर यो गर्न सक्नुहुन्छ। डिप्लोइमेन्ट स्वतः सुरु हुन्छ।
तपाईले आफ्नो विकास कार्यप्रवाह सुधार गर्ने उपकरणहरू जस्तै विचार गर्न सक्नुहुन्छ स्काफोल्ड, जसको साथ विकासकर्ताहरूले उत्पादनको नजिकको सन्दर्भमा परिवर्तनहरू परीक्षण गर्न सक्छन्।

दुई-चरण माइग्रेसन

हाम्रा विकासकर्ताहरूले यो कार्यप्रवाह २ वर्षदेखि प्रयोग गर्दै आएका छन्, त्यसैले हामी माइग्रेसनलाई सकेसम्म पीडारहित होस् भन्ने चाहन्छौँ। त्यसकारण, हामीले लक्ष्यको बाटोमा एक मध्यवर्ती चरण थप्ने निर्णय गर्यौं।
पहिलो चरण सरल छ:

हामी एप्लिकेसन डिप्लोयमेन्ट सेटअप गर्नको लागि समान संरचना राख्छौं, तर डेलीमोशन रिलिज भनिने एकल वस्तुमा।

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"

प्रति अनुप्रयोग १ रिलीज (सामान्यीकृत चार्टहरू बिना)।
अनुप्रयोगको git भण्डारमा चार्टहरू।

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

यहाँ हामीले विगतका वर्षहरूमा एप्लिकेसन डिप्लोयमेन्ट कार्यप्रवाहमा हाम्रो प्रगति वर्णन गर्ने प्रयास गरेका छौं, जसले GitOps दृष्टिकोणको बारेमा विचारहरू निम्त्यायो। हामी अझै लक्ष्यमा पुगेका छैनौं र नतिजाहरूमा रिपोर्ट गर्नेछौं, तर अब हामी विश्वस्त छौं कि हामीले सबै कुरालाई सरल बनाउने र विकासकर्ताहरूको बानीको नजिक ल्याउने निर्णय गर्दा हामीले सही काम गर्यौं।

स्रोत: www.habr.com

हेल्मको साथ धेरै Kubernetes क्लस्टरहरूमा अनुप्रयोगहरू प्रयोग गर्नुहोस्