Bruk ein eksisterande Secret for proxyvariablar i eit Helm-diagram

Vis til komplette proxy-URL-ar frå ein Secret i Helm 3 Deployment-malen i staden for å anta at ein shell-variabel blir miljøet til containeren.

Anta at namespace-et til utgåva allereie har ein Secret med namnet app-outbound-proxy. Nøklane http_proxy og https_proxy inneheld dei komplette proxy-URL-ane applikasjonen treng.

Eit Helm 3-diagram kan berre ta vare på namnet til denne Secret i values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

I Deployment-malen til den tiltenkte containeren, vis til nøklane:

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

Dette er eit utdrag av containerspesifikasjonen. Secret må finnast i namespace-et til Poden og innehalde begge dei refererte nøklane. Verdiane må bruke protokollen, verten og porten til den faktiske proxy-lyttaren. For offentlege applikasjonsførespurnader som har løyve til å bruke ein offentleg proxy utan autentisering, bygg desse URL-ane frå ein passande kandidat i lista over gratis proxyar; behald alle nødvendige direkte unntak.

Diagramverdien gir eit namn; secretKeyRef gir miljøverdiane til containeren. Berre å eksportere HTTP_PROXY i skalet som køyrer helm legg ikkje til denne env-delen i ein Pod-mal.

Å endre Secret er også ei livssyklusendring

Ein container oppdaterer ikkje miljøet sitt når Secret-dataa endrar seg. Legg til rette for den tiltenkte omstarten eller rollout-en slik at nystarta containarar får oppdaterte verdiar. Å endre data under same Secret-namn endrar ikkje i seg sjølv Pod-malen til Deployment-en.

Applikasjonen må støtte dei valde proxy-miljøvariablane. Tilgang til Helm-repositoriet og image-henting på noden er separate forbrukarar som køyrer før dette containermiljøet kan hjelpe.

Relaterte artiklar