🥇 हेल्मसह एकाधिक कुबर्नेट्स क्लस्टरवर अनुप्रयोग तैनात करणे

डेलीमोशन कुबर्नेट्स कसे वापरते: ऍप्लिकेशन डिप्लॉयमेंट

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

कुठून सुरुवात झाली

जगभरातील अनेक Kubernetes क्लस्टर्समध्ये आम्ही आमचे अॅप्लिकेशन्स कसे उपयोजित करतो ते येथे आम्ही कव्हर करू.

एकाच वेळी अनेक कुबर्नेट्स ऑब्जेक्ट्स तैनात करण्यासाठी, आम्ही वापरतो प्रमुखपदी, आणि आमचे सर्व चार्ट एका गिट रेपॉजिटरीमध्ये संग्रहित केले जातात. अनेक सेवांमधून संपूर्ण ऍप्लिकेशन स्टॅक तैनात करण्यासाठी, आम्ही तथाकथित सारांश चार्ट वापरतो. मूलत:, हा एक चार्ट आहे जो अवलंबित्व घोषित करतो आणि तुम्हाला API आणि त्याच्या सेवा एका आदेशाने सुरू करण्याची परवानगी देतो.

आम्ही तपासण्यासाठी, चार्ट तयार करण्यासाठी, रहस्ये जोडण्यासाठी आणि अनुप्रयोग तैनात करण्यासाठी हेल्मच्या शीर्षस्थानी एक लहान पायथन स्क्रिप्ट देखील लिहिली आहे. ही सर्व कार्ये केंद्रीय CI प्लॅटफॉर्मवर डॉकर इमेज वापरून केली जातात.

चला मुद्द्याकडे जाऊया.

नोंद. आपण हे वाचताच, हेल्म 3 साठी प्रथम रिलीझ उमेदवार आधीच घोषित केले गेले आहे. भूतकाळात आम्हाला आलेल्या काही समस्यांचे निराकरण करण्यासाठी मुख्य आवृत्तीमध्ये अनेक सुधारणा आहेत.

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

आम्ही ऍप्लिकेशन्ससाठी ब्रँचिंगचा वापर करतो आणि आम्ही चार्टवर समान दृष्टीकोन लागू करण्याचा निर्णय घेतला.

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

प्रत्येक पर्यावरणाचे स्वतःचे खाजगी भांडार असते जे आमचे चार्ट संग्रहित करते आणि आम्ही वापरतो चार्टम्युझियम अतिशय उपयुक्त API सह. अशा प्रकारे आम्ही उत्पादनामध्ये वापरण्यापूर्वी वातावरण आणि चार्ट्सची वास्तविक-जागतिक चाचणी दरम्यान कठोर अलगाव सुनिश्चित करतो.

वेगवेगळ्या वातावरणात चार्ट रेपॉजिटरीज

हे लक्षात घेण्यासारखे आहे की जेव्हा डेव्हलपर देव शाखा पुश करतात, तेव्हा त्यांच्या चार्टची आवृत्ती स्वयंचलितपणे देव चार्टम्युझियममध्ये ढकलली जाते. अशाप्रकारे, सर्व डेव्हलपर समान डेव्हल रिपॉजिटरी वापरतात आणि तुम्हाला तुमची चार्टची आवृत्ती काळजीपूर्वक निर्दिष्ट करणे आवश्यक आहे जेणेकरुन चुकून इतर कोणाचे बदल वापरू नयेत.

शिवाय, आमची छोटी पायथन स्क्रिप्ट कुबर्नेट्स ओपनएपीआय स्पेसिफिकेशन्सच्या विरूद्ध कुबर्नेट्स ऑब्जेक्ट्सचे प्रमाणीकरण करते. कुबेवल, चार्टम्युझमवर प्रकाशित करण्यापूर्वी.

चार्ट डेव्हलपमेंट वर्कफ्लोचे सामान्य वर्णन

विनिर्देशानुसार पाइपलाइन कार्ये सेट करणे gazr.io गुणवत्ता नियंत्रणासाठी (लिंट, युनिट-चाचणी).
पायथन टूल्ससह डॉकर प्रतिमा पुश करणे जे आमचे अनुप्रयोग तैनात करतात.
शाखेच्या नावाने वातावरण सेट करणे.
Kubeval वापरून Kubernetes yaml फायली प्रमाणित करत आहे.
चार्ट आणि त्याच्या मूळ चार्टची आवृत्ती स्वयंचलितपणे वाढवा (चार्ट बदलल्या जात असलेल्या चार्टवर अवलंबून असेल).
चार्टम्युझियमला त्याच्या वातावरणाशी जुळणारा चार्ट सबमिट करणे

क्लस्टर्समधील फरक व्यवस्थापित करणे

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

एक काळ असा होता की आपण वापरत होतो फेडरेशन ऑफ कुबर्नेट्स क्लस्टर्स, जिथे कुबर्नेट्स ऑब्जेक्ट्स एकाच API एंडपॉईंटवरून घोषित केले जाऊ शकतात. पण समस्या निर्माण झाल्या. उदाहरणार्थ, फेडरेशन एंडपॉईंटमध्ये काही कुबर्नेट्स ऑब्जेक्ट्स तयार केल्या जाऊ शकल्या नाहीत, ज्यामुळे वैयक्तिक क्लस्टरसाठी फेडरेशन ऑब्जेक्ट्स आणि इतर ऑब्जेक्ट्स राखणे कठीण होते.

समस्येचे निराकरण करण्यासाठी, आम्ही क्लस्टर्स स्वतंत्रपणे व्यवस्थापित करण्यास सुरुवात केली, ज्यामुळे प्रक्रिया मोठ्या प्रमाणात सुलभ झाली (आम्ही फेडरेशनची पहिली आवृत्ती वापरली; दुसऱ्यामध्ये काहीतरी बदलले असेल).

जिओ-वितरित प्लॅटफॉर्म

आमचे प्लॅटफॉर्म सध्या 6 क्षेत्रांमध्ये वितरीत केले आहे - 3 स्थानिक आणि 3 क्लाउडमध्ये.

वितरित तैनात

जागतिक हेल्म मूल्ये

4 जागतिक हेल्म मूल्ये तुम्हाला क्लस्टरमधील फरक ओळखण्याची परवानगी देतात. आमच्या सर्व चार्ट्समध्ये डीफॉल्ट किमान मूल्ये आहेत.

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

जागतिक मूल्ये

ही मूल्ये आमच्या अनुप्रयोगांसाठी संदर्भ परिभाषित करण्यात मदत करतात आणि विविध उद्देशांसाठी वापरली जातात: निरीक्षण, ट्रेसिंग, लॉगिंग, बाह्य कॉल करणे, स्केलिंग इ.

"क्लाउड": आमच्याकडे हायब्रीड कुबर्नेट्स प्लॅटफॉर्म आहे. उदाहरणार्थ, आमचे 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 -}}

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

कुबर्नेट्स 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 मध्‍ये गुपिते रेकॉर्ड करताना पाळण्‍याचे सर्वसाधारण नियम आम्‍ही परिभाषित केले आहेत.
जर गुपित लागू होते विशिष्ट संदर्भ किंवा क्लस्टरला, तुम्हाला एक विशिष्ट एंट्री जोडणे आवश्यक आहे. (येथे secret stack-app1-password साठी संदर्भ क्लस्टर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 git रेपॉजिटरीज म्हणजे 2 वर्कफ्लो, आणि नवशिक्यासाठी गोंधळात पडणे सोपे आहे.

सामान्यीकृत चार्ट व्यवस्थापित करणे एक त्रासदायक आहे

आम्ही आधीच म्हटल्याप्रमाणे, जेनेरिक चार्ट अवलंबित्व ओळखण्यासाठी आणि एकाधिक अनुप्रयोग त्वरित उपयोजित करण्यासाठी खूप उपयुक्त आहेत. पण आम्ही वापरतो --reuse-valuesप्रत्येक वेळी आम्ही या सामान्यीकृत चार्टचा भाग असलेला अनुप्रयोग उपयोजित करतो तेव्हा सर्व मूल्ये पार करणे टाळण्यासाठी.

सतत वितरण कार्यप्रवाहात, आमच्याकडे फक्त दोन मूल्ये आहेत जी नियमितपणे बदलतात: प्रतिकृतींची संख्या आणि प्रतिमा टॅग (आवृत्ती). इतर, अधिक स्थिर मूल्ये व्यक्तिचलितपणे बदलली जातात आणि हे खूप कठीण आहे. शिवाय, एक सामान्यीकृत तक्‍ता लावण्‍यामध्‍ये एक चूक गंभीर अपयशास कारणीभूत ठरू शकते, जसे की आम्‍ही आमच्या स्‍वत:च्‍या अनुभवातून पाहिले आहे.

एकाधिक कॉन्फिगरेशन फाइल्स अद्यतनित करत आहे

जेव्हा एखादा विकसक नवीन अनुप्रयोग जोडतो तेव्हा त्याला अनेक फायली बदलाव्या लागतात: अनुप्रयोग घोषणा, गुपितांची यादी, जर सामान्यीकृत चार्टमध्ये अनुप्रयोग समाविष्ट केला असेल तर अवलंबित्व म्हणून जोडणे.

व्हॉल्टमध्ये जेनकिन्स परवानग्या खूप वाढवल्या आहेत

आता आमच्याकडे एक आहे AppRole, जे व्हॉल्टमधील सर्व रहस्ये वाचते.

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

रोलबॅक करण्यासाठी, तुम्हाला अनेक क्लस्टर्सवर कमांड रन करणे आवश्यक आहे आणि हे त्रुटींनी भरलेले आहे. योग्य आवृत्ती आयडी निर्दिष्ट केला आहे याची खात्री करण्यासाठी आम्ही हे ऑपरेशन व्यक्तिचलितपणे करतो.

आम्ही GitOps कडे वाटचाल करत आहोत

आमचे ध्येय

आम्ही तो उपयोजित केलेल्या अनुप्रयोगाच्या भांडारात चार्ट परत करू इच्छितो.

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

अनेक फायदे आहेत:

खूप अधिक स्पष्ट विकसकासाठी. स्थानिक चार्टमध्ये बदल कसे लागू करायचे हे शिकणे सोपे आहे.
सेवा उपयोजन व्याख्या निर्दिष्ट केली जाऊ शकते कोड सारखीच जागा सेवा
सामान्यीकृत चार्ट काढणे व्यवस्थापित करणे. सेवेचे स्वतःचे हेल्म रिलीझ असेल. हे तुम्हाला ऍप्लिकेशन लाइफसायकल (रोलबॅक, अपग्रेड) सर्वात लहान स्तरावर व्यवस्थापित करण्यास अनुमती देईल, जेणेकरून इतर सेवांवर परिणाम होणार नाही.
गिटचे फायदे चार्ट मॅनेजमेंटसाठी: बदल पूर्ववत करा, ऑडिट लॉग इ. जर तुम्हाला चार्टमध्ये बदल पूर्ववत करायचा असेल, तर तुम्ही हे 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 प्रकाशन (सामान्यीकृत चार्टशिवाय).
ऍप्लिकेशनच्या गिट रेपॉजिटरीमधील चार्ट.

आम्ही सर्व विकासकांशी बोललो आहोत, त्यामुळे स्थलांतर प्रक्रिया आधीच सुरू झाली आहे. पहिला टप्पा अजूनही सीआय प्लॅटफॉर्म वापरून नियंत्रित केला जातो. मी फेज दोन बद्दल लवकरच आणखी एक पोस्ट लिहीन: आम्ही GitOps वर्कफ्लोमध्ये कसे गेलो प्रवाह. मी तुम्हाला सांगेन की आम्ही सर्वकाही कसे सेट केले आणि आम्हाला कोणत्या अडचणी आल्या (एकाधिक भांडार, रहस्ये इ.). बातम्यांचे अनुसरण करा.

येथे आम्ही मागील वर्षांमध्ये ऍप्लिकेशन डिप्लॉयमेंट वर्कफ्लोमधील आमच्या प्रगतीचे वर्णन करण्याचा प्रयत्न केला आहे, ज्यामुळे GitOps दृष्टिकोनाबद्दल विचार आले. आम्ही अद्याप उद्दिष्टापर्यंत पोहोचलो नाही आणि परिणामांबद्दल अहवाल देऊ, परंतु आता आम्हाला खात्री आहे की आम्ही सर्वकाही सोपे करण्याचा आणि विकासकांच्या सवयींच्या जवळ आणण्याचा निर्णय घेतला तेव्हा आम्ही योग्य गोष्ट केली.

स्त्रोत: www.habr.com

हेल्मसह एकाधिक कुबर्नेट्स क्लस्टरवर अनुप्रयोग तैनात करा