Použití existujícího Secret pro proxy proměnné v Helm chartu

Odkazujte na úplné proxy URL ze Secret v šabloně Deployment pro Helm 3, místo abyste předpokládali, že se proměnná shellu stane prostředím kontejneru.

Předpokládejme, že namespace vydání už obsahuje Secret s názvem app-outbound-proxy. Jeho klíče http_proxy a https_proxy obsahují úplné proxy URL, které aplikace potřebuje.

Helm 3 chart může ve values.yaml uchovat jen název tohoto Secret:

outboundProxy:
  existingSecret: app-outbound-proxy

V šabloně Deployment zamýšleného kontejneru na klíče odkažte:

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

Toto je fragment specifikace kontejneru. Secret musí existovat v namespace Podu a obsahovat oba odkazované klíče. Jeho hodnoty musí používat protokol, hostitele a port skutečného proxy listeneru. Pro veřejné požadavky aplikace, kterým je povoleno použít veřejný proxy bez ověření, sestavte tyto URL z odpovídajícího kandidáta v seznamu bezplatných proxy; zachovejte všechny potřebné přímé výjimky.

Hodnota chartu dodává název; secretKeyRef dodává hodnoty prostředí kontejneru. Pouhý export HTTP_PROXY v shellu, který spouští helm, tuto sekci env do šablony Podu nepřidá.

Změna Secret je také změnou životního cyklu

Kontejner při změně dat Secret svého prostředí neobnoví. Zařiďte zamýšlený restart nebo rollout, aby nově spuštěné kontejnery dostaly aktualizované hodnoty. Změna dat pod stejným názvem Secret sama o sobě šablonu Podu v Deployment neupraví.

Aplikace musí podporovat zvolené proxy proměnné prostředí. Přístup k repozitáři Helm a stažení image na uzlu jsou samostatní spotřebitelé, kteří běží dřív, než jim toto prostředí kontejneru může pomoci.

Související články