Kutumia Secret iliyopo kwa vigezo vya proksi katika chati ya Helm
Rejelea URL kamili za proksi kutoka kwa Secret katika kiolezo cha Deployment cha Helm 3 badala ya kudhani kuwa kigezo cha shell kitakuwa mazingira ya kontena.
Chukulia kuwa namespace ya toleo tayari ina Secret inayoitwa app-outbound-proxy. Funguo zake http_proxy na https_proxy zina URL kamili za proksi zinazohitajika na programu.
Chati ya Helm 3 inaweza kuweka jina la Secret hiyo pekee katika values.yaml:
outboundProxy:
existingSecret: app-outbound-proxy
Katika kiolezo cha Deployment cha kontena lengwa, rejelea funguo:
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
Hiki ni kipande cha vipimo vya kontena. Secret lazima iwepo katika namespace ya Pod na iwe na funguo zote mbili zilizorejelewa. Thamani zake lazima zitumie itifaki, mwenyeji na mlango wa msikilizaji halisi wa proksi. Kwa maombi ya umma ya programu yanayoruhusiwa kutumia proksi ya umma bila uthibitishaji, jenga URL hizo kutoka kwa mgombea anayefaa katika orodha ya proksi bila malipo; hifadhi vipengele vyovyote vya moja kwa moja vinavyohitajika.
Thamani ya chati hutoa jina; secretKeyRef hutoa thamani za mazingira za kontena. Ku-export HTTP_PROXY tu katika shell inayoendesha helm hakuongezi sehemu hii ya env kwenye kiolezo cha Pod.
Kubadilisha Secret pia ni badiliko la mzunguko wa maisha
Kontena haisahihishi mazingira yake data ya Secret inapobadilika. Panga uanzishaji upya au rollout inayokusudiwa ili kontena zilizoanza hivi punde zipate thamani zilizosasishwa. Kubadilisha data chini ya jina moja la Secret hakkuhariri kiolezo cha Pod cha Deployment chenyewe.
Programu lazima iunge mkono vigezo vya mazingira vya proksi vilivyochaguliwa. Ufikiaji wa hazina ya Helm na kuvuta image kwenye nodi ni watumiaji tofauti wanaokimbia kabla mazingira haya ya kontena kusaidia.