Chapter 2. Prerequisites for Installing Red Hat Ansible Automation Platform on Microsoft Azure 2.1. Azure requirements A subscription for Microsoft Azure. Contributor or Administrator access to that Azure subscription. Access to the Azure comand line interface (CLI). 2.2. Ansible Automation Platform requirements An account on the Red Hat Red Hat Customer Portal ( access.redhat.com ). A specific subscription entitlement for Red Hat Ansible Automation Platform. 2.3. Azure resource quotas and infrastructure limits Microsoft imposes resource limits within each Azure region. The CPU limit is the most likely to impact Red Hat Ansible Automation Platform on Microsoft Azure. Before you install Ansible Automation Platform on Microsoft Azure, ensure that you have capacity to deploy the managed application into your desired region. Refer to Ansible Automation Platform on Microsoft Azure infrastructure usage for infrastructure requirements. 2.3.1. Regional vCPU limits The Azure resources used during the deployment of the managed application temporarily exceed the resource requirements in Ansible Automation Platform on Microsoft Azure infrastructure usage . The Total Regional vCPUs quota is temporarily consumed when deploying the managed application. Every Azure region has a separate Total Regional vCPUs quota. To prevent installation failure, ensure that you have at least 80 DDSv5 and 8 DSV3 vCPUs available in the Azure region where you want to deploy the managed application. The following steps describe how to view the resource quotas for your subscription the Azure console: In the Azure console, search for Quotas and open the My Quotas page. Select the region where you wish to deploy the managed application to view your allocation and usage metrics for that region. Ensure that you have selected a single region. Viewing all regions at once does not show the limitations of a single Azure region. 2.3.2. Regional StandardCore limits The StandardCore limit is a compute metric for the resources that are temporarily consumed when deploying the managed application. It is possible that the Ansible Automation Platform on Microsoft Azure can deploy without hitting the StandardCore limit. When a deployment fails because the consumed resources hit the StandardCore limit, the error message includes container group quota 'StandardCores' exceeded : code: DeploymentFailed message: At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details. details: - code: DeploymentScriptContainerGroupInvalidSettings message: Resource type 'Microsoft.ContainerInstance/containerGroups' container group quota 'StandardCores' exceeded in region 'eastus'. Limit: '10', Usage: '10' Requested: '1'. Requesting StandardCore limit increase The StandardCore metric is not displayed in the My Quotas page in the Azure console. To request the value of your regional limit, contact Microsoft directly. If your deployments fail because the consumed resources reach this limit, you must submit a resource increase request for StandardCore to Microsoft. Only submit a quota increase request if you encounter a deployment failure due to this issue. Use the following information to respond to questions from Microsoft support: Will the container groups be run in Linux or Windows? Linux What will the core and memory be in your Container Group instance? Red Hat recommends 20 cores, 16 GB When will you create all the Container Group Instances? During managed application deployment of Red Hat Ansible Automation Platform on Microsoft Azure How frequent will you create/delete the container groups? Only during managed application deployment of Red Hat Ansible Automation Platform on Microsoft Azure 2.4. Azure resource providers Microsoft uses Azure resource providers as a set of REST operations that enable functionality for a specific Azure service in an Azure subscription. For example, the Key Vault service consists of a resource provider named Microsoft.KeyVault. The resource provider defines REST operations for managing vaults, secrets, keys, and certificates. The resource provider defines the Azure resources you can deploy in your Azure subscription. 2.4.1. Required Azure Resource Providers Ansible Automation Platform on Microsoft Azure installation requires specific Azure Resource Providers registered in your Azure subscription before you attempt a new installation: "Microsoft.Compute" "Microsoft.ContainerService/" "Microsoft.DBforPostgreSQL/" "Microsoft.KeyVault/" "Microsoft.ManagedIdentity/" "Microsoft.Network/" "Microsoft.OperationalInsights/" "Microsoft.OperationsManagement/" "Microsoft.Resources/" "Microsoft.ResourceGraph" "Microsoft.Storage/" "Microsoft.Solutions" 2.4.2. Registering Azure Resource Providers To register Azure Resource Providers, follow the instructions in the Register resource provider section of the Azure documentation. 2.5. Network When you deploy Ansible Automation Platform on Microsoft Azure, you can configure the following networks in the Networking tab of the form: The networking address range (CIDR block) for the VNet that your Ansible Automation Platform on Microsoft Azure application uses. AKS network CIDR blocks. Note Plan your networking configuration before you deploy the Ansible Automation Platform on Microsoft Azure application, because you cannot change it after deployment. 2.5.1. VNet CIDR blocks You can configure the networking address range (CIDR block) for the VNet that your Ansible Automation Platform on Microsoft Azure application uses. You set the CIDR block for the application in the Configure virtual networks section of the form when you deploy Ansible Automation Platform on Microsoft Azure. When you are planning your network configuration, bear the following in mind: The managed application requires at least a /24 Vnet that is divided into four subnets. The subnets have minimum address spacing. Networking entity Minimum CIDR Block VNet /24 Cluster subnet /26 Gateway subnet /28 Database subnet /28 Private link subnet /28 Ensure that the VNet range you configure does not intersect with the default CIDR block for AKS clusters (10.0.0.0/16). The Azure user interface does not prevent you entering this range, but using the default AKS CIDR block for your VNet causes networking issues. To ensure successful network peering and communication between Ansible Automation Platform on Microsoft Azure and your existing networks, your enterprise network ranges must not overlap with the VNet network range. If you do not have any existing Azure VNets, the Azure user interface suggests a default CIDR block and range for the VNet. Do not accept these defaults. Instead, use the network configuration that you have planned. For information about planning the network address range and completing the networking configuration form on deployment, refer to Red Hat Ansible Automation Platform on Microsoft Azure VNet Preparation . 2.5.2. AKS CIDR Blocks You can configure the AKS network CIDR blocks. Traffic that originates from the AKS cluster appears to come from the range configured in AKS, not from the VNET. When you are planning your AKS CIDR block configuration, bear the following in mind: Ensure that these network ranges do not overlap with any existing network range in your enterprise network. Do not use the following reserved network ranges: AKS Reserved CIDR Blocks 169.254.0.0/16 172.30.0.0/16 172.31.0.0/16 192.0.2.0/24 172.17.0.1/26 You can configure the AKS network CIDR blocks in the Configure AKS networks area of the networking tab. Do not accept the default values suggested in the Azure user interface. Instead, use the CIDR blocks that you have planned. The settings have the following requirements: Network Description Requirements Service CIDR A CIDR notation IP range from which to assign service cluster IPs. It must not overlap with any Subnet IP ranges. Requires a /24 block at minimum. A larger block is not necessary. This CIDR block must not intersect with the CIDR of the Pod CIDR block. This CIDR block also must not intersect with the CIDR of the VNET CIDR block. DNS Service IP An IP address assigned to the Kubernetes DNS service. It must be within the Kubernetes service address range specified in serviceCidr . Must be an IP address in the Service CIDR other than the first IP in that range. Red Hat recommends using the first .10 IP address within the Service CIDR block. Pod CIDR A CIDR notation IP range from which to assign pod IPs when kubenet is used. Requires a /19 or larger block. This CIDR block must not intersect with the CIDR of the Service CIDR block. 2.6. Azure Policy Azure Policy is a tool to help organizations enforce compliance of Azure resources to defined standards. For information on using Azure Policy with Ansible Automation Platform on Microsoft Azure, see Azure Policy and Ansible on Azure . 2.7. Entitling your subscription To access your deployment, you need an existing subscription entitlement that you can assign to your Ansible Automation Platform when you first log in. For information on obtaining a subscription entitlement and attaching it to Ansible Automation Platform, see Red Hat Ansible Automation Platform on Microsoft Azure Subscription Entitlement Association .

Commands:
code: DeploymentFailed message: At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details. details: - code: DeploymentScriptContainerGroupInvalidSettings message: Resource type 'Microsoft.ContainerInstance/containerGroups' container group quota 'StandardCores' exceeded in region 'eastus'. Limit: '10', Usage: '10' Requested: '1'.
"Microsoft.Compute" "Microsoft.ContainerService/" "Microsoft.DBforPostgreSQL/" "Microsoft.KeyVault/" "Microsoft.ManagedIdentity/" "Microsoft.Network/" "Microsoft.OperationalInsights/" "Microsoft.OperationsManagement/" "Microsoft.Resources/" "Microsoft.ResourceGraph" "Microsoft.Storage/" "Microsoft.Solutions"