Terraform のプロキシ障害 — ダウンロード、プロバイダー、リモート実行
プロキシが実行の一部でしか機能しない場合に、Terraform レジストリのダウンロード、Git モジュール取得、プロバイダー API 呼び出し、リモート実行を切り分けます。
プロバイダーのダウンロードが成功しても、その後のクラウド API 呼び出しについてはほとんど分かりません。最初に失敗するホスト名と操作から始め、その所有者を特定します。
| 操作 | この経路をたどる |
|---|---|
| レジストリ参照またはインストールのダウンロード | Terraform プロセス、インストール元、プロキシ環境 |
| Git ベースのモジュール取得 | ソース URL と Git トランスポート。SSH と HTTPS では設定が異なります |
| クラウド API 呼び出し | プロバイダープラグインとその SDK のルーティングおよび信頼の設定 |
| リモート実行 | ランナーの環境とネットワークであり、ノート PC のものではない |
CONNECT をサポートする HTTP プロキシであれば、この環境変数の値で HTTPS 宛先に対して正しく選択できます。
HTTPS_PROXY=http://proxy.example:3128変数が示すのは宛先のスキームであり、値が示すのはプロキシのトランスポートです。https:// は、リスナーが TLS を提供し、要求元のクライアントがそれをサポートする場合にのみ使います。プロバイダーは個別のプラグインであり SDK 固有の設定を使えるため、この値はすべてのプロバイダーに対する約束ではありません。
特定した所有者の側で、設定を変える前にエラーの層を切り分けます。プロキシ接続の拒否、プロキシ 407、CONNECT の拒否、証明書エラー、クラウド API の 403 は、それぞれ次の調査を別の形で絞り込みます。フェーズ、宛先、実行環境、最初のエラーをひとまとめに保ちます。
対応する設定をそのコンポーネントに適用します。ノート PC での export はリモートランナーを構成せず、プロキシの資格情報はレジストリやクラウド API の認証にはなりません。