Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Installing Red Hat Ansible Automation Platform

Red Hat Ansible Automation Platform installation involves deploying automation controller and automation hub.

Important

The Ansible Automation Platform installer allows you to deploy only one automation hub per inventory. You can use the Ansible Automation Platform installer for a standalone instance of automation hub and run the installer any number of times with any number of different inventories to deploy multiple automation hub nodes.

This installation option includes two supported scenarios:

You can use these instructions to install Red Hat Ansible Automation Platform (both automation controller and automation hub) with a database on the automation controller node, or a non-installer managed database.

3.1.1. Prerequisites
Copy link

  • You chose and obtained a platform installer
  • You are installing on a machine that meets base system requirements.

You can use the following settings when installing automation hub:

  • automationhub_importer_settings: Dictionary of settings/configuration to pass to galaxy-importer. It will end up in /etc/galaxy-importer/galaxy-importer.cfg
  • automationhub_require_content_approval: Whether or not automation hub enforces the approval mechanism before collections are made available
  • automationhub_disable_https: Whether or not automation hub should be deployed with TLS enabled
  • automationhub_disable_hsts: Whether or not automation hub should be deployed with the HTTP Strict Transport Security (HSTS) web-security policy mechanism enabled
  • automationhub_ssl_validate_certs: Whether or not automation hub should validate certificate when requesting itself (default = False) because by default, Platform deploys with self-signed certificates
  • automationhub_ssl_cert: Same as web_server_ssl_cert but for automation hub UI and API
  • automationhub_ssl_key: Same as web_server_ssl_key but for automation hub UI and API
  • automationhub_backup_collections: automation hub provides artifacts in /var/lib/pulp. By default, this is set to true so automation controller automatically backs up the artifacts by default. If a partition (e.g., LVM, NFS, CephFS, etc.) was mounted there, an enterprise organization would ensure it is always backed up. If this is the case, you can set automationhub_backup_collections = false and the backup/restore process will not have to backup/restore /var/lib/pulp.

You can use the Red Hat Ansible Automation Platform installer inventory file to specify your installation scenario.

Note
  • Using external databases: ensure the database sections of your inventory file are properly setup.
  • Add automation hub information in the [automationhub] group
  • automation hub and automation controller cannot be installed on the same node.
  • automation controller will not configure replication or failover for the database that it uses. automation controller should work with any replication you have.
  • The database server should be on the same network or in the same data center as the automation controller server for performance reasons.
  • For upgrading an existing cluster: When upgrading a cluster, you may decide that you want to also reconfigure your cluster to omit existing instances or instance groups. Omitting the instance or the instance group from the inventory file will not be enough to remove them from the cluster. In addition to omitting instances or instance groups from the inventory file, you must also deprovision instances or instance groups before starting the upgrade. Otherwise, omitted instances or instance groups will continue to communicate with the cluster, which can cause issues with tower services during the upgrade.
  • For clustered installations: If you are creating a clustered setup, you must replace localhost with the hostname or IP address of all instances. All nodes/instances must be able to reach any others using this hostname or address. In other words, you cannot use the localhost ansible_connection=local on one of the nodes AND all of the nodes should use the same format for the host names.
Important
  • Root access to remote machines is required. With Ansible, this can be achieved in different ways:
  • ansible_user=root ansible_ssh_pass=”your_password_here” inventory host or group variables
  • ansible_user=root ansible_ssh_private_key_file=”path_to_your_keyfile.pem” inventory host or group variables
  • ANSIBLE_BECOME_METHOD=’sudo’ ANSIBLE_BECOME=True ./setup.sh

For more information on become plugins, see Understanding privilege escalation.

Procedure

  1. Navigate to the installer

    1. [bundled installer] 

      $ cd ansible-automation-platform-setup-bundle-<latest-version>

    2. [online installer] 

      $ cd ansible-automation-platform-setup-<latest-version>
  2. Open the inventory file with a text editor.
  3. Edit inventory file parameters to specify your installation scenario. Follow the example below.

This example describes how you can populate the inventory file to install Red Hat Ansible Automation Platform. This installation inventory file includes both automation controller and automation hub with a database on the automation controller node or non-installer managed database.

Important
  • You cannot install automation controller and automation hub on the same node.
  • Provide a reachable IP address for the [automationhub] host to ensure users can sync content from Private Automation Hub from a different node. 
[automationcontroller]
tower.acme.org

[automationhub]
automationhub.acme.org

[all:vars]
admin_password='<password>'
pg_host='database-01.acme.org'
pg_port='5432'
pg_database='awx'
pg_username='awx'
pg_password='<password>'
pg_sslmode='prefer'  # set to 'verify-full' for client-side enforced SSL

# Automation Hub Configuration
#
automationhub_admin_password='<password>'
automationhub_pg_host='database-01.acme.org'
automationhub_pg_port='5432'
automationhub_pg_database='automationhub'
automationhub_pg_username='automationhub'
automationhub_pg_password='<password>'
automationhub_pg_sslmode='prefer'

# The default install will deploy a TLS enabled Automation Hub.
# If for some reason this is not the behavior wanted one can
# disable TLS enabled deployment.
#
# automationhub_disable_https = False
# The default install will generate self-signed certificates for the Automation
# Hub service. If you are providing valid certificate via automationhub_ssl_cert
# and automationhub_ssl_key, one should toggle that value to True.
#
# automationhub_ssl_validate_certs = False
# Isolated Tower nodes automatically generate an RSA key for authentication;
# To disable this behavior, set this value to false
# isolated_key_generation=true
# SSL-related variables
# If set, this will install a custom CA certificate to the system trust store.
# custom_ca_cert=/path/to/ca.crt
# Certificate and key to install in nginx for the web UI and API
# web_server_ssl_cert=/path/to/tower.cert
# web_server_ssl_key=/path/to/tower.key
# Certificate and key to install in Automation Hub node
# automationhub_ssl_cert=/path/to/automationhub.cert
# automationhub_ssl_key=/path/to/automationhub.key
# Server-side SSL settings for PostgreSQL (when we are installing it).
# postgres_use_ssl=False
# postgres_ssl_cert=/path/to/pgsql.crt
# postgres_ssl_key=/path/to/pgsql.key

3.1.5. Flags and extra vars
Copy link

You can pass flags and extra variables when installing automation controller.

:

Expand
Table 3.1. Flags
ArgumentDescription

-h

Show this help message and exit

-i INVENTORY_FILE

Path to Ansible inventory file (default: inventory)

-e EXTRA_VARS

Set additional Ansible variables as key=value or YAML/JSON

-b

Perform a database backup in lieu of installing

-r

Perform a database restore in lieu of installing

-k

Generate and dsitribute a SECRET_KEY

Use the -- separator to add any Ansible arguments you wish to apply. For example: ./setup.sh -i my_awesome_inventory.yml -e matburt_is_country_gold=True — -K.

Note

  • When passing -r to perform a database restore default restore path is used unless EXTRA_VARS are provided with a non-default path. See the example below that passed an EXTRA_VAR specifying the restore path: 

    ./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r

  • You can force an online installation by passing -e bundle_install=false: 

    $ ./setup.sh -e bundle_install=false
Expand
Table 3.2. Extra variables
VariableDescriptionDefault

upgrade_ansible_with_tower

When installing automation controller make sure Ansible is also up to date

False

create_preload_data

When installing Tower also create the Demo Org, project, credential, Job Template, etc.

True

bundle_install_folder

When installing from a bundle where to put the bundled repos

var/lib/tower-bundle

nginx_disable_https

Disable HTTPS traffic through nginx, this is useful if offloading HTTPS to a load balancer

False

nginx_disable_hsts

Disable HSTS web-security policy mechanism

False

nginx_http_port

Port to configure nginx to listen to for HTTP

80

nginx_https_port

Port to configure nginx to listen to for HTTPS

443

backup_dir

A temp location to use when backing up

/var/backups/tower/

restore_backup_file

Specify an alternative backup file to restore from

None

required_ram

The minimum RAM required to install Tower (should only be changed for test installation)

3750

min_open_fds

The minimum open file descriptions (should only be changed for test installations)

None

ignore_preflight_errors

Ignore preflight checks, useful when installing into a template or other non-system image (overrides required_ram and min_open_fds)

False

Examples

  • To upgrade core: 
./setup.sh -e upgrade_ansible_with_tower=1
  • To disable https handling at nginx: 
./setup.sh -e nginx_disable_https=true
  • To specify a non-default path when restoring from a backup file: 
./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r

* 

To override an inventory file used by passing it as an argument to the setup script:

You can run the setup script once you finish updating the inventory file with required parameters for installing your Private Automation Hub.

Procedure

  1. Run the setup.sh script 

    $ ./setup.sh

The installation will begin.

Once the installation completes, you can verify your automation controller has been installed successfully by logging in with the admin credentials you inserted into the inventory file.

Procedure

  1. Navigate to the IP address specified for the automation controller node in the inventory file.
  2. Log in with the Admin credentials you set in the inventory file.
Note

The automation controller server is accessible from port 80 (https://<TOWER_SERVER_NAME>/) but will redirect to port 443 so 443 needs to be available also.

Important

If the installation fails and you are a customer who has purchased a valid license for Red Hat Ansible Automation Platform, please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.

Your automation controller is now ready for initial configuration.

3.1.8. Verifying automation hub installation
Copy link

Once the installation completes, you can verify your automation hub has been installed successfully by logging in with the admin credentials you inserted into the inventory file.

Procedure

  1. Navigate to the IP address specified for the automation hub node in the inventory file.
  2. Log in with the Admin credentials you set in the inventory file.
Important

If the installation fails and you are a customer who has purchased a valid license for Red Hat Ansible Automation Platform, please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.

Your automation hub is now ready for initial configuration.

You can use these instructions to install Red Hat Ansible Automation Platform (both automation controller and automation hub) with an external managed database.

3.2.1. Prerequisites
Copy link

  • You chose and obtained a platform installer
  • You are installing on a machine that meets base system requirements.

You can use the following settings when installing automation hub:

  • automationhub_importer_settings: Dictionary of settings/configuration to pass to galaxy-importer. It will end up in /etc/galaxy-importer/galaxy-importer.cfg
  • automationhub_require_content_approval: Whether or not automation hub enforces the approval mechanism before collections are made available
  • automationhub_disable_https: Whether or not automation hub should be deployed with TLS enabled
  • automationhub_disable_hsts: Whether or not automation hub should be deployed with the HTTP Strict Transport Security (HSTS) web-security policy mechanism enabled
  • automationhub_ssl_validate_certs: Whether or not automation hub should validate certificate when requesting itself (default = False) because by default, Platform deploys with self-signed certificates
  • automationhub_ssl_cert: Same as web_server_ssl_cert but for automation hub UI and API
  • automationhub_ssl_key: Same as web_server_ssl_key but for automation hub UI and API
  • automationhub_backup_collections: automation hub provides artifacts in /var/lib/pulp. By default, this is set to true so automation controller automatically backs up the artifacts by default. If a partition (e.g., LVM, NFS, CephFS, etc.) was mounted there, an enterprise organization would ensure it is always backed up. If this is the case, you can set automationhub_backup_collections = false and the backup/restore process will not have to backup/restore /var/lib/pulp.

You can use the Red Hat Ansible Automation Platform installer inventory file to specify your installation scenario.

Note
  • Using external databases: ensure the database sections of your inventory file are properly setup.
  • Add automation hub information in the [automationhub] group
  • automation hub and automation controller cannot be installed on the same node.
  • automation controller will not configure replication or failover for the database that it uses. automation controller should work with any replication you have.
  • The database server should be on the same network or in the same data center as the automation controller server for performance reasons.
  • For upgrading an existing cluster: When upgrading a cluster, you may decide that you want to also reconfigure your cluster to omit existing instances or instance groups. Omitting the instance or the instance group from the inventory file will not be enough to remove them from the cluster. In addition to omitting instances or instance groups from the inventory file, you must also deprovision instances or instance groups before starting the upgrade. Otherwise, omitted instances or instance groups will continue to communicate with the cluster, which can cause issues with tower services during the upgrade.
  • For clustered installations: If you are creating a clustered setup, you must replace localhost with the hostname or IP address of all instances. All nodes/instances must be able to reach any others using this hostname or address. In other words, you cannot use the localhost ansible_connection=local on one of the nodes AND all of the nodes should use the same format for the host names.
Important
  • Root access to remote machines is required. With Ansible, this can be achieved in different ways:
  • ansible_user=root ansible_ssh_pass=”your_password_here” inventory host or group variables
  • ansible_user=root ansible_ssh_private_key_file=”path_to_your_keyfile.pem” inventory host or group variables
  • ANSIBLE_BECOME_METHOD=’sudo’ ANSIBLE_BECOME=True ./setup.sh

For more information on become plugins, see Understanding privilege escalation.

Procedure

  1. Navigate to the installer

    1. [bundled installer] 

      $ cd ansible-automation-platform-setup-bundle-<latest-version>

    2. [online installer] 

      $ cd ansible-automation-platform-setup-<latest-version>
  2. Open the inventory file with a text editor.
  3. Edit inventory file parameters to specify your installation scenario. Follow the example below.

This example describes how you can populate the inventory file to install Red Hat Ansible Automation Platform. This installation inventory file includes both automation controller and automation hub with an external managed database.

Important
  • You cannot install automation controller and automation hub on the same node.
  • Provide a reachable IP address for the [automationhub] host to ensure users can sync content from Private Automation Hub from a different node. 
[automationcontroller]
tower.acme.org

[automationhub]
automationhub.acme.org

[database]
database-01.acme.org

[all:vars]
admin_password='<password>'
pg_host='database-01.acme.org'
pg_port='5432'
pg_database='awx'
pg_username='awx'
pg_password='<password>'
pg_sslmode='prefer'  # set to 'verify-full' for client-side enforced SSL

# Automation Hub Configuration
#
automationhub_admin_password='<password>'
automationhub_pg_host='database-01.acme.org'
automationhub_pg_port='5432'
automationhub_pg_database='automationhub'
automationhub_pg_username='automationhub'
automationhub_pg_password='<password>'
automationhub_pg_sslmode='prefer'

# The default install will deploy a TLS enabled Automation Hub.
# If for some reason this is not the behavior wanted one can
# disable TLS enabled deployment.
#
# automationhub_disable_https = False
# The default install will generate self-signed certificates for the Automation
# Hub service. If you are providing valid certificate via automationhub_ssl_cert
# and automationhub_ssl_key, one should toggle that value to True.
#
# automationhub_ssl_validate_certs = False
# Isolated Tower nodes automatically generate an RSA key for authentication;
# To disable this behavior, set this value to false
# isolated_key_generation=true
# SSL-related variables
# If set, this will install a custom CA certificate to the system trust store.
# custom_ca_cert=/path/to/ca.crt
# Certificate and key to install in nginx for the web UI and API
# web_server_ssl_cert=/path/to/tower.cert
# web_server_ssl_key=/path/to/tower.key
# Certificate and key to install in Automation Hub node
# automationhub_ssl_cert=/path/to/automationhub.cert
# automationhub_ssl_key=/path/to/automationhub.key
# Server-side SSL settings for PostgreSQL (when we are installing it).
# postgres_use_ssl=False
# postgres_ssl_cert=/path/to/pgsql.crt
# postgres_ssl_key=/path/to/pgsql.key

3.2.5. Flags and extra vars
Copy link

You can pass flags and extra variables when installing automation controller.

:

Expand
Table 3.3. Flags
ArgumentDescription

-h

Show this help message and exit

-i INVENTORY_FILE

Path to Ansible inventory file (default: inventory)

-e EXTRA_VARS

Set additional Ansible variables as key=value or YAML/JSON

-b

Perform a database backup in lieu of installing

-r

Perform a database restore in lieu of installing

-k

Generate and dsitribute a SECRET_KEY

Use the -- separator to add any Ansible arguments you wish to apply. For example: ./setup.sh -i my_awesome_inventory.yml -e matburt_is_country_gold=True — -K.

Note

  • When passing -r to perform a database restore default restore path is used unless EXTRA_VARS are provided with a non-default path. See the example below that passed an EXTRA_VAR specifying the restore path: 

    ./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r

  • You can force an online installation by passing -e bundle_install=false: 

    $ ./setup.sh -e bundle_install=false
Expand
Table 3.4. Extra variables
VariableDescriptionDefault

upgrade_ansible_with_tower

When installing automation controller make sure Ansible is also up to date

False

create_preload_data

When installing Tower also create the Demo Org, project, credential, Job Template, etc.

True

bundle_install_folder

When installing from a bundle where to put the bundled repos

var/lib/tower-bundle

nginx_disable_https

Disable HTTPS traffic through nginx, this is useful if offloading HTTPS to a load balancer

False

nginx_disable_hsts

Disable HSTS web-security policy mechanism

False

nginx_http_port

Port to configure nginx to listen to for HTTP

80

nginx_https_port

Port to configure nginx to listen to for HTTPS

443

backup_dir

A temp location to use when backing up

/var/backups/tower/

restore_backup_file

Specify an alternative backup file to restore from

None

required_ram

The minimum RAM required to install Tower (should only be changed for test installation)

3750

min_open_fds

The minimum open file descriptions (should only be changed for test installations)

None

ignore_preflight_errors

Ignore preflight checks, useful when installing into a template or other non-system image (overrides required_ram and min_open_fds)

False

Examples

  • To upgrade core: 
./setup.sh -e upgrade_ansible_with_tower=1
  • To disable https handling at nginx: 
./setup.sh -e nginx_disable_https=true
  • To specify a non-default path when restoring from a backup file: 
./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r

* 

To override an inventory file used by passing it as an argument to the setup script:

You can run the setup script once you finish updating the inventory file with required parameters for installing your Private Automation Hub.

Procedure

  1. Run the setup.sh script 

    $ ./setup.sh

The installation will begin.

Once the installation completes, you can verify your automation controller has been installed successfully by logging in with the admin credentials you inserted into the inventory file.

Procedure

  1. Navigate to the IP address specified for the automation controller node in the inventory file.
  2. Log in with the Admin credentials you set in the inventory file.
Note

The automation controller server is accessible from port 80 (https://<TOWER_SERVER_NAME>/) but will redirect to port 443 so 443 needs to be available also.

Important

If the installation fails and you are a customer who has purchased a valid license for Red Hat Ansible Automation Platform, please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.

Your automation controller is now ready for initial configuration.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top