Suposem que l'espai de noms de la versió ja té un Secret anomenat app-outbound-proxy. Les seves claus http_proxy i https_proxy contenen les URL de proxy completes que necessita l'aplicació.

Un gràfic de Helm 3 pot conservar només el nom d'aquest Secret a values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

A la plantilla de Deployment del contenidor previst, referencia les claus:

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

Això és un fragment de l'especificació del contenidor. El Secret ha d'existir a l'espai de noms del Pod i contenir les dues claus referenciades. Els seus valors han d'utilitzar el protocol, l'amfitrió i el port del veritable listener de proxy. Per a les sol·licituds públiques de l'aplicació a les quals es permet usar un proxy públic sense autenticació, construeix aquestes URL a partir d'un candidat adequat de la llista de proxies gratuïts; conserva les excepcions directes necessàries.

El valor del gràfic proporciona un nom; secretKeyRef proporciona els valors d'entorn del contenidor. Només exportar HTTP_PROXY a l'intèrpret que executa helm no afegeix aquesta secció env a una plantilla de Pod.

Canviar el Secret també és un canvi de cicle de vida

Un contenidor no refresca el seu entorn quan canvien les dades del Secret. Organitza el reinici o el desplegament previst perquè els contenidors acabats d'iniciar rebin els valors actualitzats. Canviar les dades sota el mateix nom de Secret no edita, per si sol, la plantilla de Pod del Deployment.

L'aplicació ha de suportar les variables d'entorn de proxy escollides. L'accés al repositori de Helm i l'extracció de la imatge al node són consumidors separats que s'executen abans que aquest entorn del contenidor els pugui ajudar.

Articles relacionats