Use database CLI to operate databases without either VMs or remote clients
[As of July 30, 2021]
The original entry in English is here.
Japanese edition is here.
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.
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”.
As the following document says, psql (PostgreSQL client) is available on Cloud Shell.
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.
In this document, ARM template is introduced to deploy Cloud Shell on VNet.
When using the ARM template, OID (object id) is required. This value can be derived from the following command.
PS /home/logico> Get-AzADServicePrincipal -DisplayNameBeginsWith 'Azure Container Instance'The ARM template allows us to create Cloud Shell environment deployed on VNet.
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-azureIf 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.0Notes
As the document says, all Cloud Shell regions apart from Central India are currently supported.
As this customer’s system is not deployed in supported regions mentioned above, they have to connect their database with either of the following options.
- Connect between Cloud Shell VNet and service VNet via VNet peering. Cloud Shell VNet is linked to Private DNS used in service VNet.
- 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.
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.
