Red Hat SummitChapter 6. Support for Red Hat Ansible Automation Platform on Microsoft Azure
Ansible Automation Platform on Microsoft Azure is a managed application, supported and maintained by Red Hat. Due to the architecture of the application and the deployment strategy in Azure, there are some situations where customizing and changing some aspects of the configuration could lead to a change in the responsibilities of some components.
Azure Virtual Appliance Routing with Ansible Automation Platform on Microsoft Azure
As an Ansible Automation Platform on Microsoft Azure user, you can configure the Ansible Automation Platform network to peer your own network. By doing so, you can grant access from the Ansible Automation Platform instance to all the assets associated with your own network that you want to manage. Also, you can route all the Ansible Automation Platform traffic to your own Virtual Network Appliances to control, audit, or block traffic from the Ansible Automation Platform instance to the internet. To do this, you must allowlist the URL for Ansible Automation Platform to work properly.
For more information about Azure Virtual Appliance Routing, see the Azure Virtual Appliance Routing with Ansible Automation Platform on Azure article on the Red Hat customer portal.
Private DNS Zones
Ansible Automation Platform on Microsoft Azure uses Azure’s managed DNS services when deployed.
To use private DNS records that cannot be resolved publicly, you can either use Azure Private DNS zones that are peered to the managed application VNET, or you can make a submit request to Red Hat to submit DNS zones that must be forwarded to a customer-managed private DNS server.
A limitation of Private DNS zones is that only one instance of a given zone may be linked to a Virtual Network. Attempting to link zones that match the names of Private DNS zones in the managed resource group causes conflicts. Microsoft recommends consolidating DNS records into a single zone to work around this limitation.
You can replicate the records from the zones in the managed resource group into your own instance of the Private DNS zone. You can then unlink Private DNS zones in the managed resource group from the Virtual Network and replace it with your own instance of the Private DNS zone.
Failure to properly maintain the records in the Private DNS zone can prevent the managed application from operating.
The Azure Kubernetes Service (AKS) Private DNS zone cannot be customer managed and still allow Red Hat to update or upgrade the managed AKS that is a part of this offering. To allow Red Hat to upgrade the customer AKS to the latest version during the maintenance windows, do not unlink the <GUID>.privatelink.<region>.azmk8s.io Private DNS zone. For more information on this limitation, see "CreateOrUpdateVirtualNetworkLinkFailed" error when updating or upgrading an AKS cluster in the Microsoft Azure documentation.
To work around this limitation, Red Hat allows you to manage A and CNAME records in the Private DNS zones in the managed resource group. Any records that you put in the Private DNS zones in the managed resource group are visible to the Red Hat SREs. If you decide to use the Private DNS zones in the managed resource group, you are responsible for updating them with the records you need. Customer supplied records are not backed up as a part of the disaster recovery process. Removing any Azure supplied records can cause network connectivity issues with Ansible Automation Platform on Microsoft Azure.
For more information about working with Private DNS zones, see Private DNS with Red Hat Ansible Automation Platform on Microsoft Azure on the Red Hat customer portal.
Microsoft Azure Policy
In some situations, using Azure Policy to enforce, for example, tagging rules and conventions, can adversely affect the Resource Group where the components of Ansible Automation Platform on Microsoft Azure reside. The enforcement of Azure Policy could prevent changes, impact operations, or block deployment of new components in the Resource Group. These situations are identified by Red Hat during maintenance or daily operations. You must exclude the enforcement of Azure Policy, for example by using exceptions, on resources associated with the managed application.
For more information about working with Azure Policy, see the Azure Policy and Ansible on Azure article on the Red Hat customer portal.
6.1. Limited support status
Customers may implement Azure infrastructure changes or policies that negatively affect the functionality of the service and Red Hat’s ability to monitor and service it. In such scenarios, the deployment can transition into a limited support status. A deployment may move to a limited support status for many reasons, including the following scenarios:
- Inactive Ansible subscriptions
Red Hat issues subscription entitlements through the application deployment process. The entitlement expires one year after it is issued. Customers are emailed prior to expiration to renew the entitlement. This process issues a new entitlement for the next year and can be imported into Ansible Automation Platform.
- Failure to renew
- When an entitlement expires, customers can continue to use Ansible Automation Platform on Microsoft Azure. However, Red Hat support requires a valid entitlement before assisting with support issues.
- Changes to customized policies
Ansible Automation Platform on Microsoft Azure runs on infrastructure within a customer’s Azure tenant. This means that customer Azure policies can affect the deployment and function of the platform. Given the flexibility of Azure policy definitions, it is impossible to list all policies that can cause infrastructure or operational issues with the platform. When those events happen, the Red Hat SRE team can help identify the policy causing the issue, and suggested remediation. That remediation may require customer policy changes in order for the managed application to function correctly.
- Failure to remediate
- When a policy conflict arises, the Red Hat team reaches out to the customer to remediate. Some of these changes are time sensitive and can impact the platform’s operational function. The Red Hat Site Reliability Engineering (SRE) team will pause maintenance and upgrades until the customer resolves the policy issues.
- Changes to firewall and network configurations
When configuring egress routes from Ansible Automation Platform on Microsoft Azure, customers are required to route traffic to a set of domains on the public internet used for the deployment, monitoring and maintenance of the platform.
- Failure to set up
- The Ansible Automation Platform on Managed Azure will be in a state where it cannot be monitored or serviced by the Red Hat SRE team.
- Changes to quota limits
A prerequisite for Ansible Automation Platform on Microsoft Azure requires adequate capacity to deploy the managed application in the selected region. Microsoft imposes restrictions on limits (CPU) in each region. It is expected that the customers set up their infrastructure with the specifications as listed in the Product Documentation.
- Failure to remediate
- As the Red Hat SRE team perform regular maintenance and improvements, the quota limitations in the region could prevent them to manage the deployment consistently and can eventually result in an inability to manage the offering.
- Incorrect CIDR ranges
During initial deployment, customers can configure networking address range (CIDR block) for the VNet the Ansible Automation Platform uses. After configuration, when you have created the network, you cannot change CIDR blocks. To male a change you must redeploy the managed Ansible Automation Platform application with the configurations specified in the documentation.
- Failure to remediate
- While the Azure user experiences allow customers to set CIDR blocks of choice, the use of the smaller CIDR ranges smaller than our guidelines can create the circumstance that your deployment is in limited supported state where the platform is unable to scale for both automation and management workloads.
