Supoña que o espazo de nomes da versión xa ten un Secret chamado app-outbound-proxy. As súas chaves http_proxy e https_proxy conteñen as URL de proxy completas que necesita a aplicación.

Un gráfico de Helm 3 pode conservar só o nome dese Secret en values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

No modelo Deployment do contedor previsto, faga referencia ás chaves:

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

Isto é un fragmento da especificación do contedor. O Secret debe existir no espazo de nomes do Pod e conter ambas as dúas chaves referenciadas. Os seus valores deben usar o protocolo, o host e o porto do auténtico listener de proxy. Para as solicitudes públicas da aplicación ás que se permite usar un proxy público sen autenticación, construía esas URL a partir dun candidato axeitado na lista de proxies gratuítos; conserve as excepcións directas necesarias.

O valor do gráfico fornece un nome; secretKeyRef fornece os valores de contorno do contedor. Exportar HTTP_PROXY na shell que executa helm non engade por si só esta sección env a un modelo de Pod.

Cambiar o Secret tamén é un cambio de ciclo de vida

Un contedor non refresca o seu contorno cando cambian os datos do Secret. Organice o reinicio ou o rollout previsto para que os contedores recén iniciados reciban os valores actualizados. Cambiar os datos baixo o mesmo nome de Secret non edita por si mesmo o modelo de Pod do Deployment.

A aplicación debe admitir as variables de contorno de proxy escollidas. O acceso ao repositorio de Helm e a descarga da imaxe no nodo son consumidores separados que se executan antes de que este contorno do contedor poida axudar.

Artigos relacionados