Bruk en eksisterende Secret for proxyvariabler i et Helm-diagram

Referer til komplette proxy-URL-er fra en Secret i Helm 3 Deployment-malen i stedet for å anta at en shell-variabel blir containerens miljø.

Anta at utgivelsens namespace allerede har en Secret med navnet app-outbound-proxy. Nøklene http_proxy og https_proxy inneholder de komplette proxy-URL-ene applikasjonen trenger.

Et Helm 3-diagram kan bare oppbevare navnet på den Secret i values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

I den tiltenkte containerens Deployment-mal, referer til nøklene:

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 et utdrag av containerspesifikasjonen. Secret må finnes i Podens namespace og inneholde begge de refererte nøklene. Verdiene må bruke protokollen, verten og porten til den faktiske proxy-lytteren. For offentlige applikasjonsforespørsler som har tillatelse til å bruke en offentlig proxy uten autentisering, bygg disse URL-ene fra en passende kandidat i listen over gratis proxyer; behold alle nødvendige direkte unntak.

Diagramverdien gir et navn; secretKeyRef gir containerens miljøverdier. Bare å eksportere HTTP_PROXY i skallet som kjører helm legger ikke til denne env-delen i en Pod-mal.

Å endre Secret er også en livssyklusendring

En container oppdaterer ikke miljøet sitt når Secret-dataene endres. Legg til rette for den tiltenkte omstarten eller rollout-en slik at nystartede containere får oppdaterte verdier. Å endre data under samme Secret-navn redigerer ikke i seg selv Deployment-ens Pod-mal.

Applikasjonen må støtte de valgte proxy-miljøvariablene. Tilgang til Helm-repositoriet og image-henting på noden er separate forbrukere som kjører før dette containermiljøet kan hjelpe.

Relaterte artikler