こんばんは。今日は、Azure App Service/Functionsに関する小ネタです。
App ServiceにWebアプリケーションをデプロイし、その裏でさらにデータベースと接続して処理を行う・・といったケースは多いかと思います。
そんな時にいつも思うのが、App Serviceからそれらのリソースにちゃんと想定した経路で接続できているのだろうか・・・ということ。
特に、最近はプライベートエンドポイントやサービスエンドポイント経由でデータベースやストレージに接続するシナリオも多いかと思いますので、プライベートエンドポイント経由で接続していると思ったら実はパブリックアクセスしてた、なんてこともおこりがちです。
今回はそんなときに役立つコマンドを自分の備忘も兼ねて残しておこうと思います。
厳密にはOSやコンテナかどうかなどで使える/使えないが異なるかとは思いますが、今回は、Windows/LinuxのApp Serviceで確認しています。また、クラウドサービスは変化が激しいので、将来的に動作が変わる可能性は十分あると思いますので、あくまで現時点での情報と捉えていただければと思います。
Contents
[前提] pingやnslookupは使えない
前提として、App Serviceではpingやnslookupが使えません。
https://docs.microsoft.com/ja-jp/azure/app-service/web-sites-integrate-with-vnet#tools
というわけで、これらの代替として、以下コマンドが用意されています。（後述の通り、Linuxの場合は別のコマンドが使えるようでした）
| 使えないツール | 代替ツール |
|---|---|
| ping | tcpping |
| nslookup | nameresolver |
こちらにも詳しい説明があります。
疎通確認をする
＜Windowsの場合＞
上記の通り、tcppingコマンドがデフォルトで使えます。
＃コマンド
tcpping xxxx.database.windows.net:1433
＃結果
Connected to xxxx.database.windows.net:1433, time taken: 203ms
Connected to xxxx.database.windows.net:1433, time taken: 156ms
Connected to xxxx.database.windows.net:1433, time taken: 140ms
Connected to xxxx.database.windows.net:1433, time taken: 156ms
Complete: 4/4 successful attempts (100%). Average success time: 163.75ms＜Linuxの場合＞
Bashからtcppingコマンド自体は使えるようだが、上と同じコマンドをうってもダメだった。なんでだろう・・？分かったらまた更新します。
＃コマンド
tcpping xxxx.database.windows.net:1433
＃結果
Bad destination address: xxxx.database.windows.net:1433代わりにtcptracerouteコマンドが使えるようでした。（こちらもBashから）
＃コマンド
tcptraceroute xxxx.database.windows.net 1433
＃結果
1 172.xx.xx.xx 0.121 ms 0.043 ms 0.042 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 40.xx.xx.xx [open] 8.224 ms 1.696 ms 6.340 ms名前解決情報を確認する
<Windowsの場合＞
上の通り、nameresolverが使えます。
nameresolver xxxx.database.windows.net
＜Linuxの場合＞
Bashからはnameresolverは使えません。
代わりに以下のコマンドが使えました。
＃コマンド
getent hosts xxxx.database.windows.net
＃結果
40.xx.xx.xx cr3.eastus1-a.control.database.windows.net xxxx.database.windows.net xxx.privatelink.database.windows.net xxx.database.windows.net xxxx.trafficmanager.netまた、アプリケーションコンテナにSSH接続するとnameresolverは引き続き使えませんが、nslookupやdigが使えました。（すみません、ネットワーク構成を変更したので上の結果とは整合していないですが、同じネットワーク構成であればこちらでも上記と同じ結果が得られる想定です）
＃コマンド
nslookup xxxx.database.windows.net
＃結果
Server: 127.0.0.11
Address: 127.0.0.11#53
Non-authoritative answer:
xxxx.database.windows.net
canonical name = xxx.privatelink.database.windows.net.
Name: xxxx.privatelink.database.windows.net
Address: 10.1.1.4
＃コマンド
dig
＃結果
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> xxxx.database.windows.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53141
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1224
;; QUESTION SECTION:
;xxxx.database.windows.net. IN A
;; ANSWER SECTION:
xxxx.database.windows.net. 300 IN CNAME
xxxx.privatelink.database.windows.net.
xxxx.privatelink.database.windows.net. 10 IN A 10.1.1.4
;; Query time: 21 msec
;; SERVER: 127.0.0.11#53(127.0.0.11)
;; WHEN: Wed Oct 20 17:10:58 UTC 2021
;; MSG SIZE rcvd: 121以上、App Service上で接続先リソースへの疎通、名前解決を行える方法のご紹介でした。
おしまい
コメントを残す