release namespace တွင် app-outbound-proxy ဟု အမည်ရှိ Secret ရှိပြီးဖြစ်သည်ဟု ဆိုပါစို့။ ၎င်း၏ http_proxy နှင့် https_proxy သော့များတွင် application လိုအပ်သော proxy URL အပြည့်အစုံ ပါဝင်သည်။

Helm 3 chart သည် values.yaml တွင် ထို Secret ၏ အမည်ကိုသာ သိမ်းထားနိုင်သည်။

outboundProxy:
  existingSecret: app-outbound-proxy

ရည်ရွယ်ထားသော container ၏ Deployment template တွင် သော့များကို ကိုးကားပါ။

env:
  - name: HTTP_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: http_proxy
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: https_proxy

ဤသည် container spec ၏ အပိုင်းတစ်ပိုင်းဖြစ်သည်။ Secret သည် Pod ၏ namespace တွင် ရှိရမည်ဖြစ်ပြီး ကိုးကားထားသော သော့နှစ်ခုလုံး ပါဝင်ရမည်။ ၎င်း၏ တန်ဖိုးများသည် အမှန်တကယ် proxy နားထောင်သူ၏ protocol၊ host နှင့် port ကို အသုံးပြုရမည်။ authentication မပါသော အများသူငှာ proxy ကို အသုံးပြုခွင့်ရှိသော အများသူငှာ application တောင်းဆိုမှုများအတွက် ထို URL များကို အခမဲ့ proxy စာရင်းရှိ သင့်လျော်သော ကိုယ်စားလှယ်လောင်းမှ တည်ဆောက်ပါ။ လိုအပ်သော တိုက်ရိုက် ခြွင်းချက်များကို ထိန်းထားပါ။

chart တန်ဖိုးသည် အမည်ကို ပေးသည်။ secretKeyRef သည် container ၏ ပတ်ဝန်းကျင် တန်ဖိုးများကို ပေးသည်။ helm ကို run နေသော shell တွင် HTTP_PROXY ကို export လုပ်ရုံဖြင့် ဤ env အပိုင်းကို Pod template သို့ မထည့်ပါ။

Secret ကို ပြောင်းလဲခြင်းသည်လည်း ဘဝစက်ဝန်း ပြောင်းလဲမှုဖြစ်သည်

Secret ဒေတာ ပြောင်းလဲသောအခါ container သည် ၎င်း၏ ပတ်ဝန်းကျင်ကို ပြန်လည် မမွမ်းမံပါ။ အသစ် စတင်သော container များ မွမ်းမံထားသော တန်ဖိုးများ ရရှိရန် ရည်ရွယ်ထားသော restart သို့မဟုတ် rollout ကို စီစဉ်ပါ။ တူညီသော Secret အမည်အောက်တွင် ဒေတာ ပြောင်းလဲခြင်းသည် Deployment ၏ Pod template ကို သူ့ဘာသာ မတည်းဖြတ်ပါ။

application သည် ရွေးချယ်ထားသော proxy ပတ်ဝန်းကျင် ကိန်းရှင်များကို ပံ့ပိုးရမည်။ Helm repository သို့ ဝင်ရောက်ခြင်းနှင့် node တွင် image ဆွဲခြင်းသည် ဤ container ပတ်ဝန်းကျင် အကူအညီ မပေးမီ အလုပ်လုပ်သော သီးခြား သုံးစွဲသူများ ဖြစ်သည်။

ဆက်စပ်ဆောင်းပါးများ