Usare un Secret esistente per le variabili proxy in un chart Helm

Fare riferimento agli URL proxy completi da un Secret nel modello Deployment di Helm 3 invece di presumere che una variabile della shell diventi l'ambiente del container.

Supponiamo che il namespace della release contenga già un Secret chiamato app-outbound-proxy. Le sue chiavi http_proxy e https_proxy contengono gli URL proxy completi richiesti dall'applicazione.

Un chart Helm 3 può conservare in values.yaml solo il nome di quel Secret:

outboundProxy:
  existingSecret: app-outbound-proxy

Nel modello Deployment del container previsto, fare riferimento alle chiavi:

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

Questo è un frammento della specifica del container. Il Secret deve esistere nel namespace del Pod e contenere entrambe le chiavi referenziate. I suoi valori devono usare protocollo, host e porta del listener proxy reale. Per le richieste pubbliche dell'applicazione a cui è consentito usare un proxy pubblico senza autenticazione, costruire quegli URL da un candidato adatto nella lista di proxy gratuiti; mantenere eventuali eccezioni dirette necessarie.

Il valore del chart fornisce un nome; secretKeyRef fornisce i valori d'ambiente del container. Esportare solo HTTP_PROXY nella shell che esegue helm non aggiunge questa sezione env a un modello di Pod.

Cambiare il Secret è anche un cambio di ciclo di vita

Un container non aggiorna il proprio ambiente quando cambiano i dati del Secret. Organizzare il riavvio o il rollout previsto affinché i container appena avviati ricevano i valori aggiornati. Cambiare i dati sotto lo stesso nome di Secret non modifica di per sé il modello di Pod del Deployment.

L'applicazione deve supportare le variabili d'ambiente proxy scelte. L'accesso al repository Helm e il pull dell'immagine sul nodo sono consumatori separati che vengono eseguiti prima che questo ambiente del container possa aiutarli.

Articoli correlati