Use database CLI to operate databases without either VMs or remote clients

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

[Created on 30 July, 2021]

The original entry (Japanese) is here.

https://logico-jp.io/2021/07/30/use-cli-to-operate-database-without-vms/

 

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) Following our strategy, 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 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, cost 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 "CloudShell".

Overview of Azure Cloud Shell

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

 

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

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

 

However, can CloudShell be deployed on their VNet? 

 

Deploy CloudShell to VNet

Following the document below, CloudShell 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 CloudShell 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 CloudShell environment deployed on VNet.

image-5

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

 

$ cat /etc/issue Linux: CBL (Common Base Linux) Delridge 10 $ $ uname -r Kernel: 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 CloudShell deployed VNet and service deployed VNet via VNet peering. CloudShell 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 used services. Basically, I recommend deploying private endpoint on CloudShell VNet to connect the target database and using the endpoint. For example, both options are available 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-network-scenarios
MySQL (Flexible Server)
https://docs.microsoft.com/azure/mysql/flexible-server/concepts-networking#unsupported-virtual-network-scenarios

 

Conclusion

Startup of VNet deployed CloudShell is slower than that of ordinal CloudShell since Azure relay is used. However, VNet deployed CloudShell 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.