Migrating to Ansible Automation Platform 2.5
Red Hat’s Ansible Automation Platform (AAP) is a tried and tested tool for running Ansible workloads in an enterprise environment. Over the last few years it has undergone many fundamental changes: from the monolithic Ansible Tower, to AAP with Automation Hub, to the integration of Event-Driven Ansible. With the advent of AAP 2.5 there are new, substantial changes – the biggest one is arguably the deprecation of rpm-based installation. This means we need to switch to a containerized setup in the future – the AAP Life Cycle document defines exactly when this is. Full support for AAP 2.4 already ended back in October of 2024.
In this blogpost we inform you about some of the changes to AAP and show you how to setup up a containerized installation of AAP 2.5
Migrate RPM to containerized installation
Rpm-based installation of AAP will be deprecated in the future. Support on RHEL 8 and 9 will stay available, but from RHEL 10 onwards (due mid-2025), there will be no rpm-based installation available anymore. Red Hat does not provide a path for migrations from rpm to containerized install, nor does it provide an upgrade path for containerized installations from version 2.4 to 2.5. (For those of you with a Red Hat subscription, see the details in this knowledge base article.)
Initially, we were tempted to import a database from an AAP 2.5 rpm installation into an AAP 2.5 containerized installation, but we just encountered too many issues with this approach, and since it’s not supported by Red Hat we would not be able to count on their help either. This leads to the conclusion that we have to carry out a fresh installation for AAP 2.5 and start the configuration from zero.
Now, what other points need to considered?
Platform Gateway
AAP 2.5 introduces the component “Platform Gateway”. It’s your Web UI and will be the single entry point for AAP where you can access all services, be it templates (formerly on the controller), rulebook activations (edaserver) or execution environments (automation hub). Access to the APIs on the controller, edaserver and automation hub will be deprecated and you’ll have to direct your API calls for all use cases directly to the platform gateway. Fortunately, it is quite simple to setup an AAP on a single server for small-scale environments.
There are other new features like the automation calculator to help improve your automation planning, Ansible Quick Start which supports AAP newcomers and the integration of Ansible Lightspeed (to explain to you with AI what your own playbooks are actually doing).
Installing AAP 2.5 containerized on a single Server
As with the old setup.sh installer script from the rpm installation, it is still Ansible that is used for installation. You fill up your inventory file like before AAP 2.5, and then run the provided playbooks to install your environment. You can find all the details about the installation at Red Hat’s documentation. Red Hat provides an inventory file inventory for enterprise installation (each component is redundant and resides on a dedicated server, for those of you with a Red Hat subscription, see details in this article) and an inventory file inventory-growth for smaller single-node setups (all components on one single server). The latter is exactly what we want. The inventory file inventory-growth below would install the platform gateway and controller (no automation hub and eda server) on one single host and put your companies SSL certificates to ensure proper https encryption:
cat inventory-growth
[automationhub]
[automationeda]
[database]
aap25.puzzle.ch
[all:vars]
ansible_connection=local
postgresql_admin_username=postgres
postgresql_admin_password='XXXXX'
bundle_install=true
bundle_dir='{{ lookup("ansible.builtin.env", "PWD") }}/bundle'
registry_username='my_redhat_user'
registry_password='XXXXXX'
redis_mode=standalone
custom_ca_cert=/etc/pki/tls/certs/aap25.puzzle.ch.chain.cer #note that this is the intermediate/chain certificate
# Platform gateway
gateway_admin_password='XXXXX'
gateway_tls_cert=/etc/pki/tls/certs/aap25.puzzle.ch.cer
gateway_tls_key=/etc/pki/tls/private/aap25.puzzle.ch.key
gateway_pg_host=aap25.puzzle.ch
gateway_pg_password='XXXXX'
gateway_pg_tls_cert=/etc/pki/tls/certs/aap25.puzzle.ch.cer
gateway_pg_tls_key=/etc/pki/tls/private/aap25.puzzle.ch.key
gateway_redis_tls_cert=/etc/pki/tls/certs/aap25.puzzle.ch.cer
gateway_redis_tls_key=/etc/pki/tls/private/aap25.puzzle.ch.key
# Automation controller
controller_admin_password='XXXXX'
controller_tls_cert=/etc/pki/tls/certs/aap25.puzzle.ch.cer
controller_tls_key=/etc/pki/tls/private/aap25.puzzle.ch.key
controller_pg_host=aap25.puzzle.ch
controller_pg_password='XXXXX'
controller_pg_tls_cert=/etc/pki/tls/certs/aap25.puzzle.ch.cer
controller_pg_tls_key=/etc/pki/tls/private/aap25.puzzle.ch.key
Then run the installation playbook as user ansible:
ansible-playbook -i inventory-growth ansible.containerized_installer.install
This should run smoothly and at the end you should be able access the gateway’s API ping endpoint at https://aap25.puzzle.ch/api/gateway/v1/ping/
curl -u admin:XXXXX https://aap25.puzzle.ch/api/gateway/v1/ping/ | jq
{
"version": "2.5",
"pong": "2025-04-03 15:05:22.332734",
"status": "good",
"db_connected": true,
"proxy_connected": true
}
Conclusion
There are definitely some fundamental changes with the upgrade to AAP 2.5 and the migration to a containerzied installation. But don’t worry, it is still reasonably easy to operate AAP and you will quickly find your way around.
Contact us if you’re interested in setting up AAP 2.5, creating a highly available cluster, setting it up on OpenShift, or fully automating your workflows. We have tons of experience since the early Ansible Tower-days and are looking forward to provide our services to you and your company.