Red Hat Ansible Automation Platform on Microsoft Azure Networking Preparation

VNET

Red Hat Ansible Automation Platform on Microsoft Azure is deployed into its own Azure Virtual Network (VNET). This is required due to the complexities needed for AKS and SRE management of the VNET. SREs need the ability to manage the network infrastructure in the event of an Azure change that could impact the network management of the solution. Red Hat is exploring the possibilities for customers to bring-your-own-VNET, but the challenges of allowing Red Hat SREs management access to a customer's existing VNET currently prevent Red Hat from offering this capability.

When creating the managed application, the workflow allows customers to configure the network CIDR block for the VNET that it deploys. The VNET is divided into four subnets that contain the network-connected infrastructure deployed to run Ansible Automation Platform.

The range that you configure cannot intersect with the default CIDR block for AKS clusters, 10.0.0.0/16. The four subnets have minimum address spacing as well. Those minimums are covered in this article. You may allocate larger block sizes to both the VNET and the subnets, but there is no need to.

This article will help customers in planning for the networking configuration prior to deployment of the managed application.

Azure Console Considerations

The Azure Marketplace onboarding screens for network configuration have behavioral considerations that Red Hat has reported to Microsoft. Ensure that you follow these steps when configuring networking so that your deployment does not experience issues or failure post deployment.

Planning the CIDR Block

Red Hat Ansible Automation Platform on Microsoft Azure allows customers to configure the network CIDR block that it uses when deployed. The managed application will need at least a /24 VNET that is divided into four subnets.

The VNET range that you configure cannot intersect with the default CIDR block for AKS clusters, 10.0.0.0/16. The UI will allow you to set this range, but it will cause networking issues if you use that range. Plan to use a range outside of that block.

The four subnets have minimum address spacing as well. Those minimums are covered in the following section. You may allocate larger block sizes to both the VNET and the subnets, but there is no need to.

This article will help customers in planning for the networking configuration prior to deployment of the managed application.

The VNET can be reduced to a /24 range. The minimums for each of the networking entities are listed below.

Ensure that the ranges are properly calculated prior to filling out the network configuration form. You may use a tool like ipcalc to help properly plan for the CIDR blocks.

If you do not have any existing Azure VNETs, then the UI will default to 10.0.0.0/20 for the VNET (reminder, you will still need to change this range).

You will then be able to enter the VNET and subnets with the appropriate ranges that you intend to use.

Any class A, B, or C networking range should work as long as the range minimums are met. For instance, you may want to use the class B range 172.16.10.0/24 . You would configure the following values within the Networking details screen to align with your network.

Another example using a wider VNET range of /20 may look like the following.

Configuring Networking at Deployment

Once you have your CIDR block plan, then you can move to application deployment. Due to the previously mentioned UI issues, you will need to follow these steps in the order that they are listed to ensure proper deployment. These steps begin once a customer has started the managed application deployment process from the Azure Marketplace.

1. Fill all fields on the “Basic” tab.
2. Click “Next”.
3. In the “Virtual Network” field, click the “Create New” link.
   • Using an existing VNET is not supported.
   • Only the specified CIDR blocks will be respected. Any custom VNET or Subnet names will be ignored by the deployment and their names will be generated by the deployment process.
4. Enter the CIDR block of the VNET (must be /24 or greater).
5. Enter the CIDR block of the cluster subnet (must be /26 or greater).
6. Enter the CIDR block of the appgw subnet (must be /28 or greater).
7. Enter the CIDR block of the private_link subnet (must be /28 or greater).
8. Enter the CIDR block of the database subnet (must be /28 or greater).
9. Click “OK”.
10. Click “Review + create” and proceed with deploying the managed application

AKS Networking Configuration

The networking tab also allows for configuration of AKS network CIDR blocks. This is important since traffic that originates from the AKS cluster will appear to come from the range configured in AKS, not from the VNET configured in the previous section.

Like the managed application VNET, you will want to ensure that these network ranges do not overlap with any existing network range in your enterprise network. Azure also has reserved network ranges that you should not use either.

Reserved CIDR Blocks

Configuration Fields

When creating Ansible Automation Platform on Azure, the networking tab will have three fields that you may configure as you deploy your managed application instance.