Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 4. Infrastructure Migration

download PDF

To achieve a successful migration from Ansible Automation Platform 1.2 to Ansible Automation Platform 2, this reference environment takes advantage of the capabilities of the Ansible Automation Platform installer.

Using the Ansible Automation Platform installer, you’ll be able to backup, import and upgrade to the latest Ansible Automation Platform 2 with a few simple commands.

The following sections provide a step-by-step of that process.

4.1. Backup Ansible Automation Platform 1.2 on Environment A

As our Ansible Automation Platform 1.2 environment from Environment A contains all of our data, the following creates a backup using the Ansible Automation Platform installer on Environment A.

Warning

Prior to taking a backup, ensure there are no current running jobs or future jobs scheduled to run. Any data collected after the backup is taken will be LOST.

Within Environment A,

  1. Login as the ansible user 

    $ ssh ansible@enva_controller1.example.com
    Note

    This reference environment uses enva_controller1 as the host that contains the Ansible Automation Platform installer directory and binaries.

  2. Change to the ansible-tower-setup-3.8.5-X directory 

    $ cd /path/to/ansible-tower-setup-3.8.5-X

  3. Run the Ansible Automation Platform installer to create a backup

    1. backup_dest provides the location where to store the backup of your Ansible Automation Platform database
    2. use_compression shrinks the size of the Ansible Automation Platform database backup
    3. @credentials.yml passes the password variables and their values encrypted via ansible-vault
    4. -- --ask-vault-pass asks for the password used to access the encrypted credentials.yml file

    5. -b sets the create a backup option to True 

      $ ./setup.sh -e 'backup_dest=<mount_point>' -e 'use_compression=True' -e @credentials.yml -b
Note

This reference environment takes advantage of encrypted credentials and does not include passwords in plain text. Details in Appendix C, Creating an encrypted credentials.yml file can be found on how to use ansible-vault to encrypt your credentials.

Note

The backup process may take some time to complete.

4.2. Import Ansible Automation Platform 1.2 database to Environment B

With the backup from Environment A created and available, the following imports the backed up Ansible Automation Platform database using the Ansible Automation Platform installer on Environment B.

Within Environment B,

  1. Login as the ansible user 

    $ ssh ansible@envb_controller1.example.com
    Note

    This reference environment uses envb_controller1 as the host that contains the Ansible Automation Platform installer directory and binaries.

  2. Change to the ansible-tower-setup-3.8.5-X directory 

    $ cd /path/to/ansible-tower-setup-3.8.5-X

  3. Run the Ansible Automation Platform installer to import the Ansible Automation Platform database

    1. restore_backup_file provides the location of the backed up Ansible Automation Platform database
    2. use_compression is set to True due to compression being used during the backup process

    3. -r sets the restore database option to True 

      $ ./setup.sh -e ‘restore_backup_file=<mount_point>/tower-backup-latest.tar.gz -e ‘use_compression=True’ -e @credentials.yml -r -- --ask-vault-pass
Note

This reference environment takes advantage of encrypted credentials and does not include passwords in plain text. Details in Appendix C, Creating an encrypted credentials.yml file can be found on how to use ansible-vault to encrypt your credentials.

Note

The import process may take some time to complete.

4.3. Upgrade Environment B to Ansible Automation Platform 2

With the successful import of the Ansible Automation Platform database, the final step in the migration process is to upgrade the Environment B Ansible Automation Platform 1.2 environment to Ansible Automation Platform 2 and expand the architecture of Environment B as shown in Figure 1.4, “Expanded Environment B Architecture Overview”.

Within Environment B,

  1. Login as the ansible user 

    $ ssh ansible@envb_controller1.example.com
    Note

    This reference environment uses envb_controller1 as the host that contains the Ansible Automation Platform installer directory and binaries.

  2. Download Ansible Automation Platform 2.1.1 Setup tar ansible-automation-platform-setup-2.1.1-1.tar.gz

    Note

    For disconnected installs, download the Ansible Automation Platform 2.1.1 Setup Bundle

  3. Untar the ansible-automation-platform-setup-2.1.1-1.tar.gz 

    $ tar zxvf ansible-automation-platform-setup-2.1.1-1.tar.gz

  4. Change directory into ansible-automation-platform-setup-2.1.1-1 

    $ cd ansible-automation-platform-setup-2.1.1-1/

  5. Copy the Ansible Automation Platform 1.2 inventory file to the ansible-automation-platform-setup-2.1.1-1 directory 

    $ cp /path/to/ansible-tower-setup-3.8.5-X/inventory .

  6. Generate an Ansible Automation Platform 2 installation inventory proposal using the Ansible Automation Platform 1.2 inventory file copied over using the Ansible Automation Platform installer 

    $ ./setup.sh
    Note

    ansible-core is installed during this process if not already installed.

    Warning

    Expect the Ansible Automation Platform installer to fail early in the process when creating the proposal inventory.new.ini.

    Expected error task look as follows: 

    TASK [ansible.automation_platform_installer.check_config_static : Detect pre-2.x inventory and offer a migration] ***
fatal: [172.16.58.48 -> localhost]: FAILED! => {"changed": false, "msg": "The installer has detected that you are using an inventory format from a version prior to 4.0. We have created an example inventory based on your old style inventory. Please check the file `/home/ansible/aap_install-2.1.1/ansible-automation-platform-setup-bundle-2.1.1-2/inventory.new.ini` and make necessary adjustments so that the file can be used by the installer."}

    Proposed inventory.new.ini

    [all:vars]
pg_host='10.0.188.133'
pg_port='5432'
pg_database='awx'
pg_username='awx'
pg_sslmode='prefer'
ansible_become='true'
ansible_user='ansible'
tower_package_name='automation-controller'
tower_package_version='4.1.1'
automationhub_package_name='automation-hub'
automationhub_package_version='4.4.1'
automation_platform_version='2.1.1'
automation_platform_channel='ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms'
minimum_ansible_version='2.11'

# In AAP 2.X [tower] has been renamed to [automationcontroller]
# Nodes in [automationcontroller] will be hybrid by default, capable of executing user jobs.
# To specify that any of these nodes should be control-only instead, give them a host var of `node_type=control`

[automationcontroller]
envb_controller1.example.com
envb_controller2.example.com
envb_controller3.example.com

[database]
envb_database.example.com

    Note

    The variables admin_password, pg_password and registry_password are not part of the inventory.new.ini file as it is not recommended to store passwords in plain text. An encrypted credentials.yml file is used instead.

  7. With the proposed inventory.new.ini created, modify the file to include the expanded architecture of Environment B that includes hop nodes and execution nodes

    Expanded Environment B inventory.new.ini

    [all:vars]
pg_host='envb_database.example.com'
pg_port='5432'
pg_database='awx'
pg_username='awx'
pg_sslmode='prefer'
ansible_become='true'
ansible_user='ansible'
tower_package_name='automation-controller'
tower_package_version='4.1.1'
automationhub_package_name='automation-hub'
automationhub_package_version='4.4.1'
automation_platform_version='2.1.1'
automation_platform_channel='ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms'
minimum_ansible_version='2.11'
registry_url='registry.redhat.io' 1
registry_username='myusername' 2

# In AAP 2.X [tower] has been renamed to [automationcontroller]
# Nodes in [automationcontroller] will be hybrid by default, capable of executing user jobs.
# To specify that any of these nodes should be control-only instead, give them a host var of `node_type=control`

[automationcontroller]
envb_controller1.example.com
envb_controller2.example.com
envb_controller3.example.com

[database]
envb_database.example.com

[automationcontroller:vars]
node_type=control 3
peers=envb_datacenter_execution_nodes,envb_datacenter_hop_nodes 4

[execution_nodes]
envb_executionnode-1.example.com
envb_executionnode-2.example.com
envb_hopnnode-sacramento.example.com node_type=hop peers=sacramento_execution_nodes 5
envb_hopnode-new-delhi.example.com node_type=hop peers=new-delhi_execution_nodes
envb_hopnode-dublin.example.com node_type=hop peers=env_hopnode-new-delhi.example.com
envb_executionnode-3.example.com
envb_executionnode-4.example.com
envb_executionnode-5.example.com
envb_executionnode-6.example.com

[envb_datacenter_execution_nodes] 6
envb_executionnode-1.example.com
envb_executionnode-2.example.com

[envb_datacenter_hop_nodes] 7
envb_hopnnode-sacramento.example.com
envb_hopnode-new-delhi.example.com
envb_hopnode-dublin.example.com

[sacramento_execution_nodes] 8
envb_executionnode-3.example.com
envb_executionnode-4.example.com

[new-delhi_execution_nodes] 9
envb_executionnode-5.example.com
envb_executionnode-6.example.com

    1
    Execution Environment images are downloaded and included in your installation. Proper credentials required to download the images.
    2
    User credential for access to registry_url.
    3
    control nodes run project and inventory updates and system jobs, but not execution jobs. Execution capabilities are disabled on these nodes.
    4
    Setting peer relationships between the execution nodes.
    5
    Setting node type and peer relationships between the hop nodes and execution nodes.
    6
    Group of execution nodes with direct connection access to the automation controller nodes.
    7
    Group of hop nodes that route traffic to their corresponding execution nodes.
    8
    Group of execution nodes accessible via envb_hopnode-sacramento.example.com
    9
    Group of execution nodes accessible via envb_hopnode-new-delhi.example.com

  8. Run the setup.sh to upgrade to Ansible Automation Platform 2 with the following options 

    $ ./setup.sh -i inventory.new.ini -e @credentials.yml -- --ask-vault-pass

  9. Verify the Ansible Automation Platform dashboard UI is accessible across all automation controller nodes.

    Note

    If you experience 502 error or a Secure Connection Failed when accessing the the Ansible Automation Platform dashboard via any of your automation controllers, this is likely due to one or both of the following issues:

    • Certificate mismatch
    • Incorrect SELinux context for nginx

    The Appendix D, Post upgrade playbook provides a workaround to fix these issues. A fix is currently being implemented and should be fixed in an upcoming dot release.

    The cert mismatch issue is fixed in version 2.1.2 and later of Ansible Automation Platform. The incorrect SELinux context for nginx still requires the workaround Ansible Playbook. Check the Appendix D, Post upgrade playbook for more details.

This reference environment uses credentials.yml for the following variables: * admin_password * registry_password * pg_password

For more information regarding the different values that can be set within your inventory file, visit: Setting up the inventory file

4.4. Configuring instance and instance groups

With the upgrade process complete, you’ll need to associate your instances to their corresponding instance groups, e.g. sacramento and new-delhi.

  1. Select Administration→Instance Groups
  2. Click on the sacramento instance group
  3. Select the Instances tab
  4. Click the blue Associate button

  5. Within the Select Instances window, select

    1. envb_executionnode-3.example.com
    2. envb_executionnode-4.example.com
  6. Click Save

Repeat the process for the new-delhi instance group and associate the instances below with the new-delhi instance group:

  • envb_executionnode-5.example.com
  • envb_executionnode-6.example.com

Once complete, disassociate those instances within the default group.

  1. Select Administration→Instance Groups
  2. Click on the default instance group
  3. Select the Instances tab

  4. Select the checkbox to the following instances

    1. envb_executionnode-3.example.com
    2. envb_executionnode-4.example.com
    3. envb_executionnode-5.example.com
    4. envb_executionnode-6.example.com
  5. Click the blue button labeled Disassociate
  6. Confirm the dissociation via the red Disassociate button

The default instance group should only contain the following instances:

  • envb_executionnode-1.example.com
  • envb_executionnode-2.example.com

With the infrastructure migration complete, the focus shifts to migrating Python virtual environments to user-built execution environments.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.