Search

Chapter 1. Planning your Red Hat Ansible Automation Platform installation

download PDF

Red Hat Ansible Automation Platform is supported on both Red Hat Enterprise Linux and Red Hat OpenShift. Use this guide to plan your Red Hat Ansible Automation Platform installation on Red Hat Enterprise Linux.

To install Red Hat Ansible Automation Platform on your Red Hat OpenShift Container Platform environment, see Deploying the Red Hat Ansible Automation Platform operator on OpenShift Container Platform.

1.1. Red Hat Ansible Automation Platform system requirements

Use this information when planning your Red Hat Ansible Automation Platform installations and designing automation mesh topologies that fit your use case.

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

Table 1.1. Base system
 RequiredNotes

Subscription

Valid Red Hat Ansible Automation Platform

 

OS

Red Hat Enterprise Linux 8.4 or later 64-bit (x86)

Red Hat Ansible Automation Platform is also supported on OpenShift, see Deploying the Red Hat Ansible Automation Platform operator on OpenShift Container Platform for more information.

Ansible

version 2.11 (to install)

Ansible Automation Platform includes execution environments that contain ansible-core 2.13.

Python

3.8 or later

 

The following are necessary for you to work with project updates and collections:

  • Ensure that the following domain names are part of either the firewall or the proxy’s allowlist for successful connection and download of collections from automation hub or Galaxy server:

    • galaxy.ansible.com
    • cloud.redhat.com
    • console.redhat.com
    • sso.redhat.com
  • SSL inspection must be disabled either when using self signed certificates or for the Red Hat domains.

1.1.1. Automation controller

Automation controller is a distributed system, where different software components can be co-located or deployed across multiple compute nodes. In the installer, node types of control, hybrid, execution, and hop are provided as abstractions to help the user design the topology appropriate for their use case. The following table provides recommendations for node sizing:

Note

On control and hybrid nodes, allocate a minimum of 20 GB to /var/lib/awx for execution environment storage.

Execution nodes

Required

Notes

RAM

16 GB

  • Storage volume IOPS of 1500 or more is recommended.

CPUs

4

  • Runs automation. Increase memory and CPU to increase capacity for running more forks

Control nodes

Required

Notes

RAM

16 GB

 

CPUs

4

  • Processes events and runs cluster jobs including project updates and cleanup jobs. Increasing CPU and memory can help with job event processing.

Hybrid nodes

Required

Notes

RAM

16 GB

  • Notes on RAM for execution and control nodes also apply to this node type.

CPUs

4

  • Runs both automation and cluster jobs. Notes on CPUs for execution and control nodes also apply to this node type.

Hop nodes

Required

Notes

RAM

16 GB

 

CPUs

4

  • Serves to route traffic from one part of the automation mesh to another (for example, could be a bastion host into another network). RAM could affect throughput, CPU activity is low. Network bandwidth and latency generally a more important factor than either RAM/CPU.

Disk: service node

40 GB dedicated hard disk space

  • automation controller: dedicate a minimum of 20 GB to /var/ for file and working directory storage
  • Storage volume should be rated for a minimum baseline of 1500 IOPS.
  • Projects are stored on control and hybrid, and for the duration of jobs, also on execution nodes. If the cluster has many large projects, consider having twice the GB in /var/lib/awx/projects, to avoid disk space errors.

Database node

Required

Notes

RAM

16 GB

 

CPUs

4

 

Disk

20 GB dedicated hard disk space

  • Minimum dedicated hard disk space is 20 GB
  • 150 GB+ recommended
  • Storage volume should be rated for a high baseline IOPS (1500 or more).

Browser

A currently supported version of Mozilla FireFox or Google Chrome

 

Database

PostgreSQL version 13

 

Additional resources

1.1.2. Automation hub

Automation hub enables you to discover and use new certified automation content from Red Hat Ansible and Certified Partners. On Ansible automation hub, you can discover and manage Ansible Collections, which are supported automation content developed by Red Hat and its partners for use cases such as cloud automation, network automation, and security automation.

Automation hub has the following system requirements:

 RequiredNotes

RAM

8 GB minimum

  • 8 GB RAM (minimum and recommended for Vagrant trial installations)
  • 8 GB RAM (minimum for external standalone PostgreSQL databases)
  • For capacity based on forks in your configuration, see additional resources

CPUs

2 minimum

  • For capacity based on forks in your configuration, see additional resources

Disk: service node

60 GB dedicated hard disk space

  • Storage volume should be rated for a minimum baseline of 1500 IOPS.

Database node

Required

Notes

RAM

16 GB

 

CPUs

4

 

Disk

20 GB dedicated hard disk space

  • Minimum dedicated hard disk space is 20 GB
  • 150 GB+ recommended
  • Storage volume should be rated for a high baseline IOPS (1500 or more).

Browser

A currently supported version of Mozilla FireFox or Google Chrome

 

Database

PostgreSQL version 13

 
Note
  • All automation controller data is stored in the database. Database storage increases with the number of hosts managed, number of jobs run, number of facts stored in the fact cache, and number of tasks in any individual job. For example, a playbook run every hour (24 times a day) across 250, hosts, with 20 tasks will store over 800000 events in the database every week.
  • If not enough space is reserved in the database, old job runs and facts will need cleaned on a regular basis. Refer to Management Jobs in the Automation Controller Administration Guide for more information

Amazon EC2

  • Instance size of m5.large or larger
  • An instance size of m4.xlarge or larger if there are more than 100 hosts

Additional notes for Red Hat Ansible Automation Platform requirements

  • Actual RAM requirements vary based on how many hosts automation controller will manage simultaneously (which is controlled by the forks parameter in the job template or the system ansible.cfg file). To avoid possible resource conflicts, Ansible recommends 1 GB of memory per 10 forks + 2 GB reservation for automation controller, see Automation controller Capacity Determination and Job Impact for further details. If forks is set to 400, 42 GB of memory is recommended.
  • Automation controller hosts check if umask is set to 0022. If not, the setup fails. Set umask=0022 to avoid this error.
  • A larger number of hosts can be addressed, though if the fork number is less than the total host count, more passes across the hosts are required. These RAM limitations are avoided when using rolling updates or when using the provisioning callback system built into automation controller, where each system requesting configuration enters a queue and is processed as quickly as possible; or in cases where automation controller is producing or deploying images such as AMIs. All of these are great approaches to managing larger environments.
  • For questions, contact Ansible support through the Red Hat Customer portal.
  • The requirements for systems managed by Ansible Automation Platform are the same as for Ansible. See Getting Started in the Ansible User Guide.

PostgreSQL requirements

Red Hat Ansible Automation Platform uses PostgreSQL 13.

  • PostgreSQL user passwords are hashed with SCRAM-SHA-256 secure hashing algorithm before storing in the database.
  • To determine if your automation controller instance has access to the database, you can do so with the command, awx-manage check_db.

PostgreSQL Configurations

Optionally, you can configure the PostgreSQL database as separate nodes that are not managed by the Red Hat Ansible Automation Platform installer. When the Ansible Automation Platform installer manages the database server, it configures the server with defaults that are generally recommended for most workloads. However, you can adjust these PostgreSQL settings for standalone database server node where ansible_memtotal_mb is the total memory size of the database server:

max_connections == 1024
shared_buffers == ansible_memtotal_mb*0.3
work_mem == ansible_memtotal_mb*0.03
maintenance_work_mem == ansible_memtotal_mb*0.04

Refer to the PostgreSQL documentation for more detail on tuning your PostgreSQL server.

While Red Hat Ansible Automation Platform depends on Ansible Playbooks and requires the installation of the latest stable version of Ansible before installing automation controller, manual installations of Ansible are no longer required.

Upon new installations, automation controller installs the latest release package of Ansible 2.2.

If performing a bundled Ansible Automation Platform installation, the installation program attempts to install Ansible (and its dependencies) from the bundle for you.

If you choose to install Ansible on your own, the Ansible Automation Platform installation program will detect that Ansible has been installed and will not attempt to reinstall it.

Note

You must install Ansible using a package manager such as dnf, and the latest stable version of the package manager must be installed for Red Hat Ansible Automation Platform to work properly. Ansible version 2.11 is required for versions 2.2 and later.

1.2. Network ports and protocols

Red Hat Ansible Automation Platform uses a number of ports to communicate with its services. These ports must be open and available for incoming connection to the Red Hat Ansible Automation Platform server in order for it to work. Ensure that these ports are available and are not being blocked by the server firewall.

The following architectural diagram is an example of a fully deployed Ansible Automation Platform with all possible components.

Ansible Automation Platform Architectural Diagram

The following tables provide the default Red Hat Ansible Automation Platform destination ports required for each application.

Note

The default destination ports and installer inventory listed below are configurable. If you choose to configure them to suit your environment, you may experience a change in behavior.

Table 1.2. PostgreSQL
PortProtocolServiceDirectionInstaller Inventory VariableRequired for

22

TCP

SSH

Inbound and Outbound

ansible_port

Remote access during installation

5432

TCP

Postgres

Inbound and Outbound

pg_port

Default port

ALLOW connections from controller(s) to database port

Table 1.3. Automation controller
PortProtocolServiceDirectionInstaller Inventory VariableRequired for

22

TCP

SSH

Inbound and Outbound

ansible_port

Installation

80

TCP

HTTP

Inbound

nginx_http_port

UI/API

443

TCP

HTTPS

Inbound

nginx_https_port

UI/API

5432

TCP

PostgreSQL

Inbound and Outbound

pg_port

Open only if the internal database is used along with another component. Otherwise, this port should not be open

Hybrid mode in a cluster

27199

TCP

Receptor

Inbound and Outbound

receptor_listener_port

ALLOW receptor listener port across all controllers for mandatory & automatic control plane clustering

Table 1.4. Hop Nodes
PortProtocolServiceDirectionInstaller Inventory VariableRequired for

22

TCP

SSH

Inbound and Outbound

ansible_port

Installation

27199

TCP

Receptor

Inbound and Outbound

receptor_listener_port

Mesh

ALLOW connection from controller(s) to Receptor port

Table 1.5. Execution Nodes
PortProtocolServiceDirectionInstaller Inventory VariableRequired for

22

TCP

SSH

Inbound and Outbound

ansible_port

Installation

27199

TCP

Receptor

Inbound and Outbound

receptor_listener_port

Mesh - Nodes directly peered to controllers. No hop nodes involved. 27199 is bi-directional for the execution nodes

ALLOW connections from controller(s) to Receptor port (non-hop connected nodes)

ALLOW connections from hop node(s) to Receptor port (if relayed through hop nodes)

Table 1.6. Control Nodes
PortProtocolServiceDirectionInstaller Inventory VariableRequired for

22

TCP

SSH

Inbound and Outbound

ansible_port

Installation

27199

TCP

Receptor

Inbound and Outbound

receptor_listener_port

Mesh - Nodes directly peered to controllers. Direct nodes involved. 27199 is bi-diretional for execution nodes

ENABLE connections from controller(s) to Receptor port for non-hop connected nodes

ENABLE connections from hop node(s) to Receptor port if relayed through hop nodes

443

TCP

Podman

Inbound

nginx_https_port

UI/API

Table 1.7. Hybrid Nodes
PortProtocolServiceDirectionInstaller Inventory VariableRequired for

22

TCP

SSH

Inbound and Outbound

ansible_port

Installation

27199

TCP

Receptor

Inbound and Outbound

receptor_listener_port

Mesh - Nodes directly peered to controllers. No hop nodes involved. 27199 is bi-directional for the execution nodes

ENABLE connections from controller(s) to Receptor port for non-hop connected nodes

ENABLE connections from hop node(s) to Receptor port if relayed through hop nodes

443

TCP

Podman

Inbound

nginx_https_port

UI/API

Table 1.8. Automation hub
PortProtocolServiceDirectionInstaller Inventory VariableRequired for

22

TCP

SSH

Inbound and Outbound

ansible_port

Installation

80

TCP

HTTP

Inbound

Fixed value

User interface

443

TCP

HTTPS

Inbound

Fixed value

User interface

5432

TCP

PostgreSQL

Inbound and Outbound

automationhub_pg_port

Open only if the internal database is used along with another component. Otherwise, this port should not be open

Table 1.9. Services Catalog
PortProtocolServiceDirectionInstaller Inventory VariableRequired for

22

TCP

SSH

Inbound and Outbound

ansible_port

Installation

443

TCP

HTTPS

Inbound

nginx_https_port

Access to Service Catalog user interface

5432

TCP

PostgreSQL

Inbound and Outbound

pg_port

Open only if the internal database is used. Otherwise, this port should not be open

Table 1.10. Red Hat Insights for Red Hat Ansible Automation Platform
URLRequired for

http://api.access.redhat.com:443

General account services, subscriptions

https://cert-api.access.redhat.com:443

Insights data upload

https://cert.cloud.redhat.com:443

Inventory upload and Cloud Connector connection

https://cloud.redhat.com

Access to Insights dashboard

Table 1.11. Automation Hub
URLRequired for

https://console.redhat.com:443

General account services, subscriptions

https://sso.redhat.com:443

TCP

https://automation-hub-prd.s3.amazonaws.com

 

https://galaxy.ansible.com

Ansible Community curated Ansible content

https://ansible-galaxy.s3.amazonaws.com

 

https://registry.redhat.io:443

Access to container images provided by Red Hat and partners

https://cert.cloud.redhat.com:443

Red Hat and partner curated Ansible Collections

Table 1.12. Execution Environments (EE)
URLRequired for

https://registry.redhat.io:443

Access to container images provided by Red Hat and partners

cdn.quay.io:443

Access to container images provided by Red Hat and partners

cdn01.quay.io:443

Access to container images provided by Red Hat and partners

cdn02.quay.io:443

Access to container images provided by Red Hat and partners

cdn03.quay.io:443

Access to container images provided by Red Hat and partners

Important

Image manifests and filesystem blobs are served directly from registry.redhat.io. However, from 1 May 2023, filesystem blobs are served from quay.io instead. To avoid problems pulling container images, you must enable outbound connections to the listed quay.io hostnames. Make this change to any firewall configuration that specifically enables outbound connections to registry.redhat.io. Use the hostnames instead of IP addresses when configuring firewall rules. After making this change, you can continue to pull images from registry.redhat.io. You do not need a quay.io login, or need to interact with the quay.io registry directly in any way to continue pulling Red Hat container images. For more information, see the article here.

1.3. Attaching your Red Hat Ansible Automation Platform subscription

You must have valid subscriptions attached on all nodes before installing Red Hat Ansible Automation Platform. Attaching your Ansible Automation Platform subscription allows you to access subcription-only resources necessary to proceed with the installation.

Note

Attaching a subscription is unnecessary if you have enabled Simple Content Access Mode on your Red Hat account. Once enabled, you will need to register your systems to either Red Hat Subscription Management (RHSM) or Satellite before installing the Ansible Automation Platform. See Simple Content Access Mode for more information.

Procedure

  1. Obtain the pool_id for your Red Hat Ansible Automation Platform subscription:

    # subscription-manager list --available --all | grep "Ansible Automation Platform" -B 3 -A 6

    Example

    An example output of the subsciption-manager list command. Obtain the pool_id as seen in the Pool ID: section:

    Subscription Name: Red Hat Ansible Automation, Premium (5000 Managed Nodes)
      Provides: Red Hat Ansible Engine
      Red Hat Ansible Automation Platform
      SKU: MCT3695
      Contract: ````
      Pool ID: <pool_id>
      Provides Management: No
      Available: 4999
      Suggested: 1
  2. Attach the subscription:

    # subscription-manager attach --pool=<pool_id>

You have now attached your Red Hat Ansible Automation Platform subscriptions to all nodes.

Verification

  • Verify the subscription was successfully attached:
# subscription-manager list --consumed

Troubleshooting

  • If you are unable to locate certain packages that came bundled with the Ansible Automation Platform installer, or if you are seeing a Repositories disabled by configuration message, try enabling the repository using the command:

    Red Hat Ansible Automation Platform 2.2 for RHEL 8

    subscription-manager repos --enable ansible-automation-platform-2.2-for-rhel-8-x86_64-rpms

    Red Hat Ansible Automation Platform 2.2 for RHEL 9

    subscription-manager repos --enable ansible-automation-platform-2.2-for-rhel-9-x86_64-rpms

1.4. Red Hat Ansible Automation Platform platform components

Red Hat Ansible Automation Platform consists of the following components:

Ansible automation hub

A repository for certified content of Ansible Content Collections. Ansible automation hub is the centralized repository for Red Hat and its partners to publish content, and for customers to discover certified, supported Ansible Content Collections. Red Hat Ansible Certified Content provides users with content that has been tested and is supported by Red Hat.

Private automation hub

Private automation hub provides both disconnected and on premise solution for synchronizing content. You can synchronize collections and execution environment images from Red Hat cloud automation hub, storing and serving your own custom automation collections and execution images. You can also use other sources such as Ansible Galaxy or other container registries to provide content to your private automation hub. Private automation hub can integrate into your enterprise directory and your CI/CD pipelines.

Automation controller

An enterprise framework for controlling, securing, and managing Ansible automation with a user interface (UI) and RESTful application programming interface (API).

Automation services catalog

Automation services catalog is a service within Red Hat Ansible Automation Platform. Automation services catalog enables you to organize and govern product catalog sources on Ansible automation controller across various environments.

Using automation services catalog you can:

  • Apply multi-level approval to individual platform inventories.
  • Organize content in the form of products from your platforms into portfolios.
  • Choose portfolios to share with specific groups of users.
  • Set boundaries around values driving execution of user requests.

Automation mesh

Automation mesh is an overlay network intended to ease the distribution of work across a large and dispersed collection of workers through nodes that establish peer-to-peer connections with each other using existing networks.

Automation mesh provides:

  • Dynamic cluster capacity that scales independently, allowing you to create, register, group, ungroup and deregister nodes with minimal downtime.
  • Control and execution plane separation that enables you to scale playbook execution capacity independently from control plane capacity.
  • Deployment choices that are resilient to latency, reconfigurable without outage, and that dynamically re-reroute to choose a different path when outages exist.
  • Mesh routing changes.
  • Connectivity that includes bi-directional, multi-hopped mesh communication possibilities which are Federal Information Processing Standards (FIPS) compliant.

Automation execution environments

A solution that includes the Ansible execution engine and hundreds of modules that help users automate all aspects of IT environments and processes. Execution environments automate commonly used operating systems, infrastructure platforms, network devices, and clouds.

Ansible Galaxy

A hub for finding, reusing, and sharing Ansible content. Community-provided Galaxy content, in the form of prepackaged roles, can help start automation projects. Roles for provisioning infrastructure, deploying applications, and completing other tasks can be dropped into Ansible Playbooks and be applied immediately to customer environments.

Automation content navigator

A textual user interface (TUI) that becomes the primary command line interface into the automation platform, covering use cases from content building, running automation locally in an execution environment, running automation in Ansible Automation Platform, and providing the foundation for future integrated development environments (IDEs).

1.5. Choosing and obtaining a Red Hat Ansible Automation Platform installer

Choose the Red Hat Ansible Automation Platform installer you need based on your Red Hat Enterprise Linux environment internet connectivity. Review the following scenarios and determine which Red Hat Ansible Automation Platform installer meets your needs.

Note

A valid Red Hat customer account is required to access Red Hat Ansible Automation Platform installer downloads on the Red Hat Customer Portal.

Installing with internet access

Choose the Red Hat Ansible Automation Platform installer if your Red Hat Enterprise Linux environment is connected to the internet. Installing with internet access retrieves the latest required repositories, packages, and dependencies. Choose one of the following ways to set up your Ansible Automation Platform installer.

Tarball install

  1. Navigate to https://access.redhat.com/downloads/content/480
  2. Click Download Now for the Ansible Automation Platform <latest-version> Setup.
  3. Extract the files:

    $ tar xvzf ansible-automation-platform-setup-<latest-version>.tar.gz

RPM install

  1. Install the Ansible Automation Platform Installer Package

    v.2.2 for RHEL 8 for x86_64

    $ sudo dnf install --enablerepo=ansible-automation-platform-2.2-for-rhel-8-x86_64-rpms ansible-automation-platform-installer

    v.2.2 for RHEL 9 for x86-64

    $ sudo dnf install --enablerepo=ansible-automation-platform-2.2-for-rhel-9-x86_64-rpms ansible-automation-platform-installer
Note

dnf install enables the repo as the repo is disabled by default.

When you use the RPM installer, the files are placed under the /opt/ansible-automation-platform/installer directory.

Installing without internet access

Use the Red Hat Ansible Automation Platform Bundle installer if you are unable to access the internet, or would prefer not to install separate components and dependencies from online repositories. Access to Red Hat Enterprise Linux repositories is still needed. All other dependencies are included in the tar archive.

  1. Navigate to https://access.redhat.com/downloads/content/480
  2. Click Download Now for the Ansible Automation Platform <latest-version> Setup Bundle.
  3. Extract the files:

    $ tar xvzf ansible-automation-platform-setup-bundle-<latest-version>.tar.gz

1.6. About the installer inventory file

Red Hat Ansible Automation Platform works against a list of managed nodes or hosts in your infrastructure that are logically organized, using an inventory file. You can use the Red Hat Ansible Automation Platform installer inventory file to specify your installation scenario and describe host deployments to Ansible. By using an inventory file, Ansible can manage a large number of hosts with a single command. Inventories also help you use Ansible more efficiently by reducing the number of command line options you have to specify.

The inventory file can be in one of many formats, depending on the inventory plugins that you have. The most common formats are INI and YAML. Inventory files listed in this document are shown in INI format.

The location of the inventory file depends on the installer you used. The following table shows possible locations:

InstallerLocation

Bundle tar

/ansible-automation-platform-setup-bundle-<latest-version>

Non-bundle tar

/ansible-automation-platform-setup-<latest-version>

RPM

/opt/ansible-automation-platform/installer

You can verify the hosts in your inventory using the command:

ansible all -i <path-to-inventory-file. --list-hosts

Example inventory file

[automationcontroller]
host1.example.com
host2.example.com
Host4.example.com

[automationhub]
host3.example.com

[database]
Host5.example.com

[all:vars]
admin_password='<password>'

pg_host=''
pg_port=''

pg_database='awx'
pg_username='awx'
pg_password='<password>'

registry_url='registry.redhat.io'
registry_username='<registry username>'
registry_password='<registry password>'

The first part of the inventory file specifies the hosts or groups that Ansible can work with.

1.6.1. Guidelines for hosts and groups

Databases

  • When using an external database, ensure the [database] sections of your inventory file are properly set up.
  • To improve performance, do not colocate the database and the automation controller on the same server.

automation hub

  • Add Ansible automation hub information in the [automationhub] group.
  • Do not install Ansible automation hub and automation controller on the same node.
  • Provide a reachable IP address or fully qualified domain name (FQDN) for the [automationhub] host to ensure that users can synchronize and install content from Ansible automation hub from a different node. Do not use localhost.
Important

You must separate the installation of automation controller and Ansible automation hub because the [database] group does not distinguish between the two if both are installed at the same time.

If you use one value in [database] and both automation controller and Ansible automation hub define it, they would use the same database.

automation controller

  • Automation controller does not configure replication or failover for the database that it uses. automation controller works with any replication that you have.

Clustered installations

  • When upgrading an existing cluster, you can also reconfigure your cluster to omit existing instances or instance groups. Omitting the instance or the instance group from the inventory file is not 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. See Deprovisioning nodes or groups. Otherwise, omitted instances or instance groups continue to communicate with the cluster, which can cause issues with automation controller services during the upgrade.
  • If you are creating a clustered installation setup, you must replace [localhost] with the hostname or IP address of all instances. Installers for automation controller, automation hub, and automation services catalog do not accept [localhost] All nodes and instances must be able to reach any others by using this hostname or address. You cannot use the localhost ansible_connection=local on one of the nodes. Use the same format for the host names of all the nodes.

    Therefore, this does not work:

    [automationhub]
    localhost ansible_connection=local
    hostA
    hostB.example.com
    172.27.0.4

    Instead, use these formats:

    [automationhub]
    hostA
    hostB
    hostC

    or

    [automationhub]
    hostA.example.com
    hostB.example.com
    hostC.example.com

1.6.2. Deprovisioning nodes or groups

You can deprovision nodes and instance groups using the Ansible Automation Platform installer. Running the installer will remove all configuration files and logs attached to the nodes in the group.

Note

You can deprovision any hosts in your inventory except for the first host specified in the [automationcontroller] group.

To deprovision nodes, append node_state=deprovision to the node or group within the inventory file.

For example:

To remove a single node from a deployment:

[automationcontroller]
host1.example.com
host2.example.com
host4.example.com   node_state=deprovision

or

To remove an entire instance group from a deployment:

[instance_group_restrictedzone]
host4.example.com
host5.example.com

[instance_group_restrictedzone:vars]
node_state=deprovision

1.6.3. Inventory variables

The second part of the example inventory file, following [all:vars], is a list of variables used by the installer. Using all means the variables apply to all hosts.

To apply variables to a particular host, use [hostname:vars]. For example, [automationhub:vars].

1.6.4. Rules for declaring variables in inventory files

The values of string variables are declared in quotes. For example:

pg_database='awx'
pg_username='awx'
pg_password='<password>'

When declared in a :vars section, INI values are interpreted as strings. For example, var=FALSE creates a string equal to FALSE. Unlike host lines, :vars sections accept only a single entry per line, so everything after the = must be the value for the entry. Host lines accept multiple key=value parameters per line. Therefore they need a way to indicate that a space is part of a value rather than a separator. Values that contain whitespace can be quoted (single or double). See the Python shlex parsing rules for details.

If a variable value set in an INI inventory must be a certain type (for example, a string or a boolean value), always specify the type with a filter in your task. Do not rely on types set in INI inventories when consuming variables.

Note

Consider using YAML format for inventory sources to avoid confusion on the actual type of a variable. The YAML inventory plugin processes variable values consistently and correctly.

If a parameter value in the Ansible inventory file contains special characters, such as #, { or }, you must double-escape the value (that is enclose the value in both single and double quotation marks).

For example, to use mypasswordwith#hashsigns as a value for the variable pg_password, declare it as pg_password='"mypasswordwith#hashsigns"' in the Ansible host inventory file.

1.6.5. Securing secrets in the inventory file

You can encrypt sensitive or secret variables with Ansible Vault. However, encrypting the variable names as well as the variable values makes it hard to find the source of the values. To circumvent this, you can encrypt the variables individually using ansible-vault encrypt_string, or encrypt a file containing the variables.

Procedure

  1. Create a file labeled credentials.yml to store the encrypted credentials.

    $ cat credentials.yml
    
    admin_password: my_long_admin_pw
    pg_password: my_long_pg_pw
    registry_password: my_long_registry_pw
  2. Encrypt the credentials.yml file using ansible-vault.

    $ ansible-vault encrypt credentials.yml
    New Vault password:
    Confirm New Vault password:
    Encryption successful
    Important

    Store your encrypted vault password in a safe place.

  3. Verify that the credentials.yml file is encrypted.

    $ cat credentials.yml
    $ANSIBLE_VAULT;1.1;
    AES256363836396535623865343163333339613833363064653364656138313534353135303764646165393765393063303065323466663330646232363065316666310a373062303133376339633831303033343135343839626136323037616366326239326530623438396136396536356433656162333133653636616639313864300a353239373433313339613465326339313035633565353464356538653631633464343835346432376638623533613666326136343332313163343639393964613265616433363430633534303935646264633034383966336232303365383763
  4. Run setup.sh for installation of Ansible Automation Platform 2.2 and pass both credentials.yml and the --ask-vault-pass option.

    $ ANSIBLE_BECOME_METHOD='sudo' ANSIBLE_BECOME=True ANSIBLE_HOST_KEY_CHECKING=False ./setup.sh -e @credentials.yml -- --ask-vault-pass

1.6.6. Additional inventory file variables

You can further configure your Red Hat Ansible Automation Platform installation by including additional variables in the inventory file. These configurations add optional features for managing your Red Hat Ansible Automation Platform. Add these variables by editing the inventory file using a text editor.

A table of predefined values for inventory file variables can be found in Appendix A: Inventory File Variables

1.7. Supported installation scenarios

Red Hat supports the following installations scenarios for Red Hat Ansible Automation Platform

1.7.1. Standalone automation controller with a database on the same node, or a non-installer managed database

This scenario includes installation of automation controller, including the web frontend, REST API backend, and database on a single machine. It installs PostgreSQL, and configures the automation controller to use that as its database. This is considered the standard automation controller installation scenario.

See Installing automation controller with a database on the same node in Installing Red Hat Ansible Automation Platform components on a single machine to get started.

1.7.2. Standalone automation controller with an external managed database

This scenario includes installation of the automation controller server on a single machine and configures communication with a remote PostgreSQL instance as its database. This remote PostgreSQL can be a server you manage, or can be provided by a cloud service such as Amazon RDS.

See Installing automation controller with an external managed database in Installing Red Hat Ansible Automation Platform components on a single machine to get started.

1.7.3. Standalone automation hub with a database on the same node, or a non-installer managed database

This scenario includes installation of automation hub, including the web frontend, REST API backend, and database on a single machine. It installs PostgreSQL, and configures the automation hub to use that as its database.

See Installing automation hub with a database on the same node in Installing Red Hat Ansible Automation Platform components on a single machine to get started.

1.7.4. Standalone automation hub with an external managed database

This scenario includes installation of the automation hub server on a single machine, and installs a remote PostgreSQL database, managed by the Red Hat Ansible Automation Platform installer.

See Installing automation hub with an external database in Installing Red Hat Ansible Automation Platform components on a single machine to get started.

1.7.5. Platform installation with a database on the automation controller node, or non-installer managed database

This scenario includes installation of automation controller and automation hub with a database on the automation controller node, or a non-installer managed database.

See Installing Red Hat Ansible Automation Platform with a database on the automation controller node or non-installer managed database in Installing Red Hat Ansible Automation Platform to get started.

1.7.6. Platform installation with an external managed database

This scenario includes installation of automation controller and automation hub and configures communication with a remote PostgreSQL instance as its database. This remote PostgreSQL can be a server you manage, or can be provided by a cloud service such as Amazon RDS.

See Installing Red Hat Ansible Automation Platform with an external managed database in Installing Red Hat Ansible Automation Platform to get started.

1.7.7. Multi-machine cluster installation with an external managed database

This scenario includes installation of multiple automation controller nodes and an automation hub instance and configures communication with a remote PostgreSQL instance as its database. This remote PostgreSQL can be a server you manage, or can be provided by a cloud service such as Amazon RDS. In this scenario, all automation controller are active and can execute jobs, and any node can receive HTTP requests.

Note
  • Running in a cluster setup requires any database that automation controller uses to be external—​PostgreSQL must be installed on a machine that is not one of the primary or secondary tower nodes. When in a redundant setup, the remote PostgreSQL version requirements is PostgreSQL 13.

    • See Clustering for more information on configuring a clustered setup.
  • Provide a reachable IP address for the [automationhub] host to ensure users can sync content from Private Automation Hub from a different node.

See Installing a multi-node Red Hat Ansible Automation Platform with an external managed database in Multi-machine cluster installation to get started.

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.

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.

© 2024 Red Hat, Inc.