Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 2. Migration considerations
With the introduction of Ansible Automation Platform 2, a re-imagined architecture has been created that expands the capabilities of automation. Ansible Automation Platform 2 now decouples the automation control plane and execution plane, which provides for a much more flexible architecture. This new capability alongside the introduction of automation mesh allows an organization to scale automation across the globe and allows automation to run as close to the endpoints as possible.
Prior to the step-by-step migration approach provided for this reference architecture, it is important to carefully assess and plan to determine your overall migration readiness to proceed without exceptions.
2.1. Technical considerations
One of the key changes between Ansible Automation Platform 1.2 and Ansible Automation Platform 2 is the removal of isolated nodes in favor of hop nodes and execution nodes with automation mesh. Automation mesh is an overlay network that provides a simple, flexible and reliable way to scale automation of large inventories across diverse network topologies, platforms and regions. Automation mesh provides flexible design options to build resilient and fault-tolerant architectures while providing enhanced security to standardize and normalize automation across your entire IT estate.
In this reference environment, we capture the steps of migrating Ansible Automation Platform 1.2 that uses isolated nodes and third party tooling, such as SSH proxies and jump hosts, to upgrade to Ansible Automation Platform 2 using automation mesh hop and execution nodes.
The use of automation mesh and execution nodes will require additional ports be opened within your firewall.
| Protocol | Port | Purpose |
|---|---|---|
| SSH | 22/TCP | Ansible Automation Platform installation |
| HTTPS | 443/TCP | Web UI, API, Execution Environment (EE) pulls |
| Receptor | 27199/TCP | automation mesh |
The receptor TCP port can be customized during the Ansible Automation Platform upgrade process.
Another important consideration is database supportability. With the introduction of automation controller, the requirement of Postgres 12 database is introduced. If your existing Postgres 10 database was installed/managed by Ansible Automation Platform 1.2, the upgrade process to Ansible Automation Platform 2 handles the upgrade of the Postgres database to the new version 12.
For this reference architecture, the Postgres database is managed by Ansible Automation Platform.
If you manage your own Postgres 10 database, you will want to:
- Install a new Postgres 10 database that will be part of the side-by-side migration
- Import your data from Environment A to the newly created Postgres 10 database that is to be used by Environment B
- Upgrade from Postgres 10 to Postgres 12 on the database that is to be used by Environment B
- With the upgraded Postgres 12, upgrade your Ansible Automation Platform 1.2 to Ansible Automation Platform 2 on Environment B
Managing your own Postgres database is out of scope for this reference architecture.
For more information regarding database supportability, visit the Database Scope of Coverage article.
Aside from the key considerations regarding isolated nodes and database supportability, there is a list of functionality that has been removed in Ansible Automation Platform 2. The list includes:
- The ability to delete the default instance group through the User Interface
- Support for deploying on CentOS (any version) and RHEL 7
- Support for Mercurial projects
- Support for custom inventory scripts stored in controller
- Resource profiling code (AWX_RESOURCE_PROFILING_*)
- Support for custom Python virtual environments in favor of execution environments
-
Top-level
/api/v2/job_events/API endpoint - Job isolation is achieved using Execution environments and is no longer a feature of Ansible Tower.
The replacement of custom Python virtual environments with user-built execution environments is described and done via an Ansible Playbook provided by this reference architecture in a later chapter.
2.2. Ansible content migration considerations
As you evaluate the process of migrating your environment to Ansible Automation Platform 1.2 to Ansible Automation Platform 2, there may be additional considerations to address when it comes to Ansible content (Collections, modules, roles, plugins, etc).
These considerations are not limited to this list, but include the following:
- Ansible Playbooks must run on Ansible Engine 2.9.10 or higher in order to be used in a compatibility execution environment (required)
- Ansible content in playbooks should utilize Ansible Collections (not required, but recommended)
- Ansible content in playbooks should utilize Fully Qualified Collection Name (FQCN) (not required, but recommended)
- Ansible Playbooks must be modified to address any references to localhost as using execution environments this refers to the pod itself and not the underlying host as previously done.
User-built execution environments may be required if additional dependencies are needed to successfully execute your Ansible content.
2.3. Operating model considerations
With the adoption of a new Ansible Automation Platform architecture, it is vital to have a plan on how you will integrate your newly designed Ansible Automation Platform environment.
Key questions to have answers to include the following:
- What training and enablement is required in my organization to run Ansible Automation Platform 2?
- How will execution environments and Ansible Content Collections be managed?
What execution environment container versioning best fits my organization?
- Do I want different models for development and production?
- If user-built execution environments are needed, how will I manage and distribute those environments?
- Do we plan on building CI around execution environments?
- What is the security response plan to patch CVEs and remain compliant?
- How often will I upgrade my Ansible Automation Platform clusters?
While these are just a few examples, they are critical questions that need answers to ensure a successful strategy for your organization.
