Použitie existujúceho Secret pre proxy premenné v Helm charte

Odkazujte na úplné proxy URL zo Secret v šablóne Deployment pre Helm 3 namiesto predpokladu, že sa premenná shellu stane prostredím kontajnera.

Predpokladajme, že namespace vydania už obsahuje Secret s názvom app-outbound-proxy. Jeho kľúče http_proxy a https_proxy obsahujú úplné proxy URL, ktoré aplikácia potrebuje.

Helm 3 chart môže vo values.yaml uchovávať len názov tohto Secret:

outboundProxy:
  existingSecret: app-outbound-proxy

V šablóne Deployment zamýšľaného kontajnera odkážte na kľúče:

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 špecifikácie kontajnera. Secret musí existovať v namespace Podu a obsahovať oba odkazované kľúče. Jeho hodnoty musia používať protokol, hostiteľa a port skutočného proxy listenera. Pre verejné požiadavky aplikácie, ktorým je povolené používať verejný proxy bez overenia, zostavte tieto URL z vhodného kandidáta v zozname bezplatných proxy; zachovajte všetky potrebné priame výnimky.

Hodnota chartu poskytuje názov; secretKeyRef poskytuje hodnoty prostredia kontajnera. Samotné exportovanie HTTP_PROXY v shelli, ktorý spúšťa helm, túto sekciu env do šablóny Podu nepridá.

Zmena Secret je tiež zmenou životného cyklu

Kontajner neobnoví svoje prostredie, keď sa zmenia údaje Secret. Zabezpečte zamýšľaný reštart alebo rollout, aby novo spustené kontajnery dostali aktualizované hodnoty. Zmena údajov pod rovnakým názvom Secret sama o sebe neupraví šablónu Podu v Deployment.

Aplikácia musí podporovať zvolené proxy premenné prostredia. Prístup k úložisku Helm a sťahovanie obrazu na uzle sú samostatní spotrebitelia, ktorí bežia skôr, než im toto prostredie kontajnera môže pomôcť.

Súvisiace články