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 /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 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 variables automationhub_pg_host and automationhub_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. 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 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. 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 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). 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. 8.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 Create a file labeled credentials.yml to store the encrypted credentials. USD cat credentials.yml admin_password: my_long_admin_pw pg_password: my_long_pg_pw registry_password: my_long_registry_pw Encrypt the credentials.yml file using ansible-vault . USD ansible-vault encrypt credentials.yml New Vault password: Confirm New Vault password: Encryption successful Important Store your encrypted vault password in a safe place. Verify that the credentials.yml file is encrypted. USD cat credentials.yml USDANSIBLE_VAULT;1.1; AES256363836396535623865343163333339613833363064653364656138313534353135303764646165393765393063303065323466663330646232363065316666310a373062303133376339633831303033343135343839626136323037616366326239326530623438396136396536356433656162333133653636616639313864300a353239373433313339613465326339313035633565353464356538653631633464343835346432376638623533613666326136343332313163343639393964613265616433363430633534303935646264633034383966336232303365383763 Run setup.sh for installation of Ansible Automation Platform 2.3 and pass both credentials.yml and the --ask-vault-pass option . USD 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 .

Commands:
ansible all -i <path-to-inventory-file. --list-hosts
[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>'
[automationhub] localhost ansible_connection=local hostA hostB.example.com 172.27.0.4
[automationhub] hostA hostB hostC
[automationhub] hostA.example.com hostB.example.com hostC.example.com
[automationcontroller] host1.example.com host2.example.com host4.example.com node_state=deprovision
[instance_group_restrictedzone] host4.example.com host5.example.com [instance_group_restrictedzone:vars] node_state=deprovision
pg_database='awx' pg_username='awx' pg_password='<password>'
cat credentials.yml admin_password: my_long_admin_pw pg_password: my_long_pg_pw registry_password: my_long_registry_pw
ansible-vault encrypt credentials.yml New Vault password: Confirm New Vault password: Encryption successful
cat credentials.yml USDANSIBLE_VAULT;1.1; AES256363836396535623865343163333339613833363064653364656138313534353135303764646165393765393063303065323466663330646232363065316666310a373062303133376339633831303033343135343839626136323037616366326239326530623438396136396536356433656162333133653636616639313864300a353239373433313339613465326339313035633565353464356538653631633464343835346432376638623533613666326136343332313163343639393964613265616433363430633534303935646264633034383966336232303365383763
ANSIBLE_BECOME_METHOD='sudo' ANSIBLE_BECOME=True ANSIBLE_HOST_KEY_CHECKING=False ./setup.sh -e @credentials.yml -- --ask-vault-pass