ഹെൽമിനൊപ്പം ഒന്നിലധികം കുബർനെറ്റസ് ക്ലസ്റ്ററുകളിലുടനീളം ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുക

Dailymotion എങ്ങനെയാണ് Kubernetes ഉപയോഗിക്കുന്നത്: ആപ്ലിക്കേഷൻ വിന്യാസം

Dailymotion-ലെ ഞങ്ങൾ 3 വർഷം മുമ്പ് നിർമ്മാണത്തിൽ Kubernetes ഉപയോഗിക്കാൻ തുടങ്ങി. എന്നാൽ ഒന്നിലധികം ക്ലസ്റ്ററുകളിലുടനീളം ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നത് രസകരമാണ്, അതിനാൽ കഴിഞ്ഞ കുറച്ച് വർഷങ്ങളായി ഞങ്ങൾ ഞങ്ങളുടെ ടൂളുകളും വർക്ക്ഫ്ലോകളും മെച്ചപ്പെടുത്താൻ ശ്രമിക്കുകയാണ്.

എവിടെ നിന്നാണ് തുടങ്ങിയത്

ലോകമെമ്പാടുമുള്ള ഒന്നിലധികം Kubernetes ക്ലസ്റ്ററുകളിലുടനീളം ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ എങ്ങനെ വിന്യസിക്കുന്നുവെന്ന് ഞങ്ങൾ ഇവിടെ വിവരിക്കും.

ഒന്നിലധികം Kubernetes ഒബ്‌ജക്‌റ്റുകൾ ഒരേസമയം വിന്യസിക്കാൻ, ഞങ്ങൾ ഉപയോഗിക്കുന്നു ഹെൽം, ഞങ്ങളുടെ എല്ലാ ചാർട്ടുകളും ഒരു ജിറ്റ് ശേഖരത്തിൽ സംഭരിച്ചിരിക്കുന്നു. നിരവധി സേവനങ്ങളിൽ നിന്ന് ഒരു പൂർണ്ണ ആപ്ലിക്കേഷൻ സ്റ്റാക്ക് വിന്യസിക്കാൻ, ഞങ്ങൾ സംഗ്രഹ ചാർട്ട് എന്ന് വിളിക്കുന്നു. അടിസ്ഥാനപരമായി, ഇത് ഡിപൻഡൻസികൾ പ്രഖ്യാപിക്കുകയും ഒരു കമാൻഡ് ഉപയോഗിച്ച് API യും അതിന്റെ സേവനങ്ങളും ആരംഭിക്കാൻ നിങ്ങളെ അനുവദിക്കുകയും ചെയ്യുന്ന ഒരു ചാർട്ടാണ്.

പരിശോധനകൾ നടത്താനും ചാർട്ടുകൾ സൃഷ്ടിക്കാനും രഹസ്യങ്ങൾ ചേർക്കാനും ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കാനും ഞങ്ങൾ ഹെൽമിന് മുകളിൽ ഒരു ചെറിയ പൈത്തൺ സ്ക്രിപ്റ്റും എഴുതി. ഈ ജോലികളെല്ലാം ഒരു ഡോക്കർ ഇമേജ് ഉപയോഗിച്ച് ഒരു സെൻട്രൽ CI പ്ലാറ്റ്‌ഫോമിൽ നിർവഹിക്കുന്നു.

നമുക്ക് കാര്യത്തിലേക്ക് വരാം.

കുറിപ്പ്. നിങ്ങൾ ഇത് വായിക്കുമ്പോൾ, ഹെൽം 3-ന്റെ ആദ്യ റിലീസ് കാൻഡിഡേറ്റ് ഇതിനകം പ്രഖ്യാപിച്ചു. മുൻകാലങ്ങളിൽ ഞങ്ങൾ നേരിട്ട ചില പ്രശ്‌നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള ഒരു കൂട്ടം മെച്ചപ്പെടുത്തലുകൾ പ്രധാന പതിപ്പിൽ അടങ്ങിയിരിക്കുന്നു.

ചാർട്ട് വികസന വർക്ക്ഫ്ലോ

ആപ്ലിക്കേഷനുകൾക്കായി ഞങ്ങൾ ബ്രാഞ്ചിംഗ് ഉപയോഗിക്കുന്നു, ചാർട്ടുകളിലും ഇതേ സമീപനം പ്രയോഗിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

• ശാഖ ദേവ് വികസന ക്ലസ്റ്ററുകളിൽ പരീക്ഷിക്കപ്പെടുന്ന ചാർട്ടുകൾ സൃഷ്ടിക്കാൻ ഉപയോഗിക്കുന്നു.
• ഒരു പുൾ അഭ്യർത്ഥന സമർപ്പിക്കുമ്പോൾ യജമാനന്, അവ സ്റ്റേജിംഗിൽ പരിശോധിക്കുന്നു.
• അവസാനമായി, ബ്രാഞ്ചിൽ മാറ്റങ്ങൾ വരുത്താൻ ഞങ്ങൾ ഒരു പുൾ അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു ഉത്പന്നം അവ ഉൽപാദനത്തിൽ പ്രയോഗിക്കുക.

ഓരോ പരിതസ്ഥിതിക്കും അതിന്റേതായ സ്വകാര്യ ശേഖരം ഉണ്ട്, അത് ഞങ്ങളുടെ ചാർട്ടുകൾ സംഭരിക്കുന്നു, ഞങ്ങൾ ഉപയോഗിക്കുന്നു ചാർട്ട്മ്യൂസിയം വളരെ ഉപയോഗപ്രദമായ API-കൾക്കൊപ്പം. ഈ രീതിയിൽ, ഉൽപ്പാദനത്തിൽ ഉപയോഗിക്കുന്നതിന് മുമ്പ് ചാർട്ടുകളുടെ പരിസ്ഥിതിയും യഥാർത്ഥ ലോക പരിശോധനയും തമ്മിൽ കർശനമായ ഒറ്റപ്പെടൽ ഞങ്ങൾ ഉറപ്പാക്കുന്നു.

വ്യത്യസ്ത പരിതസ്ഥിതികളിൽ ചാർട്ട് ശേഖരങ്ങൾ

ഡവലപ്പർമാർ ഒരു ദേവ് ബ്രാഞ്ച് പുഷ് ചെയ്യുമ്പോൾ, അവരുടെ ചാർട്ടിന്റെ ഒരു പതിപ്പ് സ്വയമേവ ദേവ ചാർട്ട്മ്യൂസിയത്തിലേക്ക് തള്ളപ്പെടും എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. അതിനാൽ, എല്ലാ ഡെവലപ്പർമാരും ഒരേ ഡെവലപ്പർ റിപ്പോസിറ്ററിയാണ് ഉപയോഗിക്കുന്നത്, മറ്റൊരാളുടെ മാറ്റങ്ങൾ ആകസ്മികമായി ഉപയോഗിക്കാതിരിക്കാൻ നിങ്ങളുടെ ചാർട്ടിന്റെ പതിപ്പ് നിങ്ങൾ ശ്രദ്ധാപൂർവ്വം വ്യക്തമാക്കേണ്ടതുണ്ട്.

മാത്രമല്ല, ഞങ്ങളുടെ ചെറിയ പൈത്തൺ സ്ക്രിപ്റ്റ് ഉപയോഗിച്ച് കുബർനെറ്റ്സ് ഓപ്പൺഎപിഐ സ്പെസിഫിക്കേഷനുകൾക്കെതിരെ കുബർനെറ്റസ് ഒബ്ജക്റ്റുകളെ സാധൂകരിക്കുന്നു. കുബേവൽ, ചാർട്ട്‌മുസെമിൽ അവ പ്രസിദ്ധീകരിക്കുന്നതിന് മുമ്പ്.

ചാർട്ട് വികസന വർക്ക്ഫ്ലോയുടെ പൊതുവായ വിവരണം

1. സ്പെസിഫിക്കേഷൻ അനുസരിച്ച് പൈപ്പ്ലൈൻ ജോലികൾ സജ്ജീകരിക്കുന്നു gazr.io ഗുണനിലവാര നിയന്ത്രണത്തിനായി (ലിന്റ്, യൂണിറ്റ്-ടെസ്റ്റ്).
2. ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്ന പൈത്തൺ ടൂളുകൾ ഉപയോഗിച്ച് ഒരു ഡോക്കർ ഇമേജ് പുഷ് ചെയ്യുന്നു.
3. ശാഖയുടെ പേരിൽ പരിസ്ഥിതി സജ്ജീകരിക്കുന്നു.
4. Kubeval ഉപയോഗിച്ച് Kubernetes yaml ഫയലുകൾ സാധൂകരിക്കുന്നു.
5. ഒരു ചാർട്ടിന്റെ പതിപ്പും അതിന്റെ പാരന്റ് ചാർട്ടുകളും സ്വയമേവ വർദ്ധിപ്പിക്കുക (മാറ്റപ്പെടുന്ന ചാർട്ടിനെ ആശ്രയിച്ചിരിക്കുന്ന ചാർട്ടുകൾ).
6. പരിസ്ഥിതിയുമായി പൊരുത്തപ്പെടുന്ന ഒരു ചാർട്ട്മ്യൂസിയത്തിലേക്ക് ഒരു ചാർട്ട് സമർപ്പിക്കുന്നു

ക്ലസ്റ്ററുകളിലുടനീളം വ്യത്യാസങ്ങൾ കൈകാര്യം ചെയ്യുക

ഫെഡറേഷൻ ഓഫ് ക്ലസ്റ്ററുകൾ

നമ്മൾ ഉപയോഗിച്ചിരുന്ന ഒരു കാലമുണ്ടായിരുന്നു ഫെഡറേഷൻ ഓഫ് കുബർനെറ്റസ് ക്ലസ്റ്ററുകൾ, കുബെർനെറ്റസ് ഒബ്‌ജക്‌റ്റുകൾ ഒരൊറ്റ API എൻഡ്‌പോയിന്റിൽ നിന്ന് പ്രഖ്യാപിക്കാൻ കഴിയുന്നിടത്ത്. എന്നാൽ പ്രശ്നങ്ങൾ ഉയർന്നു. ഉദാഹരണത്തിന്, ചില കുബർനെറ്റസ് ഒബ്‌ജക്റ്റുകൾ ഫെഡറേഷൻ എൻഡ്‌പോയിന്റിൽ സൃഷ്‌ടിക്കാൻ കഴിഞ്ഞില്ല, ഇത് വ്യക്തിഗത ക്ലസ്റ്ററുകൾക്കായി ഫെഡറേറ്റഡ് ഒബ്‌ജക്റ്റുകളും മറ്റ് ഒബ്‌ജക്റ്റുകളും പരിപാലിക്കുന്നത് ബുദ്ധിമുട്ടാക്കുന്നു.

പ്രശ്നം പരിഹരിക്കുന്നതിന്, ഞങ്ങൾ ക്ലസ്റ്ററുകൾ സ്വതന്ത്രമായി കൈകാര്യം ചെയ്യാൻ തുടങ്ങി, ഇത് പ്രക്രിയയെ വളരെ ലളിതമാക്കി (ഞങ്ങൾ ഫെഡറേഷന്റെ ആദ്യ പതിപ്പ് ഉപയോഗിച്ചു; രണ്ടാമത്തേതിൽ എന്തെങ്കിലും മാറിയിരിക്കാം).

ജിയോ ഡിസ്ട്രിബ്യൂട്ടഡ് പ്ലാറ്റ്ഫോം

ഞങ്ങളുടെ പ്ലാറ്റ്ഫോം നിലവിൽ 6 പ്രദേശങ്ങളിൽ വിതരണം ചെയ്യുന്നു - 3 പ്രാദേശികമായും 3 ക്ലൗഡിലും.

വിതരണം ചെയ്ത വിന്യാസം

ആഗോള ഹെൽമിന്റെ മൂല്യങ്ങൾ

4 ഗ്ലോബൽ ഹെൽം മൂല്യങ്ങൾ ക്ലസ്റ്ററുകൾ തമ്മിലുള്ള വ്യത്യാസങ്ങൾ തിരിച്ചറിയാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ഞങ്ങളുടെ എല്ലാ ചാർട്ടുകൾക്കും ഡിഫോൾട്ട് മിനിമം മൂല്യങ്ങളുണ്ട്.

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

ആഗോള മൂല്യങ്ങൾ

ഈ മൂല്യങ്ങൾ ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകളുടെ സന്ദർഭം നിർവചിക്കാൻ സഹായിക്കുന്നു കൂടാതെ വിവിധ ആവശ്യങ്ങൾക്കായി ഉപയോഗിക്കുന്നു: നിരീക്ഷണം, കണ്ടെത്തൽ, ലോഗിംഗ്, ബാഹ്യ കോളുകൾ, സ്കെയിലിംഗ് മുതലായവ.

• "Cloud": ഞങ്ങൾക്ക് ഒരു ഹൈബ്രിഡ് കുബർനെറ്റസ് പ്ലാറ്റ്‌ഫോം ഉണ്ട്. ഉദാഹരണത്തിന്, ഞങ്ങളുടെ API GCP സോണുകളിലും ഞങ്ങളുടെ ഡാറ്റാ സെന്ററുകളിലും വിന്യസിച്ചിരിക്കുന്നു.
• "env": ഉൽപ്പാദനേതര പരിതസ്ഥിതികൾക്കായി ചില മൂല്യങ്ങൾ മാറിയേക്കാം. ഉദാഹരണത്തിന്, റിസോഴ്സ് ഡെഫനിഷനുകളും ഓട്ടോസ്കേലിംഗ് കോൺഫിഗറേഷനുകളും.
• "region": ഈ വിവരങ്ങൾ ക്ലസ്റ്ററിന്റെ സ്ഥാനം നിർണ്ണയിക്കാൻ സഹായിക്കുന്നു, കൂടാതെ ബാഹ്യ സേവനങ്ങൾക്കായി സമീപത്തുള്ള എൻഡ്‌പോയിന്റുകൾ നിർണ്ണയിക്കാൻ ഇത് ഉപയോഗിക്കാം.
• "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

സേവന നിർവ്വചനം

ഞങ്ങളുടെ വിന്യാസ വർക്ക്ഫ്ലോ നിർവചിക്കുന്ന എല്ലാ ഘട്ടങ്ങളുടെയും ഒരു രൂപരേഖയാണിത്. അവസാന ഘട്ടം ഒരേസമയം ഒന്നിലധികം തൊഴിലാളി ക്ലസ്റ്ററുകളിലേക്ക് ആപ്ലിക്കേഷൻ വിന്യസിക്കുന്നു.

ജെങ്കിൻസ് വിന്യാസ നടപടികൾ

രഹസ്യങ്ങളുടെ കാര്യമോ?

സുരക്ഷയെ സംബന്ധിച്ച്, വിവിധ സ്ഥലങ്ങളിൽ നിന്നുള്ള എല്ലാ രഹസ്യങ്ങളും ഞങ്ങൾ ട്രാക്ക് ചെയ്യുകയും അവയെ ഒരു അദ്വിതീയ നിലവറയിൽ സൂക്ഷിക്കുകയും ചെയ്യുന്നു വോൾട്ട് പാരീസിൽ.

ഞങ്ങളുടെ വിന്യാസ ഉപകരണങ്ങൾ വോൾട്ടിൽ നിന്ന് രഹസ്യ മൂല്യങ്ങൾ എക്‌സ്‌ട്രാക്റ്റുചെയ്യുന്നു, വിന്യാസ സമയം വരുമ്പോൾ, അവയെ ഹെൽമിലേക്ക് തിരുകുക.

ഇത് ചെയ്യുന്നതിന്, വോൾട്ടിലെ രഹസ്യങ്ങളും ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾക്ക് ആവശ്യമായ രഹസ്യങ്ങളും തമ്മിലുള്ള മാപ്പിംഗ് ഞങ്ങൾ നിർവ്വചിച്ചു:

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 git റിപ്പോസിറ്ററികൾ അർത്ഥമാക്കുന്നത് 2 വർക്ക്ഫ്ലോകൾ ആണ്, ഒരു പുതിയ വ്യക്തിക്ക് ആശയക്കുഴപ്പത്തിലാകുന്നത് എളുപ്പമാണ്.

സാമാന്യവൽക്കരിച്ച ചാർട്ടുകൾ കൈകാര്യം ചെയ്യുന്നത് ഒരു ബുദ്ധിമുട്ടാണ്

ഞങ്ങൾ ഇതിനകം പറഞ്ഞതുപോലെ, ഡിപൻഡൻസികൾ തിരിച്ചറിയുന്നതിനും ഒന്നിലധികം ആപ്ലിക്കേഷനുകൾ വേഗത്തിൽ വിന്യസിക്കുന്നതിനും ജനറിക് ചാർട്ടുകൾ വളരെ ഉപയോഗപ്രദമാണ്. എന്നാൽ ഞങ്ങൾ ഉപയോഗിക്കുന്നു --reuse-valuesഈ സാമാന്യവൽക്കരിച്ച ചാർട്ടിന്റെ ഭാഗമായ ഒരു ആപ്ലിക്കേഷൻ ഞങ്ങൾ വിന്യസിക്കുമ്പോഴെല്ലാം എല്ലാ മൂല്യങ്ങളും കടന്നുപോകാതിരിക്കാൻ.

തുടർച്ചയായ ഡെലിവറി വർക്ക്ഫ്ലോയിൽ, ഞങ്ങൾക്ക് പതിവായി മാറുന്ന രണ്ട് മൂല്യങ്ങൾ മാത്രമേയുള്ളൂ: പകർപ്പുകളുടെ എണ്ണവും ഇമേജ് ടാഗും (പതിപ്പ്). മറ്റുള്ളവ, കൂടുതൽ സ്ഥിരതയുള്ള മൂല്യങ്ങൾ സ്വമേധയാ മാറ്റുന്നു, ഇത് വളരെ ബുദ്ധിമുട്ടാണ്. മാത്രമല്ല, ഒരു സാമാന്യവൽക്കരിച്ച ചാർട്ട് വിന്യസിക്കുന്നതിലെ ഒരു തെറ്റ് ഗുരുതരമായ പരാജയങ്ങളിലേക്ക് നയിച്ചേക്കാം, നമ്മുടെ സ്വന്തം അനുഭവത്തിൽ നിന്ന് നമ്മൾ കണ്ടതുപോലെ.

ഒന്നിലധികം കോൺഫിഗറേഷൻ ഫയലുകൾ അപ്ഡേറ്റ് ചെയ്യുന്നു

ഒരു ഡെവലപ്പർ ഒരു പുതിയ ആപ്ലിക്കേഷൻ ചേർക്കുമ്പോൾ, അയാൾക്ക് നിരവധി ഫയലുകൾ മാറ്റേണ്ടി വരും: ആപ്ലിക്കേഷൻ ഡിക്ലറേഷൻ, രഹസ്യങ്ങളുടെ ലിസ്റ്റ്, സാമാന്യവൽക്കരിച്ച ചാർട്ടിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ടെങ്കിൽ അത് ഒരു ആശ്രിതത്വമായി ചേർക്കുന്നു.

ജെങ്കിൻസ് അനുമതികൾ വോൾട്ടിൽ വളരെ വിപുലീകരിച്ചിരിക്കുന്നു

ഇപ്പോൾ നമുക്കൊന്ന് ഉണ്ട് AppRole, അത് വോൾട്ടിൽ നിന്നുള്ള എല്ലാ രഹസ്യങ്ങളും വായിക്കുന്നു.

റോൾബാക്ക് പ്രക്രിയ ഓട്ടോമേറ്റഡ് അല്ല

റോൾബാക്ക് ചെയ്യുന്നതിന്, നിങ്ങൾ നിരവധി ക്ലസ്റ്ററുകളിൽ കമാൻഡ് പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്, ഇത് പിശകുകളാൽ നിറഞ്ഞതാണ്. ശരിയായ പതിപ്പ് ഐഡി വ്യക്തമാക്കിയിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ഈ പ്രവർത്തനം സ്വമേധയാ ചെയ്യുന്നു.

ഞങ്ങൾ GitOps-ലേക്ക് നീങ്ങുകയാണ്

നമ്മുടെ ലക്ഷ്യം

അത് വിന്യസിക്കുന്ന ആപ്ലിക്കേഷന്റെ ശേഖരത്തിലേക്ക് ചാർട്ട് തിരികെ നൽകാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

വർക്ക്ഫ്ലോ വികസനത്തിന് തുല്യമായിരിക്കും. ഉദാഹരണത്തിന്, ഒരു ബ്രാഞ്ച് മാസ്റ്ററിലേക്ക് തള്ളപ്പെടുമ്പോൾ, വിന്യാസം സ്വയമേവ പ്രവർത്തനക്ഷമമാകും. ഈ സമീപനവും നിലവിലെ വർക്ക്ഫ്ലോയും തമ്മിലുള്ള പ്രധാന വ്യത്യാസം അതായിരിക്കും എല്ലാം git-ൽ കൈകാര്യം ചെയ്യും (അപ്ലിക്കേഷനും അത് കുബർനെറ്റസിൽ വിന്യസിച്ചിരിക്കുന്ന രീതിയും).

നിരവധി ഗുണങ്ങളുണ്ട്:

• വളരെ കൂടുതൽ വ്യക്തമാണ് ഡെവലപ്പർക്ക്. ഒരു പ്രാദേശിക ചാർട്ടിൽ മാറ്റങ്ങൾ എങ്ങനെ പ്രയോഗിക്കാമെന്ന് മനസിലാക്കുന്നത് എളുപ്പമാണ്.
• സേവന വിന്യാസത്തിന്റെ നിർവചനം വ്യക്തമാക്കാം കോഡിന്റെ അതേ സ്ഥലം സേവനം.
• സാമാന്യവൽക്കരിച്ച ചാർട്ടുകൾ നീക്കംചെയ്യുന്നത് നിയന്ത്രിക്കുന്നു. സേവനത്തിന് അതിന്റേതായ ഹെൽം റിലീസ് ഉണ്ടായിരിക്കും. മറ്റ് സേവനങ്ങളെ ബാധിക്കാതിരിക്കാൻ, ഏറ്റവും ചെറിയ തലത്തിൽ ആപ്ലിക്കേഷൻ ലൈഫ് സൈക്കിൾ (റോൾബാക്ക്, അപ്‌ഗ്രേഡ്) നിയന്ത്രിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കും.
• ജിറ്റിന്റെ പ്രയോജനങ്ങൾ ചാർട്ട് മാനേജ്മെന്റിനായി: മാറ്റങ്ങൾ പഴയപടിയാക്കുക, ഓഡിറ്റ് ലോഗ് മുതലായവ. നിങ്ങൾക്ക് ഒരു ചാർട്ടിലേക്കുള്ള മാറ്റം പഴയപടിയാക്കണമെങ്കിൽ, git ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയും. വിന്യാസം സ്വയമേവ ആരംഭിക്കുന്നു.
• പോലുള്ള ഉപകരണങ്ങൾ ഉപയോഗിച്ച് നിങ്ങളുടെ വികസന വർക്ക്ഫ്ലോ മെച്ചപ്പെടുത്തുന്നത് നിങ്ങൾ പരിഗണിച്ചേക്കാം സ്കഫോൾഡ്, ഇത് ഉപയോഗിച്ച് ഡവലപ്പർമാർക്ക് ഉൽപ്പാദനത്തിന് അടുത്തുള്ള ഒരു സന്ദർഭത്തിൽ മാറ്റങ്ങൾ പരിശോധിക്കാനാകും.

രണ്ട്-ഘട്ട കുടിയേറ്റം

ഞങ്ങളുടെ ഡവലപ്പർമാർ ഇപ്പോൾ 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 റിലീസ് (സാമാന്യവൽക്കരിച്ച ചാർട്ടുകൾ ഇല്ലാതെ).
• ആപ്ലിക്കേഷന്റെ ജിറ്റ് റിപ്പോസിറ്ററിയിലെ ചാർട്ടുകൾ.

ഞങ്ങൾ എല്ലാ ഡെവലപ്പർമാരുമായും സംസാരിച്ചു, അതിനാൽ മൈഗ്രേഷൻ പ്രക്രിയ ഇതിനകം ആരംഭിച്ചു. ആദ്യ ഘട്ടം ഇപ്പോഴും CI പ്ലാറ്റ്ഫോം ഉപയോഗിച്ച് നിയന്ത്രിക്കപ്പെടുന്നു. രണ്ടാം ഘട്ടത്തെക്കുറിച്ച് ഞാൻ ഉടൻ തന്നെ മറ്റൊരു പോസ്റ്റ് എഴുതാം: ഞങ്ങൾ എങ്ങനെയാണ് ഒരു GitOps വർക്ക്ഫ്ലോയിലേക്ക് മാറിയത് ഒഴുകുക. ഞങ്ങൾ എല്ലാം എങ്ങനെ സജ്ജീകരിച്ചുവെന്നും ഞങ്ങൾ നേരിട്ട ബുദ്ധിമുട്ടുകൾ (ഒന്നിലധികം ശേഖരങ്ങൾ, രഹസ്യങ്ങൾ മുതലായവ) ഞാൻ നിങ്ങളോട് പറയും. വാർത്ത പിന്തുടരുക.

കഴിഞ്ഞ വർഷങ്ങളിലെ ആപ്ലിക്കേഷൻ വിന്യാസ വർക്ക്ഫ്ലോയിലെ ഞങ്ങളുടെ പുരോഗതി വിവരിക്കാൻ ഞങ്ങൾ ഇവിടെ ശ്രമിച്ചു, ഇത് GitOps സമീപനത്തെക്കുറിച്ചുള്ള ചിന്തകളിലേക്ക് നയിച്ചു. ഞങ്ങൾ ഇതുവരെ ലക്ഷ്യത്തിലെത്തിയിട്ടില്ല, ഫലങ്ങളെക്കുറിച്ച് റിപ്പോർട്ടുചെയ്യും, എന്നാൽ എല്ലാം ലളിതമാക്കാനും ഡവലപ്പർമാരുടെ ശീലങ്ങളിലേക്ക് അടുപ്പിക്കാനും ഞങ്ങൾ തീരുമാനിച്ചപ്പോൾ ഞങ്ങൾ ശരിയായ കാര്യം ചെയ്തുവെന്ന് ഇപ്പോൾ ഞങ്ങൾക്ക് ബോധ്യമുണ്ട്.

അവലംബം: www.habr.com