Ansible configuration file (ansible.cfg)

Now that our ansible configuration is complete, let's learn more about ansible configuration file which we have not used till now. An Ansible configuration file uses an INI format to store its configuration data. In Ansible, you can overwrite nearly all of the configuration settings either through Ansible playbook options or environment variables.

While running an Ansible command, the command looks for its configuration file in a predefined order, as follows:

• ANSIBLE_CFG: This environment variable is used, provided it is set
• ansible.cfg: This is located in the current directory
• ~/.ansible.cfg: This is located in the user's home directory
• /etc/ansible/ansible.cfg

The default ansible configuration file is available under /etc/ansible

[ansible@controller ~]$ tree /etc/ansible/
/etc/ansible/
├── ansible.cfg
├── hosts
└── roles

In this section we will go through some of the options and parameters which are part of ansible.cfg configuration file

 

[defaults] section

Ansible's configuration file is divided into several sections. The main section that we will concentrate on is the [defaults] general section.

inventory

• This points to the path of the inventory file which contains hostname or IP address details of managed nodes.
• On most systems, it points to /etc/ansible/hosts, as follows:

inventory = /etc/ansible/hosts

 

roles_path

This contains the path of default roles directory where the Ansible playbook should look for additional roles:

roles_path = /etc/ansible/roles

 

log_path

• This defines the log files where Ansible should be storing its log.
• The log file and path must have enough permission for the user running Ansible to perform read and write operation.

An example is as follows:

log_path = /var/log/ansible.log

 

retry_files_enabled

• This is a parameter to enable the retry feature, allowing Ansible to create a .retry file whenever a playbook fails.
• It is better to keep this disabled unless you really need it.
• This is because it creates multiple files and clogs your playbook folder with old failed tasks that are already logged in both the Ansible log and the dashboard's playbook execution status section.

Here is an example of the parameter disabled:

retry_files_enabled = False

 

host_keychecking

• A host key is assigned for individual managed nodes.
• Now it is possible that the client nodes gets re-installed multiple times which can cause Ansible to throw warning at the time of initiating the connection.
• Disabling this parameter will make Ansible ignore the error messages related to the known_hosts keys:

host_key_checking = False

 

forks

• This is a parameter to define the number of parallel tasks executed to the client hosts.
• The default number is five, to save on both resources and network bandwidth.
• If there are enough resources and a large bandwidth to serve many hosts, it can be raised to the maximum number of hosts as follows:

forks = 5

 

sudo_user and ask_sudo_pass

• These are both legacy parameters.
• It is still possible to use them with the current version of Ansible, but they are not reliable.
• It is recommended to set these parameters when creating groups in Ansible's inventory

sudo_user = install
ask_sudo_pass = True

 

remote_port

• This is a parameter to indicate which port is to be used by SSH on the client hosts which by default is 22 in most cases.
• It is also a parameter that is better set in the inventory groups:

remote_port = 22

 

nocolor

• This is an optional parameter.
• It allows you to show different colors for the Ansible tasks and playbook to indicate errors and successes.
• You can set to 1 if you don't want colors, or export ANSIBLE_NOCOLOR=1

nocolor = 0

 

[ssh_connection] section

The following parameters relate to the SSH connection with the host [ssh_connection].

pipelining

• This parameter enables the feature of reducing the number of SSH operations required to execute a module.
• This happens by executing Ansible modules without an actual file transfer and can improve Ansible's performance greatly.
• It requires having require tty disabled in /etc/sudoers on all the managed hosts.

An example of its use is as follows:

pipelining = True

 

scp_if_ssh and transfer_method

• The scp_if_ssh and transfer_method parameters both of these are responsible for file transfers between the master node and the client hosts.
• Choosing the smart value allows Ansible to choose between SFTP and SCP to opt for the most suitable protocol when transferring files:

scp_if_ssh = smart
transfer_method = smart

 

[persistent_connection] section

The following two examples relate to the persistence of the SSH connection, [persistent_connection]. We are only covering timeout for a connection and a retry for a failed one. The SSH timeout can be set by editing the value of those two parameters as follows, firstly:

connect_timeout = 30

And secondly:

connect_retry_timeout = 15

 

[colors] section

Finally, let's look at the [colors] color selection. This section gets activated when enabling the color feature in the [default] section. It allows you to choose different colors for various output statuses.

[colors]
highlight = white
verbose = blue
warn = bright purple
error = red
debug = dark gray
deprecate = purple
skip = cyan
unreachable = red
ok = green
changed = yellow
diff_add = green
diff_remove = red
diff_lines = cyan

This is all about the ansible configuration file, you can learn more about different options in the configuration file at official ansible page.

 

What’s Next

Next in our Ansible Tutorial we will learn about Ansible ad-hoc commands with examples on different scenarios.