Red Hat Ansible for Network Automation
After completing this section, you should be able to:
Recognize valid locations for the Ansible configuration file.
Describe how to determine which Ansible configuration file will be used.
Customize the connection method, authentication details, privilege escalation, and performance.
Ansible settings are stored in its configuration file.
Ansible chooses which configuration file to use from several possible locations on the control node.
The Ansible installation provides the default configuration file
/etc/ansible/ansible.cfg. Settings and their default values are described in this file using comments.A sample configuration file that documents all settings with comments is also available on the web:
https://raw.githubusercontent.com/ansible/ansible/devel/examples/ansible.cfg
Note
Misspelled section headings, such as [default], are ignored.
The correct heading is [defaults].
Ansible uses the environment and the file system to determine which configuration file to use.
It searches these in this order and uses the first file it finds (it only uses one configuration file):
The one specified by the
ANSIBLE_CONFIGenvironment variable, if setThe current working directory:
./ansible.cfgA hidden file in the user's home directory:
~/.ansible.cfgThe system's default configuration file:
/etc/ansible/ansible.cfg
You do not have to do things a particular way, but these work well in many contexts.
Store a copy of the ansible.cfg file at the top level of the project.
If you are uncertain about which configuration file is being used, run this command:
[user@host ~]$ansible --versionansible 2.5.0config file = /etc/ansible/ansible.cfgconfigured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']! ansible python module location = /usr/lib/python2.7/site-packages/ansible executable location = /usr/bin/ansible python version = 2.7.5 (default, Aug 4 2017, 00:39:18) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]
The Ansible configuration file uses the familiar INI format. Comments are prefixed by either the number (#) or semicolon (;).
Settings are defined using key-value pairs that fall under one of these groups:
defaultsprivilege_escalationparamiko_connection
ssh_connection
accelerate
Selinux
The sections that contain settings most likely to be useful in terms of customization are defaults and privilege_escalation.
Key information that Ansible relies on to connect to hosts includes:
Where the inventory is that lists the managed hosts and host groups.
Which connection protocol to use to communicate with the managed hosts.
Whether the protocol uses its standard port or a non-standard one, and if not the standard one, which port to use.
Which identity to use to access managed hosts.
Whether privilege escalation is needed when using an unprivileged user to access a managed host.
Whether to prompt for an SSH password or sudo password to log in or gain privileges.
Customization of ansible.cfg establishes settings that apply when not otherwise overridden by being set elsewhere in ways that have higher precedence.
The
ansible.cfgfile establishes a reasonable set of default behaviors.The recommended practice is to create an
ansible.cfgfile in a directory from which you run Ansible commands, or where playbooks are located. When anansible.cfgfile exists in the playbook directory, it is used instead of the configuration file in the default location (/etc/ansible/ansible.cfg).
The table shown below shows commonly modified directives in ansible.cfg.
| Setting | Description |
|---|---|
inventory | The location of the Ansible inventory. |
remote_user | The remote user account used to establish connections to managed hosts. |
ask_pass | Prompt for a password to use when connecting as the remote user. |
become | Enable or disable privilege escalation for operations on managed hosts. |
become_method | The privilege escalation method to use on managed hosts. |
become_user | The user account to escalate privileges to on managed hosts. |
become_ask_pass | Defines whether privilege escalation on managed hosts should prompt for a password. |
gathering | Set to explicit to disable gathering by default. |
The following ansible.cfg configuration file defaults to always prompting for the password used to access devices.
[defaults] inventory = inventory ask_pass = True host_key_checking = False [persistent_connection] # custom timeout values to accommodate slow 1000V VM command_timeout = 180 connect_timeout = 100 connect_retry_timeout = 100
The following ansible.cfg configuration file uses a Vault password file, which must be suitably protected by file-system permissions.
[defaults] inventory = inventory ask_pass = True host_key_checking = False
By default, Ansible connects to managed hosts using SSH, and defaults to using the same user name on remote systems as the local user running Ansible commands.
To use a different identity, set the remote_user parameter to the desired user name.
If the local user running Ansible has private SSH keys configured that allow them to authenticate as the remote user on the managed hosts, Ansible automatically logs in.
If that is not the case, you can configure Ansible to prompt the local user for the password used by the remote user by setting the directive ask_pass = true.
Privilege escalation settings are configured in the [privilege_escalation] section.
To enable privilege escalation by default, set the directive become = true in the configuration file.
Other privilege escalation settings include become_method, which defaults to sudo, and become_user, which defaults to root.
If become_method requires providing a password, set become_ask_pass = true in the configuration file.
Ansible 2.5 added support for become to be used to enter enable mode (Privileged EXEC mode) on network devices that support it.
You must set the host connection type to connection: network_cli to use become for privilege escalation on network devices.
Ansible 2.5.3 supports become for privilege escalation on eos, ios, and nxos.
Connection decisions: SSH or not? If SSH, smart or not?
Ansible determines the most efficient way to use SSH to connect to managed hosts. For instance, Ansible uses SSH multiplexing if it can be used.
Ansible can be configured to use a particular SSH connection plug-in.
The special connection type local is available for running ad hoc commands and plays locally on the Ansible control node.
When a localhost entry is not listed in your inventory file, Ansible defines localhost implicitly so that ad hoc commands and playbooks target the control node.
Ansible defaults to the local connection type when using the implicit localhost definition.
The local connection type ignores the remote_user setting and runs commands directly on the local system.
If privilege escalation is used, it runs sudo from the user account that ran the Ansible command, not remote_user.
Before Ansible 2.5, network modules used local connections to run tasks on the control node that modified remote network devices.
The netconf and network_cli connection plug-ins connect to network devices. These were introduced NEW in version 2.5.
The NETWORK_CLI plug-in sends and receives network device CLI commands.
http://docs.ansible.com/ansible/2.5/plugins/connection/network_cli.html
$ansible-doc -t connection network_cli
The NETCONF plug-in provides a persistent connection using the netconf protocol.
http://docs.ansible.com/ansible/2.5/plugins/connection/netconf.html
$ansible-doc -t connection netconf
These new connection plug-ins allow network automation plays to be written in the same style as plays used with servers.
Which should I use?
The target platforms (the network devices you will be managing) must be supported by the connection method you use to manage them.
This connection plug-in provides a connection to remote devices over the SSH and implements a CLI shell. It is typically used by network devices for sending and receiving CLI commands to network devices. This connection method supports a broad variety of network devices, including the IOS and VyOS devices in the Lab Environment.
This connection plug-in provides a persistent connection to remote devices over the SSH NETCONF subsystem. It is typically used by network devices for sending and receiving RPC calls over NETCONF. This plug-in requires ncclient to be installed on the local Ansible controller. It does not currently support the network devices in the Lab Environment.
Ansible uses connection plug-ins to connect to managed hosts.
Use ansible-doc -t connection -l to see a list of available
connection plug-ins.
The important ones for network automation are network_cli and netconf.
The netconf_cli connection plug-in currently supports the widest range of platforms.
The netconf plug-in provides a connection to devices over the SSH NETCONF subsystem.
Different connection plug-ins have different performance characteristics.
How Ansible connects to hosts affects how long it takes to execute a play.
Plays typically run faster using plug-ins that support persistent connections compared to those that create and delete connections for each task.
When downloading resources such as packages, use local mirrors or caches whenever possible.
The forks parameter determines how many hosts Ansible applies a play to in parallel.
By default, Ansible sets the forks parameter conservatively to 5.
Whenever the number of hosts to which a play is being applied is smaller than the fork value, Ansible only spins up as many ansible-playbook processes as there are hosts in the target set.
The value of the serial setting is used to specify how many hosts run all the way through a play before proceeding to the next set of that many hosts.
With serial: 5, for instance, Ansible runs five hosts all the way through the play, then runs the next five hosts all the way through the play, until it runs out of hosts targeted by the play.
If you have 100 routers, and want to only work on ten at a time, use serial: 10.
The play is applied to ten hosts.
When done with the first ten, the play is applied to the next ten hosts, all the way through the play, until it runs out of targeted hosts.
By default, serial is set to 0, which runs all targeted hosts through the play in parallel.
With the forks setting, all the hosts in the play complete a task before moving to the next task in the play.
With forks: 5, for instance, Ansible talks to 5 hosts for each task at a time in parallel, and has all hosts in the play complete that task before moving to the next task in the play.
By default, forks is set to 5.
With forks: M and serial: N, Ansible talks to M hosts at a time for each task, and runs them all the way through the play in groups of N.
Upon completing the play with the first N hosts, it picks N more hosts from the target and work through the play, doing each task across M hosts at a time in parallel.
