In besteand Secret brûke foar proxy-fariabelen yn in Helm-kaart
Ferwize yn 'e Helm 3 Deployment-sjabloan nei folsleine proxy-URL's út in Secret ynstee fan oan te nimmen dat in shell-fariabele de containeromjouwing wurdt.
Stel dat de namespace fan 'e release al in Secret hat mei de namme app-outbound-proxy. De kaaien http_proxy en https_proxy befetsje de folsleine proxy-URL's dy't de applikaasje nedich hat.
In Helm 3-kaart kin allinnich de namme fan dat Secret yn values.yaml bewarje:
outboundProxy:
existingSecret: app-outbound-proxy
Ferwize yn 'e Deployment-sjabloan fan 'e bedoelde container nei de kaaien:
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 in fragmint fan 'e containerspesifikaasje. It Secret moat bestean yn 'e namespace fan 'e Pod en beide ferwiisde kaaien befetsje. De wearden moatte it protokol, de host en de poarte fan 'e echte proxy-listener brûke. Foar iepenbiere oanfragen fan 'e applikaasje dy't in iepenbier proxy sûnder autentikaasje brûke meie, bou dy URL's fan in passende kandidaat yn 'e list fan fergees proxy's; behâld alle ferplichte direkte útsûnderings.
De kaartwearde leveret in namme; secretKeyRef leveret de omjouwingswearden fan 'e container. Allinnich HTTP_PROXY exportearje yn 'e shell dy't helm rint, foeget dizze env-seksje net ta oan in Pod-sjabloan.
It Secret feroarje is ek in libbenssyklusferoaring
In container ferfarsket syn omjouwing net as de Secret-datum feroarje. Regelje de bedoelde herstart of rollout sadat nij starte containers bywurke wearden krije. Datum ûnder deselde Secret-namme feroarje bewurket op himsels it Pod-sjabloan fan 'e Deployment net.
De applikaasje moat de keazen proxy-omjouwingsfariabelen stypje. Tagong ta it Helm-repository en it lûken fan 'e image op 'e node binne aparte brûkers dy't rinne foardat dizze containeromjouwing helpe kin.