Brug en eksisterende Secret til proxyvariabler i et Helm-diagram
Referer til komplette proxy-URL'er fra en Secret i Helm 3 Deployment-skabelonen i stedet for at antage, at en shell-variabel bliver containerens miljø.
Antag at udgivelsens namespace allerede har en Secret med navnet app-outbound-proxy. Dens nøgler http_proxy og https_proxy indeholder de komplette proxy-URL'er, som applikationen har brug for.
Et Helm 3-diagram kan kun gemme navnet på den Secret i values.yaml:
outboundProxy:
existingSecret: app-outbound-proxy
Referer til nøglerne i den tiltænkte containers Deployment-skabelon:
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 uddrag af containerspecifikationen. Secret skal findes i Pod'ens namespace og indeholde begge de refererede nøgler. Dets værdier skal bruge den faktiske proxy-lytters protokol, vært og port. For offentlige applikationsanmodninger, der må bruge en offentlig proxy uden godkendelse, skal du bygge disse URL'er ud fra en passende kandidat på listen over gratis proxyer; bevar alle nødvendige direkte undtagelser.
Diagramværdien leverer et navn; secretKeyRef leverer containerens miljøværdier. Det er ikke nok at eksportere HTTP_PROXY i den shell, der kører helm — det tilføjer ikke dette env-afsnit til en Pod-skabelon.
Ændring af Secret er også en livscyklusændring
En container opdaterer ikke sit miljø, når Secret-data ændres. Tilrettelæg den tilsigtede genstart eller rollout, så nystartede containere får opdaterede værdier. Ændring af data under samme Secret-navn redigerer ikke i sig selv Deployment'ens Pod-skabelon.
Applikationen skal understøtte de valgte proxy-miljøvariabler. Adgang til Helm-repositoriet og nodens image-træk er separate forbrugere, der kører, før dette containermiljø kan hjælpe dem.