リリースの namespace に app-outbound-proxy という Secret がすでにあるとします。その http_proxy キーと https_proxy キーには、アプリケーションが必要とする完全なプロキシ URL が入っています。

Helm 3 チャートは values.yaml にその Secret の名前だけを保持できます。

outboundProxy:
  existingSecret: app-outbound-proxy

対象のコンテナの Deployment テンプレートで、キーを参照します。

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

これはコンテナ仕様の断片です。Secret は Pod の namespace に存在し、参照する両方のキーを含む必要があります。その値には、実際のプロキシリスナーのプロトコル、ホスト、ポートを使います。認証なしの公開プロキシの利用が許可された公開アプリケーション要求では、そうした URL を無料プロキシ一覧の適切な候補から組み立ててください。必要な直接除外は残します。

チャートの値は名前を渡し、secretKeyRef はコンテナの環境値を渡します。helm を実行するシェルで HTTP_PROXY を export するだけでは、この env セクションは Pod テンプレートに追加されません。

Secret の変更もライフサイクルの変更です

Secret のデータが変わっても、コンテナは環境を再読み込みしません。新しく起動したコンテナが更新後の値を受け取るように、意図した再起動や rollout を手配します。同じ Secret 名の下でデータを変えても、それだけでは Deployment の Pod テンプレートは編集されません。

アプリケーションは選んだプロキシ環境変数をサポートしている必要があります。Helm リポジトリへのアクセスとノードのイメージ取得は別の利用者であり、このコンテナ環境が役立つより前に動作します。

関連記事