ayumin.log

読みにくかったら脳内sedで整形してね

TerraformでAzureのVMを用意しようとしたらハマった話

2022/3/4 追記

以下の対応をした後、git push 時に名前解決ができない問題が発生した。

/etc/resolv.cof には問題なくnameserverの設定があるため原因は分からないが、DNS周りに問題が出る可能性がある。

きっかけ

ICTSC の勉強をしようと思い、せっかくなのでAzureの勉強ついでにTerraformで構成を管理しようと思った。

が、そこで結構辛いハマり方をしたので備忘録として残しておく。

環境

  • WSL2 on windows11
  • Terraform 1.1.5
  • azurevm provider 2.96.0

結論

結論から言うと、WSLのネットワーク特有の問題だった。

解決方法は以下とその後に続く議論を参照。

github.com

簡単に言えば、wslでのresolv.confの自動生成を止め、代わりにネームサーバを固定してやれば良いらしい。

自分の設定は以下。

/etc/wsl.conf

[network]
generateResolvConf = false

[boot]
command = printf 'nameserver 8.8.8.8\nnameserver 8.8.4.4\n' >> /etc/resolv.conf

この後PowershellでWSLをシャットダウンする。

powershell

wsl --shutdown

後は通常通りに使ってOK。正しく設定がされているかは、`cat /etc/resolv.conf' を確認してやると良い。

原因究明

状況把握

結構ざっと書いていたので、どこまで再現性があるかコメントアウトしながら確認したところ、

  • Provider のみの環境であればplanが通る
  • resource group を作ろうとするとplanがハングする

ということが確認できた。

ログ確認

次にログを見てみた。

$ terraform init
$ TF_LOG=TRACE terraform plan
...(省略)
# <subscription_id> はサブスクリプションIDで、環境によって変わるので適宜読み替え
2022-02-16T00:57:38.418+0900 [DEBUG] provider.terraform-provider-azurerm_v2.96.0_x5: AzureRM Response Error: Get "https://management.azure.com/subscriptions/<subscription_id>/providers?api-version=2016-02-01": dial tcp: lookup management.azure.com on 172.24.208.1:53: cannot unmarshal DNS message for https://management.azure.com/subscriptions/<subscription_id>/providers?api-version=2016-02-01: timestamp=2022-02-16T00:57:38.418+0900
...(省略)

この時点で、接続に失敗していそうなことは分かったものの、

という状態だったので、ネットワークの問題を疑いはしなかった。

アーキテクチャ確認

まさかないとは思ったものの、アーキテクチャ依存の問題を考え手元にあったm1 macで実行してみた。

するとなぜか成功した(!?!?!?!?) この時点でWSL固有の問題であることを疑い始める。

これがヒット、上で紹介したGitHub のissuesが見つかった。

GitHubのissueが立っていて助かった

もしissueが立ってなかったら確実に気づけなかった。providerのGitHubのissueぐらいは確認するが、WSLまでは気にしていなかった。

こんなこともあるんだなと思い急いでブログに備忘録を残している。

こういうのってterraformのprovider側にもissueたてておいた方が良いのだろうか。