Suponha que o namespace da versão já tenha um Secret chamado app-outbound-proxy. As suas chaves http_proxy e https_proxy contêm os URL de proxy completos de que a aplicação precisa.

Um chart Helm 3 pode guardar apenas o nome desse Secret em values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

No template Deployment do contentor pretendido, referencie as 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 é um fragmento da especificação do contentor. O Secret deve existir no namespace do Pod e conter ambas as chaves referenciadas. Os seus valores devem usar o protocolo, o anfitrião e a porta do verdadeiro listener de proxy. Para pedidos públicos da aplicação autorizados a usar um proxy público sem autenticação, construa esses URL a partir de um candidato adequado na lista de proxies gratuitos; mantenha as exceções diretas necessárias.

O valor do chart fornece um nome; o secretKeyRef fornece os valores de ambiente do contentor. Apenas exportar HTTP_PROXY na shell que executa o helm não acrescenta esta secção env a um template de Pod.

Alterar o Secret também é uma alteração de ciclo de vida

Um contentor não atualiza o seu ambiente quando os dados do Secret mudam. Organize o reinício ou o rollout pretendido para que os contentores recém-iniciados recebam os valores atualizados. Alterar os dados com o mesmo nome de Secret não edita, por si só, o template de Pod do Deployment.

A aplicação tem de suportar as variáveis de ambiente de proxy escolhidas. O acesso ao repositório Helm e a obtenção da imagem no nó são consumidores separados que correm antes de este ambiente do contentor poder ajudar.

Artigos relacionados