Chef のプロキシ設定と compile/converge フェーズの関係
1 つの remote_file アクションのためにグローバルプロキシを変更するときは、レシピのコンパイルとリソース実行のタイミングを考慮します。
previous = Chef::Config[:http_proxy]
Chef::Config[:http_proxy] = 'http://proxy.example.net:8080'
remote_file '/var/tmp/package.zip' do
source 'https://downloads.example.net/package.zip'
end
Chef::Config[:http_proxy] = previous一時的な値は、このごく普通のリソースが何かをダウンロードする前に消えています。
- Compile: トップレベルの Ruby が値を保存し、一時的なプロキシを設定し、
remote_fileを宣言してから値を元に戻します。 - Converge: リソースはその時点で利用可能な設定を使ってアクションを実行します。
適切な内部除外を備えた安定したクライアントプロキシを使えば、このタイミングの問題を避けられます。シェルのワイルドカード規則を前提にせず、インストール済みクライアントの文書化された除外構文を使ってください。許可された公開経路で公開アーティファクトを個別にダウンロードする場合、Chef クライアントに設定済みまたは保持されたプロキシアカウントがなければ、HTTP プロキシ一覧のエントリが安定した HTTP エンドポイントを提供できます。内部除外はそのまま維持してください。アドレスを選んでも、compile と converge がそれを消費する時期は変わりません。
1 つの操作に特別な経路が必要なら、その設定変更と実行を同じスコープに置きます。適切な unified-mode 動作を持つカスタムリソースは選択肢の 1 つですが、Chef::Config はグローバルのままです。ダウンロードが失敗したときと、ファイルがすでに最新のときの両方で元に戻してください。更新通知は無条件には実行されず、例外の後に後続のクリーンアップリソースが決して実行されない可能性があります。
lazy source プロパティが遅延するのはそのプロパティの評価であり、周囲の Ruby 代入ではありません。ダウンロードがまさにその時点に属するなら、compile 時のリソース実行は別個にサポートされた選択肢です。依存関係と通知のタイミングも変わります。宣言順序が分離をもたらすと期待するのではなく、HTTP クライアントがプロキシ設定をいつ消費するかに基づいて選んでください。