ஹெல்ம் மூலம் பல குபெர்னெட்ஸ் கிளஸ்டர்களில் பயன்பாடுகளை வரிசைப்படுத்தவும்

Dailymotion எப்படி Kubernetes ஐப் பயன்படுத்துகிறது: பயன்பாட்டு வரிசைப்படுத்தல்

டெய்லிமோஷனில் நாங்கள் 3 ஆண்டுகளுக்கு முன்பு தயாரிப்பில் குபெர்னெட்ஸைப் பயன்படுத்தத் தொடங்கினோம். ஆனால் பல கிளஸ்டர்களில் பயன்பாடுகளை வரிசைப்படுத்துவது வேடிக்கையாக உள்ளது, எனவே கடந்த சில ஆண்டுகளாக நாங்கள் எங்கள் கருவிகள் மற்றும் பணிப்பாய்வுகளை மேம்படுத்த முயற்சித்து வருகிறோம்.

எங்கிருந்து தொடங்கியது

உலகெங்கிலும் உள்ள பல குபெர்னெட்ஸ் கிளஸ்டர்களில் எங்கள் பயன்பாடுகளை எவ்வாறு வரிசைப்படுத்துகிறோம் என்பதை இங்கே காண்போம்.

ஒரே நேரத்தில் பல குபெர்னெட்ஸ் பொருட்களை வரிசைப்படுத்த, நாங்கள் பயன்படுத்துகிறோம் தலைமையில், மற்றும் எங்கள் அனைத்து விளக்கப்படங்களும் ஒரு ஜிட் களஞ்சியத்தில் சேமிக்கப்படும். பல சேவைகளிலிருந்து முழு பயன்பாட்டு அடுக்கை வரிசைப்படுத்த, சுருக்க விளக்கப்படம் என்று அழைக்கப்படுவதைப் பயன்படுத்துகிறோம். அடிப்படையில், இது சார்புகளை அறிவிக்கும் ஒரு விளக்கப்படம் மற்றும் ஒரு கட்டளையுடன் API மற்றும் அதன் சேவைகளை துவக்க உங்களை அனுமதிக்கிறது.

ஹெல்மின் மேல் ஒரு சிறிய பைதான் ஸ்கிரிப்டை நாங்கள் சரிபார்ப்பதற்கும், விளக்கப்படங்களை உருவாக்குவதற்கும், ரகசியங்களைச் சேர்ப்பதற்கும், பயன்பாடுகளை வரிசைப்படுத்துவதற்கும் எழுதினோம். இந்தப் பணிகள் அனைத்தும் டாக்கர் படத்தைப் பயன்படுத்தி மத்திய CI இயங்குதளத்தில் செய்யப்படுகின்றன.

விஷயத்திற்கு வருவோம்.

குறிப்பு. இதைப் படிக்கும்போது, ​​ஹெல்ம் 3க்கான முதல் வெளியீட்டு வேட்பாளர் ஏற்கனவே அறிவிக்கப்பட்டுள்ளார். கடந்த காலத்தில் நாங்கள் எதிர்கொண்ட சில சிக்கல்களைத் தீர்ப்பதற்கான முழு அளவிலான மேம்பாடுகளை முதன்மைப் பதிப்பில் கொண்டுள்ளது.

விளக்கப்படம் அபிவிருத்தி பணிப்பாய்வு

நாங்கள் பயன்பாடுகளுக்கு கிளைகளைப் பயன்படுத்துகிறோம், அதே அணுகுமுறையை விளக்கப்படங்களுக்கும் பயன்படுத்த முடிவு செய்தோம்.

  • கிளை தேவ் மேம்பாடு கிளஸ்டர்களில் சோதிக்கப்படும் விளக்கப்படங்களை உருவாக்கப் பயன்படுகிறது.
  • ஒரு இழுப்பு கோரிக்கை சமர்ப்பிக்கப்படும் போது மாஸ்டர், அவர்கள் மேடையில் சரிபார்க்கப்படுகிறார்கள்.
  • இறுதியாக, கிளையில் மாற்றங்களைச் செய்ய இழுக்கும் கோரிக்கையை உருவாக்குகிறோம் தயாரிப்பு மற்றும் உற்பத்தியில் அவற்றைப் பயன்படுத்துங்கள்.

ஒவ்வொரு சூழலுக்கும் அதன் சொந்த தனிப்பட்ட களஞ்சியங்கள் உள்ளன, அவை எங்கள் விளக்கப்படங்களைச் சேமிக்கின்றன, மேலும் நாங்கள் பயன்படுத்துகிறோம் சார்ட்மியூசியம் மிகவும் பயனுள்ள APIகளுடன். இந்த வழியில், சுற்றுச்சூழலுக்கு இடையே கடுமையான தனிமைப்படுத்தப்படுவதை உறுதிசெய்கிறோம் மற்றும் அவற்றை உற்பத்தியில் பயன்படுத்துவதற்கு முன்பு வரைபடங்களின் நிஜ-உலக சோதனை.

வெவ்வேறு சூழல்களில் விளக்கப்பட களஞ்சியங்கள்

டெவலப்பர்கள் ஒரு டெவ் கிளையைத் தள்ளும்போது, ​​அவர்களின் விளக்கப்படத்தின் பதிப்பு தானாகவே தேவ் சார்ட்மியூசியத்திற்குத் தள்ளப்படும் என்பது குறிப்பிடத்தக்கது. எனவே, எல்லா டெவலப்பர்களும் ஒரே dev களஞ்சியத்தைப் பயன்படுத்துகின்றனர், மேலும் தற்செயலாக வேறொருவரின் மாற்றங்களைப் பயன்படுத்தாமல் இருக்க, உங்கள் விளக்கப்படத்தின் பதிப்பை கவனமாகக் குறிப்பிட வேண்டும்.

மேலும், எங்கள் சிறிய பைதான் ஸ்கிரிப்ட் குபெர்னெட்ஸ் ஓபன்ஏபிஐ விவரக்குறிப்புகளுக்கு எதிராக குபெர்னெட்ஸ் பொருட்களை சரிபார்க்கிறது குபேவல், அவற்றை Chartmusem இல் வெளியிடுவதற்கு முன்.

விளக்கப்பட மேம்பாட்டிற்கான பொதுவான விளக்கம்

  1. விவரக்குறிப்பின்படி குழாய் பணிகளை அமைத்தல் gazr.io தரக் கட்டுப்பாட்டுக்கு (லிண்ட், யூனிட்-டெஸ்ட்).
  2. எங்கள் பயன்பாடுகளை வரிசைப்படுத்தும் பைதான் கருவிகளைக் கொண்டு ஒரு டாக்கர் படத்தைத் தள்ளுதல்.
  3. கிளையின் பெயரால் சூழலை அமைத்தல்.
  4. Kubeval ஐப் பயன்படுத்தி Kubernetes yaml கோப்புகளைச் சரிபார்க்கிறது.
  5. தானாக ஒரு விளக்கப்படத்தின் பதிப்பு மற்றும் அதன் பெற்றோர் விளக்கப்படங்களை அதிகரிக்கவும் (விளக்கப்படம் மாற்றப்படுவதைப் பொறுத்து விளக்கப்படங்கள்).
  6. அதன் சுற்றுச்சூழலுடன் பொருந்தக்கூடிய சார்ட்மியூசியத்திற்கு ஒரு விளக்கப்படத்தை சமர்ப்பித்தல்

கிளஸ்டர்களில் உள்ள வேறுபாடுகளை நிர்வகித்தல்

கிளஸ்டர்களின் கூட்டமைப்பு

நாம் பயன்படுத்திய காலம் ஒன்று இருந்தது குபெர்னெட்ஸ் கிளஸ்டர்களின் கூட்டமைப்பு, குபெர்னெட்ஸ் பொருள்களை ஒரு ஏபிஐ இறுதிப் புள்ளியில் இருந்து அறிவிக்க முடியும். ஆனால் பிரச்சினைகள் எழுந்தன. எடுத்துக்காட்டாக, சில குபெர்னெட்ஸ் பொருள்களை ஃபெடரேஷன் இறுதிப் புள்ளியில் உருவாக்க முடியவில்லை, இது தனிப்பட்ட கிளஸ்டர்களுக்கான கூட்டமைக்கப்பட்ட பொருள்கள் மற்றும் பிற பொருட்களைப் பராமரிப்பதை கடினமாக்குகிறது.

சிக்கலைத் தீர்க்க, நாங்கள் கிளஸ்டர்களை சுயாதீனமாக நிர்வகிக்கத் தொடங்கினோம், இது செயல்முறையை பெரிதும் எளிதாக்கியது (கூட்டமைப்பின் முதல் பதிப்பைப் பயன்படுத்தினோம்; இரண்டாவதாக ஏதாவது மாறியிருக்கலாம்).

ஜியோ-விநியோக தளம்

எங்கள் இயங்குதளம் தற்போது 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 ஜிட் களஞ்சியங்கள் என்பது 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

கருத்தைச் சேர்