Use database CLI to operate databases without either VMs or remote clients
Published Jul 30 2021 02:17 AM 5,281 Views
Microsoft

[Created on 30 July, 2021]

The original entry (Japanese) is here.

https://logico-jp.io/2021/07/30/use-database-cli-to-operate-databases-without-either-vms-or-remote-c...

 

Inquiry from customer

My customer asked me about the following topic.

 

"We're creating some system on Azure. This system consists of VNet, App Service, and Azure Database for PostgreSQL.
1) The App Service instance is connected to VNet via VNet integration, and private endpoint is deployed on VNet to connect the managed database instance. 
2) Our deployment strategy is to use managed services as many as possible. Following this strategy, we don't want to use any VMs (virtual machine).
3) Furthermore, neither VPN nor ExpressRoute is used to connect between VNet and on-premise environment.
4) Even though using managed database, a few database configuration is required.

So, we would like to use database CLI to maintain the database instance.

In this circumstance listed above, what option can we use?"

According to their comment, their system topology seems the image below.

image-3

Their deployment strategy is reasonable, because...

  • indeed, costs for VMs are small, but both applying security patches to VMs and upgrading OS are mandatory in case of deploying VMs for maintenance.
  • they want to focus on valuable tasks instead of system management.

 

What is an alternative for VMs?

What I proposed to the customer is "Cloud Shell".

Overview of Azure Cloud Shell

https://docs.microsoft.com/azure/cloud-shell/overview

 

As the following document says, psql (PostgreSQL client) is available on Cloud Shell.

Features & tools for Azure Cloud Shell
https://docs.microsoft.com/azure/cloud-shell/features#tools

 

However, can Cloud Shell be deployed on their VNet? 

 

Deploy Cloud Shell to VNet

Following the document below, Cloud Shell can be deployed to VNet.

Deploy Cloud Shell into an Azure virtual network
https://docs.microsoft.com/azure/cloud-shell/private-vnet

 

In this document, ARM template is introduced to deploy Cloud Shell on VNet.

Azure Cloud Shell – VNet
https://azure.microsoft.com/resources/templates/cloud-shell-vnet/

 

When using the ARM template, OID (object id) is required. This value can be derived from the following command.

Get-AzADServicePrincipal -DisplayNameBeginsWith 'Azure Container Instance'

The ARM template allows us to create Cloud Shell environment deployed on VNet.

image-5

As you might know, Cloud Shell container (running on Azure Container Instances) is connected to the subnet of "CloudShellSubnet". Storage account is attached to Cloud Shell container in order to persist content under $HOME. At the time of writing this article, Cloud Shell container seems like this.

 

$ cat /etc/issue
Common Base Linux Delridge 10
$
$ uname -r
4.15.0-1113-azure

 

If using PowerShell, $PSVersionTable allows us to check component versions.

 

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

 

 

Notes

As the document says, all Cloud Shell regions apart from Central India are currently supported.

Virtual network deployment limitations

https://docs.microsoft.com/azure/cloud-shell/private-vnet#virtual-network-deployment-limitations

 

As this customer's system is not deployed in supported regions mentioned above, they have to connect their database with either options.

  1. Connect between Cloud Shell VNet and service VNet via VNet peering. Cloud Shell VNet is linked to Private DNS used in service VNet.
  2. Create another subnet and deploy private endpoint to their database in the subnet.

Which options should be used? It depends upon what services you use. Basically, I recommend deploying private endpoint on Cloud Shell VNet to connect the target database and using the endpoint. For example, both options are applicable in case of MySQL/PostgreSQL Single Server, while the only option is the latter in case of Flexible Server since cross region VNet peering is not supported.

Unsupported virtual network scenarios
PostgreSQL (Flexible Server)
https://docs.microsoft.com/azure/postgresql/flexible-server/concepts-networking#unsupported-virtual-...
MySQL (Flexible Server)
https://docs.microsoft.com/azure/mysql/flexible-server/concepts-networking#unsupported-virtual-netwo...

 

Conclusion

Startup of VNet deployed Cloud Shell is slower than that of ordinal Cloud Shell since Azure relay is used. However, VNet deployed Cloud Shell seems a good option if you have to use VM like environment to maintain service(s) but you don't want to deploy any VMs on VNet.

Co-Authors
Version history
Last update:
‎Jul 31 2021 04:13 PM
Updated by: