હેલ્મ સાથે બહુવિધ Kubernetes ક્લસ્ટરોમાં એપ્લિકેશનો જમાવો

ડેલીમોશન કુબરનેટ્સનો ઉપયોગ કેવી રીતે કરે છે: એપ્લિકેશન ડિપ્લોયમેન્ટ

ડેઇલીમોશન પર અમે 3 વર્ષ પહેલાં ઉત્પાદનમાં કુબરનેટ્સનો ઉપયોગ કરવાનું શરૂ કર્યું. પરંતુ બહુવિધ ક્લસ્ટરોમાં એપ્લિકેશનો જમાવવી એ આનંદદાયક છે, તેથી છેલ્લા કેટલાક વર્ષોથી અમે અમારા ટૂલ્સ અને વર્કફ્લોને બહેતર બનાવવાનો પ્રયાસ કરી રહ્યા છીએ.

તેની શરૂઆત ક્યાંથી થઈ

અહીં અમે આવરી લઈશું કે અમે વિશ્વભરના બહુવિધ કુબરનેટ્સ ક્લસ્ટરોમાં અમારી એપ્લિકેશન કેવી રીતે જમાવીએ છીએ.

એકસાથે બહુવિધ કુબરનેટ્સ ઑબ્જેક્ટ્સ જમાવવા માટે, અમે ઉપયોગ કરીએ છીએ હેલ્મ, અને અમારા બધા ચાર્ટ એક ગિટ રિપોઝીટરીમાં સંગ્રહિત છે. ઘણી સેવાઓમાંથી સંપૂર્ણ એપ્લિકેશન સ્ટેક જમાવવા માટે, અમે કહેવાતા સારાંશ ચાર્ટનો ઉપયોગ કરીએ છીએ. આવશ્યકપણે, આ એક ચાર્ટ છે જે નિર્ભરતા જાહેર કરે છે અને તમને 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

વૈશ્વિક મૂલ્યો

આ મૂલ્યો અમારી એપ્લિકેશન માટે સંદર્ભને વ્યાખ્યાયિત કરવામાં મદદ કરે છે અને તેનો ઉપયોગ વિવિધ હેતુઓ માટે થાય છે: મોનિટરિંગ, ટ્રેસિંગ, લોગિંગ, બાહ્ય કૉલ્સ, સ્કેલિંગ વગેરે.

• "ક્લાઉડ": અમારી પાસે હાઇબ્રિડ કુબરનેટ્સ પ્લેટફોર્મ છે. ઉદાહરણ તરીકે, અમારું 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"

• અમે વૉલ્ટમાં રહસ્યો રેકોર્ડ કરતી વખતે અનુસરવા માટેના સામાન્ય નિયમોને વ્યાખ્યાયિત કર્યા છે.
• જો રહસ્ય લાગુ પડે છે ચોક્કસ સંદર્ભ અથવા ક્લસ્ટર માટે, તમારે ચોક્કસ એન્ટ્રી ઉમેરવાની જરૂર છે. (અહીં સંદર્ભ ક્લસ્ટર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, જે વૉલ્ટમાંથી તમામ રહસ્યો વાંચે છે.

રોલબેક પ્રક્રિયા સ્વચાલિત નથી

રોલબેક કરવા માટે, તમારે કેટલાક ક્લસ્ટરો પર આદેશ ચલાવવાની જરૂર છે, અને આ ભૂલોથી ભરપૂર છે. સાચા સંસ્કરણ IDનો ઉલ્લેખ કરવામાં આવ્યો છે તેની ખાતરી કરવા માટે અમે આ ઑપરેશન મેન્યુઅલી કરીએ છીએ.

અમે GitOps તરફ આગળ વધી રહ્યા છીએ

આપણો લક્ષ

અમે ચાર્ટને તે જમાવેલી એપ્લિકેશનના રિપોઝીટરીમાં પરત કરવા માંગીએ છીએ.

કાર્યપ્રવાહ વિકાસ માટે જેવો જ રહેશે. ઉદાહરણ તરીકે, જ્યારે કોઈ શાખાને માસ્ટર પર ધકેલવામાં આવે છે, ત્યારે જમાવટ આપમેળે ટ્રિગર થઈ જશે. આ અભિગમ અને વર્તમાન વર્કફ્લો વચ્ચેનો મુખ્ય તફાવત તે હશે બધું 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