Ansible Automation Platform 2 Upgrade: Preparation and Planning

Every day we are edging closer and closer to finally migrating to Ansible Automation Platform 2 (AAP 2). It brings updated architecture, new tools, and an enhanced automation experience that will simplify and modernize your automation journey. Now the time has come to start thoroughly preparing for the upgrade. We are going to talk about how to prepare for AAP 2.3 (the latest released version) update and be ahead of the curve when the day finally comes.

Let’s roll up our sleeves and jump right into it!

Outlining a high-level plan

1. Organization

Being organized can save you so much trouble, so let’s start with that. How will your business be affected by the upgrade? Here are some basic topics you can organize your plan around:

• Let’s talk numbers

There will be cost-related considerations that come with the upgrade. We recommend an analysis that touches on costs, savings, and revenue impact.

• The stakeholders

Consider, address, and assess all internal and external stakeholders for their level of involvement and availability when the time comes. You don’t want to be waiting for someone to cooperate in the upgrade in crucial moments or keep anyone in the dark about the happenings around it.

• Time frames

When assessing the involvement and availability of all stakeholders considered, keep in mind that it can all be done well only if there are concrete time frames accompanying this effort. The when is important, since there are deadlines involved with end of life (EOL) cycles that you need to respect.

• Management

Make sure you manage and execute tasks properly to achieve desired outcomes, and ensure your managers are appropriately educated and informed about what needs to be implemented by the engineers when it comes to the upgrade.

• Metrics

Equip all previous points in this segment with concrete metrics to measure and document your development, success, and potential failures of implementing the upgrade.

2. Environment

The configuration of your environment and conducting a thorough technical inspection is an absolute must. Here are some factors that you can consider:

• Current platform installation

What is your current Ansible Automation Platform 1.x like? Study deployment patterns, integrations, and other details that could be relevant to the upgrade.

• Desired platform installation

Take the previous paragraph and repeat; consider the same factors (deployment patterns, integrations, etc…) for your AAP 2.3 upgrade.

• Stakeholders and their technicalities

Once you have the current and desired platform installation figured out, take this information to your stakeholders, and make sure they are also ready to plan and implement the upgrade.

• Bureaucracy

Make sure your bureaucracy is airtight: ensure compliance, security policy enforcement, and auditing.

3. Automation content

Asses if Ansible roles, Ansible Content Collections, Ansible Playbooks, and Ansible modules are compatible with AAP 2.3:

• Python virtual environments (venv)

Plan, test, and port; decide if user-built execution environments are needed based on the dependencies you need. AAP 2.3 offers great tools that can help you. We highly recommend having full knowledge of how to migrate from venv to Automation Execution Environments.

• Existing automation content

You should retire redundant content and keep or refactor the remaining content. We recommend moving to a collection-only model because of the benefits that come with having a great collection. It includes updates and the use of fully qualified collection names that allow you to have more control over your playbooks.

4. Technical requirements

Review the new technical requirements needed to migrate to AAP 2.3:

• Automation Controller 4.3 (formerly known as Ansible Tower) supports PostgreSQL 12+

• Red Hat Enterprise Linux (RHEL) 8.4+, 9.0+

• Automation Execution Environment is replacing Python virtual environments: you will need Ansible Core 2.14, ee-minimal, ee-supported, ee-2.9

For more detailed or version-specific technical requirements descriptions, click here .

5. Systems and workflows integration

Once you have all the previous paragraphs covered, you can overview the information and ask yourself: How does the migration affect your current workflows? How do we integrate into the existing systems and workflows? To answer these questions, review the management of:

• Platform life cycle

Ask yourself how you can deploy new clusters and provide minimum requirements. That includes how to execute cluster upgrades, what the upgrade cadence is, and what are the nonfunctional requirements and design effects (backups, configuration management, disaster recovery, and high availability).

• Execution environment life cycle

Consider how to manage and distribute ansible-builder definition files and how to provide security-related updates and remain compliant.

• Platform adoption

Plan how to execute external stakeholders support, think about training and onboarding for all involved, and how to tackle execution environments management.

• Content promotion

You will need Automation Execution Environment versioning (test, stage, latest, and release number) and the Automation Hub (container registry) repository structure.

Don’t forget about timing

Time sure does fly, doesn’t it? It makes no sense to prepare well for the upgrade and then miss the deadline of implementation and cause yourself unwanted problems. Timing is equally important.

Let’s cover the basic dates to keep in mind for AAP 2.3:

General availability: November 29, 2022

Full support: June 30, 2023

Maintenance support 1: November 29, 2023

Maintenance support 2: May 31, 2024

You can find a detailed description of every Red Hat Ansible Automation Platform version life cycle here .

Shifting to Automation Execution Environment

They say we should face our biggest fears to conquer them. Well, when it comes to the upgrade, shifting from a Python virtual environment in Ansible Tower to Automation Execution Environment in Ansible Automation Platform is a little bit like that. This is a big change, but a very welcome one, nonetheless. The intention behind this shift is to make it easier to build, reuse and scale automation content. We recommend careful planning to ensure all roles, collections, and playbooks still work after the update. Here are some general tips to help you achieve it:

1. Use a private Automation Hub as the container registry to store execution environments. Automation Controller can sync directly to private Automation Hub, from where you can pull execution environments. Once they are created, you can use them to run jobs and use the Automation Controller UI to specify those you would like to use in your job templates.

2. Make sure execution environments all have the same package versions as your Python virtual environments to streamline the transition.

3. Build a pipeline to create execution environments based on a given inventory. Every team can complete merge requests on the inventory to change their execution environments, with the intention of enabling users and providing a self-service experience. Organization admins in AAP can choose to use execution environments from other registries.

For more information on how to migrate from Python virtual environments to Automation Execution Environment, click here .

Prepare and excel: Updating your playbooks to run on Ansible Automation Platform 2 can be faster

You made it through the preparation plan, great, that is a big first step. “Give me six hours to chop down a tree and I will spend the first four sharpening the axe,” said Abraham Lincoln, and this is how we view preparing for the migration to AAP 2 at XLAB Steampunk. Make sure your “axe” is sharp and ensure your AAP 2 upgrade is going to be smooth sailing after the preparation.

One thing that could really help you speed up the upgrade process of playbooks is Steampunk Spotter , an Ansible Playbook scanning tool with a built-in rewrite function that can turn hours of updating your playbooks to run on newer Ansible versions into mere minutes. Spotter checks if playbooks are compatible with a specific Ansible version, pinpoints issues that need to be fixed and saves time with convenience features like generating a requirements file or by pointing users to the module documentation of a specific Ansible version.

Check out how Spotter can help you update your playbooks to run on newer Ansible versions!

Try it out and find out what else Spotter is capable of.

Interested in Spotter, but don’t know how to start? Explore our Getting started guide.