Table of Contents
Objectives:
After completing this section, you should be able to describe where Ansible configuration files are located, how they are selected by Ansible, and edit them to apply changes to default settings.
Why the Ansible Configuration File Is Essential ?
When starting small, ad-hoc commands can quickly automate tasks. However, as your automation projects scale, customizing Ansible’s behavior becomes crucial. This is where the Ansible configuration file (ansible.cfg) comes into play. It allows you to tailor Ansible’s settings to fit the needs of your project.
Ansible Configurations:
Ansible configuration file is the brain and the heart of Ansible, the file that governs the behavior of all interactions performed by the control node. In Ansible the default configuration file is (ansible.cfg) located in /etc/ansible/ansible.cfg.
Ansible chooses its configuration file from one of several possible locations on the control node:
1. Using /etc/ansible/ansible.cfg
The ansible package provides a base configuration file located at /etc/ansible/ansible.cfg.
This file is used if no other configuration file is found.
2. Using ~/.ansible.cfg
Ansible looks for a .ansible.cfg file in the user’s home directory. This configuration is used instead of the /etc/ansible/ansible.cfg if it exists and if there is no ansible.cfg file in the current working directory.
3. Using ./ansible.cfg
If an ansible.cfg file exists in the directory in which the ansible command is executed, it is used instead of the global file or the user’s personal file. This allows administrators to create a directory structure where different environments or projects are stored in separate directories, with each directory containing a configuration file tailored with a unique set of settings.
IMPORTANT:
The recommended practice is to create an ansible.cfg file in a directory from which you run Ansible commands. This directory would also contain any files used by your Ansible project, such as an inventory and a playbook. This is the most common location used for the Ansible configuration file. It is unusual to use a ~/.ansible.cfg or /etc/ansible/ansible.cfg file in practice.
4. Using the ANSIBLE_CONFIG environment variable:
You can use different configuration files by placing them in different directories and then executing Ansible commands from the appropriate directory, but this method can be restrictive and hard to manage as the number of configuration files grows. A more flexible option is to define the location of the configuration file with the ANSIBLE_CONFIG environment variable. When this variable is defined, Ansible uses the configuration file that the variable specifies instead of any of the previously mentioned configuration files.
CONFIGURATION FILE PRECEDENCE:
Any file specified by the ANSIBLE_CONFIG environment variable overrides all other configuration files. If that variable is not set, the directory in which the ansible command was run is then checked for an ansible.cfg file. If that file is not present, the user’s home directory is checked for a .ansible.cfg file. The global /etc/ansible/ansible.cfg file is only used if no other configuration file is found. If the /etc/ansible/ansible.cfg configuration file is not present, Ansible contains defaults which it uses.
Because of the multitude of locations in which Ansible configuration files can be placed, it can be confusing which configuration file is being used by Ansible. You can run the ansible –version command to clearly identify which version of Ansible is installed, and which configuration file is being used.
Gautams-MacBook-Pro:Ansible gautamkumar$ ansible --version
ansible [core 2.16.14]
config file = /Users/gautamkumar/Devops/Ansible/ansible.cfg
Another way to display the active Ansible configuration file is to use the -v option when executing Ansible commands on the command line.
MANAGING SETTINGS IN THE CONFIGURATION FILE:
The Ansible configuration file consists of several sections, with each section containing settings defined as key-value pairs. Section titles are enclosed in square brackets. For basic operation use the following two sections:
• [defaults] sets defaults for Ansible operation
• [privilege_escalation] configures how Ansible performs privilege escalation on managed hosts.
For example, the following is a typical ansible.cfg file:
[defaults]
inventory = ./inventory
remote_user = user
ask_pass = false
[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false
The directives in this file are explained in the following table:
Ansible Configuration
| DIRECTIVE | DESCRIPTION |
| inventory | Specifies the path to the inventory file. |
| remote_user | The name of the user to log in as on the managed hosts. If not specified, the current user's name is used. |
| ask_pass | Whether or not to prompt for an SSH password. Can be false if using SSH public key authentication. |
| become | Whether to automatically switch user on the managed host (typically to root) after connecting. This can also be specified by a play. |
| become_method | How to switch user (typically sudo, which is the default, but su is an option). |
| become_user | The user to switch to on the managed host (typically root, which is the default). |
| become_ask_pass | Whether to prompt for a password for your become_method. Defaults to false. |
CONFIGURING CONNECTIONS
Ansible needs to know how to communicate with its managed hosts. One of the most common reasons to change the configuration file is to control which methods and users Ansible uses to administer managed hosts. Some of the information needed includes:
• The location of the inventory that lists the managed hosts and host groups.
• Which connection protocol to use to communicate with the managed hosts (by default, SSH), and whether or not a nonstandard network port is needed to connect to the server.
• Which remote user to use on the managed hosts, this could be root or it could be an unprivileged user unprivileged user.
• If the remote user is unprivileged, Ansible needs to know if it should try to escalate privileges to root and how to do it (for example, by using sudo).
• Whether or not to prompt for an SSH password or sudo password to log in or gain privileges.
Inventory Location
In the [defaults] section, the inventory directive can point directly to a static inventory file, or to a directory containing multiple static inventory files and dynamic inventory scripts.
[defaults]
inventory = ./inventory
Connection Settings:
By default, Ansible connects to managed hosts using the SSH protocol. The most important parameters that control how Ansible connects to the managed hosts are set in the [defaults] section.
By default, Ansible attempts to connect to the managed host using the same user name as the local user running the Ansible commands. To specify a different remote user, set the remote_user parameter to that 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.
[defaults]
inventory = ./inventory
remote_user = root
ask_pass = true
Assuming that you are using a Linux control node and OpenSSH on your managed hosts, if you can log in as the remote user with a password then you can probably set up SSH key-based authentication, which would allow you to set ask_pass = false .
Escalating Privileges:
For security and auditing reasons, Ansible might need to connect to remote hosts as an unprivileged user before escalating privileges to get administrative access as root. This can be set up in the [privilege_escalation] section of the Ansible configuration file.
To enable privilege escalation by default, set the directive become = true in the configuration file. Even if this is set by default, there are various ways to override it when running ad hoc commands or Ansible Playbooks. (For example, there might be times when you want to run a task or play that does not escalate privileges.)
The become_method directive specifies how to escalate privileges. Several options are available, but the default is to use sudo. Likewise, the become_user directive specifies which user to escalate to, but the default is root. If the become_method mechanism chosen requires the user to enter a password to escalate privileges, you can set the become_ask_pass = true directive in the configuration file.
The following example ansible.cfg file assumes that you can connect to the managed hosts as someuser using SSH key-based authentication, and that someuser can use sudo to run commands as root without entering a password:
[defaults]
inventory = ./inventory
remote_user = someuser
ask_pass = false
[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false
Non-SSH Connections:
The protocol used by Ansible to connect to managed hosts is set by default to smart, With smart, Ansible automatically chooses the best available method to connect to managed hosts and Typically, it use SSH.Fif SSH isn’t available, it falls back to paramiko (a Python SSH client).
For example, there is one exception to the rule that SSH is used by default. If you do not have localhost in your inventory, Ansible sets up an implicit localhost entry to allow you to run ad hoc commands and playbooks that target localhost. This special inventory entry is not included in the all or ungrouped host groups. In addition, instead of using the smart SSH connection type, Ansible connects to it using the special local connection type by default.
[user@controlnode ~]$ ansible localhost --list-hosts
[WARNING]: provided hosts list is empty, only localhost is available
hosts (1):
localhost
The local connection type ignores the remote_user setting and runs commands directly on the local system. If privilege escalation is being used, it runs sudo from the user account that ran the Ansible command, not remote_user.
If you want to make sure that you connect to localhost using SSH like other managed hosts, one approach is to list it in your inventory. But, this includes it in the all and ungrouped groups, which you may not want to do.
Another approach is to change the protocol used to connect to localhost. The best way to do this is to set the ansible_connection host variable for localhost. To do this, in the directory from which you run Ansible commands, create a host_vars subdirectory. In that subdirectory, create a file named localhost, containing the line ansible_connection: smart. This ensures that the smart (SSH) connection protocol is used instead of local for localhost.
You can use this the other way around as well. If you have 127.0.0.1 listed in your inventory, by default you will connect to it using smart. You can also create a host_vars/127.0.0.1 file containing the line ansible_connection: local and it will use local instead.
You can refer also Ansible public documentation https://docs.ansible.com/projects/ansible/latest/reference_appendices/config.html to know more about Ansible Configuration.
Please visit our official website https://linuxgktech.com/ansible/ to know more about Ansible.
