An inventory file is an INI-like configuration file that defines the mapping of hosts into groups.

In our example, the inventory file defines the groups eos, ios, vyos and a “group of groups” called switches. Further details about subgroups and inventory files can be found in the Ansible inventory Group documentation.

Because Ansible is a flexible tool, there are a number of ways to specify connection information and credentials. We recommend using the [my_group:vars] capability in your inventory file. Here’s what it would look like if you specified your ssh passwords (encrypted with Ansible Vault) among your variables:

If you use ssh-agent, you do not need the ansible_ssh_pass lines. If you use ssh keys, but not ssh-agent, and you have multiple keys, specify the key to use for each connection in the [group:vars] section with ansible_ssh_private_key_file=/path/to/correct/key. For more information on ansible_ssh_ options see the List of Behavioral Inventory Parameters.

Warning

Never store passwords in plain text.

The “Vault” feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See Using Vault in playbooks for more information.

ansible_connection:

Ansible uses the ansible-connection setting to determine how to connect to a remote device. When working with Ansible Networking, set this to network_cli so Ansible treats the remote node as a network device with a limited execution environment. Without this setting, Ansible would attempt to use ssh to connect to the remote and execute the Python script on the network device, which would fail because Python generally isn’t available on network devices.

ansible_network_os:

Informs Ansible which Network platform this hosts corresponds to. This is required when using network_cli or netconf.

ansible_user:

The user to connect to the remote device (switch) as. Without this the user that is running ansible-playbook would be used.
Specifies which user on the network device the connection

ansible_ssh_pass:

The corresponding password for ansible_user to log in as. If not specified SSH key will be used.

ansible_become:

If enable mode (privilege mode) should be used, see the next section.

ansible_become_method:

Which type of become should be used, for network_cli the only valid choice is enable.

Certain network platforms, such as eos and ios, have the concept of different privilege modes. Certain network modules, such as those that modify system state including users, will only work in high privilege states. Ansible version 2.5 added support for become when using connection:network_cli. This allows privileges to be raised for the specific tasks that need them. Adding become:yes and become_method:enable informs Ansible to go into privilege mode before executing the task, as shown here:

Ansible facts modules gather system information ‘facts’ that are available to the rest of your playbook.

Ansible Networking ships with a number of network-specific facts modules. In this example, we use the _facts modules eos_facts, ios_facts and vyos_facts to connect to the remote networking device. As the credentials are not explicitly passed via module arguments, Ansible uses the username and password from the inventory file.

Ansible’s “Network Fact modules” gather information from the system and store the results in facts prefixed with ansible_net_. The data collected by these modules is documented in the Return Values section of the module docs, in this case eos_facts and vyos_facts. We can use the facts, such as ansible_net_version late on in the “Display some facts” task.

To ensure we call the correct mode (*_facts) the task is conditionally run based on the group defined in the inventory file, for more information on the use of conditionals in Ansible Playbooks see The When Statement.

The eos_config and vyos_config modules have a backup: option that when set will cause the module to create a full backup of the current running-config from the remote device before any changes are made. The backup file is written to the backup folder in the playbook root directory. If the directory does not exist, it is created.

To demonstrate how we can move the backup file to a different location, we register the result and move the file to the path stored in backup_path.

Note that when using variables from tasks in this way we use double quotes (") and double curly-brackets ({{...}} to tell Ansible that this is a variable.

If you receive an connection error please double check the inventory and Playbook for typos or missing lines. If the issue still occurs follow the debug steps in Network Debug and Troubleshooting Guide.