Share a Virtual Network to Join Instances from the Same Resource Group
Introduction
When experiencing scalability issues, isolating resources can be a way of extending workloads in the cloud. An alternative solution for scalability issues is to use a multi-tier backend database internally connected to the application frontend.
This guide walks you through the internal connection process between a frontend stack (in this guide we use Bitnami WordPress as an example) and an existing backend (a sample MySQL with replication). Both belong to the same resource group, and the internal connection will be performed by sharing the same virtual network.
Assumptions and prerequisites
This guide focuses on the internal connection of frontend and backend stacks by sharing the same virtual network, both deployed in the same resource group. For the purposes of demonstration, we will use a WordPress and MySQL database with replication deployments as an example.
This guide makes the following assumptions:
- You have an account in the Microsoft Azure Cloud.
- You have basic knowledge about the elements that make up the Azure Resource Manager (ARM). For more information about the elements that make up the ARM, see the Azure official documentation.
- You have a multi-tier solution running in an existing resource group, or you have created a new one during the deployment. (In this guide, we use a MySQL with replication).
Your deployments must meet the following prerequisites:
- All resources have been launched using the ARM, and not the classic deployment mode. Learn how to check your deployment model.
- The new deployment (a Bitnami WordPress stack) must be launched using the same subscription, region (location), and resource group as the existing deployment (in this guide, a Bitnami MySQL with replication deployment).
NOTE: If you have launched an application and a database in different resource groups, check our guide on how to connect instances in different private network using network peering.
Step 1: Deploy an application from the Azure Portal with a shared virtual network
Launch a cloud server with an application running on it. It must meet the prerequisites listed in the “Assumptions and prerequisites” section of the guide. To launch the cloud server, follow the instructions below:
-
Log in to your Microsoft Azure account. You will be redirected to your dashboard.
-
In the left-side menu, select “New” and in the marketplace search box, enter “wordpress bitnami”.
-
Click on the first result. You will see the description of the application on the right side of the screen. To create the new virtual machine, click “Create”.
-
In “Create virtual machine -> Basics” complete the required fields.
IMPORTANT: Remember that the subscription, resource group, and location must be the same as in the existing MySQL with replication deployment.
To make sure that the subscription, resource group, and location match the values you have entered in the database deployment, you can navigate to the “Resource Group -> Deployments” section. To see a summary of the basic configuration, click the database deployment.
-
Choose the virtual machine size depending on your needs.
Once you have selected the size of the virtual machine, you must configure the network. This step is very important because it is when you configure the shared virtual network between the two instances (WordPress and MySQL with replication). The deployments share a VPN, and in order to avoid network conflicts, the system automatically assigns free IPs for both deployments in the address space.
To add the new virtual machine to the existing virtual network, follow the instructions below.
-
Click the “Virtual network” section. You will see a list of the existing virtual networks. Select the virtual network associated to the resource group you have selected in the “Basics” section.
-
Click “Subnet”. It shows the subnet associated to the virtual network you have selected in the previous step.
-
To ensure that the HTTP, HTTPS, and SSH inbound rules are enabled, click the “Network security group” section.
-
For the rest of parameters, you can customize them (if applicable) or leave the values defined by default.
Step 2: Restrict the application access to its public IP address
NOTE: Deleting the database’s public IP address is optional. This step is recommended because, by default, all Bitnami stacks have a configured public IP address. By deleting the public IP address, you ensure that the database can only be reached internally.
Once you have deployed and configured the application with a shared virtual network, you must set its public IP address as the only way of accessing it externally. This step is essential because the goal of this guide is to connect both instances (application and database) internally. To do this, we perform the following actions:
- Check the application and database connection
- Disassociate the database Network Security Group (NSG) from the application network
- Delete the database NSG and its public IP address
Checking the application and database connection
Before deleting the database NSG and its public IP address, we highly recommend to check if the application and database servers are internally connected. If any issues occur, you can debug them and change the database configuration to allow the internal connection between both servers.
The best way to check the connection is to try and connect to the database (backend) from the application (frontend) server. To check the internal connection, follow the instructions below:
- Connect to the WordPress application server through SSH. Learn how to connect to the server with an SSH client in our FAQs.
Once you have connected to the frontend server, the next step is to connect to the backend database (MySQL with replication).
-
In the Resource Group panel, select the “Network interface” of the master node:
-
On the resulting page, note the database’s private IP address:
-
From the shell prompt, run the following command. Remember to replace PRIV_DB_IP_ADDRESS with the IP address you have obtained in the previous step.
$ mysql -u root -p -h PRIV_DB_IP_ADDRESS
You will be prompted to enter the root user password. This is the password you entered during the database deployment.
Now you are connected to the backend database. To ensure that the internal connection between the two instances (frontend and backend) has been successful, you can run the command below:
mysql> show databases;
You will see an output similar to the following:
+--------------------+
| Database |
+--------------------+
| information_schema |
| bitnami |
| mysql |
| performance_schema |
| sys |
+--------------------+
5 rows in set (0.00 sec)
Now you can proceed with the remaining steps.
Disassociating the database NSG from the application network
-
In the Resource Group panel, select the “Virtual network” item from the list of resources:
-
On the resulting page, navigate to the left-side menu and select “Subnets”, then double-click the subnet.
-
You will see a configuration summary for the selected subnet. Click on the “Network security group” section and select “None” in the resulting interface. Click “Save”.
Deleting the database NSG and its public IP address
Now the database NSG is disassociated from the application network. It is time to delete both the database NSG and its public IP address.
-
In the Resource Group panel, select the “Network Security Group” item from the list of resources:
-
On the resulting page, to delete the entire NSG, click “Delete”.
In the Resource Group panel, you should only see the application’s NSG:
-
To delete the database’s public IP address, select it from the list of resources in the Resource Group panel:
-
On the resulting page, click “Dissociate”, and then “Delete”:
Now you should be able to access your application by entering its public IP address in a browser:
[](/images/img/how_to_guides/connect-instances-network-peering-azure/shared-vnet-19.png)
Step 3: Migrate the current WordPress database and specify the new database IP and credentials
To use the new multi-tier database as the backend of the application, you must migrate the current WordPress database and specify the new IP and credentials of the remote database.
Learn how to migrate the current bitnami_wordpress database to the new remote database by following our guide.
To specify the new database IP and credentials, change these values in the /opt/bitnami/apps/wordpress/htdocs//wp-config.php file.
Useful links
To learn more about the topics discussed in this guide, see the links below: