Helm ဖြင့် Kubernetes အစုအဝေးများစွာတွင် အပလီကေးရှင်းများကို အသုံးပြုပါ။

Dailymotion သည် Kubernetes ကိုအသုံးပြုပုံ- Application Deployment

ကျွန်ုပ်တို့သည် Dailymotion မှ Kubernetes ကို လွန်ခဲ့သော 3 နှစ်က ထုတ်လုပ်မှုတွင် စတင်အသုံးပြုခဲ့သည်။ သို့သော် အစုအဝေးများစွာတွင် အပလီကေးရှင်းများကို ဖြန့်ကျက်အသုံးပြုခြင်းသည် ပျော်စရာကောင်းသည်၊ ထို့ကြောင့် ပြီးခဲ့သည့်နှစ်အနည်းငယ်အတွင်း ကျွန်ုပ်တို့၏ကိရိယာများနှင့် အလုပ်အသွားအလာများကို မြှင့်တင်ရန် ကြိုးစားနေပါသည်။

ဘယ်ကစတာလဲ။

ဤနေရာတွင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏အပလီကေးရှင်းများကို ကမ္ဘာတစ်ဝှမ်းရှိ Kubernetes အစုအဝေးများစွာတွင် မည်သို့အသုံးချပုံကို ဖော်ပြပါမည်။

Kubernetes အရာဝတ္ထုများစွာကို တစ်ပြိုင်နက်အသုံးပြုရန် ကျွန်ုပ်တို့အသုံးပြုသည်။ သံခမောက်နှင့် ကျွန်ုပ်တို့၏ဇယားအားလုံးကို git repository တစ်ခုတည်းတွင် သိမ်းဆည်းထားသည်။ ဝန်ဆောင်မှုများစွာမှ အပလီကေးရှင်းအစုအစည်းကို အပြည့်အဝအသုံးချရန်၊ ကျွန်ုပ်တို့သည် အနှစ်ချုပ်ဇယားဟုခေါ်သော ဇယားကို အသုံးပြုသည်။ အခြေခံအားဖြင့်၊ ဤသည်မှာ မှီခိုမှုကိုကြေငြာပြီး API နှင့် ၎င်း၏ဝန်ဆောင်မှုများကို command တစ်ခုတည်းဖြင့် စတင်နိုင်စေမည့် ဇယားတစ်ခုဖြစ်သည်။

စစ်ဆေးမှုများပြုလုပ်ရန်၊ ဇယားများဖန်တီးရန်၊ လျှို့ဝှက်ချက်များထည့်ရန်နှင့် အပလီကေးရှင်းများအသုံးပြုရန်အတွက် Helm ၏ထိပ်တွင် Python script ငယ်တစ်ခုကိုလည်း ရေးသားခဲ့သည်။ ဤလုပ်ဆောင်စရာများအားလုံးကို docker ပုံကို အသုံးပြု၍ ဗဟို CI ပလပ်ဖောင်းပေါ်တွင် လုပ်ဆောင်ပါသည်။

အမှတ်ရရအောင်။

မှတ်ချက်။ သင်ဤစာကိုဖတ်ပြီး Helm 3 အတွက်ပထမဆုံးဖြန့်ချိမည့်ကိုယ်စားလှယ်ကိုကြေငြာပြီးဖြစ်သည်။ ပင်မဗားရှင်းတွင် ယခင်က ကျွန်ုပ်တို့ကြုံတွေ့ခဲ့ရသည့် ပြဿနာအချို့ကို ဖြေရှင်းရန်အတွက် တိုးတက်မှုများစွာပါရှိသည်။

ဇယားကွက် ဖွံ့ဖြိုးတိုးတက်ရေး လုပ်ငန်းအသွားအလာ

ကျွန်ုပ်တို့သည် အပလီကေးရှင်းများအတွက် အကိုင်းအခက်များကို အသုံးပြုပြီး ဇယားကွက်များအတွက် တူညီသောချဉ်းကပ်မှုကို အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။

• ကိုင်း dev ဖွံ့ဖြိုးတိုးတက်မှုအစုအဝေးများတွင် စမ်းသပ်မည့်ဇယားများကို ဖန်တီးရန် အသုံးပြုသည်။
• ဆွဲတင်ရန် တောင်းဆိုမှုကို တင်ပြသည့်အခါ မာစတာသူတို့က သူ့ထက်ငါ စစ်တယ်။
• နောက်ဆုံးတွင်၊ ဌာနခွဲသို့ ပြောင်းလဲမှုများကို ကျူးလွန်ရန် ဆွဲထုတ်ရန် တောင်းဆိုချက်ကို ဖန်တီးပါသည်။ ရော့ ထုတ်လုပ်မှုတွင် အသုံးချပါ။

ပတ်ဝန်းကျင်တစ်ခုစီတွင် ကျွန်ုပ်တို့၏ဇယားများကို သိမ်းဆည်းထားကာ ကျွန်ုပ်တို့အသုံးပြုသည့် ကိုယ်ပိုင်သိုလှောင်မှုရှိသည်။ Chartmuseum အလွန်အသုံးဝင်သော API များနှင့်အတူ။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် ၎င်းတို့အား ထုတ်လုပ်ရာတွင် အသုံးမပြုမီ ပတ်၀န်းကျင်နှင့် လက်တွေ့ကမ္ဘာစမ်းသပ်မှုတို့ကြားတွင် တင်းကျပ်သော အထီးကျန်မှုကို သေချာစေသည်။

မတူညီသောပတ်ဝန်းကျင်များရှိဇယားကွက်များ

developer များသည် dev ဌာနခွဲတစ်ခုကို တွန်းသောအခါ၊ ၎င်းတို့၏ဇယားဗားရှင်းကို dev Chartmuseum သို့ အလိုအလျောက် တွန်းပို့သည်ကို သတိပြုသင့်သည်။ ထို့ကြောင့်၊ developer များအားလုံးသည် တူညီသော dev repository ကိုအသုံးပြုကြပြီး အခြားသူ၏ပြောင်းလဲမှုများကို မတော်တဆအသုံးမပြုမိစေရန်အတွက် သင့်ဇယား၏ဗားရှင်းကို ဂရုတစိုက်သတ်မှတ်ရန် လိုအပ်ပါသည်။

ထို့အပြင်၊ ကျွန်ုပ်တို့၏ Python script သည် Kubernetes အရာဝတ္ထုများကို Kubernetes OpenAPI သတ်မှတ်ချက်များနှင့် ဆန့်ကျင်၍ တရားဝင်စေသည် KubevalChartmusem တွင် မထုတ်ဝေမီ၊

ဇယားဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းအသွားအလာ၏ အထွေထွေဖော်ပြချက်

1. သတ်မှတ်ချက်အတိုင်း ပိုက်လိုင်းလုပ်ငန်းများကို သတ်မှတ်ခြင်း။ gazr.io အရည်အသွေးထိန်းချုပ်မှုအတွက် (lint၊ ယူနစ်စမ်းသပ်မှု)။
2. ကျွန်ုပ်တို့၏ အပလီကေးရှင်းများကို အသုံးပြုသည့် Python ကိရိယာများဖြင့် docker ပုံတစ်ခုကို တွန်းတင်ခြင်း။
3. ဌာနခွဲအမည်ဖြင့် ပတ်ဝန်းကျင်ကို သတ်မှတ်ခြင်း။
4. Kubeval ကို အသုံးပြု၍ Kubernetes yaml ဖိုင်များကို စစ်ဆေးခြင်း
5. ဇယားတစ်ခု၏ ဗားရှင်းနှင့် ၎င်း၏ ပင်မဇယားများ (ပြောင်းလဲနေသော ဇယားအပေါ် မူတည်သော ဇယားများ) ကို အလိုအလျောက် တိုးမြှင့်ပါ။
6. ၎င်း၏ပတ်ဝန်းကျင်နှင့်ကိုက်ညီသော Chartmuseum သို့ဇယားတစ်ခုတင်ပြခြင်း။

အစုအဖွဲ့များတစ်လျှောက် ကွဲပြားမှုများကို စီမံခန့်ခွဲခြင်း။

ပဒေသာပင်များအဖွဲ့ချုပ်

ကျွန်တော်သုံးတဲ့ အချိန်တစ်ခုရှိတယ်။ Kubernetes အစုအဖွဲ့များ အဖွဲ့ချုပ်API အဆုံးမှတ်တစ်ခုမှ Kubernetes အရာဝတ္ထုများကို ကြေငြာနိုင်သည့်နေရာ။ ဒါပေမယ့် ပြဿနာတွေ ပေါ်လာတယ်။ ဥပမာအားဖြင့်၊ အချို့သော Kubernetes အရာဝတ္ထုများကို ဖယ်ဒရယ် အဆုံးမှတ်တွင် ဖန်တီး၍မရသောကြောင့် အစုအဖွဲ့တစ်ခုစီအတွက် အစုအဝေးအရာဝတ္ထုများနှင့် အခြားအရာဝတ္ထုများကို ထိန်းသိမ်းရန်ခက်ခဲစေသည်။

ပြဿနာကိုဖြေရှင်းရန်၊ ကျွန်ုပ်တို့သည် လုပ်ငန်းစဉ်ကို အလွန်ရိုးရှင်းလွယ်ကူစေသည့် အစုအဖွဲ့များကို လွတ်လပ်စွာစီမံခန့်ခွဲရန် စတင်ခဲ့သည် (ကျွန်ုပ်တို့သည် အဖွဲ့ချုပ်၏ပထမဗားရှင်းကိုအသုံးပြုခဲ့သည်၊ ဒုတိယပိုင်းတွင် တစ်စုံတစ်ခုပြောင်းလဲသွားနိုင်သည်)။

ပထဝီ ဖြန့်ဝေသည့် ပလက်ဖောင်း

ကျွန်ုပ်တို့၏ပလပ်ဖောင်းသည် လက်ရှိတွင် ဒေသ 6 ခုတွင် ဖြန့်ကျက်ထားသည် - ပြည်တွင်းတွင် 3 ခုနှင့် cloud တွင် 3 ခုရှိသည်။

ဖြန့်ကျက်ဖြန့်ကျက်ခြင်း။

Global Helm တန်ဖိုးများ

4 global Helm တန်ဖိုးများသည် အစုအဖွဲ့များကြားတွင် ကွဲပြားမှုများကို ခွဲခြားသတ်မှတ်နိုင်စေပါသည်။ ကျွန်ုပ်တို့၏ဇယားများအားလုံးတွင် မူရင်းအနိမ့်ဆုံးတန်ဖိုးများရှိသည်။

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 -}}

Helm နမူနာပုံစံ

Kubernetes YAML ရှုပ်ပွခြင်းကို ရှောင်ရှားရန် ဤယုတ္တိဗေဒကို အထောက်အကူပုံစံပုံစံတွင် သတ်မှတ်ထားသည်။

လျှောက်လွှာကြေငြာခြင်း။

ကျွန်ုပ်တို့၏ အသုံးချကိရိယာများသည် YAML ဖိုင်များစွာကို အခြေခံထားသည်။ အောက်တွင် ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုတစ်ခုအား ကျွန်ုပ်တို့ကြေညာပုံနှင့် ၎င်း၏စကေးချဲ့ထွင်မှုဆိုင်ရာ topology (အစုလိုက်ပုံတူအရေအတွက်) ၏ ဥပမာတစ်ခုဖြစ်သည်။

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

ဝန်ဆောင်မှု အဓိပ္ပါယ်

ဤသည်မှာ ကျွန်ုပ်တို့၏ ဖြန့်ကျက်လုပ်ဆောင်မှုအသွားအလာကို သတ်မှတ်သည့် အဆင့်အားလုံး၏ အကြမ်းဖျင်းဖြစ်သည်။ နောက်ဆုံးအဆင့်မှာ အပလီကေးရှင်းကို အလုပ်သမားအစုအဝေးများစွာထံ တပြိုင်နက် ဖြန့်ကျက်ချထားပါသည်။

Jenkins ဖြန့်ကျက်မှု အဆင့်များ

လျှို့ဝှက်ချက်များကော။

လုံခြုံရေးနှင့် ပတ်သက်၍ ကျွန်ုပ်တို့သည် မတူညီသော နေရာများမှ လျှို့ဝှက်ချက်အားလုံးကို ခြေရာခံပြီး ၎င်းတို့ကို ထူးခြားသော အခန်းထဲတွင် သိမ်းဆည်းထားသည်။ ပင်လယ်ကမ်းစောင်း ပါရီတွင်။

ကျွန်ုပ်တို့၏ ဖြန့်ကျက်မှုကိရိယာများသည် Vault မှ လျှို့ဝှက်တန်ဖိုးများကို ထုတ်ယူပြီး ဖြန့်ကျက်ချိန်ရောက်သည့်အခါ ၎င်းတို့ကို Helm ထဲသို့ ထည့်သွင်းပါ။

ဒါကိုလုပ်ဖို့၊ 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 တွင် လျှို့ဝှက်ချက်များကို မှတ်တမ်းတင်သည့်အခါ လိုက်နာရန် ယေဘုယျစည်းမျဉ်းများကို သတ်မှတ်ထားပါသည်။
• လျှို့ဝှက်ချက်တွေပေါ့။ သီးခြားအကြောင်းအရာ သို့မဟုတ် အစုအဝေးသို့တိကျသော entry ကိုထည့်ရန်လိုအပ်သည်။ (ဤနေရာတွင် context cluster1 သည် လျှို့ဝှက် stack-app1-password အတွက် ၎င်း၏ကိုယ်ပိုင်တန်ဖိုးရှိသည်။)
• မဟုတ်ရင် တန်ဖိုးကို သုံးပါတယ်။ မူလက.
• ဤစာရင်းတွင်ပါဝင်သည့်အရာတစ်ခုစီအတွက် 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

ပြဿနာများနှင့် ကန့်သတ်ချက်များ

သိုလှောင်မှုအများအပြားနှင့်အလုပ်လုပ်

ယခု ကျွန်ုပ်တို့သည် ဇယားများနှင့် အပလီကေးရှင်းများ၏ ဖွံ့ဖြိုးတိုးတက်မှုကို ခွဲခြားထားသည်။ ဆိုလိုသည်မှာ developer များသည် git repositories နှစ်ခုတွင် အလုပ်လုပ်ရမည်ဖြစ်ပြီး တစ်ခုသည် အပလီကေးရှင်းအတွက် တစ်ခုနှင့် Kubernetes သို့ ၎င်း၏ deployment ကို သတ်မှတ်ခြင်းအတွက် တစ်ခုဖြစ်သည်။ 2 git repositories သည် အလုပ်အသွားအလာ 2 ခုကို ဆိုလိုပြီး အသစ်လုပ်သူအတွက် ရှုပ်ထွေးလွယ်သည်။

အထွေထွေဇယားကွက်များကို စီမံခန့်ခွဲခြင်းသည် ခက်ခဲသည်။

ကျွန်ုပ်တို့ပြောခဲ့သည့်အတိုင်း၊ ယေဘုယျဇယားများသည် မှီခိုမှုကို ခွဲခြားသတ်မှတ်ရန်နှင့် အပလီကေးရှင်းများစွာကို လျင်မြန်စွာအသုံးချရန်အတွက် အလွန်အသုံးဝင်ပါသည်။ ဒါပေမယ့် ကျွန်တော်တို့ သုံးပါတယ်။ --reuse-valuesဤယေဘူယျပုံစံဇယား၏ အစိတ်အပိုင်းဖြစ်သော အက်ပလီကေးရှင်းကို အသုံးပြုသည့်အခါတိုင်း တန်ဖိုးများအားလုံးကို ကျော်ဖြတ်ခြင်းမှ ရှောင်ကြဉ်ပါ။

စဉ်ဆက်မပြတ် ပေးပို့ခြင်းလုပ်ငန်းအသွားအလာတွင်၊ ကျွန်ုပ်တို့တွင် ပုံမှန်ပြောင်းလဲနေသော တန်ဖိုးနှစ်ခုသာရှိသည်- ပုံတူအရေအတွက်နှင့် ပုံတဂ် (ဗားရှင်း)။ အခြား၊ ပိုမိုတည်ငြိမ်သောတန်ဖိုးများကိုကိုယ်တိုင်ပြောင်းလဲပြီး၎င်းသည်အတော်လေးခက်ခဲသည်။ ထို့အပြင်၊ ယေဘူယျအားဖြင့် ဇယားတစ်ခုကို အသုံးချခြင်းတွင် အမှားတစ်ခုသည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်အတွေ့အကြုံမှ မြင်တွေ့ခဲ့ရသည့်အတိုင်း ကြီးလေးသောကျရှုံးမှုများဆီသို့ ဦးတည်သွားစေနိုင်သည်။

ဖွဲ့စည်းမှုပုံစံဖိုင်များစွာကို အပ်ဒိတ်လုပ်ခြင်း။

developer သည် အပလီကေးရှင်းအသစ်တစ်ခုကို ပေါင်းထည့်သောအခါတွင် ဖိုင်အများအပြားကို ပြောင်းရပါမည်- အပလီကေးရှင်းကြေငြာချက်၊ လျှို့ဝှက်ချက်များစာရင်း၊ ၎င်းကို ယေဘူယျပုံစံဇယားတွင် ထည့်သွင်းပါက အပလီကေးရှင်းကို မှီခိုမှုတစ်ခုအဖြစ် ထည့်သွင်းပါ။

Jenkins ခွင့်ပြုချက်များသည် Vault တွင် တိုးချဲ့လွန်းသည်။

အခု ကျွန်တော်တို့မှာ တစ်ခုရှိတယ်။ AppRoleVault မှလျှို့ဝှက်ချက်များအားလုံးကိုဖတ်သည်။

နောက်ပြန်ဆွဲခြင်းလုပ်ငန်းစဉ်သည် အလိုအလျောက်လုပ်ဆောင်ခြင်းမဟုတ်ပါ။

ပြန်လှည့်ရန်၊ သင်သည် အစုအဝေးများစွာရှိ command ကို run ရန် လိုအပ်ပြီး ၎င်းသည် အမှားအယွင်းများနှင့် ပြည့်နေပါသည်။ မှန်ကန်သောဗားရှင်း ID ကို သတ်မှတ်ထားကြောင်း သေချာစေရန် ကျွန်ုပ်တို့သည် ဤလုပ်ဆောင်ချက်ကို ကိုယ်တိုင်လုပ်ဆောင်ပါသည်။

ကျွန်ုပ်တို့သည် GitOps သို့ ဦးတည်သွားနေပါသည်။

ငါတို့ရဲ့ပန်းတိုင်

ကျွန်ုပ်တို့သည် ၎င်းအသုံးပြုနေသော အပလီကေးရှင်း၏ သိုလှောင်ခန်းသို့ ဇယားကို ပြန်ပေးလိုပါသည်။

ဖွံ့ဖြိုးတိုးတက်မှုအတွက် လုပ်ငန်းအသွားအလာက အတူတူပါပဲ။ ဥပမာအားဖြင့်၊ ဌာနခွဲတစ်ခုကို ကျွမ်းကျင်ရန် တွန်းလိုက်သောအခါ၊ ဖြန့်ကျက်မှုကို အလိုအလျောက် အစပျိုးသွားမည်ဖြစ်သည်။ ဤချဉ်းကပ်နည်းနှင့် လက်ရှိလုပ်ငန်းအသွားအလာအကြား အဓိက ကွာခြားချက်မှာ ထိုသို့ဖြစ်ပေမည်။ အရာအားလုံးကို git တွင်စီမံခန့်ခွဲလိမ့်မည်။ (အပလီကေးရှင်းကိုယ်တိုင်နှင့် Kubernetes တွင်အသုံးပြုပုံ)။

အားသာချက်များစွာရှိသည်-

• အများကြီး ပိုရှင်းတယ်။ developer အတွက်။ ဒေသတွင်းဇယားတစ်ခုတွင် အပြောင်းအလဲများကို အသုံးချနည်းကို လေ့လာရန် ပိုမိုလွယ်ကူသည်။
• ဝန်ဆောင်မှု ဖြန့်ကျက်ခြင်း အဓိပ္ပါယ် သတ်မှတ်နိုင်သည်။ ကုဒ်နဲ့တူတဲ့နေရာ ဝန်ဆောင်မှု။
• အထွေထွေဇယားကွက်များကို ဖယ်ရှားခြင်းကို စီမံခန့်ခွဲခြင်း။. ဝန်ဆောင်မှုတွင် ၎င်း၏ကိုယ်ပိုင် Helm ထွက်ရှိမည်ဖြစ်သည်။ ၎င်းသည် သင့်အား အခြားဝန်ဆောင်မှုများကိုမထိခိုက်စေရန် အသေးငယ်ဆုံးအဆင့်တွင် အပလီကေးရှင်းဘဝသံသရာ (ပြန်လှည့်ခြင်း၊ အဆင့်မြှင့်တင်ခြင်း) ကို စီမံနိုင်စေမည်ဖြစ်သည်။
• git ၏အကျိုးကျေးဇူးများ ဇယားစီမံခန့်ခွဲမှုအတွက်- အပြောင်းအလဲများ၊ စာရင်းစစ်မှတ်တမ်း စသည်တို့ကို ပြန်ဖျက်ရန်။ အကယ်၍ သင်သည် ဇယားတစ်ခုသို့ ပြောင်းလဲမှုကို ပြန်ဖျက်ရန် လိုအပ်ပါက၊ သင်သည် ဤအရာကို git သုံးပြီး လုပ်ဆောင်နိုင်သည်။ ဖြန့်ကျက်မှုသည် အလိုအလျောက် စတင်သည်။
• ကဲ့သို့သော ကိရိယာများဖြင့် သင်၏ ဖွံ့ဖြိုးတိုးတက်မှု လုပ်ငန်းအသွားအလာကို မြှင့်တင်ရန် စဉ်းစားနိုင်သည်။ တံကျင်ထုတ်လုပ်သူများနှင့် နီးစပ်သော အကြောင်းအရာတစ်ခုတွင် အပြောင်းအလဲများကို စမ်းသပ်နိုင်သည့် developer များ။

နှစ်ဆင့် ရွှေ့ပြောင်းခြင်း။

ကျွန်ုပ်တို့၏ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် ဤလုပ်ငန်းအသွားအလာကို ယခု 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 ခု (ယေဘုယျဇယားကွက်များမပါဘဲ)။
• အပလီကေးရှင်း၏ git repository ရှိဇယားများ။

ကျွန်ုပ်တို့သည် ဆော့ဖ်ဝဲရေးသားသူအားလုံးနှင့် စကားပြောပြီးပြီဖြစ်သောကြောင့် ရွှေ့ပြောင်းခြင်းလုပ်ငန်းစဉ်ကို စတင်နေပြီဖြစ်သည်။ ပထမအဆင့်သည် CI ပလပ်ဖောင်းကို အသုံးပြု၍ ထိန်းချုပ်ထားဆဲဖြစ်သည်။ အဆင့် ၂ အကြောင်းကို မကြာခင်မှာ နောက်ထပ် ပို့စ်တစ်ခု ထပ်ရေးပါဦးမယ်။ စီးဆင်း. အရာအားလုံးကို ဘယ်လိုပြင်ဆင်ပြီး ဘယ်လိုအခက်အခဲတွေ ကြုံတွေ့ခဲ့ရလဲ (သိုလှောင်မှုများစွာ၊ လျှို့ဝှက်ချက်များ စသည်ဖြင့်) ကို ပြောပြပါမယ်။ သတင်းကိုလိုက်နာပါ။

ဤနေရာတွင် ကျွန်ုပ်တို့သည် လွန်ခဲ့သောနှစ်များအတွင်း အပလီကေးရှင်းဖြန့်ကျက်ခြင်းလုပ်ငန်းအသွားအလာတွင် ကျွန်ုပ်တို့၏တိုးတက်မှုကို ဖော်ပြရန်ကြိုးစားခဲ့ပြီး GitOps ချဉ်းကပ်မှုနှင့်ပတ်သက်၍ အတွေးအမြင်များဖြစ်ပေါ်စေခဲ့သည်။ ကျွန်ုပ်တို့သည် ပန်းတိုင်သို့မရောက်သေးဘဲ ရလဒ်များကို အစီရင်ခံတင်ပြပါမည်၊ သို့သော် အရာအားလုံးကို ရိုးရှင်းလွယ်ကူစေရန်နှင့် ဆော့ဖ်ဝဲရေးသားသူများ၏အလေ့အထနှင့် ပိုမိုနီးကပ်စေရန် ဆုံးဖြတ်လိုက်သောအခါ ကျွန်ုပ်တို့သည် မှန်ကန်သောအရာကို လုပ်ဆောင်ခဲ့ကြောင်း ကျွန်ုပ်တို့ယုံကြည်ပါသည်။

source: www.habr.com