Supposons que l'espace de noms de la release contienne déjà un Secret nommé app-outbound-proxy. Ses clés http_proxy et https_proxy contiennent les URL de proxy complètes dont l'application a besoin.

Un chart Helm 3 peut ne conserver que le nom de ce Secret dans values.yaml :

outboundProxy:
  existingSecret: app-outbound-proxy

Dans le modèle Deployment du conteneur visé, référencez les clés :

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

Il s'agit d'un fragment de spécification de conteneur. Le Secret doit exister dans l'espace de noms du Pod et contenir les deux clés référencées. Ses valeurs doivent utiliser le protocole, l'hôte et le port du véritable écouteur de proxy. Pour les requêtes publiques de l'application autorisées à utiliser un proxy public sans authentification, construisez ces URL à partir d'un candidat approprié de la liste de proxys gratuits ; conservez les exceptions directes nécessaires.

La valeur du chart fournit un nom ; secretKeyRef fournit les valeurs d'environnement du conteneur. Le simple export de HTTP_PROXY dans le shell qui exécute helm n'ajoute pas cette section env à un modèle de Pod.

Modifier le Secret est aussi un changement de cycle de vie

Un conteneur ne rafraîchit pas son environnement lorsque les données du Secret changent. Organisez le redémarrage ou le rollout prévu pour que les conteneurs nouvellement démarrés reçoivent les valeurs à jour. Modifier les données sous le même nom de Secret ne modifie pas, à lui seul, le modèle de Pod du Deployment.

L'application doit prendre en charge les variables d'environnement de proxy choisies. L'accès au dépôt Helm et le tirage de l'image sur le nœud sont des consommateurs distincts qui s'exécutent avant que cet environnement de conteneur puisse les aider.

Articles similaires