Helm チャートでプロキシ変数に既存の Secret を使う
シェル変数がコンテナ環境になると仮定せず、Helm 3 の Deployment テンプレートで Secret から完全なプロキシ URL を参照します。
リリースの 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 リポジトリへのアクセスとノードのイメージ取得は別の利用者であり、このコンテナ環境が役立つより前に動作します。