Ansible Automation Platform (AAP) on ARO

Ansible Automation Platform (AAP) is a popular platform for centralizing and managing an organization’s automation content using Ansible as the engine for writing automation code. Prior to deployment, organizations are faced with the decision “where do I want to host this thing?”. In today’s landscape, there are several options between traditional Virtual Machines, running it on OpenShift, or even running it as a managed offering. This walkthrough covers a scenario when a customer wants to run AAP on top of a managed OpenShift offering like Azure Red Hat OpenShift (ARO).

Prerequisites

• Azure CLI
• An Azure Red Hat OpenShift (ARO) cluster version 4.20 or later
• Red Hat OpenShift pull secret from console.redhat.com

High-Level Architecture

Below represents a high-level architecture. It is intended to show a simplified architecture with most components deployed. Please note that components can easily be spread across multiple availability zones to achieve high availability requirements, which is not represented in the overly simplified diagram below:

Prepare your Environment

This step simply sets up your environment with variables to be used during installation:

Create the Prerequisite Projects and Secrets

AAP 2.6 uses a unified deployment model where all components are managed through a single AnsibleAutomationPlatform resource. All components will be deployed in the aap namespace.

1. Create the project for AAP:

2. Create the admin password secret that will be used to authenticate with all AAP components:

Install the AAP Operator

This section covers the installation of the AAP operator. The AAP operator is responsible for all deployment and management actions for all AAP components including the Platform Gateway, Automation Controller, EDA, and Automation Hub.

1. Install the AAP Operator:

   NOTE: The startingCSV field has been removed to allow the operator to automatically select the latest AAP 2.6 version.

2. Verify the operator installation:

   You should see output similar to:

Deploy Ansible Automation Platform

AAP 2.6 introduces a unified deployment model using the AnsibleAutomationPlatform custom resource. This single resource deploys and manages all AAP components including:

• Platform Gateway - Unified API and authentication gateway
• Automation Controller - Job execution and orchestration
• Event Driven Ansible (EDA) - Event-driven automation
• Automation Hub - Private automation content repository

1. Deploy the unified AAP platform:

   NOTE: You can adjust resource requirements and replicas based on your deployment size. See oc explain ansibleautomationplatform.spec for full configuration options.

2. Monitor the deployment progress. The operator will create all AAP components:

   expected output:

   Check all pods in the aap namespace

   expected output:

   The deployment typically takes 15-20 minutes. You should see pods for:

   • Platform Gateway (2 pods)
   • Automation Controller (web, task, postgres pods)
   • EDA (api, workers, scheduler pods)
   • Automation Hub (web, api, worker, content pods)
   • Shared PostgreSQL 15 database
   • Redis cache

3. Verify all components are running:

   Expected output:

Access the AAP Components

Once the deployment is complete, you can access each AAP component through its dedicated route.

1. First, retrieve the actual route URLs:

1. Platform Gateway (Unified API Gateway):

   The Platform Gateway provides a unified API endpoint and authentication for all AAP components. The URL will be in the format:

   Access the Platform Gateway at the URL shown by the route command. Login with $AAP_ADMIN_USERNAME and $AAP_ADMIN_PASSWORD. You will need to provide an AAP subscription via your Red Hat credentials and accept the EULA on first login.

   When you first login, you will se this. Enter your Red Hat Ansible subscription manifest which you can retrieve from https://console.redhat.com/subscriptions/manifests

   

   After entering your subscription and agreeing to the terms and conditions, you will see the Ansible Dashboard.

   

Migration from AAP 2.4 to 2.6

If you have an existing AAP 2.4 deployment and are upgrading to AAP 2.6, be aware of the following important changes:

Key Changes in AAP 2.6

1. Unified Deployment Model: AAP 2.6 uses a single AnsibleAutomationPlatform custom resource instead of separate component CRs. The operator automatically creates individual component resources.

2. Platform Gateway: AAP 2.6 introduces a Platform Gateway that provides unified API access and authentication across all components. This is integrated into the unified deployment model.

3. Operator Channel: The operator channel has changed from stable-2.4-cluster-scoped to stable-2.6-cluster-scoped.

4. Namespace Consolidation: AAP 2.6 can deploy all components in a single namespace (aap) for simplified management, though separate namespaces are still supported.

Migration Steps

For users upgrading from AAP 2.4:

1. Backup Your Configuration: Before upgrading, export critical configurations:

   • Automation Controller: job templates, inventories, credentials, projects
   • Automation Hub: content collections and configurations
   • EDA: rulebook activations and decision environments

2. Update the Operator Subscription:

3. Migration Considerations:

   • Database Compatibility: PostgreSQL databases are generally compatible, but database migrations will run automatically
   • Authentication Changes: Platform Gateway centralizes authentication - existing authentication configurations may need adjustment
   • API Changes: Review API version changes if you have external integrations

4. Verify the Upgrade:

Important Notes

• The upgrade process typically takes 15-30 minutes
• Existing automation jobs will be interrupted during the upgrade
• Plan the upgrade during a maintenance window
• Test thoroughly in a non-production environment first
• Review the AAP 2.6 Release Notes for complete details

Rollback

If you need to roll back to AAP 2.4:

1. Change the operator channel back to stable-2.4-cluster-scoped
2. Restore from backups if necessary
3. Note that rolling back may result in data loss for configurations created in AAP 2.6