エラーメッセージ
terraform init の実行は、通常スムーズなプロセスです。しかし、TerraformがAWSやAzureなどのプロバイダーを取得するためにHashiCorp Registryと通信できない場合、すべてが停止してしまいます。マシンがインターネットへの明確な経路を欠いているか、ドメインの解決に失敗すると、次の壁に突き当たります：
Error: Failed to query available provider packages
Could not retrieve the list of available versions for provider hashicorp/aws:
could not connect to registry.terraform.io: dial tcp: lookup
registry.terraform.io: no such host
根本原因の特定
Terraformは実質的に虚空に向かって叫んでいる状態で、何の応答も得られません。このエラーはネットワーク層で発生するため、Terraformは registry.terraform.io のIPアドレスすら見つけることができません。これは通常、次の3つの原因に集約されます：
- DNSの失敗： システムのDNSリゾルバーがドメインの変換に失敗しています。
- 企業プロキシ： ファイアウォールがトラフィックを遮断しており、ポート443を介したHTTPSトラフィックを通過させるために特定の環境変数が必要です。
- 完全な隔離： 公開ウェブへの物理的なルートがない、エアギャップ環境で作業しています。
解決策1：手動によるDNSとネットワークの検証
最初のステップは、問題がシステム全体のものか、それともTerraformだけに限定されたものかを判断することです。nslookup または dig を使用して、ホスト名を直接テストします。
nslookup registry.terraform.io
"NXDOMAIN"（存在しないドメイン）という応答が返ってくる場合、DNS設定が壊れていることを示しています。Linuxでは、/etc/resolv.conf を確認してください。Googleの 8.8.8.8 や自社の内部DNS IPなど、信頼できるネームサーバーがリストされていることを確認します。
DNSに問題がないように見えるのに terraform init が依然としてハングする場合は、curlを使用してレジストリとの手動ハンドシェイクを試してください：
curl -I https://registry.terraform.io
解決策2：HTTPプロキシの設定
企業のセットアップでは、セキュリティ上の理由からポート443での直接的なアウトバウンドトラフィックがブロックされていることがよくあります。このような場合、Terraformに対して明示的に会社のプロキシサーバーを指定する必要があります。Terraformコマンドを実行する前に、ターミナルで以下の環境変数を設定してください。
LinuxおよびmacOSの場合：
export HTTP_PROXY="http://proxy.yourcompany.com:8080"
export HTTPS_PROXY="http://proxy.yourcompany.com:8080"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254"
Windows（PowerShell）の場合：
$env:HTTP_PROXY="http://proxy.yourcompany.com:8080"
$env:HTTPS_PROXY="http://proxy.yourcompany.com:8080"
プロキシにログインが必要な場合は、http://user:password@proxy.url:port の形式を使用してください。これらが設定されると、Terraformは指定されたトンネルを介してプロバイダーのリクエストをルーティングします。
解決策3：ローカルファイルシステムミラーの設定
オフライン環境では、レジストリに一切アクセスできないため、異なるアプローチが必要です。接続されているマシンでプロバイダーのバイナリをダウンロードし、セキュリティ保護されたUSBや内部のジャンプボックスなどを介してオフラインサーバーに転送する必要があります。
ファイルを移動した後、CLI設定ファイル（Linux/macOSでは .terraformrc、Windowsでは terraform.rc）を作成し、Terraformにまずローカルを確認するように指示します。
以下のブロックを ~/.terraformrc に記述します：
provider_installation {
filesystem_mirror {
path = "/usr/share/terraform/providers"
include = ["hashicorp/*", "registry.terraform.io/*/*"]
}
direct {
exclude = ["hashicorp/*", "registry.terraform.io/*/*"]
}
}
フォルダ構造がTerraformの期待するものと正確に一致していることを確認してください。以下のようになります：
/usr/share/terraform/providers/registry.terraform.io/hashicorp/aws/5.0.0/linux_amd64/terraform-provider-aws_v5.0.0_x5
検証
修正を確認するために、次の3つのステップを実行してください：
.terraform/フォルダと.terraform.lock.hclを削除して、ローカルキャッシュをクリアします。terraform initを再実行します。- 緑色のチェックマークを確認します：
✔ HashiCorp AWS provider v5.x.x successfully installed。
「Finding latest version...」のステップがタイムアウトせずに素早く完了すれば、正常に復旧しています。
予防策とベストプラクティス
デプロイを安定させるために、以下の習慣を検討してください：
- グローバルキャッシュの有効化： プロバイダーをローカルにキャッシュすることで、帯域幅と時間を節約します。設定に
plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"を追加してください。 - バージョンのロック： 常に
.terraform.lock.hclをGitにコミットしてください。これにより、チームメイトの接続速度やDNSキャッシュが異なる場合に発生する「自分のマシンでは動く」といった問題を防ぐことができます。 - ネットワークルートの監査： 制限されたVPCで構築している場合は、NATゲートウェイまたはインターネットゲートウェイが実際に到達可能であることを確認してください。
ネットワーク境界の設計や複雑なファイアウォールルールのデバッグを行う際、私はよく IPサブネット計算機 を使用します。これは、CIDR範囲を検証し、DNSの幽霊を何時間も追いかける無駄な時間を費やす前に、ゲートウェイが正しい場所にあることを確認する簡単な方法です。