Chapter 9. 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. Note Upgrades of Event-Driven Ansible version 2.4 to 2.5 are not supported. Database migrations between Event-Driven Ansible 2.4 and Event-Driven Ansible 2.5 are not compatible. Use these procedures to migrate any of the following deployments to the Ansible Automation Platform Operator: OpenShift cluster A to OpenShift cluster B OpenShift namespace A to OpenShift namespace B Virtual machine (VM) based or containerized VM Ansible Automation Platform 2.5 Ansible Automation Platform 2.5 9.1. Migration considerations If you are upgrading from any version of Ansible Automation Platform older than 2.4, you must upgrade through Ansible Automation Platform first. If you are on OpenShift Container Platform 3 and you want to upgrade to 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. 9.2. Preparing for migration Before migrating your current Ansible Automation Platform deployment to Ansible Automation Platform Operator, you must back up your existing data, and create Kubernetes secrets for your secret key and postgresql configuration. Note 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 . 9.2.1. Migrating to Ansible Automation Platform Operator 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 PostgreSQL database Note 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.4, you must back up your data for loss prevention. Procedure Log in to your current deployment project. Run USD ./setup.sh -b to create a backup of your current data or deployment. 9.2.2. Creating a secret key secret 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. Note 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 . Note 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 installation. Create a YAML file for your secret keys: --- apiVersion: v1 kind: Secret metadata: name: <controller-resourcename>-secret-key namespace: <target-namespace> stringData: secret_key: <content of /etc/tower/SECRET_KEY from old controller> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: <eda-resourcename>-secret-key namespace: <target-namespace> stringData: secret_key: </etc/ansible-automation-platform/eda/SECRET_KEY> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: <hub-resourcename>-secret-key namespace: <target-namespace> stringData: database_fields.symmetric.key: </etc/pulp/certs/database_fields.symmetric.key> type: Opaque Note If admin_password_secret is not provided, the operator looks for a secret named <resourcename>-admin-password for 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> 9.2.3. Creating a postgresql configuration secret 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: apiVersion: v1 kind: Secret metadata: name: <resourcename>-old-postgres-configuration namespace: <target namespace> stringData: host: "<external ip or url resolvable by the cluster>" port: "<external port, this usually defaults to 5432>" database: "<desired database name>" username: "<username to connect as>" password: "<password to connect with>" type: Opaque Apply the postgresql configuration yaml to the cluster: oc apply -f <old-postgres-configuration.yml> 9.2.4. Verifying network connectivity 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: apiVersion: v1 kind: Pod metadata: name: dbchecker spec: containers: - name: dbchecker image: registry.redhat.io/rhel8/postgresql-13:latest command: ["sleep"] args: ["600"] Apply the connection checker yaml file to your new project deployment: oc project ansible-automation-platform oc apply -f connection_checker.yaml Verify that the connection checker pod is running: oc get pods Connect to a pod shell: oc rsh dbchecker 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 AutomationContoller Example 9.3. Migrating data to the Ansible Automation Platform Operator When migrating a 2.5 containerized or RPM installed deployment to OpenShift Container Platform you must create a secret with credentials to access the PostgreSQL database from the original deployment, then specify it when creating the Ansible Automation Platform object. Important The operator does not support Event-Driven Ansible migration at this time. Prerequisites You have completed the following procedures: Installing the Red Hat Ansible Automation Platform Operator on Red Hat OpenShift Creating a secret key Creating a postgresql configuration secret Verifying network connectivity 9.3.1. Creating an Ansible Automation Platform object Use the following steps to create an AnsibleAutomationPlatform custom resource object. Procedure Log in to Red Hat OpenShift Container Platform . Navigate to Operators Installed Operators . Select the Ansible Automation Platform Operator installed on your project namespace. Select the Ansible Automation Platform tab. Click Create AnsibleAutomationPlatform . Seclect YAML view and paste in the following, modified accordingly: --- apiVersion: aap.ansible.com/v1alpha1 kind: AnsibleAutomationPlatform metadata: name: myaap spec: postgres_configuration_secret: external-postgres-configuration controller: disabled: false postgres_configuration_secret: external-controller-postgres-configuration secret_key_secret: controller-secret-key hub: disabled: false postgres_configuration_secret: external-hub-postgres-configuration db_fields_encryption_secret: hub-db-fields-encryption-secret Click Create . 9.4. Post migration cleanup After data migration, delete unnecessary instance groups and unlink the old database configuration secret from the automation controller resource definition. 9.4.1. Deleting Instance Groups post migration Procedure Log in to Red Hat Ansible Automation Platform as the administrator with the password you created during migration. Note 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 Workloads Secrets 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 Automation Execution Infrastructure Instance Groups . Select all Instance Groups except controlplane and default. Click Delete . 9.4.2. Unlinking the old database configuration secret post migration Log in to Red Hat OpenShift Container Platform . Navigate to Operators Installed Operators . 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_secret item within the spec section of the YAML contents. Delete the line that contains this item. Click Save .

Commands:
--- apiVersion: v1 kind: Secret metadata: name: <controller-resourcename>-secret-key namespace: <target-namespace> stringData: secret_key: <content of /etc/tower/SECRET_KEY from old controller> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: <eda-resourcename>-secret-key namespace: <target-namespace> stringData: secret_key: </etc/ansible-automation-platform/eda/SECRET_KEY> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: <hub-resourcename>-secret-key namespace: <target-namespace> stringData: database_fields.symmetric.key: </etc/pulp/certs/database_fields.symmetric.key> type: Opaque
apply -f <yaml-file>
apiVersion: v1 kind: Secret metadata: name: <resourcename>-old-postgres-configuration namespace: <target namespace> stringData: host: "<external ip or url resolvable by the cluster>" port: "<external port, this usually defaults to 5432>" database: "<desired database name>" username: "<username to connect as>" password: "<password to connect with>" type: Opaque
apply -f <old-postgres-configuration.yml>
apiVersion: v1 kind: Pod metadata: name: dbchecker spec: containers: - name: dbchecker image: registry.redhat.io/rhel8/postgresql-13:latest command: ["sleep"] args: ["600"]
project ansible-automation-platform apply -f connection_checker.yaml
get pods
rsh dbchecker
pg_isready -h <old-host-address> -p <old-port-number> -U AutomationContoller
<old-host-address>:<old-port-number> - accepting connections
--- apiVersion: aap.ansible.com/v1alpha1 kind: AnsibleAutomationPlatform metadata: name: myaap spec: postgres_configuration_secret: external-postgres-configuration controller: disabled: false postgres_configuration_secret: external-controller-postgres-configuration secret_key_secret: controller-secret-key hub: disabled: false postgres_configuration_secret: external-hub-postgres-configuration db_fields_encryption_secret: hub-db-fields-encryption-secret