A not very visible topic, at least when I look at my research at Google, is the Ansible client settings. This is a bit of a shame because there are some helpful settings that I would like to share in this post. First of all, the client configuration is done in the .ansible.cfg file which is located in the user’s home directory. The configuration file uses the INI style and is organized in sections. Underneath every section are one or more parameters that could be adjusted to reflect either the personal taste or the used environment. If you are looking for a complete list of parameters that can be used within the sections, you can use the following command to create an example configuration file with all available parameters:
ansible-config init --disabled -t all > ansible.cfg
As usual, most default settings are already quite useful and you don’t have to change them. In fact, you can run Ansible without changing a single parameter and it will still do the job. But some parameters can improve the way Ansible behave. Let me start with the output that Ansible generates:
[defaults]
# Disable cows
nocows = true
# Use the YAML callback plugin.
stdout_callback = yaml
# Use the stdout_callback when running ad-hoc commands.
bin_ansible_callbacks = false
# Set verbosity
verbosity = 0
# Disable debug
debug = false
# Profiling
callbacks_enabled = timer, profile_tasks, profile_roles
Essentially, the output becomes a bit more compact, a bit more human-readable enriched with profiling information about runtime. The second part I would like to cover is the performance area:
[defaults]
# Run on 50 nodes in parallel
forks = 50
# Use faster strategy
# strategy = free
[inventory]
# Cache host facts
cache=True
# Use jsonfile as cache plugin
cache_plugin=jsonfile
[ssh_connection]
# Configure SSH optimization
ssh_args = -o ControlMaster=auto -o ControlPersist=60s
The option with the biggest potential is the strategy. Free means that Ansible will not wait for a host to finish its task before executing the next tasks on the already finished hosts. But you need to be careful using this option if the roles or playbooks use dependencies across multiple hosts.