How to Configure Ansible

When working with Ansible, the default settings aren’t always the best fit for your environment—especially in a development or test setup.

By creating and customizing a configuration file, you can fine-tune Ansible’s behavior to suit your needs, avoid repetitive command-line flags, and ensure consistency across your projects. In this post, we’ll walk through where Ansible looks for its configuration, the recommended placement for your file, and key settings to include.

Since we want to operate Ansible with some settings that deviate from the default, we need a configuration file. You can search for this file in the following locations (in order; the first one wins):

1. The content of the ANSIBLE_CONFIG environment variable
2. cfg in the current directory
3. ~/.ansible.cfg
4. /etc/ansible/ansible.cfg

According to our specifications, we recommend option 2. You should place the following first version of a configuration file in your ~/ansible/projects/start/ project directory:

[defaults]

inventory = ./inventory

interpreter_python = auto_silent

host_key_checking = False

Here, Ansible is configured using a variant of the INI format. I need to briefly mention the following non-obvious peculiarities here:

• Comments begin with a number sign (#) or a semicolon (;). You can only use a number sign at the beginning of a line, whereas you can use a semicolon anywhere.
• If a line begins with one or more white spaces, it is considered a continuation of the previous line. As a result, one space is used as a separator.

Now, let’s move on to the explanations of the actual configuration settings.

inventory

With the inventory directive, you set the path to an (as yet to be created) inventory file. The default here would have been /etc/ansible/hosts, which is unsuitable for us.

interpreter_python

With the interpreter_python directive, you can either set the path to the Python interpreter in the target hosts or choose one of four additional settings that allow you to control how Ansible looks for an appropriate Python interpreter. The auto default is fine in most cases, and the auto_silent variant does the same but spares us the constant notification messages regarding automatic interpreter detection. If you unexpectedly encounter issues with the Python version you want to use, please refer to the official documentation.

host_key_checking

By setting host_key_checking = False, you can disable the checking of SSH host keys, which you may want to do because lab or test hosts are often newly added, reprovisioned, or installed. In our test environment, we can certainly encounter events like this one:

The authenticity of host '[…]' can't be established.

ECDSA key fingerprint is 8a:a3:a5:43:c6:e4:6c:11:3a:c9:2b:97:94:23:40:c9.

Are you sure you want to continue connecting (yes/no)?

And here’s another one:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

You can safely do without host key checking; in production operation, I strongly advise against this setting (or you should only use it there if you are fully aware of the implications)!

At this point, you may be asking whether the configuration file has also been found. As long as you are in the project’s base folder, Ansible should find and use the new configuration file if you input the following:

$ ansible --version

ansible [core 2.14.16]

   config file = /home/vagrant/ansible/projects/start/ansible.cfg

   […]

However, as soon as you change your current working directory, Ansible will fall back to another (or no) configuration, which is not in your best interests. But since it is not always convenient to make every call in the base folder, you should always refer to our configuration file with the ANSIBLE_CONFIG environment variable (which is option 1 from the list at the beginning of this section).

I strongly encourage you to solve this problem with the direnv software. Of course, you could set this environment variable in your .bashrc, for example, but sooner or later, you will manage multiple Ansible projects, each with its own configuration, and then, it will become difficult again.

So, please take a short detour to Appendix A, where you will learn how to install, initialize, and use direnv in general. After that, you can return here and simply place the following .envrc file in your project folder:

export ANSIBLE_CONFIG=$(expand_path ansible.cfg)

This ensures that Ansible will always access your newly created ansible.cfg configuration file whenever you’re in the corresponding project folder or its subdirectories. The following configuration parameters are also of interest at this point:

log_path

If desired, you can instruct Ansible to log all actions with the log_path directive. The log file is freely selectable, and only the directory that will contain the log file must exist. So if, for example, the ~/logs/ directory exists, you could make the following setting:

# [defaults]

log_path = ~/logs/ansible.log

private_key_file

If the filename of your private SSH key deviates from the default, then you can specify it in the configuration to avoid constantly using --private-key on the command line:

# [defaults]

private_key_file = ~/.ssh/ansible_key

Conclusion

A well-structured Ansible configuration file can save time, reduce errors, and make your workflow far more efficient. By setting parameters like your inventory path, Python interpreter, and host key checking behavior up front, you create a reliable baseline for all your automation tasks. As your projects grow, tools like direnv can help keep each configuration isolated and easy to manage—ensuring Ansible always runs with the right settings, no matter which directory you’re in.

Editor’s note: This post has been adapted from a section of the book Ansible: The Practical Guide for Administrators and DevOps Teams by Axel Miesen. Axel is an Ansible coach. His interest in Linux systems began with his studies at the University of Kaiserslautern, where he studied mathematics and computer science. After graduating in 1998, he began working as a consultant and trainer and has passed on his Linux knowledge and experience to numerous professionals.

This post was originally published 8/2025.