Chapter 3. Installing Red Hat Ansible Automation Platform
Red Hat Ansible Automation Platform installation involves deploying automation controller and automation hub.
The Ansible Automation Platform installer allows you to deploy only one automation hub per inventory. You can use the Ansible Automation Platform installer for a standalone instance of automation hub and run the installer any number of times with any number of different inventories to deploy multiple automation hub nodes.
This installation option includes two supported scenarios:
3.1. Installing Red Hat Ansible Automation Platform with a database on the automation controller node or non-installer managed database
You can use these instructions to install Red Hat Ansible Automation Platform (both automation controller and automation hub) with a database on the automation controller node, or a non-installer managed database.
3.1.1. Prerequisites
- You chose and obtained a platform installer from the Red Hat Ansible Automation Platform Product Software.
- You are installing on a machine that meets base system requirements.
- You have created a Red Hat Registry Service Account, following the instructions in the Creating Registry Service Accounts guide.
3.1.2. Red Hat Ansible Automation Platform installation settings
You can use the following settings when installing automation hub:
-
automationhub_importer_settings: Dictionary of settings/configuration to pass togalaxy-importer. It will end up in/etc/galaxy-importer/galaxy-importer.cfg -
automationhub_require_content_approval: Whether or not automation hub enforces the approval mechanism before collections are made available -
automationhub_disable_https: Whether or not automation hub should be deployed with TLS enabled -
automationhub_disable_hsts: Whether or not automation hub should be deployed with the HTTP Strict Transport Security (HSTS) web-security policy mechanism enabled -
automationhub_ssl_validate_certs: Whether or not automation hub should validate certificate when requesting itself (default = False) because by default, Platform deploys with self-signed certificates -
automationhub_ssl_cert: Same asweb_server_ssl_certbut for automation hub UI and API -
automationhub_ssl_key: Same asweb_server_ssl_keybut for automation hub UI and API -
automationhub_backup_collections: automation hub provides artifacts in/var/lib/pulp. By default, this is set totrueso automation controller automatically backs up the artifacts by default. If a partition (e.g., LVM, NFS, CephFS, etc.) was mounted there, an enterprise organization would ensure it is always backed up. If this is the case, you can setautomationhub_backup_collections = falseand the backup/restore process will not have to backup/restore/var/lib/pulp.
3.1.3. Editing the Red Hat Ansible Automation Platform installer inventory file
You can use the Red Hat Ansible Automation Platform installer inventory file to specify your installation scenario.
- Using external databases: ensure the database sections of your inventory file are properly setup.
-
Add automation hub information in the
[automationhub]group - automation hub and automation controller cannot be installed on the same node.
- automation controller will not configure replication or failover for the database that it uses. automation controller should work with any replication you have.
- The database server should be on the same network or in the same data center as the automation controller server for performance reasons.
-
A container registry service is required to install the Ansible Automation Platform. Access to a container registry enables you to load automation execution environments onto the Ansible Automation Platform, giving you a consistent and containerized environment for executing Ansible playbooks and roles. By default, the Ansible Automation Platform uses
registry.redhat.io, which requires a Red Hat registry service account. See the Creating Registry Service Accounts guide to create a registry service account. - For upgrading an existing cluster: When upgrading a cluster, you may decide that you want to also reconfigure your cluster to omit existing instances or instance groups. Omitting the instance or the instance group from the inventory file will not be enough to remove them from the cluster. In addition to omitting instances or instance groups from the inventory file, you must also deprovision instances or instance groups before starting the upgrade. Otherwise, omitted instances or instance groups will continue to communicate with the cluster, which can cause issues with tower services during the upgrade.
-
For clustered installations: If you are creating a clustered setup, you must replace
localhostwith the hostname or IP address of all instances. All nodes/instances must be able to reach any others using this hostname or address. In other words, you cannot use thelocalhost ansible_connection=localon one of the nodes AND all of the nodes should use the same format for the host names.
- Root access to remote machines is required. With Ansible, this can be achieved in different ways:
-
ansible_user=root ansible_ssh_pass=”your_password_here”inventory host or group variables -
ansible_user=root ansible_ssh_private_key_file=”path_to_your_keyfile.pem”inventory host or group variables -
ANSIBLE_BECOME_METHOD=’sudo’ ANSIBLE_BECOME=True ./setup.sh
For more information on become plugins, see Understanding privilege escalation.
Procedure
Navigate to the installer
[bundled installer]
$ cd ansible-automation-platform-setup-bundle-<latest-version>
[online installer]
$ cd ansible-automation-platform-setup-<latest-version>
-
Open the
inventoryfile with a text editor. -
Edit
inventoryfile parameters to specify your installation scenario. Follow the example below.
3.1.4. Example inventory file for a database on the automation controller node or a non-installer managed database
This example describes how you can populate the inventory file to install Red Hat Ansible Automation Platform. This installation inventory file includes both automation controller and automation hub with a database on the automation controller node or non-installer managed database.
- You cannot install automation controller and automation hub on the same node.
-
Provide a reachable IP address for the
[automationhub]host to ensure users can sync content from Private Automation Hub from a different node. -
Enter your Red Hat Registry Service Account credentials in
registry_usernameandregistry_passwordto link to the Red Hat container registry.
[automationcontroller] controller.acme.org [automationhub] automationhub.acme.org [all:vars] admin_password='<password>' pg_host='' pg_port='' pg_database='awx' pg_username='awx' pg_password='<password>' pg_sslmode='prefer' # set to 'verify-full' for client-side enforced SSL registry_url='registry.redhat.io' registry_username='<registry username>' registry_password='<registry password>' # Automation Hub Configuration # automationhub_admin_password='<password>' automationhub_pg_host='controller.acme.org' automationhub_pg_port='5432' automationhub_pg_database='automationhub' automationhub_pg_username='automationhub' automationhub_pg_password='<password>' automationhub_pg_sslmode='prefer' # The default install will deploy a TLS enabled Automation Hub. # If for some reason this is not the behavior wanted one can # disable TLS enabled deployment. # # automationhub_disable_https = False # The default install will generate self-signed certificates for the Automation # Hub service. If you are providing valid certificate via automationhub_ssl_cert # and automationhub_ssl_key, one should toggle that value to True. # # automationhub_ssl_validate_certs = False # SSL-related variables # If set, this will install a custom CA certificate to the system trust store. # custom_ca_cert=/path/to/ca.crt # Certificate and key to install in nginx for the web UI and API # web_server_ssl_cert=/path/to/tower.cert # web_server_ssl_key=/path/to/tower.key # Certificate and key to install in Automation Hub node # automationhub_ssl_cert=/path/to/automationhub.cert # automationhub_ssl_key=/path/to/automationhub.key # Server-side SSL settings for PostgreSQL (when we are installing it). # postgres_use_ssl=False # postgres_ssl_cert=/path/to/pgsql.crt # postgres_ssl_key=/path/to/pgsql.key
3.1.5. Setup script flags and extra variables
You can also pass flags and extra variables when running the setup script to install automation controller:
| Argument | Description |
|---|---|
|
| Show this help message and exit |
|
|
Path to Ansible inventory file (default: |
|
| Set additional Ansible variables as key=value or YAML/JSON |
|
| Perform a database backup in lieu of installing |
|
| Perform a database restore in lieu of installing |
|
| Generate and dsitribute a SECRET_KEY |
Use the -- separator to add any Ansible arguments you wish to apply. For example: ./setup.sh -i my_awesome_inventory.yml -e matburt_is_country_gold=True — -K.
When passing
-rto perform a database restore default restore path is used unless EXTRA_VARS are provided with a non-default path. See the example below that passed an EXTRA_VAR specifying the restore path:./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
You can force an online installation by passing
-e bundle_install=false:$ ./setup.sh -e bundle_install=false
| Variable | Description | Default |
|---|---|---|
|
| When installing automation controller make sure Ansible is also up to date |
|
|
| When installing Tower also create the Demo Org, project, credential, Job Template, etc. |
|
|
| When installing from a bundle where to put the bundled repos |
|
|
| Disable HTTPS traffic through nginx, this is useful if offloading HTTPS to a load balancer |
|
|
| Disable HSTS web-security policy mechanism |
|
|
| Port to configure nginx to listen to for HTTP |
|
|
| Port to configure nginx to listen to for HTTPS |
|
|
| A temp location to use when backing up |
|
|
| Specify an alternative backup file to restore from | None |
|
| The minimum RAM required to install Tower (should only be changed for test installation) |
|
|
| The minimum open file descriptions (should only be changed for test installations) | None |
|
|
Ignore preflight checks, useful when installing into a template or other non-system image (overrides |
|
Examples
- To upgrade core:
./setup.sh -e upgrade_ansible_with_tower=1
- To disable https handling at nginx:
./setup.sh -e nginx_disable_https=true
- To specify a non-default path when restoring from a backup file:
./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
3.1.6. Running the Red Hat Ansible Automation Platform installer setup script
You can run the setup script once you finish updating the inventory file with required parameters for installing your Private Automation Hub.
Procedure
Run the
setup.shscript$ ./setup.sh
The installation will begin.
3.1.7. Verifying automation controller installation
Once the installation completes, you can verify your automation controller has been installed successfully by logging in with the admin credentials you inserted into the inventory file.
Procedure
-
Navigate to the IP address specified for the automation controller node in the
inventoryfile. -
Log in with the Admin credentials you set in the
inventoryfile.
The automation controller server is accessible from port 80 (https://<TOWER_SERVER_NAME>/) but will redirect to port 443 so 443 needs to be available also.
If the installation fails and you are a customer who has purchased a valid license for Red Hat Ansible Automation Platform, please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.
Upon a successful login to automation controller, your installation of Red Hat Ansible Automation Platform 2.1 is now complete.
3.1.7.1. Additional automation controller configuration and resources
See the following resources to explore additional automation controller configurations.
| Link | Description |
|---|---|
| Set up automation controller and run your first playbook | |
| Configure automation controller administration through customer scripts, management jobs, etc. | |
| Configuring proxy support for Red Hat Ansible Automation Platform | Set up automation controller with a proxy server |
| Managing usability analytics and data collection from automation controller | Manage what automation controller information you share with Red Hat |
| Review automation controller functionality in more detail |
3.1.8. Verifying automation hub installation
Once the installation completes, you can verify your automation hub has been installed successfully by logging in with the admin credentials you inserted into the inventory file.
Procedure
-
Navigate to the IP address specified for the automation hub node in the
inventoryfile. -
Log in with the Admin credentials you set in the
inventoryfile.
If the installation fails and you are a customer who has purchased a valid license for Red Hat Ansible Automation Platform, please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.
Upon a successful login to automation hub, your installation of Red Hat Ansible Automation Platform 2.1 is now complete.
3.1.8.1. Additional automation hub configuration and resources
See the following resources to explore additional automation hub configurations.
| Link | Description |
|---|---|
| Configure user access for automation hub | |
| Managing Red Hat Certified and Ansible Galaxy collections in automation hub | Add content to your automation hub |
| Publishing proprietary content collections in automation hub | Publish internally developed collections on your automation hub |
3.1.9. What’s next with Ansible Automation Platform 2.1
Whether you are a new Ansible Automation Platform user looking to start automating, or an existing administrator looking to migrate old Ansible content to your latest installed version of Red Hat Ansible Automation Platform, explore the next steps to begin leveraging the new features of Ansible Automation Platform 2.1:
3.1.9.1. Migrating data to Ansible Automation Platform 2.1
For platform administrators looking to complete an upgrade to the Ansible Automation Platform 2.1, there may be additional steps needed to migrate data to a new instance:
3.1.9.1.1. Migrating from legacy virtual environments (venvs) to automation execution environments
Ansible Automation Platform 2.1 moves you away from custom Python virtual environments (venvs) in favor of automation execution environments - containerized images that package the necessary components needed to execute and scale your Ansible automation. This includes Ansible Core, Ansible Content Collections, Python dependencies, Red Hat Enterprise Linux UBI 8, and any additional package dependencies.
If you are looking to migrate your venvs to execution environments, you will (1) need to use the awx-manage command to list and export a list of venvs from your original instance, then (2) use ansible-builder to create execution environments. For more information, see the Upgrading to Automation Execution Environments guide and the Ansible Builder Guide.
3.1.9.1.2. Migrating to Ansible Engine 2.9 images using Ansible Builder
To migrate Ansible Engine 2.9 images for use with Ansible Automation Platform 2.1, the ansible-builder tool automates the process of rebuilding images (including its custom plugins and dependencies) for use with automation execution environments. For more information on using Ansible Builder to build execution environments, see the Ansible Builder Guide.
3.1.9.1.3. Migrating to Ansible Core 2.12
When upgrading to Ansible Core 2.12, you will need to update your playbooks, plugins, or other parts of your Ansible infrastructure in order to be supported by the latest version of Ansible Core. For instructions on updating your Ansible content to be Ansible Core 2.12 compatible, see the Ansible-core 2.12 Porting Guide.
3.1.9.2. Scale up your automation using automation mesh
The automation mesh component of the Red Hat Ansible Automation Platform simplifies the process of distributing automation across multi-site deployments. For enterprises with multiple isolated IT environments, automation mesh provides a consistent and reliable way to deploy and scale up automation across your execution nodes using a peer-to-peer mesh communication network.
When upgrading from version 1.x to the latest version of the Ansible Automation Platform, you will need to migrate the data from your legacy isolated nodes into execution nodes necessary for automation mesh. You can implement automation mesh by planning out a network of hybrid and control nodes, then editing the inventory file found in the Ansible Automation Platform installer to assign mesh-related values to each of your execution nodes.
For instructions on how to migrate from isolated nodes to execution nodes, see the upgrade & migration guide.
For information about automation mesh and the various ways to design your automation mesh for your environment, see the Red Hat Ansible Automation Platform automation mesh guide.
3.2. Installing Red Hat Ansible Automation Platform with an external managed database
You can use these instructions to install Red Hat Ansible Automation Platform (both automation controller and automation hub) with an external managed database.
3.2.1. Prerequisites
- You chose and obtained a platform installer from the Red Hat Ansible Automation Platform Product Software.
- You are installing on a machine that meets base system requirements.
- You have created a Red Hat Registry Service Account, following the instructions in the Creating Registry Service Accounts guide.
3.2.2. Red Hat Ansible Automation Platform installation settings
You can use the following settings when installing automation hub:
-
automationhub_importer_settings: Dictionary of settings/configuration to pass togalaxy-importer. It will end up in/etc/galaxy-importer/galaxy-importer.cfg -
automationhub_require_content_approval: Whether or not automation hub enforces the approval mechanism before collections are made available -
automationhub_disable_https: Whether or not automation hub should be deployed with TLS enabled -
automationhub_disable_hsts: Whether or not automation hub should be deployed with the HTTP Strict Transport Security (HSTS) web-security policy mechanism enabled -
automationhub_ssl_validate_certs: Whether or not automation hub should validate certificate when requesting itself (default = False) because by default, Platform deploys with self-signed certificates -
automationhub_ssl_cert: Same asweb_server_ssl_certbut for automation hub UI and API -
automationhub_ssl_key: Same asweb_server_ssl_keybut for automation hub UI and API -
automationhub_backup_collections: automation hub provides artifacts in/var/lib/pulp. By default, this is set totrueso automation controller automatically backs up the artifacts by default. If a partition (e.g., LVM, NFS, CephFS, etc.) was mounted there, an enterprise organization would ensure it is always backed up. If this is the case, you can setautomationhub_backup_collections = falseand the backup/restore process will not have to backup/restore/var/lib/pulp.
3.2.3. Editing the Red Hat Ansible Automation Platform installer inventory file
You can use the Red Hat Ansible Automation Platform installer inventory file to specify your installation scenario.
- Using external databases: ensure the database sections of your inventory file are properly setup.
-
Add automation hub information in the
[automationhub]group - automation hub and automation controller cannot be installed on the same node.
- automation controller will not configure replication or failover for the database that it uses. automation controller should work with any replication you have.
- The database server should be on the same network or in the same data center as the automation controller server for performance reasons.
-
A container registry service is required to install the Ansible Automation Platform. Access to a container registry enables you to load automation execution environments onto the Ansible Automation Platform, giving you a consistent and containerized environment for executing Ansible playbooks and roles. By default, the Ansible Automation Platform uses
registry.redhat.io, which requires a Red Hat registry service account. See the Creating Registry Service Accounts guide to create a registry service account. - For upgrading an existing cluster: When upgrading a cluster, you may decide that you want to also reconfigure your cluster to omit existing instances or instance groups. Omitting the instance or the instance group from the inventory file will not be enough to remove them from the cluster. In addition to omitting instances or instance groups from the inventory file, you must also deprovision instances or instance groups before starting the upgrade. Otherwise, omitted instances or instance groups will continue to communicate with the cluster, which can cause issues with tower services during the upgrade.
-
For clustered installations: If you are creating a clustered setup, you must replace
localhostwith the hostname or IP address of all instances. All nodes/instances must be able to reach any others using this hostname or address. In other words, you cannot use thelocalhost ansible_connection=localon one of the nodes AND all of the nodes should use the same format for the host names.
- Root access to remote machines is required. With Ansible, this can be achieved in different ways:
-
ansible_user=root ansible_ssh_pass=”your_password_here”inventory host or group variables -
ansible_user=root ansible_ssh_private_key_file=”path_to_your_keyfile.pem”inventory host or group variables -
ANSIBLE_BECOME_METHOD=’sudo’ ANSIBLE_BECOME=True ./setup.sh
For more information on become plugins, see Understanding privilege escalation.
Procedure
Navigate to the installer
[bundled installer]
$ cd ansible-automation-platform-setup-bundle-<latest-version>
[online installer]
$ cd ansible-automation-platform-setup-<latest-version>
-
Open the
inventoryfile with a text editor. -
Edit
inventoryfile parameters to specify your installation scenario. Follow the example below.
3.2.4. Example Red Hat Ansible Automation Platform inventory file with an external managed database
This example describes how you can populate the inventory file to install Red Hat Ansible Automation Platform. This installation inventory file includes both automation controller and automation hub with an external managed database.
- You cannot install automation controller and automation hub on the same node.
-
Provide a reachable IP address for the
[automationhub]host to ensure users can sync content from Private Automation Hub from a different node. -
Enter your Red Hat Registry Service Account credentials in
registry_usernameandregistry_passwordto link to the Red Hat container registry.
[automationcontroller] controller.acme.org [automationhub] automationhub.acme.org [database] database-01.acme.org [all:vars] admin_password='<password>' pg_host='database-01.acme.org' pg_port='5432' pg_database='awx' pg_username='awx' pg_password='<password>' pg_sslmode='prefer' # set to 'verify-full' for client-side enforced SSL registry_url='registry.redhat.io' registry_username='<registry username>' registry_password='<registry password>' # Automation Hub Configuration # automationhub_admin_password='<password>' automationhub_pg_host='database-01.acme.org' automationhub_pg_port='5432' automationhub_pg_database='automationhub' automationhub_pg_username='automationhub' automationhub_pg_password='<password>' automationhub_pg_sslmode='prefer' # The default install will deploy a TLS enabled Automation Hub. # If for some reason this is not the behavior wanted one can # disable TLS enabled deployment. # # automationhub_disable_https = False # The default install will generate self-signed certificates for the Automation # Hub service. If you are providing valid certificate via automationhub_ssl_cert # and automationhub_ssl_key, one should toggle that value to True. # # automationhub_ssl_validate_certs = False # SSL-related variables # If set, this will install a custom CA certificate to the system trust store. # custom_ca_cert=/path/to/ca.crt # Certificate and key to install in nginx for the web UI and API # web_server_ssl_cert=/path/to/tower.cert # web_server_ssl_key=/path/to/tower.key # Certificate and key to install in Automation Hub node # automationhub_ssl_cert=/path/to/automationhub.cert # automationhub_ssl_key=/path/to/automationhub.key # Server-side SSL settings for PostgreSQL (when we are installing it). # postgres_use_ssl=False # postgres_ssl_cert=/path/to/pgsql.crt # postgres_ssl_key=/path/to/pgsql.key
3.2.5. Setup script flags and extra variables
You can also pass flags and extra variables when running the setup script to install automation controller:
| Argument | Description |
|---|---|
|
| Show this help message and exit |
|
|
Path to Ansible inventory file (default: |
|
| Set additional Ansible variables as key=value or YAML/JSON |
|
| Perform a database backup in lieu of installing |
|
| Perform a database restore in lieu of installing |
|
| Generate and dsitribute a SECRET_KEY |
Use the -- separator to add any Ansible arguments you wish to apply. For example: ./setup.sh -i my_awesome_inventory.yml -e matburt_is_country_gold=True — -K.
When passing
-rto perform a database restore default restore path is used unless EXTRA_VARS are provided with a non-default path. See the example below that passed an EXTRA_VAR specifying the restore path:./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
You can force an online installation by passing
-e bundle_install=false:$ ./setup.sh -e bundle_install=false
| Variable | Description | Default |
|---|---|---|
|
| When installing automation controller make sure Ansible is also up to date |
|
|
| When installing Tower also create the Demo Org, project, credential, Job Template, etc. |
|
|
| When installing from a bundle where to put the bundled repos |
|
|
| Disable HTTPS traffic through nginx, this is useful if offloading HTTPS to a load balancer |
|
|
| Disable HSTS web-security policy mechanism |
|
|
| Port to configure nginx to listen to for HTTP |
|
|
| Port to configure nginx to listen to for HTTPS |
|
|
| A temp location to use when backing up |
|
|
| Specify an alternative backup file to restore from | None |
|
| The minimum RAM required to install Tower (should only be changed for test installation) |
|
|
| The minimum open file descriptions (should only be changed for test installations) | None |
|
|
Ignore preflight checks, useful when installing into a template or other non-system image (overrides |
|
Examples
- To upgrade core:
./setup.sh -e upgrade_ansible_with_tower=1
- To disable https handling at nginx:
./setup.sh -e nginx_disable_https=true
- To specify a non-default path when restoring from a backup file:
./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
3.2.6. Running the Red Hat Ansible Automation Platform installer setup script
You can run the setup script once you finish updating the inventory file with required parameters for installing your Private Automation Hub.
Procedure
Run the
setup.shscript$ ./setup.sh
The installation will begin.
3.2.7. Verifying automation controller installation
Once the installation completes, you can verify your automation controller has been installed successfully by logging in with the admin credentials you inserted into the inventory file.
Procedure
-
Navigate to the IP address specified for the automation controller node in the
inventoryfile. -
Log in with the Admin credentials you set in the
inventoryfile.
The automation controller server is accessible from port 80 (https://<TOWER_SERVER_NAME>/) but will redirect to port 443 so 443 needs to be available also.
If the installation fails and you are a customer who has purchased a valid license for Red Hat Ansible Automation Platform, please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.
Upon a successful login to automation controller, your installation of Red Hat Ansible Automation Platform 2.1 is now complete.
3.2.7.1. Additional automation controller configuration and resources
See the following resources to explore additional automation controller configurations.
| Link | Description |
|---|---|
| Set up automation controller and run your first playbook | |
| Configure automation controller administration through customer scripts, management jobs, etc. | |
| Configuring proxy support for Red Hat Ansible Automation Platform | Set up automation controller with a proxy server |
| Managing usability analytics and data collection from automation controller | Manage what automation controller information you share with Red Hat |
| Review automation controller functionality in more detail |
3.2.8. Verifying automation hub installation
Once the installation completes, you can verify your automation hub has been installed successfully by logging in with the admin credentials you inserted into the inventory file.
Procedure
-
Navigate to the IP address specified for the automation hub node in the
inventoryfile. -
Log in with the Admin credentials you set in the
inventoryfile.
If the installation fails and you are a customer who has purchased a valid license for Red Hat Ansible Automation Platform, please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.
Upon a successful login to automation hub, your installation of Red Hat Ansible Automation Platform 2.1 is now complete.
3.2.8.1. Additional automation hub configuration and resources
See the following resources to explore additional automation hub configurations.
| Link | Description |
|---|---|
| Configure user access for automation hub | |
| Managing Red Hat Certified and Ansible Galaxy collections in automation hub | Add content to your automation hub |
| Publishing proprietary content collections in automation hub | Publish internally developed collections on your automation hub |
3.2.9. What’s next with Ansible Automation Platform 2.1
Whether you are a new Ansible Automation Platform user looking to start automating, or an existing administrator looking to migrate old Ansible content to your latest installed version of Red Hat Ansible Automation Platform, explore the next steps to begin leveraging the new features of Ansible Automation Platform 2.1:
3.2.9.1. Migrating data to Ansible Automation Platform 2.1
For platform administrators looking to complete an upgrade to the Ansible Automation Platform 2.1, there may be additional steps needed to migrate data to a new instance:
3.2.9.1.1. Migrating from legacy virtual environments (venvs) to automation execution environments
Ansible Automation Platform 2.1 moves you away from custom Python virtual environments (venvs) in favor of automation execution environments - containerized images that package the necessary components needed to execute and scale your Ansible automation. This includes Ansible Core, Ansible Content Collections, Python dependencies, Red Hat Enterprise Linux UBI 8, and any additional package dependencies.
If you are looking to migrate your venvs to execution environments, you will (1) need to use the awx-manage command to list and export a list of venvs from your original instance, then (2) use ansible-builder to create execution environments. For more information, see the Upgrading to Automation Execution Environments guide and the Ansible Builder Guide.
3.2.9.1.2. Migrating to Ansible Engine 2.9 images using Ansible Builder
To migrate Ansible Engine 2.9 images for use with Ansible Automation Platform 2.1, the ansible-builder tool automates the process of rebuilding images (including its custom plugins and dependencies) for use with automation execution environments. For more information on using Ansible Builder to build execution environments, see the Ansible Builder Guide.
3.2.9.1.3. Migrating to Ansible Core 2.12
When upgrading to Ansible Core 2.12, you will need to update your playbooks, plugins, or other parts of your Ansible infrastructure in order to be supported by the latest version of Ansible Core. For instructions on updating your Ansible content to be Ansible Core 2.12 compatible, see the Ansible-core 2.12 Porting Guide.
3.2.9.2. Scale up your automation using automation mesh
The automation mesh component of the Red Hat Ansible Automation Platform simplifies the process of distributing automation across multi-site deployments. For enterprises with multiple isolated IT environments, automation mesh provides a consistent and reliable way to deploy and scale up automation across your execution nodes using a peer-to-peer mesh communication network.
When upgrading from version 1.x to the latest version of the Ansible Automation Platform, you will need to migrate the data from your legacy isolated nodes into execution nodes necessary for automation mesh. You can implement automation mesh by planning out a network of hybrid and control nodes, then editing the inventory file found in the Ansible Automation Platform installer to assign mesh-related values to each of your execution nodes.
For instructions on how to migrate from isolated nodes to execution nodes, see the upgrade & migration guide.
For information about automation mesh and the various ways to design your automation mesh for your environment, see the Red Hat Ansible Automation Platform automation mesh guide.
