Chapter 8. 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:
| Installer | Location |
|---|---|
| Bundle tar |
|
| Non-bundle tar |
|
| RPM |
|
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.
8.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
-
If there is an
[automationhub]group, you must include the variablesautomationhub_pg_hostandautomationhub_pg_port. -
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]and[automationcontroller]hosts to ensure that users can synchronize and install content from Ansible automation hub and automation controller from a different node.The FQDN must not contain either the
-or the_symbols, as it will not be processed correctly.Do not use
localhost.
Private automation hub
- Do not install private automation hub and automation controller on the same node.
- You can use the same PostgreSQL (database) instance, but they must use a different (database) name.
- If you install private automation hub from an internal address, and have a certificate which only encompasses the external address, it can result in an installation you cannot use as a container registry without certificate issues.
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.
Event-Driven Ansible controller
- Event-Driven Ansible controller must be installed on a separate server and cannot be installed on the same host as automation hub and automation controller.
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. For more information, 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 and automation hub 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 localhostansible_connection=localon 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
8.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.
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
8.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].
8.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). For more information, see Python shlex parsing rules.
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.
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.
8.5. Securing secrets in the inventory file
You can encrypt sensitive or secret variables with Ansible Vault. However, encrypting the variable names and the variable values makes it hard to find the source of the values. To circumvent this, you can encrypt the variables individually by using ansible-vault encrypt_string, or encrypt a file containing the variables.
Procedure
Create a file labeled
credentials.ymlto 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
Encrypt the
credentials.ymlfile usingansible-vault.$ ansible-vault encrypt credentials.yml New Vault password: Confirm New Vault password: Encryption successful
ImportantStore your encrypted vault password in a safe place.
Verify that the
credentials.ymlfile is encrypted.$ cat credentials.yml $ANSIBLE_VAULT;1.1; AES256363836396535623865343163333339613833363064653364656138313534353135303764646165393765393063303065323466663330646232363065316666310a373062303133376339633831303033343135343839626136323037616366326239326530623438396136396536356433656162333133653636616639313864300a353239373433313339613465326339313035633565353464356538653631633464343835346432376638623533613666326136343332313163343639393964613265616433363430633534303935646264633034383966336232303365383763
Run
setup.shfor installation of Ansible Automation Platform 2.4 and pass bothcredentials.ymland 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
8.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 Inventory file variables in the Red Hat Ansible Automation Platform Installation Guide.
