Chapter 8. Migrating Red Hat Ansible Automation Platform to Red Hat Ansible Automation Platform Operator
Migrating your Red Hat Ansible Automation Platform deployment to the Ansible Automation Platform Operator allows you to take advantage of the benefits provided by a Kubernetes native operator, including simplified upgrades and full lifecycle support for your Red Hat Ansible Automation Platform deployments.
Use these procedures to migrate any of the following deployments to the Ansible Automation Platform Operator:
- A VM-based installation of Ansible Tower 3.8.6, automation controller, or automation hub
- An Openshift instance of Ansible Tower 3.8.6 (Ansible Automation Platform 1.2)
8.1. Migration considerations Copy linkLink copied to clipboard!
If you are upgrading from Ansible Automation Platform 1.2 on OpenShift Container Platform 3 to Ansible Automation Platform 2.x on OpenShift Container Platform 4, you must provision a fresh OpenShift Container Platform version 4 cluster and then migrate the Ansible Automation Platform to the new cluster.
8.2. Preparing for migration Copy linkLink copied to clipboard!
Before migrating your current Ansible Automation Platform deployment to Ansible Automation Platform Operator, you need to back up your existing data, create k8s secrets for your secret key and postgresql configuration.
If you are migrating both automation controller and automation hub instances, repeat the steps in Creating a secret key secret and Creating a postgresql configuration secret for both and then proceed to Migrating data to the Ansible Automation Platform Operator.
8.2.1. Migrating to Ansible Automation Platform Operator Copy linkLink copied to clipboard!
Prerequisites
To migrate Ansible Automation Platform deployment to Ansible Automation Platform Operator, you must have the following:
- Secret key secret
- Postgresql configuration
- Role-based Access Control for the namespaces on the new OpenShift cluster
- The new OpenShift cluster must be able to connect to the previous PostgreSQL database
You can store the secret key information in the inventory file before the initial Red Hat Ansible Automation Platform installation. If you are unable to remember your secret key or have trouble locating your inventory file, contact Ansible support through the Red Hat Customer portal.
Before migrating your data from Ansible Automation Platform 2.x or earlier, you must back up your data for loss prevention. To backup your data, do the following:
Procedure
- Log in to your current deployment project.
Run
setup.shto create a backup of your current data or deployment:For on-prem deployments of version 2.x or earlier:
./setup.sh -b
$ ./setup.sh -bCopy to Clipboard Copied! Toggle word wrap Toggle overflow For OpenShift deployments before version 2.0 (non-operator deployments):
./setup_openshift.sh -b
./setup_openshift.sh -bCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.2. Creating a secret key secret Copy linkLink copied to clipboard!
To migrate your data to Ansible Automation Platform Operator on OpenShift Container Platform, you must create a secret key. If you are migrating automation controller, automation hub, and Event-Driven Ansible you must have a secret key for each that matches the secret key defined in the inventory file during your initial installation. Otherwise, the migrated data remains encrypted and unusable after migration.
When specifying the symmetric encryption secret key on the custom resources, note that for automation controller the field is called secret_key_name. But for automation hub and Event-Driven Ansible, the field is called db_fields_encryption_secret.
In the Kubernetes secrets, automation controller and Event-Driven Ansible use the same stringData key (secret_key) but, automation hub uses a different key (database_fields.symmetric.key).
Procedure
- Locate the old secret keys in the inventory file you used to deploy Ansible Automation Platform in your previous installation.
Create a YAML file for your secret keys:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf
admin_password_secretis not provided, the operator looks for a secret named<resourcename>-admin-passwordfor the admin password. If it is not present, the operator generates a password and create a secret from it named<resourcename>-admin-password.Apply the secret key YAML to the cluster:
oc apply -f <yaml-file>
oc apply -f <yaml-file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.3. Creating a postgresql configuration secret Copy linkLink copied to clipboard!
For migration to be successful, you must provide access to the database for your existing deployment.
Procedure
Create a yaml file for your postgresql configuration secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Apply the postgresql configuration yaml to the cluster:
oc apply -f <old-postgres-configuration.yml>
oc apply -f <old-postgres-configuration.yml>
8.2.4. Verifying network connectivity Copy linkLink copied to clipboard!
To ensure successful migration of your data, verify that you have network connectivity from your new operator deployment to your old deployment database.
Prerequisites
Take note of the host and port information from your existing deployment. This information is located in the postgres.py file located in the conf.d directory.
Procedure
Create a yaml file to verify the connection between your new deployment and your old deployment database:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the connection checker yaml file to your new project deployment:
oc project ansible-automation-platform oc apply -f connection_checker.yaml
oc project ansible-automation-platform oc apply -f connection_checker.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the connection checker pod is running:
oc get pods
oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Connect to a pod shell:
oc rsh dbchecker
oc rsh dbcheckerCopy to Clipboard Copied! Toggle word wrap Toggle overflow After the shell session opens in the pod, verify that the new project can connect to your old project cluster:
pg_isready -h <old-host-address> -p <old-port-number> -U awx
pg_isready -h <old-host-address> -p <old-port-number> -U awxCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example
<old-host-address>:<old-port-number> - accepting connections
<old-host-address>:<old-port-number> - accepting connectionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3. Migrating data to the Ansible Automation Platform Operator Copy linkLink copied to clipboard!
After you have set your secret key, postgresql credentials, verified network connectivity and installed the Ansible Automation Platform Operator, you must create a custom resource controller object before you can migrate your data.
8.3.1. Creating an AutomationController object Copy linkLink copied to clipboard!
Use the following steps to create an AutomationController custom resource object.
Procedure
- Log in to Red Hat OpenShift Container Platform.
-
Navigate to
. - Select the Ansible Automation Platform Operator installed on your project namespace.
- Select the Automation Controller tab.
Click . You can create the object through the Form view or YAML view. The following inputs are available through the Form view.
- Enter a name for the new deployment.
In Advanced configurations:
- From the Secret Key list, select your secret key secret.
- From the Old Database Configuration Secret list, select the old postgres configuration secret.
- Click .
8.3.2. Creating an AutomationHub object Copy linkLink copied to clipboard!
Use the following steps to create an AutomationHub custom resource object.
Procedure
- Log in to Red Hat OpenShift Container Platform.
-
Navigate to
. - Select the Ansible Automation Platform Operator installed on your project namespace.
- Select the Automation Hub tab.
- Click .
- Enter a name for the new deployment.
- In Advanced configurations, select your secret key secret and postgres configuration secret.
- Click .
8.4. Post migration cleanup Copy linkLink copied to clipboard!
After data migration, delete unnecessary instance groups and unlink the old database configuration secret from the automation controller resource definition.
8.4.1. Deleting Instance Groups post migration Copy linkLink copied to clipboard!
Procedure
Log in to Red Hat Ansible Automation Platform as the administrator with the password you created during migration.
NoteNote: If you did not create an administrator password during migration, one was automatically created for you. To locate this password, go to your project, select
and open controller-admin-password. From there you can copy the password and paste it into the Red Hat Ansible Automation Platform password field. -
Select
. - Select all Instance Groups except controlplane and default.
- Click .
8.4.2. Unlinking the old database configuration secret post migration Copy linkLink copied to clipboard!
- Log in to Red Hat OpenShift Container Platform.
-
Navigate to
. - Select the Ansible Automation Platform Operator installed on your project namespace.
- Select the Automation Controller tab.
- Click your AutomationController object. You can then view the object through the Form view or YAML view. The following inputs are available through the YAML view.
-
Locate the
old_postgres_configuration_secretitem within the spec section of the YAML contents. - Delete the line that contains this item.
- Click .