この記事は2021/07/30現在の情報に基づいています。将来の機能追加や変更に伴い、記載内容との乖離が発生する可能性があります。
問い合わせ
例によって、以下のような問い合わせをもらった。
VNetにPrivate Endpointで接続したデータベース (Azure Database for PostgreSQL Single Server) やApp Serviceなどのマネージドサービスを使ってシステムを構成している。なお、このVNetはVPN、ExpressRouteと接続しておらず、今後もその予定はない。当然ながら、Databaseインスタンスには外部インターネットからのアクセスを許容していない。このような状況下で、データベースクライアントを使ってデータベースを操作したいのだが、どうすればよいか。可能な限りマネージドサービスを使う方針（どうしようもない場合には最終手段としてVMを立てるが）なので、VMを立てたくない。何かよい方法はないか？
よくあるこんなトポロジーのよう。
おねだん的にはそれほど高いものではないが、VMを立てるとなると、セキュリティパッチの適用やアップグレードが必要になるため、できるだけマネージドサービスを使い、本来の対象であるデータベースやアプリケーションのみをお守りしたい、ということのよう。
何が使えそうか？
ここでVMの代わりになるものがCloud Shell。Cloud Shellには以下のドキュメントに記載がある通り、PostgreSQLクライアント (psql) もある。
Azure Cloud Shell の機能とツール / Features & tools for Azure Cloud Shell
https://docs.microsoft.com/azure/cloud-shell/features#tools
VNetに接続する
以下のドキュメントに従って構成すると、VNetにCloud Shellをデプロイし、接続できる。
Azure 仮想ネットワークに Cloud Shell をデプロイする / Deploy Cloud Shell into an Azure virtual network
https://docs.microsoft.com/azure/cloud-shell/private-vnet
構成にあたって以下のARMテンプレートが案内されている。
Azure Cloud Shell – VNet
https://azure.microsoft.com/resources/templates/cloud-shell-vnet/
この中でOID (Object ID) を指定するように求められるが、以下のコマンドで取得したidの値を使う必要がある。
Get-AzADServicePrincipal -DisplayNameBeginsWith 'Azure Container Instance'
ARMテンプレートを実行すると、以下のような構成のVNetができあがる。
CloudShellSubnetにはCloudShellのContainerが接続され、そのCloudShell Containerは$HOME以下を永続化するためのStorage Accountをアタッチしている。現時点で、CloudShellのContainerは以下の環境のよう。
$ cat /etc/issue
Linux: CBL (Common Base Linux) Delridge 10
$
$ uname -r
Kernel: 4.15.0-1113-azure
PowerShellなら$PSVersionTableを使ってバージョンを確認できる。
PS /home/logico> $PSVersionTable
Name Value
---- -----
PSVersion 7.1.3
PSEdition Core
GitCommitId 7.1.3
OS Linux 4.15.0-1113-azure #126~16.04.1-Ubuntu SMP Tue Apr 13 16:55:24 UTC 2021
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
注意点
Cloud ShellをVNetにデプロイ可能なのは、以下のリージョンのみである。具体的には、サポートされているストレージリージョンから、インド中部を除いたリージョン。現時点では東西日本リージョンにはデプロイできない。
| 領域 | リージョン |
|---|---|
| アメリカ | 米国東部、米国中南部、米国西部 |
| ヨーロッパ | 北ヨーロッパ、西ヨーロッパ |
| アジア太平洋 | 東南アジア |
上記リージョン以外にサービスを構成している場合、以下の2方法でCloudShellからアクセスするできるようにする必要がある（当然リージョン間の通信が発生する）。
- リージョン間でVNet Peeringを構成し、Private Endpoint作成時に統合したプライベートDNSをVNet（今回の場合はCloud ShellがデプロイされたVNet）に紐付ける
- 仮想ネットワークのリンク / Link the virtual network
https://docs.microsoft.com/azure/dns/private-dns-getstarted-portal#link-the-virtual-network
- 仮想ネットワークのリンク / Link the virtual network
- Cloud ShellをデプロイしたVNetにDatabaseへのPrivate Endpointを構成する
利用サービスによって、リージョン間のVNet Peeringを使ってアクセスできない場合がある点に注意が必要。例えばMySQL/PostgreSQL Single Serverの場合は前者、つまりリージョン間のVNet Peeringでも接続できるが、Flexible Serverの場合、リージョン間のVNet Peeringをサポートしないため、後者の方法をとらざるを得ない。
基本的にはVNet Peeringするのではなく、Private Endpointを構成するほうがよいと思われる。
サポートされない仮想ネットワークのシナリオ / Unsupported virtual network scenarios
PostgreSQL (Flexible Server)
https://docs.microsoft.com/azure/postgresql/flexible-server/concepts-networking#unsupported-virtual-network-scenarios
MySQL (Flexible Server)
https://docs.microsoft.com/azure/mysql/flexible-server/concepts-networking#unsupported-virtual-network-scenarios
まとめ
Azure relayを使うため、通常のCloud Shellよりも立ち上がりに時間がかかる点はデメリットではあるが、管理用VMを置かずにマネージドサービスだけでなんとかしたいという場合には、一つの方法かもしれない。
Logico Inside 