Gebruik 'n bestaande Secret vir proxy-veranderlikes in 'n Helm-grafiek
Verwys na volledige proxy-URL's uit 'n Secret in die Helm 3 Deployment-sjabloon in plaas daarvan om te aanvaar dat 'n shell-veranderlike container-omgewing word.
Veronderstel die release-naamruimte het reeds 'n Secret met die naam app-outbound-proxy. Die sleutels http_proxy en https_proxy bevat die volledige proxy-URL's wat die toepassing benodig.
'n Helm 3-grafiek kan slegs die naam van daardie Secret in values.yaml hou:
outboundProxy:
existingSecret: app-outbound-proxy
Verwys in die beoogde container se Deployment-sjabloon na die sleutels:
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
Dit is 'n fragment van die container-spesifikasie. Die Secret moet in die Pod se naamruimte bestaan en albei verwysde sleutels bevat. Die waardes moet die werklike proxy-luisteraar se protokol, gasheer en poort gebruik. Vir openbare toepassingsversoeke wat 'n publieke proxy sonder verifiëring mag gebruik, bou daardie URL's uit 'n ooreenstemmende kandidaat in die gratis proxy-lys; behou enige vereiste direkte uitsonderings.
Die grafiekwaarde verskaf 'n naam; secretKeyRef verskaf die container se omgewingswaardes. Om bloot HTTP_PROXY in die shell wat helm uitvoer te export, voeg nie hierdie env-afdeling by 'n Pod-sjabloon nie.
Om die Secret te verander is ook 'n lewensiklusverandering
'n Container herlaai nie sy omgewing wanneer Secret-data verander nie. Reël die beoogde herbegin of rollout sodat nuutgestarte containers opgedateerde waardes ontvang. Om data onder dieselfde Secret-naam te verander, wysig nie op sigself die Deployment se Pod-sjabloon nie.
Die toepassing moet die gekose proxy-omgewingsveranderlikes ondersteun. Helm-bergplektoegang en die onttrekking van die node se beeld is aparte verbruikers wat loop voordat hierdie container-omgewing kan help.