2022 年の最後は反省 *1。
事のいきさつ
これを試そうとした。
Azure Container Apps を VNET にデプロイするやーつ。
ごくごく普通にドキュメント通りにやればいいだけ。
Azure ポータルからも Azure CLI からもできる、と書いてある。
これを読んで、普段いろんなリソースをつないで VPN 接続もできる VNET に Azure Container Apps のデプロイしてみた。
︙
︙
ダメ。
むむむ、なぜかデプロイできない。何か設定が足らないのか、テナント制限なのか、日ごろの行いか。。。https://t.co/GyPoF9o28L
— ほりひろ loves <⚡> (@hori__hiro) 2022年12月25日
タイムアウトするという謎(当時は)の事象。
The resource provision operation did not complete within the allowed timeout period.
曰く、リソースのデプロイが所定の時間内に終わらなかった、と。
詳細もよくわからない。
「たまたまプラットフォーム側に負荷が高いだけ?」と思って何度かトライしても結果は一緒。
Azure CLI からやってみる。
︙
︙
やっぱりダメ。
もう少しヒントがでた。
ErrorCode: ManagedEnvironmentConnectionBlocked, Message: Fail to create managed environment because outbound connectivity was blocked, refer to https://go.microsoft.com/fwlink/?linkid=2198255 for more detail.
何やら、Outbound 接続に問題がある様子。
でもこれ以上はわからない。
テナントを疑ってみる
デプロイ先の VNET が、普段検証作業をしている割と厳しめなテナント*2にあるので、別のテナントで試してみる。
︙
︙
一発で成功。
ん?元のテナントは何かの制限をされてる?
でも社内の人は同じテナントを使っているはずなのに、こんなトラブル聞いたことない。
VNET を疑ってみる
デプロイ失敗した VNET と同じテナントに新しい VNET を作って、新 VNET の方にデプロイしてみる。
︙
︙
こちらも成功。
同じテナントなのに。
てことは、デプロイしようとしている VNET リソース固有の問題か。
問題解決は突然に
完全に VNET リソースが怪しいので、各サブネットにつけられてた NSG を片っ端から外したり、全ブレード*3をくまなく調査。
ふと初心に戻り [概要] ブレードを開いた時に目が行った。
そう、この VNET リソース、DNS サーバーを独自に設定している。
なんでかっていうと、 手元の PC でこの VNET 内にある Private Endpoint の動作確認等のために VPN でつなぐことがあるため。
同じ VNET 内に Azure Container Instances で DNS フォワーダーを立てて、その IP アドレスを VNET の DNS サーバーとしていた。
この DNS フォワーダーは普段シャットダウンしてて、PC から VPN する時だけ起こしている。
DNS フォワーダーの話はこちら。
uncaughtexception.hatenablog.com
そして今は Container App をデプロイしたかっただけで、VPN 接続はしてないので、当然 DNS フォワーダーは起こしていない。
あー、、、完全にこれだなー。。。
︙
︙
一発 OK。
、、、 ですよね。
反省
自分がやった設定くらいは覚えておけ!
唯一得られた知見は、Container Apps Environment を VNET にデプロイする時、VNET の DNS 設定に従って何らか Outbound 通信が発生している、ということ。
まぁ、普通は DNS サーバー設定をいじってても名前解決できる状態にしとくだろうから、デプロイできるんだろうけど。
以上。
よいお年を。