Inventory variable data

Inventories provide more than just system names and groupings. Data pertaining to the systems can be passed along as well. This data may include the following:

Variables are a powerful construct within Ansible and can be used in a variety of ways, not just those described here. Nearly every single thing done in Ansible can include a variable reference. While Ansible can discover data about a system during the setup phase, not all data can be discovered. Defining data with the inventory expands this. Note that variable data can come from many different sources, and one source may override another. Variable precedence order is covered later in this chapter.

Let's improve upon our existing example inventory and add to it some variable data. We will add some host-specific data, as well as group-specific data:

[web] 
mastery.example.name ansible_host=192.168.10.25 
 
[dns] 
backend.example.name 
 
[database] 
backend.example.name 
 
[frontend:children] 
web 
 
[backend:children] 
dns 
database 
 
[web:vars] 
http_port=88 
proxy_timeout=5 
 
[backend:vars] 
ansible_port=314 
 
[all:vars] 
ansible_ssh_user=otto

In this example, we defined ansible_host for mastery.example.name to be the IP address of 192.168.10.25. The ansible_host variable is a behavioral inventory variable, which is intended to alter the way Ansible behaves when operating with this host. In this case, the variable instructs Ansible to connect to the system using the IP address provided, rather than performing a DNS lookup on the name using mastery.example.name. There are a number of other behavioral inventory variables that are listed at the end of this section, along with their intended use.

Our new inventory data also provides group-level variables for the web and backend groups. The web group defines http_port, which may be used in an NGINX configuration file, and proxy_timeout, which might be used to determine HAProxy behavior. The backend group makes use of another behavioral inventory parameter to instruct Ansible to connect to the hosts in this group using port 314 for SSH, rather than the default of 22.

Finally, a construct is introduced that provides variable data across all the hosts in the inventory by utilizing a built-in all group. Variables defined within this group will apply to every host in the inventory. In this particular example, we instruct Ansible to log in as the otto user when connecting to the systems. This is also a behavioral change, as the Ansible default behavior is to log in as a user with the same name as the user executing ansible or ansible-playbook on the control host.

Here is a table of behavior inventory variables and the behaviors they intend to modify:

Inventory parameters Behavior
ansible_host This is the DNS name or or the Docker container name which Ansible will initiate a connection to.
ansible_port Specifies the port number that Ansible will use to connect to the inventory host, if not the default value of 22.
ansible_user Specifies the username that Ansible will connect to the inventory host with, regardless of the connection type.
ansible_ssh_pass Used to provide Ansible with the password for authentication to the inventory host in conjunction with ansible_user.
ansible_ssh_private_key_file Used to specify which SSH private key file will be used to connect to the inventory host, if not using the default one or ssh-agent.
ansible_ssh_common_args This defines SSH arguments to append to the default arguments for ssh, sftp, and scp.
ansible_sftp_extra_args Used to specify additional arguments that will be passed to the sftp binary when called by Ansible.
ansible_scp_extra_args Used to specify additional arguments that will be passed to the scp binary when called by Ansible.
ansible_ssh_extra_args Used to specify additional arguments that will be passed to the ssh binary when called by Ansible.
ansible_ssh_pipelining This setting uses a Boolean to define whether SSH pipelining should be used for this host.
ansible_ssh_executable This setting overrides the path to the SSH executable for this host.
ansible_become This defines whether privilege escalation (sudo or otherwise) should be used with this host.
ansible_become_method This is the method to use for privilege escalation, and can be one of sudo, su, pbrun, pfexec, doas, dzdo, or ksu.
ansible_become_user This is the user to become through privilege escalation.
ansible_become_pass This is the password to use for privilege escalation.
ansible_sudo_pass This is the sudo password to use (this is insecure; we strongly recommend using --ask-sudo-pass).
ansible_connection This is the connection type of the host. Candidates are local, smart, ssh, paramiko, docker, or winrm (more on this later in the book). The default is smart in any modern Ansible distribution (this detects whether the SSH feature ControlPersist is supported and, if so, uses ssh as the connection type, falling back to paramiko otherwise).
ansible_docker_extra_args Used to specify the extra argument that will be passed to a remote Docker daemon on a given inventory host.
ansible_shell_type Used to determine the shell type on the inventory host(s) in question. Defaults to sh-style syntax, but can be set to csh or fish to work with systems that use these shells.
ansible_shell_executable Used to determine the shell type on the inventory host(s) in question. Defaults to sh-style syntax, but can be set to csh or fish to work with systems that use these shells.
ansible_python_interpreter This is used to manually set the path to Python on a given host in the inventory. For example some distributions of Linux have more than one Python version installed, and it is important that the correct one is set. For example, a host might have both /usr/bin/python27 and /usr/bin/python3, and this is used to define which one will be used.
ansible_*_interpreter Used for any other interpreted language that Ansible might depend upon (e.g. Perl or Ruby). Replaces the interpreter binary with the one specified.