Before You Begin The Deployment - Ansible on Azure

Introduction

Ansible on Azure is a unique type of offering called a Managed Application specific to Microsoft Azure. While "managed" is in the name of the offering, you can think of this model as having "shared management" between Red Hat and a customer, since the deployment sits within the customer's Azure tenant. Both the deployment and management have different management responsibilities based on this model. This article provides an overview of the customer's responsibilities for both deploying and managing Ansible on Azure.

This article provides an overview of all of the planning and tasks that you should perform prior to deploying Ansible on Azure. You will need to plan how Ansible on Azure fits within your Azure tenant, and this preparation will make deploying the solution easier. This article supplements the product documentation and knowledge base article index as a place to get started with Ansible on Azure.

Red Hat Subscription

Subscription Entitlement Activation (REQUIRED)

The Ansible Automation Platform on Azure requires an active entitlement to login to the Automation Controller to begin your automation. There are multiple ways to initiate, access and associate the entitlement with your Red Hat account to begin using the Automation Controller.

The Red Hat Ansible Automation Platform on Microsoft Azure Subscription Entitlement Association article details the steps you must take to :
1. Activate and use your subscription entitlement, and
2. Set up auto-renewal process for your Red Hat Ansible Automation Platform support subscription.

Note: You will be unable to access Ansible Automation Platform after deployment until you complete these steps.

Networking

Pre-Deployment Considerations

Networking preparation is the most important preparation step. This step includes planning the solution's networking ranges and planning for the implications of how your organization will configure user defined routes and configure your firewall(s). If you do not properly plan the networking layout of the managed application, then you can run into failed Azure infrastructure deployment or conflicts with your other networks that cause routing errors. This configuration cannot be changed after deployment, so it is important to be certain of the setup prior to deployment.

Post-Deployment Considerations

Ansible on Azure is not a SaaS offering, and therefor a customer's Azure networking configuration can have a significant impact on the deployment. Each customer's networking configuration is different, and it is possible to make a change that Red Hat cannot monitor or resolve; these changes are the customer's responsibility to configure correctly in order to allow the solution to access the external services, such as container registries and monitoring, that are required for proper function and monitoring.

If your organization uses Virtual Network Appliances, proxies, or custom firewalls, and those devices are not configured to allow network traffic that Ansible on Azure requires, then it can leave the deployment in a broken state where Red Hat is unable to monitor, upgrade, or manage the deployment. It can also cause an outage where your users are unable to access the deployment or automation is unable to run.

If your organization has a custom networking configuration that will require Virtual Network Appliances or a similar networking configuration that prevents the ability for Red Hat SREs to monitor the offering, then Red Hat will make a best effort to help identify the customer's configuration that is the source of the issue. It is ultimately the customer's responsibility to ensure that traffic can flow from the Ansible on Azure managed application to the destinations defined here.

Monitoring

Similar to the networking considerations, Red Hat's ability to monitor an Ansible on Azure deployment is dependent on proper network configuration. A default deployment always has proper connectivity in place for monitoring, but customer networking and routing changes can alter or prevent monitoring from occurring. Red Hat SREs attempt to identify when monitoring stops, however, a customer-introduced networking change can prevent this. It will be up to the customer to ensure that network traffic is restored to allow SRE monitoring.

Upgrades and Planned Outages

Ansible on Azure has a planned upgrade and outage release cycle. Maintenance windows do not mean that your deployment will be out during those windows, but they can be as SREs upgrade both Ansible Automation Platform and the underlying Azure infrastructure during those windows.