Migrating to Ansible Automation Platform 2: How we did it

In the first article in this series about migrating workloads, we shared key factors we considered when designing Red Hat IT's migration strategy from Ansible Tower to Red Hat Ansible Automation Platform 2. With support for Red Hat Ansible Automation Platform 1.2 (also known as Red Hat Ansible Tower) going end-of-life in September 2023, we started migrating workloads in January 2022.

One thing we needed to consider in our planning was merging two Ansible Tower deployments into one Ansible Automation Platform deployment. We also prioritized self-service automation and a seamless experience for our end users. In this article, we'll cover what we did, how it went, and the new Ansible Automation Platform features we're using.

[ Get the checklist: 5 ways to prepare for migration to Red Hat Ansible Automation Platform 2. ]

Implementing our migration strategy

The implementation involved a significant change in environments. We also ran into a few surprises, which validated our test-test-test approach. Here are some additional details.

Migrating from Python virtual environments to automation execution environments

As we began our migration, the biggest change we encountered was shifting from Python virtual environments in Ansible Tower to automation execution environments in Ansible Automation Platform.

In Ansible Tower, Python virtual environments helped us manage dependencies and execute automation consistently by allowing us to install third-party libraries in an isolated directory instead of installing them globally. Ansible Automation Platform packages Ansible workloads into containers, providing defined, consistent, and portable environments for executing Ansible playbooks and roles.

[ Write your first playbook in this hands-on interactive lab. ]

The goal of this shift is to make it easier for IT teams to build, reuse, and scale automation content. It's a significant change, however, so it required careful planning to ensure our automation content (including roles, collections, and playbooks) would work as expected after the migration. We made several strategic choices to enable this, including:

• Using a private automation hub as the container registry to store our execution environments (about 150 total, split between multiple teams). This plan followed guidelines from Ansible Automation Platform architects.
• Ensuring our execution environments had all the same package versions as our Python virtual environments to streamline the transition.
• Building a pipeline for creating execution environments based on a given inventory. In the interest of enabling users and providing a self-service experience, every team is allowed to complete merge requests on the inventory to change their execution environments. Additionally, since our users are organization administrators in Ansible Automation Platform, they can use other execution environments from other registries if they choose.

[ Learn 5 reasons to migrate to Red Hat Ansible Automation Platform 2 ]

Migration challenges and surprises

Converting all of these environments and building the execution pipeline took us quite a bit of time, partly because of the number of environments involved and partly because some of our end users required older Ansible versions.

We had to resolve some existing jobs that failed when we first made the change. One hurdle along the way was the Secure Shell protocol (SSH) moving from the Ansible Tower nodes to the container level. This change meant we needed to reconfigure our execution environments to mimic the actual host and require secure shell daemon (SSHD) and Kerberos configuration.

We also couldn't migrate credentials because we weren't following the traditional process of fully backing up Ansible Tower data and restoring it into Ansible Automation Platform. This meant we had to go back in and create credentials manually, which also affected our timeline.

Lesson learned: Test, test, test

It took us about seven months to migrate our users and environments from Ansible Tower to Ansible Automation Platform 2. Because of our unique use case, this was a much longer timeframe than most other IT departments will experience with their migrations. We also took additional time to test everything to ensure it worked as intended. In fact, we have just one piece of advice for other enterprise teams: Take it slow.

In a migration of this scale, taking a little extra time to design everything so that you can easily back up and restore it is worth the investment. And then test, test, test to ensure that everything works in your environment.

This approach was also effective from our end users' perspective. They shared feedback with us that nothing was missing from the migration process and that the platform completes tasks faster, so they spend less time waiting for jobs to complete before beginning others. While they did encounter a few minor bugs, we created a strong feedback loop with Red Hat's engineering teams to improve the product through expanded use cases.

[ Want to test your sysadmin skills? Take a skills assessment today. ]

New features: Improved fault tolerance and scalability

Now that we've fully migrated out of Ansible Tower, we're excited to take advantage of new features that will help us improve our automation strategy now and in the future.

From an architecture topology perspective, our Ansible Automation Platform deployment follows the same structure we used in Ansible Tower. Our control nodes reside in Amazon Relational Database Service (RDS), with execution nodes distributed in datacenters. One feature that differs, however, is the automation mesh offered in Ansible Automation Platform. Leveraging this feature provides more fault tolerance across our datacenters.

Additionally, now that our Ansible workloads are running in containers, it's more scalable for the future. We're looking forward to the opportunity to support much bigger workloads with less computing power.

Skip to the bottom of list

Image

Download now

Wrap up

If one thing is certain in IT, it's change. Automation is a journey, and as we continue to grow our use of this technology at Red Hat, we're excited to see how Ansible Automation Platform evolves. We plan to continue strengthening our feedback loop with our engineering teams to deliver better results for our internal teams and for Red Hat customers and partners.

[ Learn more about how to simplify network automation management. ]