Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 1. Overview
The Ansible Automation Platform 1.2 to Ansible Automation Platform 2 migration guide provides an opinionated methodology on how to approach a side-by-side migration using the Ansible Automation Platform installer. Throughout this guide, you’ll be provided steps to follow that ensure the process of backing up, importing and upgrading to Ansible Automation Platform 2 is a success. This reference architecture is best suited for system and platform administrators looking to migrate to the latest version of Ansible Automation Platform 2.
This side-by-side migration reference architecture consists of having two environments, Environment A and Environment B, where all the data from your Environment A Ansible Automation Platform 1.2 environment gets migrated and upgraded to a new Environment B Ansible Automation Platform 2 replacement environment.
The high level approach of the platform migration process:
- Creates a full Ansible Automation Platform 1.2 data backup using the Ansible Automation Platform installer on Environment A
- Imports the full Ansible Automation Platform data backup to the new and empty replacement Ansible Automation Platform 1.2 environment control plane (Environment B)
- Upgrades Environment B using the Ansible Automation Platform 2 installer from its Ansible Automation Platform 1.2 version
- Deploy automation mesh execution and hop nodes in Environment B
Once the infrastructure is successfully migrated, the focus shifts to migrating your Python virtual environments in your Ansible Automation Platform 1.2 environment from Environment A to automation execution environments that will be used within your newly available Ansible Automation Platform 2 environment on Environment B. This one-time effort opens the door to take advantage of the latest Ansible Automation Platform 2 capabilities and the ability to execute consistent automation across multiple platforms with reduced operational overhead.
The high level execution environment adoption process consists of:
- Exporting custom virtual environments from Ansible Automation Platform 1.2 on Environment A
- Comparing each exported virtual environment against Ansible 2.9 base execution environment on Environment A
- Creating new execution environments using the Ansible 2.9 execution environment plus the additional dependencies not included that were exported by the virtual environment
- Attaching the new execution environment(s) to corresponding Job Templates on Environment B
This document shows an opinionated reference environment showing a holistic migration approach which helps customers understand how they can retain their job run history and platform objects between the two clusters in a complex architecture. Based upon your existing architecture and requirements, the migration process may be further simplified. In many cases, the default Ansible Automation Platform installer values are sufficient. The migration process documented here applies to both simple and complex environments.
Customers migrating from Ansible Automation Platform 1.2 to version 2 may use the same manifest in both clusters/instances for upgrading as long as the managed node inventory is the same for both clusters/instances. The migration period may not exceed six months without an approved exception from the Ansible Business Unit by means of a formal BU Guidance request from the Red Hat Account Representative.
1.1. Architectural Overview
This section focuses on the architecture details of the two environments as they go through the side-by-side migration process.
The first environment, Environment A, consists of:
- 3 Ansible Tower 3.8.5 nodes running Red Hat Enterprise Linux 7 located in Raleigh, NC data center
- 1 Red Hat Enterprise Linux 7 database node
- 2 bastion hosts (jump hosts to access their corresponding isolated nodes)
- 2 isolated nodes located in Sacramento, CA data center
- 2 isolated nodes located in New Delhi, India data center
A pictorial representation of this environment is shown in:
Figure 1.1. Environment A Architecture Overview
The second environment, Environment B, is a new and empty Ansible Automation Platform 1.2 environment that will be used to import all the data from Environment A using the Ansible Automation Platform 1.2 installer from Environment B prior to upgrading to Ansible Automation Platform 2.
Initially, Environment B consists of:
- 3 Ansible Tower 3.8.5 nodes running Red Hat Enterprise Linux 8
- 1 Red Hat Enterprise Linux 8 database node
Ansible Automation Platform 2 does not support Red Hat Enterprise Linux 7. It is critical that Red Hat Enterprise Linux 8 be used as the base OS for your Ansible Automation Platform 1.2 Environment B prior to upgrading to Ansible Automation Platform 2.
Throughout this reference architecture you will find references to Ansible Automation Platform 2.1. However, the Ansible Automation Platform migration process found within this document applies to version 2.1 or later.
A pictorial representation of the initial Environment B footprint is shown below:
Figure 1.2. Initial Environment B Architecture Overview
Once the data migration from Environment A to Environment B is successful, we expand the architecture of Environment B during the upgrade process by including:
- 2 execution nodes accessible directly by the Ansible controllers
-
3 hop nodes (
sacramento-hop,dublin-hopnew-delhi-hop) -
2 execution nodes accessible only via hop node
sacramento-hop -
2 execution nodes accessible via hop node
dublin-hopandnew-delhi-hop
The dublin-hop provides another route via the automation mesh that can be used to access the execution nodes that reside in New Delhi, India.
A world view of the expanded Ansible Automation Platform 2 Environment B is shown below:
Figure 1.3. World View of Environment B
A detailed representation of the expanded Ansible Automation Platform 2 Environment B architectural footprint is shown below:
Figure 1.4. Expanded Environment B Architecture Overview
The process of disabling schedules from Job Templates is not covered within this reference architecture. It is important that once a successful migration is complete, to disable scheduling from any Job Templates from Environment A to ensure you do not have both Environment A and Environment B running the same jobs simultaneously.
