Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 2. Ansible Automation Platform containerized installation

Ansible Automation Platform is a commercial offering that helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments.

This guide helps you to understand the installation requirements and processes behind the containerized version of Ansible Automation Platform.

Note

Upgrades from 2.4 Containerized Ansible Automation Platform Tech Preview to 2.5 Containerized Ansible Automation Platform are not supported.

2.1. Tested deployment models
Copiar enlace

Red Hat tests Ansible Automation Platform 2.5 with a defined set of topologies to give you opinionated deployment options. The supported topologies include infrastructure topology diagrams, tested system configurations, example inventory files, and network ports information.

For containerized Ansible Automation Platform, there are two infrastructure topology shapes:

  1. Growth - (All-in-one) Intended for organizations that are getting started with Ansible Automation Platform. This topology allows for smaller footprint deployments.
  2. Enterprise - Intended for organizations that require Ansible Automation Platform deployments to have redundancy or higher compute for large volumes of automation. This is a more future-proofed scaled out architecture.

For more information about the tested deployment topologies for containerized Ansible Automation Platform, see Container topologies in Tested deployment models.

2.2. System requirements
Copiar enlace

Use this information when planning your installation of containerized Ansible Automation Platform.

2.2.1. Prerequisites
Copiar enlace

  • Ensure a dedicated non-root user is configured on the Red Hat Enterprise Linux host.

    • This user requires sudo or other Ansible supported privilege escalation (sudo is recommended) to perform administrative tasks during the installation.
    • This user is responsible for the installation of containerized Ansible Automation Platform.
    • This user is also the service account for the containers running Ansible Automation Platform.
  • For managed nodes, ensure a dedicated user is configured on each node. Ansible Automation Platform connects as this user to run tasks on the node. For more information about configuring a dedicated user on each node, see Preparing the managed nodes for containerized installation.
  • For remote host installations, ensure SSH public key authentication is configured for the non-root user. For guidelines on setting up SSH public key authentication for the non-root user, see How to configure SSH public key authentication for passwordless login.
  • Ensure internet access is available from the Red Hat Enterprise Linux host if you are using the default online installation method.
  • Ensure the appropriate network ports are open if a firewall is in place. For more information about the ports to open, see Container topologies in Tested deployment models.
Important

Storing container images on an NFS share is not supported by Podman. To use an NFS share for the user home directory, set up the Podman storage backend path outside of the NFS share. For more information, see Rootless Podman and NFS.

2.2.2. Ansible Automation Platform system requirements
Copiar enlace

Your system must meet the following minimum system requirements to install and run Red Hat Ansible Automation Platform.

Expand
Table 2.1. System configuration
TypeDescriptionNotes

Subscription

  • Valid Red Hat Ansible Automation Platform subscription
  • Valid Red Hat Enterprise Linux subscription (to consume the BaseOS and AppStream repositories)
 

Operating system

  • Red Hat Enterprise Linux 9.2 or later minor versions of Red Hat Enterprise Linux 9.
  • Red Hat Enterprise Linux 10 or later minor versions of Red Hat Enterprise Linux 10.
 

CPU architecture

x86_64, AArch64, s390x (IBM Z), ppc64le (IBM Power)

 

ansible-core

  • RHEL 9: installation program uses ansible-core 2.14, Ansible Automation Platform operation uses ansible-core 2.16.
  • RHEL 10: installation program uses ansible-core 2.16, Ansible Automation Platform operation uses ansible-core 2.16.
  • The installation program uses the ansible-core package from the RHEL AppStream repository.
  • Ansible Automation Platform bundles ansible-core 2.16 for operation, so you do not need to install it manually.

Browser

A currently supported version of Mozilla Firefox or Google Chrome.

 

Database

PostgreSQL 15

External (customer supported) databases require International Components for Unicode (ICU) support.

Each virtual machine (VM) has the following system requirements:

Expand
Table 2.2. Virtual machine requirements
RequirementMinimum requirement

RAM

16 GB

CPUs

4

Local disk

  • Total available disk space: 60 GB
  • Installation directory: 15 GB (if on a dedicated partition)
  • /var/tmp for online installations: 1 GB
  • /var/tmp for offline or bundled installations: 3 GB
  • Temporary directory (defaults to /tmp) for offline or bundled installations: 10GB

Disk IOPS

3000

Note

If performing a bundled installation of the growth topology with hub_seed_collections=true, then 32 GB RAM is recommended. Note that with this configuration the install time is going to increase and can take 45 or more minutes alone to complete seeding the collections.

2.2.3. Database requirements
Copiar enlace

Ansible Automation Platform can work with two varieties of database:

  1. Database installed with Ansible Automation Platform - This database consists of a PostgreSQL installation done as part of an Ansible Automation Platform installation using PostgreSQL packages provided by Red Hat.
  2. Customer provided or configured database - This is an external database that is provided by the customer, whether on bare metal, virtual machine, container, or cloud hosted service.

Ansible Automation Platform requires customer provided (external) database to have International Components for Unicode (ICU) support.

Containerized Ansible Automation Platform runs the component services as Podman based containers on top of a Red Hat Enterprise Linux host. Prepare the Red Hat Enterprise Linux host to ensure a successful installation.

Procedure

  1. Log in to the Red Hat Enterprise Linux host as your non-root user.

  2. Ensure the hostname associated with your host is set as a fully qualified domain name (FQDN).

    1. To check the hostname associated with your host, run the following command: 

      hostname -f
      Copy to Clipboard Toggle word wrap

      Example output: 

      aap.example.org
      Copy to Clipboard Toggle word wrap

    2. If the hostname is not a FQDN, you can set it with the following command: 

      $ sudo hostnamectl set-hostname <your_hostname>
      Copy to Clipboard Toggle word wrap

  3. Register your Red Hat Enterprise Linux host with subscription-manager: 

    $ sudo subscription-manager register
    Copy to Clipboard Toggle word wrap

  4. Verify that only the BaseOS and AppStream repositories are enabled on the host: 

    $ sudo dnf repolist
    Copy to Clipboard Toggle word wrap

    Example output for RHEL 9: 

    Updating Subscription Management repositories.
repo id                                                    repo name
rhel-9-for-x86_64-appstream-rpms                           Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs)
rhel-9-for-x86_64-baseos-rpms                              Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)
    Copy to Clipboard Toggle word wrap

    Example output for RHEL 10: 

    Updating Subscription Management repositories.
repo id                                                    repo name
rhel-10-for-x86_64-appstream-rpms                          Red Hat Enterprise Linux 10 for x86_64 - AppStream (RPMs)
rhel-10-for-x86_64-baseos-rpms                             Red Hat Enterprise Linux 10 for x86_64 - BaseOS (RPMs)
    Copy to Clipboard Toggle word wrap
  5. Ensure the host can resolve host names and IP addresses using DNS. This is essential to ensure services can talk to one another.

  6. Install ansible-core: 

    $ sudo dnf install -y ansible-core
    Copy to Clipboard Toggle word wrap

  7. Optional: You can install additional utilities that can be useful for troubleshooting purposes, for example wget, git-core, rsync, and vim: 

    $ sudo dnf install -y wget git-core rsync vim
    Copy to Clipboard Toggle word wrap
  8. Optional: To have the installation program automatically pick up and apply your Ansible Automation Platform subscription manifest license, follow the steps in Obtaining a manifest file.

2.4. Preparing the managed nodes for containerized installation
Copiar enlace

Managed nodes, also referred to as hosts, are the devices that Ansible Automation Platform is configured to manage.

To ensure a consistent and secure setup of containerized Ansible Automation Platform, create a dedicated user on each host. Ansible Automation Platform connects as this user to run tasks on the host.

Once configured, you can define the dedicated user for each host by adding ansible_user=<username> in your inventory file, for example: aap.example.org ansible_user=aap.

Complete the following steps for each host:

Procedure

  1. Log in to the host as the root user.

  2. Create a new user. Replace <username> with the username you want, for example aap. 

    $ sudo adduser <username>
    Copy to Clipboard Toggle word wrap

  3. Set a password for the new user. Replace <username> with the username you created. 

    $ sudo passwd <username>
    Copy to Clipboard Toggle word wrap

  4. Configure the user to run sudo commands.

    For a secure and maintainable installation, it is a best practice to configure sudo privileges for the installation user in a dedicated file within the /etc/sudoers.d/ directory.

    1. Create a dedicated sudoers file for the user: 

      $ sudo visudo -f /etc/sudoers.d/<username>
      Copy to Clipboard Toggle word wrap

    2. Add the following line to the file, replacing <username> with the username you created: 

      <username> ALL=(ALL) NOPASSWD: ALL
      Copy to Clipboard Toggle word wrap
    3. Save and exit the file.

2.5. Downloading Ansible Automation Platform
Copiar enlace

Choose the installation program you need based on your Red Hat Enterprise Linux environment internet connectivity and download the installation program to your Red Hat Enterprise Linux host.

Prerequisites

  • You have logged in to the Red Hat Enterprise Linux host as your non-root user.

Procedure

  1. Download the latest version of containerized Ansible Automation Platform from the Ansible Automation Platform download page.

    1. For online installations: Ansible Automation Platform 2.5 Containerized Setup
    2. For offline or bundled installations: Ansible Automation Platform 2.5 Containerized Setup Bundle

  2. Copy the installation program .tar.gz file and the optional manifest .zip file onto your Red Hat Enterprise Linux host.

    1. You can use the scp command to securely copy the files. The basic syntax for scp is: 

      scp [options] <path_to_source_file> <path_to_destination>
      Copy to Clipboard Toggle word wrap

      Use the following scp command to copy the installation program .tar.gz file to an AWS EC2 instance with a private key (replace the placeholder <> values with your actual information): 

      scp -i <path_to_private_key> ansible-automation-platform-containerized-setup-<version_number>.tar.gz ec2-user@<remote_host_ip_or_hostname>:<path_to_destination>
      Copy to Clipboard Toggle word wrap

  3. Decide where you want the installation program to reside on the file system. This is referred to as your installation directory.

    1. Installation related files are created under this location and require at least 15 GB for the initial installation.

  4. Unpack the installation program .tar.gz file into your installation directory, and go to the unpacked directory.

    1. To unpack the online installer: 

      $ tar xfvz ansible-automation-platform-containerized-setup-<version_number>.tar.gz
      Copy to Clipboard Toggle word wrap

    2. To unpack the offline or bundled installer: 

      $ tar xfvz ansible-automation-platform-containerized-setup-bundle-<version_number>-<arch_name>.tar.gz
      Copy to Clipboard Toggle word wrap

2.6. Configuring the inventory file
Copiar enlace

You can control the installation of Ansible Automation Platform with inventory files. Inventory files define the information needed to customize the installation. For example, host details, certificate details, and various component-specific settings.

Example inventory files are available in this document that you can copy and change to quickly get started.

Additionally, growth topology and enterprise topology inventory files are available in the following locations:

  • In the downloaded installation program package:

    • The default inventory file, named inventory, is for the enterprise topology pattern.
    • To deploy the growth topology (all-in-one) pattern, use the inventory-growth file instead.
  • In Container topologies in Tested deployment models.

To use the example inventory files, replace the < > placeholders with your specific variables, and update the host names.

Refer to the README.md file in the installation directory or Inventory file variables for more information about optional and required variables.

Use the example inventory file to perform an online installation for the containerized growth topology (all-in-one): 

# This is the Ansible Automation Platform installer inventory file intended for the container growth deployment topology.
# This inventory file expects to be run from the host where Ansible Automation Platform will be installed.
# Consult the Ansible Automation Platform product documentation about this topology's tested hardware configuration.
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/tested_deployment_models/container-topologies
#
# Consult the docs if you are unsure what to add
# For all optional variables consult the included README.md
# or the Ansible Automation Platform documentation:
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation

# This section is for your platform gateway hosts
# -----------------------------------------------------
[automationgateway]
aap.example.org

# This section is for your automation controller hosts
# -----------------------------------------------------
[automationcontroller]
aap.example.org

# This section is for your automation hub hosts
# -----------------------------------------------------
[automationhub]
aap.example.org

# This section is for your Event-Driven Ansible controller hosts
# -----------------------------------------------------
[automationeda]
aap.example.org

# This section is for the Ansible Automation Platform database
# -----------------------------------------------------
[database]
aap.example.org

[all:vars]
# Ansible
ansible_connection=local

# Common variables
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#general-variables
# -----------------------------------------------------
postgresql_admin_username=postgres
postgresql_admin_password=<set your own>

registry_username=<your RHN username>
registry_password=<your RHN password>

redis_mode=standalone

# Platform gateway
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#platform-gateway-variables
# -----------------------------------------------------
gateway_admin_password=<set your own>
gateway_pg_host=aap.example.org
gateway_pg_password=<set your own>

# Automation controller
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#controller-variables
# -----------------------------------------------------
controller_admin_password=<set your own>
controller_pg_host=aap.example.org
controller_pg_password=<set your own>
controller_percent_memory_capacity=0.5

# Automation hub
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#hub-variables
# -----------------------------------------------------
hub_admin_password=<set your own>
hub_pg_host=aap.example.org
hub_pg_password=<set your own>
hub_seed_collections=false

# Event-Driven Ansible controller
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#event-driven-ansible-variables
# -----------------------------------------------------
eda_admin_password=<set your own>
eda_pg_host=aap.example.org
eda_pg_password=<set your own>
Copy to Clipboard Toggle word wrap

  • ansible_connection=local - Used for all-in-one installations where the installation program is run on the same node that hosts Ansible Automation Platform.

    • If the installation program is run from a separate node, do not include ansible_connection=local. In this case, use an SSH connection instead.
  • [database] - This group in the inventory file defines the Ansible Automation Platform managed database.

Use the example inventory file to perform an online installation for the containerized enterprise topology: 

# This is the Ansible Automation Platform enterprise installer inventory file
# Consult the docs if you are unsure what to add
# For all optional variables consult the included README.md
# or the Red Hat documentation:
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation

# This section is for your platform gateway hosts
# -----------------------------------------------------
[automationgateway]
gateway1.example.org
gateway2.example.org

# This section is for your automation controller hosts
# -----------------------------------------------------
[automationcontroller]
controller1.example.org
controller2.example.org

# This section is for your Ansible Automation Platform execution hosts
# -----------------------------------------------------
[execution_nodes]
hop1.example.org receptor_type='hop'
exec1.example.org
exec2.example.org

# This section is for your automation hub hosts
# -----------------------------------------------------
[automationhub]
hub1.example.org
hub2.example.org

# This section is for your Event-Driven Ansible controller hosts
# -----------------------------------------------------
[automationeda]
eda1.example.org
eda2.example.org

[redis]
gateway1.example.org
gateway2.example.org
hub1.example.org
hub2.example.org
eda1.example.org
eda2.example.org

[all:vars]

# Common variables
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#general-variables
# -----------------------------------------------------
postgresql_admin_username=<set your own>
postgresql_admin_password=<set your own>
registry_username=<your RHN username>
registry_password=<your RHN password>

# Platform gateway
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#platform-gateway-variables
# -----------------------------------------------------
gateway_admin_password=<set your own>
gateway_pg_host=externaldb.example.org
gateway_pg_database=<set your own>
gateway_pg_username=<set your own>
gateway_pg_password=<set your own>

# Automation controller
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#controller-variables
# -----------------------------------------------------
controller_admin_password=<set your own>
controller_pg_host=externaldb.example.org
controller_pg_database=<set your own>
controller_pg_username=<set your own>
controller_pg_password=<set your own>

# Automation hub
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#hub-variables
# -----------------------------------------------------
hub_admin_password=<set your own>
hub_pg_host=externaldb.example.org
hub_pg_database=<set your own>
hub_pg_username=<set your own>
hub_pg_password=<set your own>

# Event-Driven Ansible controller
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/appendix-inventory-files-vars#event-driven-ansible-variables
# -----------------------------------------------------
eda_admin_password=<set your own>
eda_pg_host=externaldb.example.org
eda_pg_database=<set your own>
eda_pg_username=<set your own>
eda_pg_password=<set your own>
Copy to Clipboard Toggle word wrap

2.6.3. Setting registry_username and registry_password
Copiar enlace

When using the registry_username and registry_password variables for an online non-bundled installation, you need to create a new registry service account.

Registry service accounts are named tokens that can be used in environments where credentials will be shared, such as deployment systems.

Procedure

  1. Go to https://access.redhat.com/terms-based-registry/accounts.
  2. On the Registry Service Accounts page click New Service Account.
  3. Enter a name for the account using only the allowed characters.
  4. Optionally enter a description for the account.
  5. Click Create.
  6. Find the created account in the list by searching for your name in the search field.
  7. Click the name of the account that you created.

  8. Alternatively, if you know the name of your token, you can go directly to the page by entering the URL: 

    https://access.redhat.com/terms-based-registry/token/<name-of-your-token>
    Copy to Clipboard Toggle word wrap

  9. A token page opens, displaying a generated username (different from the account name) and a token.

    1. If no token is displayed, click Regenerate Token. You can also click this to generate a new username and token.
  10. Copy the username (for example "1234567|testuser") and use it to set the variable registry_username.
  11. Copy the token and use it to set the variable registry_password.

2.7. Advanced configuration options
Copiar enlace

Advanced configuration options, such as external database set up and the use of custom TLS certs, are available for more complex deployments of containerized Ansible Automation Platform.

If you are not using these advanced configuration options, go to Installing containerized Ansible Automation Platform to continue with your installation.

When using redhat.insights_eda or similar plugins to run rulebook activations in Event-Driven Ansible controller, you must add a safe plugin variable to a directory in Ansible Automation Platform. This ensures connection between Event-Driven Ansible controller and the source plugin, and displays port mappings correctly.

Procedure

  1. Create a directory for the safe plugin variable: 

    mkdir -p ./group_vars/automationeda
    Copy to Clipboard Toggle word wrap
  2. Create a file within that directory for your new setting (for example, touch ./group_vars/automationeda/custom.yml)

  3. Add the variable eda_safe_plugins with a list of plugins to enable. For example: 

    eda_safe_plugins: ['ansible.eda.webhook', 'ansible.eda.alertmanager']
    Copy to Clipboard Toggle word wrap

2.7.2. Adding execution nodes
Copiar enlace

Containerized Ansible Automation Platform can deploy remote execution nodes.

You can define remote execution nodes in the [execution_nodes] group of your inventory file: 

[execution_nodes]
<fqdn_of_your_execution_host>
Copy to Clipboard Toggle word wrap

By default, an execution node is configured with the following settings which can be modified as needed: 

receptor_port=27199
receptor_protocol=tcp
receptor_type=execution
Copy to Clipboard Toggle word wrap
  • receptor_port - The port number that receptor listens on for incoming connections from other receptor nodes.
  • receptor_type - The role of the node. Valid options include execution or hop.
  • receptor_protocol - The protocol used for communication. Valid options include tcp or udp.

By default, all nodes in the [execution_nodes] group are added as peers for the controller node. To change the peer configuration, use the receptor_peers variable.

Note

The value of receptor_peers must be a comma-separated list of host names. Do not use inventory group names.

Example configuration: 

[execution_nodes]
# Execution nodes
exec1.example.com
exec2.example.com
# Hop node that peers with the two execution nodes above
hop1.example.com receptor_type=hop receptor_peers='["exec1.example.com","exec2.example.com"]'
Copy to Clipboard Toggle word wrap

2.7.3. Configuring storage for automation hub
Copiar enlace

Configure storage backends for automation hub including Amazon S3, Azure Blob Storage, and Network File System (NFS) storage.

2.7.3.1. Configuring Amazon S3 storage for automation hub
Copiar enlace

Amazon S3 storage is a type of object storage that is supported in containerized installations. When using an AWS S3 storage backend, set hub_storage_backend to s3. The AWS S3 bucket needs to exist before running the installation program.

Procedure

  1. Ensure your AWS S3 bucket exists before proceeding with the installation.

  2. Add the following variables to your inventory file under the [all:vars] group to configure S3 storage:

    • hub_s3_access_key
    • hub_s3_secret_key
    • hub_s3_bucket_name

    • hub_s3_extra_settings

      You can pass extra parameters through an Ansible hub_s3_extra_settings dictionary. For example: 

      hub_s3_extra_settings:
  AWS_S3_MAX_MEMORY_SIZE: 4096
  AWS_S3_REGION_NAME: eu-central-1
  AWS_S3_USE_SSL: True
      Copy to Clipboard Toggle word wrap

2.7.3.2. Configuring Azure Blob Storage for automation hub
Copiar enlace

Azure Blob storage is a type of object storage that is supported in containerized installations. When using an Azure blob storage backend, set hub_storage_backend to azure. The Azure container needs to exist before running the installation program.

Procedure

  1. Ensure your Azure container exists before proceeding with the installation.

  2. Add the following variables to your inventory file under the [all:vars] group to configure Azure Blob storage:

    • hub_azure_account_key
    • hub_azure_account_name
    • hub_azure_container

    • hub_azure_extra_settings

      You can pass extra parameters through an Ansible hub_azure_extra_settings dictionary. For example: 

      hub_azure_extra_settings:
  AZURE_LOCATION: foo
  AZURE_SSL: True
  AZURE_URL_EXPIRATION_SECS: 60
      Copy to Clipboard Toggle word wrap

NFS is a type of shared storage that is supported in containerized installations. Shared storage is required when installing more than one instance of automation hub with a file storage backend. When installing a single instance of the automation hub, shared storage is optional.

Procedure

  1. To configure shared storage for automation hub, set the hub_shared_data_path variable in your inventory file: 

    hub_shared_data_path=<path_to_nfs_share>
    Copy to Clipboard Toggle word wrap

    The value must match the format host:dir, for example nfs-server.example.com:/exports/hub.

  2. (Optional) To change the mount options for your NFS share, use the hub_shared_data_mount_opts variable. The default value is rw,sync,hard.

2.7.4. Configuring a HAProxy load balancer
Copiar enlace

To configure a HAProxy load balancer in front of platform gateway with a custom CA cert, set the following inventory file variables under the [all:vars] group: 

custom_ca_cert=<path_to_cert_crt>
gateway_main_url=<https://load_balancer_url>
Copy to Clipboard Toggle word wrap
Note

HAProxy SSL passthrough mode is not supported with platform gateway.

2.7.5. Enabling automation content collection and container signing
Copiar enlace

Automation content signing is disabled by default. To enable it, the following installation variables are required in the inventory file: 

# Collection signing
hub_collection_signing=true
hub_collection_signing_key=<full_path_to_collection_gpg_key>

# Container signing
hub_container_signing=true
hub_container_signing_key=<full_path_to_container_gpg_key>
Copy to Clipboard Toggle word wrap

The following variables are required if the keys are protected by a passphrase: 

# Collection signing
hub_collection_signing_pass=<gpg_key_passphrase>

# Container signing
hub_container_signing_pass=<gpg_key_passphrase>
Copy to Clipboard Toggle word wrap

The hub_collection_signing_key and hub_container_signing_key variables require the set up of keys before running an installation.

Automation content signing currently only supports GnuPG (GPG) based signature keys. For more information about GPG, see the GnuPG man page.

Note

The algorithm and cipher used is the responsibility of the customer.

Procedure

  1. On a RHEL9 server run the following command to create a new key pair for collection signing: 

    gpg --gen-key
    Copy to Clipboard Toggle word wrap

  2. Enter your information for "Real name" and "Email address":

    Example output: 

    gpg --gen-key
gpg (GnuPG) 2.3.3; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Note: Use "gpg --full-generate-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Joe Bloggs
Email address: jbloggs@example.com
You selected this USER-ID:
    "Joe Bloggs <jbloggs@example.com>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? O
    Copy to Clipboard Toggle word wrap

    If this fails, your environment does not have the necessary prerequisite packages installed for GPG. Install the necessary packages to proceed.

  3. A dialog box will appear and ask you for a passphrase. This is optional but recommended.

  4. The keys are then generated, and produce output similar to the following: 

    We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 022E4FBFB650F1C4 marked as ultimately trusted
gpg: revocation certificate stored as '/home/aapuser/.gnupg/openpgp-revocs.d/F001B037976969DD3E17A829022E4FBFB650F1C4.rev'
public and secret key created and signed.

pub   rsa3072 2024-10-25 [SC] [expires: 2026-10-25]
      F001B037976969DD3E17A829022E4FBFB650F1C4
uid                      Joe Bloggs <jbloggs@example.com>
sub   rsa3072 2024-10-25 [E] [expires: 2026-10-25]
    Copy to Clipboard Toggle word wrap

    Note the expiry date that you can set based on company standards and needs.

  5. You can view all of your GPG keys by running the following command: 

    gpg --list-secret-keys --keyid-format=long
    Copy to Clipboard Toggle word wrap

  6. To export the public key run the following command: 

    gpg --export -a --output collection-signing-key.pub <email_address_used_to_generate_key>
    Copy to Clipboard Toggle word wrap

  7. To export the private key run the following command: 

    gpg -a --export-secret-keys <email_address_used_to_generate_key> > collection-signing-key.priv
    Copy to Clipboard Toggle word wrap
  8. If a passphrase is detected, you will be prompted to enter the passphrase.

  9. To view the private key file contents, run the following command: 

    cat collection-signing-key.priv
    Copy to Clipboard Toggle word wrap

    Example output: 

    -----BEGIN PGP PRIVATE KEY BLOCK-----

lQWFBGcbN14BDADTg5BsZGbSGMHypUJMuzmIffzzz4LULrZA8L/I616lzpBHJvEs
sSN6KuKY1TcIwIDCCa/U5Obm46kurpP2Y+vNA1YSEtMJoSeHeamWMDd99f49ItBp

<snippet>

j920hRy/3wJGRDBMFa4mlQg=
=uYEF
-----END PGP PRIVATE KEY BLOCK-----
    Copy to Clipboard Toggle word wrap
  10. Repeat steps 1 to 9 to create a key pair for container signing.

  11. Add the following variables to the inventory file and run the installation to create the signing services: 

    # Collection signing
hub_collection_signing=true
hub_collection_signing_key=/home/aapuser/aap/ansible-automation-platform-containerized-setup-<version_number>/collection-signing-key.priv
# This variable is required if the key is protected by a passphrase
hub_collection_signing_pass=<password>

# Container signing
hub_container_signing=true
hub_container_signing_key=/home/aapuser/aap/ansible-automation-platform-containerized-setup-<version_number>/container-signing-key.priv
# This variable is required if the key is protected by a passphrase
hub_container_signing_pass=<password>
    Copy to Clipboard Toggle word wrap

2.7.6. Setting up a customer provided (external) database
Copiar enlace

There are two possible scenarios for setting up an external database:

  1. An external database with PostgreSQL admin credentials
  2. An external database without PostgreSQL admin credentials
Important
  • When using an external database with Ansible Automation Platform, you must create and maintain that database. Ensure that you clear your external database when uninstalling Ansible Automation Platform.
  • Red Hat Ansible Automation Platform requires customer provided (external) database to have ICU support.
  • During configuration of an external database, you must check the external database coverage. For more information, see Red Hat Ansible Automation Platform Database Scope of Coverage.

If you have PostgreSQL admin credentials, you can supply them in the inventory file and the installation program creates the PostgreSQL users and databases for each component for you. The PostgreSQL admin account must have SUPERUSER privileges.

Procedure

  • To configure the PostgreSQL admin credentials, add the following variables to the inventory file under the [all:vars] group: 

    postgresql_admin_username=<set your own>
postgresql_admin_password=<set your own>
    Copy to Clipboard Toggle word wrap

If you do not have PostgreSQL admin credentials, then PostgreSQL users and databases need to be created for each component (platform gateway, automation controller, automation hub, and Event-Driven Ansible) before running the installation program.

Procedure

  1. Connect to a PostgreSQL compliant database server with a user that has SUPERUSER privileges. 

    # psql -h <hostname> -U <username> -p <port_number>
    Copy to Clipboard Toggle word wrap

    For example: 

    # psql -h db.example.com -U superuser -p 5432
    Copy to Clipboard Toggle word wrap

  2. Create the user with a password and ensure the CREATEDB role is assigned to the user. For more information, see Database Roles. 

    CREATE USER <username> WITH PASSWORD <password> CREATEDB;
    Copy to Clipboard Toggle word wrap

  3. Create the database and add the user you created as the owner. 

    CREATE DATABASE <database_name> OWNER <username>;
    Copy to Clipboard Toggle word wrap

  4. When you have created the PostgreSQL users and databases for each component, you can supply them in the inventory file under the [all:vars] group. 

    # Platform gateway
gateway_pg_host=aap.example.org
gateway_pg_database=<set your own>
gateway_pg_username=<set your own>
gateway_pg_password=<set your own>

# Automation controller
controller_pg_host=aap.example.org
controller_pg_database=<set your own>
controller_pg_username=<set your own>
controller_pg_password=<set your own>

# Automation hub
hub_pg_host=aap.example.org
hub_pg_database=<set your own>
hub_pg_username=<set your own>
hub_pg_password=<set your own>

# Event-Driven Ansible
eda_pg_host=aap.example.org
eda_pg_database=<set your own>
eda_pg_username=<set your own>
eda_pg_password=<set your own>
    Copy to Clipboard Toggle word wrap

The database migration script uses hstore fields to store information, therefore the hstore extension must be enabled in the automation hub PostgreSQL database.

This process is automatic when using the Ansible Automation Platform installer and a managed PostgreSQL server.

If the PostgreSQL database is external, you must enable the hstore extension in the automation hub PostgreSQL database manually before installation.

If the hstore extension is not enabled before installation, a failure raises during database migration.

Procedure

  1. Check if the extension is available on the PostgreSQL server (automation hub database). 

    $ psql -d <automation hub database> -c "SELECT * FROM pg_available_extensions WHERE name='hstore'"
    Copy to Clipboard Toggle word wrap

  2. Where the default value for <automation hub database> is automationhub.

    Example output with hstore available: 

    name  | default_version | installed_version |comment
------+-----------------+-------------------+---------------------------------------------------
 hstore | 1.7           |                   | data type for storing sets of (key, value) pairs
(1 row)
    Copy to Clipboard Toggle word wrap

    Example output with hstore not available: 

     name | default_version | installed_version | comment
------+-----------------+-------------------+---------
(0 rows)
    Copy to Clipboard Toggle word wrap

  3. On a RHEL based server, the hstore extension is included in the postgresql-contrib RPM package, which is not installed automatically when installing the PostgreSQL server RPM package.

    To install the RPM package, use the following command: 

    dnf install postgresql-contrib
    Copy to Clipboard Toggle word wrap

  4. Load the hstore PostgreSQL extension into the automation hub database with the following command: 

    $ psql -d <automation hub database> -c "CREATE EXTENSION hstore;"
    Copy to Clipboard Toggle word wrap

    In the following output, the installed_version field lists the hstore extension used, indicating that hstore is enabled. 

    name | default_version | installed_version | comment
-----+-----------------+-------------------+------------------------------------------------------
hstore  |     1.7      |       1.7         | data type for storing sets of (key, value) pairs
(1 row)
    Copy to Clipboard Toggle word wrap

mTLS authentication is disabled by default. To configure each component’s database with mTLS authentication, add the following variables to your inventory file under the [all:vars] group and ensure each component has a different TLS certificate and key:

Procedure

  • Add the following variables to your inventory file under the [all:vars] group: 

    # Platform gateway
gateway_pg_cert_auth=true
gateway_pg_tls_cert=/path/to/gateway.cert
gateway_pg_tls_key=/path/to/gateway.key
gateway_pg_sslmode=verify-full

# Automation controller
controller_pg_cert_auth=true
controller_pg_tls_cert=/path/to/awx.cert
controller_pg_tls_key=/path/to/awx.key
controller_pg_sslmode=verify-full

# Automation hub
hub_pg_cert_auth=true
hub_pg_tls_cert=/path/to/pulp.cert
hub_pg_tls_key=/path/to/pulp.key
hub_pg_sslmode=verify-full

# Event-Driven Ansible
eda_pg_cert_auth=true
eda_pg_tls_cert=/path/to/eda.cert
eda_pg_tls_key=/path/to/eda.key
eda_pg_sslmode=verify-full
    Copy to Clipboard Toggle word wrap

2.7.7. Using custom TLS certificates
Copiar enlace

Red Hat Ansible Automation Platform uses X.509 certificate and key pairs to secure traffic both internally between Ansible Automation Platform components and externally for public UI and API connections.

There are two primary ways to manage TLS certificates for your Ansible Automation Platform deployment:

  1. Ansible Automation Platform generated certificates (this is the default)
  2. User-provided certificates

2.7.7.1. Ansible Automation Platform generated certificates
Copiar enlace

By default, the installation program creates a self-signed Certificate Authority (CA) and uses it to generate self-signed TLS certificates for all Ansible Automation Platform services. The self-signed CA certificate and key are generated on one node under the ~/aap/tls/ directory and copied to the same location on all other nodes. This CA is valid for 10 years after the initial creation date.

Self-signed certificates are not part of any public chain of trust. The installation program creates a certificate truststore that includes the self-signed CA certificate under ~/aap/tls/extracted/ and bind-mounts that directory to each Ansible Automation Platform service container under /etc/pki/ca-trust/extracted/. This allows each Ansible Automation Platform component to validate the self-signed certificates of the other Ansible Automation Platform services. The CA certificate can also be added to the truststore of other systems or browsers as needed.

2.7.7.2. User-provided certificates
Copiar enlace

To use your own TLS certificates and keys to replace some or all of the self-signed certificates generated during installation, you can set specific variables in your inventory file. These certificates and keys must be generated by a public or organizational CA in advance so that they are available during the installation process.

2.7.7.2.1. Using a custom CA to generate all TLS certificates
Copiar enlace

Use this method when you want Ansible Automation Platform to generate all of the certificates, but you want them signed by a custom CA rather than the default self-signed certificates.

Procedure

  • To use a custom Certificate Authority (CA) to generate TLS certificates for all Ansible Automation Platform services, set the following variables in your inventory file: 

    ca_tls_cert=<path_to_ca_tls_certificate>
ca_tls_key=<path_to_ca_tls_key>
    Copy to Clipboard Toggle word wrap
2.7.7.2.2. Providing custom TLS certificates for each service
Copiar enlace

Use this method if your organization manages TLS certificates outside of Ansible Automation Platform and requires manual provisioning.

Procedure

  • To manually provide TLS certificates for each individual service (for example, automation controller, automation hub, and Event-Driven Ansible), set the following variables in your inventory file: 

    # Platform gateway
gateway_tls_cert=<path_to_tls_certificate>
gateway_tls_key=<path_to_tls_key>
gateway_pg_tls_cert=<path_to_tls_certificate>
gateway_pg_tls_key=<path_to_tls_key>
gateway_redis_tls_cert=<path_to_tls_certificate>
gateway_redis_tls_key=<path_to_tls_key>

# Automation controller
controller_tls_cert=<path_to_tls_certificate>
controller_tls_key=<path_to_tls_key>
controller_pg_tls_cert=<path_to_tls_certificate>
controller_pg_tls_key=<path_to_tls_key>

# Automation hub
hub_tls_cert=<path_to_tls_certificate>
hub_tls_key=<path_to_tls_key>
hub_pg_tls_cert=<path_to_tls_certificate>
hub_pg_tls_key=<path_to_tls_key>

# Event-Driven Ansible
eda_tls_cert=<path_to_tls_certificate>
eda_tls_key=<path_to_tls_key>
eda_pg_tls_cert=<path_to_tls_certificate>
eda_pg_tls_key=<path_to_tls_key>
eda_redis_tls_cert=<path_to_tls_certificate>
eda_redis_tls_key=<path_to_tls_key>

# PostgreSQL
postgresql_tls_cert=<path_to_tls_certificate>
postgresql_tls_key=<path_to_tls_key>

# Receptor
receptor_tls_cert=<path_to_tls_certificate>
receptor_tls_key=<path_to_tls_key>

# Redis
redis_tls_cert=<path_to_tls_certificate>
redis_tls_key=<path_to_tls_key>
    Copy to Clipboard Toggle word wrap
2.7.7.2.3. Considerations for certificates provided per service
Copiar enlace

When providing custom TLS certificates for each individual service, consider the following:

  • It is possible to provide unique certificates per host. This requires defining the specific _tls_cert and _tls_key variables in your inventory file as shown in the earlier inventory file example.
  • For services deployed across many nodes (for example, when following the enterprise topology), the provided certificate for that service must include the FQDN of all associated nodes in its Subject Alternative Name (SAN) field.
  • If an external-facing service (such as automation controller or platform gateway) is deployed behind a load balancer that performs SSL/TLS offloading, the service’s certificate must include the load balancer’s FQDN in its SAN field, in addition to the FQDNs of the individual service nodes.
2.7.7.2.4. Providing a custom CA certificate
Copiar enlace

When you manually provide TLS certificates, those certificates might be signed by a custom CA. Provide a custom CA certificate to ensure proper authentication and secure communication within your environment. If you have multiple custom CA certificates, you must merge them into a single file.

Procedure

  • If any of the TLS certificates you manually provided are signed by a custom CA, you must specify the CA certificate by using the following variable in your inventory file: 

    custom_ca_cert=<path_to_custom_ca_certificate>
    Copy to Clipboard Toggle word wrap

    If you have more than one CA certificate, combine them into a single file and reference the combined certificate with the custom_ca_cert variable.

2.7.7.3. Receptor certificate considerations
Copiar enlace

When using a custom certificate for Receptor nodes, the certificate requires the otherName field specified in the Subject Alternative Name (SAN) of the certificate with the value 1.3.6.1.4.1.2312.19.1. For more information, see Above the mesh TLS.

Receptor does not support the usage of wildcard certificates. Additionally, each Receptor certificate must have the host FQDN specified in its SAN for TLS hostname validation to be correctly performed.

2.7.7.4. Redis certificate considerations
Copiar enlace

When using custom TLS certificates for Redis-related services, consider the following for mutual TLS (mTLS) communication if specifying Extended Key Usage (EKU):

  • The Redis server certificate (redis_tls_cert) should include the serverAuth (web server authentication) and clientAuth (client authentication) EKU.
  • The Redis client certificates (gateway_redis_tls_cert, eda_redis_tls_cert) should include the clientAuth (client authentication) EKU.

2.7.8. Using custom Receptor signing keys
Copiar enlace

Receptor signing is enabled by default unless receptor_disable_signing=true is set, and an RSA key pair (public and private) is generated by the installation program. However, you can set custom RSA public and private keys by using the following variables: 

receptor_signing_private_key=<full_path_to_private_key>
receptor_signing_public_key=<full_path_to_public_key>
Copy to Clipboard Toggle word wrap

2.8. Installing containerized Ansible Automation Platform
Copiar enlace

After you prepare the Red Hat Enterprise Linux host, download Ansible Automation Platform, and configure the inventory file, run the install playbook to install containerized Ansible Automation Platform.

Prerequisites

You have done the following:

Procedure

  1. Go to the installation directory on your Red Hat Enterprise Linux host.

  2. Run the install playbook: 

    ansible-playbook -i <inventory_file_name> ansible.containerized_installer.install
    Copy to Clipboard Toggle word wrap

    For example: 

    ansible-playbook -i inventory ansible.containerized_installer.install
    Copy to Clipboard Toggle word wrap

    You can add additional parameters to the installation command as needed: 

    ansible-playbook -i <inventory_file_name> -e @<vault_file_name> --ask-vault-pass -K -v ansible.containerized_installer.install
    Copy to Clipboard Toggle word wrap

    For example: 

    ansible-playbook -i inventory -e @vault.yml --ask-vault-pass -K -v  ansible.containerized_installer.install
    Copy to Clipboard Toggle word wrap
    • -i <inventory_file_name> - The inventory file to use for the installation.
    • -e @<vault_file_name> --ask-vault-pass - (Optional) If you are using a vault to store sensitive variables, add this to the installation command.
    • -K - (Optional) If your privilege escalation requires you to enter a password, add this to the installation command. You are then prompted for the BECOME password.
    • -v - (Optional) You can use increasing verbosity, up to 4 v’s (-vvvv) to see the details of the installation process. However, it is important to note that this can significantly increase installation time, so use it only as needed or requested by Red Hat support.

Verification

  • After the installation completes, verify that you can access Ansible Automation Platform which is available by default at the following URL: 

    https://<gateway_node>:443
    Copy to Clipboard Toggle word wrap
  • Log in as the admin user with the credentials you created for gateway_admin_username and gateway_admin_password.

  • The default ports and protocols used for Ansible Automation Platform are 80 (HTTP) and 443 (HTTPS). You can customize the ports with the following variables: 

    envoy_http_port=80
envoy_https_port=443
    Copy to Clipboard Toggle word wrap

  • If you want to disable HTTPS, set envoy_disable_https to true: 

    envoy_disable_https: true
    Copy to Clipboard Toggle word wrap

2.9. Updating containerized Ansible Automation Platform
Copiar enlace

Perform a patch update for a container-based installation of Ansible Automation Platform from 2.5 to 2.5.x.

Upgrades from 2.4 Containerized Ansible Automation Platform Tech Preview to 2.5 Containerized Ansible Automation Platform are not supported.

Prerequisites

  • You have reviewed the release notes for the associated patch release.
  • You have created a backup of your Ansible Automation Platform deployment.

Procedure

  1. Log in to the Red Hat Enterprise Linux host as your dedicated non-root user.
  2. Follow the steps in Downloading Ansible Automation Platform to download the latest version of containerized Ansible Automation Platform.
  3. Copy the downloaded installation program to your Red Hat Enterprise Linux Host.
  4. Edit the inventory file to match your required configuration. You can keep the same parameters from your existing Ansible Automation Platform deployment or you can change the parameters to match any modifications to your environment.

  5. Run the install playbook: 

    $ ansible-playbook -i inventory ansible.containerized_installer.install
    Copy to Clipboard Toggle word wrap
    • If your privilege escalation requires a password to be entered, append -K to the command. You will then be prompted for the BECOME password.
    • You can use increasing verbosity, up to 4 v’s (-vvvv) to see the details of the installation process. However it is important to note that this can significantly increase installation time, so it is recommended that you use it only as needed or requested by Red Hat support.
  6. The update begins.

2.10. Backing up containerized Ansible Automation Platform
Copiar enlace

Perform a backup of your container-based installation of Ansible Automation Platform.

Note
  • When backing up Ansible Automation Platform, use the installation program that matches your currently installed version of Ansible Automation Platform.
  • Backup functionality only works with the PostgreSQL versions supported by your current Ansible Automation Platform version. For more information, see System requirements.
  • Backup and restore for content stored in Azure Blob Storage or Amazon S3 must be handled through their respective vendor portals, as each vendor provides their own backup solutions.

Prerequisites

  • You have logged in to the Red Hat Enterprise Linux host as your dedicated non-root user.

Procedure

  1. Go to the Red Hat Ansible Automation Platform installation directory on your Red Hat Enterprise Linux host.

  2. To control compression of the backup artifacts before they are sent to the host running the backup operation, you can use the following variables in your inventory file:

    1. For control of compression for filesystem related backup files: 

      # Global control of compression for filesystem backup files
use_archive_compression=true

# Component-level control of compression for filesystem backup files
#controller_use_archive_compression=true
#eda_use_archive_compression=true
#gateway_use_archive_compression=true
#hub_use_archive_compression=true
#pcp_use_archive_compression=true
#postgresql_use_archive_compression=true
#receptor_use_archive_compression=true
#redis_use_archive_compression=true
      Copy to Clipboard Toggle word wrap

    2. For control of compression for database related backup files: 

      # Global control of compression for database backup files
use_db_compression=true

# Component-level control of compression for database backup files
#controller_use_db_compression=true
#eda_use_db_compression=true
#hub_use_db_compression=true
#gateway_use_db_compression=true
      Copy to Clipboard Toggle word wrap

  3. Run the backup playbook: 

    $ ansible-playbook -i <path_to_inventory> ansible.containerized_installer.backup
    Copy to Clipboard Toggle word wrap

    The backup process creates archives of the following data:

    • PostgreSQL databases
    • Configuration files
    • Data files

Next steps

To customize the backup process, you can use the following variables in your inventory file:

  • Change the backup destination directory from the default ./backups by using the backup_dir variable.

  • Exclude paths that contain duplicated data, such as snapshot subdirectories, by using the hub_data_path_exclude variable. For example, to exclude a .snapshots subdirectory, specify hub_data_path_exclude=['/.snapshots/'] in your inventory file.

    • Alternatively, you can use the command-line interface with the -e flag to pass this variable at runtime: 

      $ ansible-playbook -i inventory ansible.containerized_installer.backup -e hub_data_path_exclude="['*/.snapshots/*']"
      Copy to Clipboard Toggle word wrap

2.11. Restoring containerized Ansible Automation Platform
Copiar enlace

Restore your container-based installation of Ansible Automation Platform from a backup, or to a different environment.

Note

When restoring Ansible Automation Platform, use the latest installation program available at the time of the restore. For example, if you are restoring a backup taken from version 2.5-1, use the latest 2.5-x installation program available at the time of the restore.

Restore functionality only works with the PostgreSQL versions supported by your current Ansible Automation Platform version. For more information, see System requirements.

Prerequisites

  • You have logged in to the Red Hat Enterprise Linux host as your dedicated non-root user.
  • You have a backup of your Ansible Automation Platform deployment. For more information, see Backing up container-based Ansible Automation Platform.
  • If restoring to a different environment with the same hostnames, you have performed a fresh installation on the target environment with the same topology as the original (source) environment.
  • You have ensured that the administrator credentials on the target environment match the administrator credentials from the source environment.

Procedure

  1. Go to the installation directory on your Red Hat Enterprise Linux host.

  2. Perform the relevant restoration steps:

    • If you are restoring to the same environment with the same hostnames, run the restore playbook: 

      $ ansible-playbook -i <path_to_inventory> ansible.containerized_installer.restore
      Copy to Clipboard Toggle word wrap

      This restores the important data deployed by the containerized installer such as:

      • PostgreSQL databases
      • Configuration files

      • Data files

        By default, the backup directory is set to ./backups. You can change this by using the backup_dir variable in your inventory file.

    • If you are restoring to a different environment with different hostnames, perform the following additional steps before running the restore playbook:

      Important

      Restoring to a different environment with different hostnames is not recommended and is intended only as a workaround.

      1. For each component, identify the backup file from the source environment that contains the PostgreSQL dump file.

        For example: 

        $ cd ansible-automation-platform-containerized-setup-<version_number>/backups
        Copy to Clipboard Toggle word wrap 
        $ tar tvf gateway_env1-gateway-node1.tar.gz | grep db

-rw-r--r-- ansible/ansible 4850774 2025-06-30 11:05 aap/backups/awx.db
        Copy to Clipboard Toggle word wrap
      2. Copy the backup files from the source environment to the target environment.

      3. Rename the backup files on the target environment to reflect the new node names.

        For example: 

        $ cd ansible-automation-platform-containerized-setup-<version_number>/backups
        Copy to Clipboard Toggle word wrap 
        $ mv gateway_env1-gateway-node1.tar.gz gateway_env2-gateway-node1.tar.gz
        Copy to Clipboard Toggle word wrap

      4. For enterprise topologies, ensure that the component backup file containing the component.db file is listed first in its group within the inventory file.

        For example: 

        $ cd ansible-automation-platform-containerized-setup-<version_number>
        Copy to Clipboard Toggle word wrap 
        $ ls backups/gateway*

gateway_env2-gateway-node1.tar.gz
gateway_env2-gateway-node2.tar.gz
        Copy to Clipboard Toggle word wrap 
        $ tar tvf backups/gateway_env2-gateway-node1.tar.gz | grep db

-rw-r--r-- ansible/ansible 416687 2025-06-30 11:05 aap/backups/gateway.db
        Copy to Clipboard Toggle word wrap 
        $ tar tvf backups/gateway_env2-gateway-node2.tar.gz | grep db
        Copy to Clipboard Toggle word wrap 
        $ vi inventory

[automationgateway]
env2-gateway-node1
env2-gateway-node2
        Copy to Clipboard Toggle word wrap

2.12. Uninstalling containerized Ansible Automation Platform
Copiar enlace

Uninstall your container-based installation of Ansible Automation Platform.

Prerequisites

  • You have logged in to the Red Hat Enterprise Linux host as your dedicated non-root user.

Procedure

  1. If you intend to reinstall Ansible Automation Platform and want to use the preserved databases, you must collect the existing secret keys:

    1. First, list the available secrets: 

      $ podman secret list
      Copy to Clipboard Toggle word wrap

    2. Next, collect the secret keys by running the following command: 

      $ podman secret inspect --showsecret <secret_key_variable> | jq -r .[].SecretData
      Copy to Clipboard Toggle word wrap

      For example: 

      $ podman secret inspect --showsecret controller_secret_key | jq -r .[].SecretData
      Copy to Clipboard Toggle word wrap

  2. Run the uninstall playbook: 

    $ ansible-playbook -i inventory ansible.containerized_installer.uninstall
    Copy to Clipboard Toggle word wrap

    • This stops all systemd units and containers and then deletes all resources used by the containerized installer such as:

      • configuration and data directories and files
      • systemd unit files
      • Podman containers and images
      • RPM packages

    • To keep container images, set the container_keep_images parameter to true. 

      $ ansible-playbook -i inventory ansible.containerized_installer.uninstall -e container_keep_images=true
      Copy to Clipboard Toggle word wrap

    • To keep PostgreSQL databases, set the postgresql_keep_databases parameter to true. 

      $ ansible-playbook -i inventory ansible.containerized_installer.uninstall -e postgresql_keep_databases=true
      Copy to Clipboard Toggle word wrap

2.13. Reinstalling containerized Ansible Automation Platform
Copiar enlace

To reinstall a containerized deployment after uninstalling and preserving the database, follow the steps in Installing containerized Ansible Automation Platform and include the existing secret key value in the playbook command: 

$ ansible-playbook -i inventory ansible.containerized_installer.install -e controller_secret_key=<secret_key_value>
Copy to Clipboard Toggle word wrap
Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat