Să presupunem că spațiul de nume al versiunii are deja un Secret numit app-outbound-proxy. Cheile sale http_proxy și https_proxy conțin URL-urile complete de proxy de care are nevoie aplicația.

Un chart Helm 3 poate păstra în values.yaml doar numele acelui Secret:

outboundProxy:
  existingSecret: app-outbound-proxy

În șablonul Deployment al containerului vizat, faceți referire la chei:

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

Acesta este un fragment din specificația containerului. Secretul trebuie să existe în spațiul de nume al Pod-ului și să conțină ambele chei menționate. Valorile sale trebuie să folosească protocolul, gazda și portul ascultătorului real de proxy. Pentru cererile publice ale aplicației cărora li se permite să folosească un proxy public fără autentificare, construiți acele URL-uri dintr-un candidat potrivit din lista de proxy gratuite; păstrați excepțiile directe necesare.

Valoarea chartului oferă un nume; secretKeyRef oferă valorile de mediu ale containerului. Doar exportarea HTTP_PROXY în shell-ul care rulează helm nu adaugă această secțiune env într-un șablon de Pod.

Schimbarea Secretului este și o schimbare de ciclu de viață

Un container nu își reîmprospătează mediul când se schimbă datele Secretului. Organizați repornirea sau rollout-ul dorit astfel încât containerele nou pornite să primească valorile actualizate. Schimbarea datelor sub același nume de Secret nu editează prin sine șablonul de Pod al Deployment-ului.

Aplicația trebuie să accepte variabilele de mediu de proxy alese. Accesul la depozitul Helm și extragerea imaginii pe nod sunt consumatori separați care rulează înainte ca acest mediu de container să poată ajuta.

Articole similare