Ansible Configuration

Introduction

In this lab, you will learn about Ansible configuration files and how to customize Ansible's behavior. Ansible uses configuration files to define various settings that control its operation. You'll explore the default configuration, create a custom configuration file, and understand how different configuration options affect Ansible's behavior. By the end of this lab, you'll have hands-on experience with configuring Ansible for different scenarios, which is crucial for tailoring Ansible to your specific needs and environment.

Skills Graph

Understanding the Default Ansible Configuration

Let's start by examining Ansible's default configuration. Ansible looks for configuration files in several locations, with each location having a different priority.

First, let's check if there's a system-wide Ansible configuration file:

cat /etc/ansible/ansible.cfg

You might see an error message if this file doesn't exist, which is normal in many environments.

Now, let's look at Ansible's default configuration values. We can do this by running:

ansible-config dump

This command will show you all the current Ansible configuration settings. It's a long list, so let's break down some important settings:

• DEFAULT_HOST_LIST: The default inventory file path.
• DEFAULT_REMOTE_USER: The default SSH user Ansible will use to connect to remote hosts.
• DEFAULT_BECOME_METHOD: The default method Ansible will use for privilege escalation (like sudo).

Don't worry if you don't understand all these settings yet. As you work more with Ansible, you'll become familiar with the ones most relevant to your needs.

Press Q to exit the output.

Now, let's create a simple inventory file to use in our next steps:

echo "localhost ansible_connection=local" > /home/labex/project/inventory

This creates a minimal inventory file with just the localhost defined.

Creating a Custom Ansible Configuration File

Now that we understand the default configuration, let's create a custom Ansible configuration file. This allows us to override default settings and tailor Ansible's behavior to our needs.

Create a new file named ansible.cfg in the /home/labex/project directory:

nano /home/labex/project/ansible.cfg

Add the following content to the file:

[defaults]
inventory = /home/labex/project/inventory
remote_user = labex
host_key_checking = False
stdout_callback = yaml

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

Let's break down these settings:

• inventory: Specifies the path to our inventory file.
• remote_user: Sets the default SSH user for connections.
• host_key_checking: Disables SSH host key checking, which can be useful in test environments (but should be enabled in production for security).
• stdout_callback: Changes the output format to YAML for better readability.
• become: Enables privilege escalation by default.
• become_method: Sets sudo as the method for privilege escalation.
• become_user: Specifies which user to become when escalating privileges.
• become_ask_pass: Disables prompting for the sudo password.

Save and exit the editor. In nano, you can do this by pressing Ctrl+X, then Y to confirm, and Enter to save.

Now, let's verify that Ansible is using our new configuration file. Run:

ansible-config dump --only-changed

DEFAULT_BECOME(/home/labex/project/ansible.cfg) = True
DEFAULT_BECOME_ASK_PASS(/home/labex/project/ansible.cfg) = False
DEFAULT_BECOME_METHOD(/home/labex/project/ansible.cfg) = sudo
DEFAULT_BECOME_USER(/home/labex/project/ansible.cfg) = root
DEFAULT_HOST_LIST(/home/labex/project/ansible.cfg) = ['/home/labex/project/inventory']
DEFAULT_REMOTE_USER(/home/labex/project/ansible.cfg) = labex
DEFAULT_STDOUT_CALLBACK(/home/labex/project/ansible.cfg) = yaml
HOST_KEY_CHECKING(/home/labex/project/ansible.cfg) = False

This command will show only the settings that differ from the default configuration. You should see the changes we made in our custom ansible.cfg file.

Testing the Custom Configuration

Now that we have our custom configuration in place, let's create a simple playbook to test it. This will help us understand how our configuration changes affect Ansible's behavior.

Create a new file named test_config.yml in the /home/labex/project directory:

nano /home/labex/project/test_config.yml

Update the content as follows:

---
- name: Test Custom Configuration
  hosts: all
  tasks:
    - name: Display remote user
      debug:
        msg: "Connected as user: {{ ansible_user }}"

    - name: Display privilege escalation info
      debug:
        msg: "Privilege escalation is {{ 'enabled' if ansible_become | default(false) else 'disabled' }}"

    - name: Show Ansible configuration
      debug:
        msg: "Inventory file: {{ lookup('config', 'DEFAULT_HOST_LIST') }}"

    - name: Check if become is enabled in ansible.cfg
      command: grep "become = True" /home/labex/project/ansible.cfg
      register: become_check
      changed_when: false
      failed_when: false

    - name: Display become setting from ansible.cfg
      debug:
        msg: "Become is {{ 'enabled' if become_check.rc == 0 else 'disabled' }} in ansible.cfg"

This updated playbook makes the following changes:

1. We've added a default value for ansible_become to prevent the undefined variable error.
2. We've added two new tasks that check the ansible.cfg file directly for the become setting, providing a more accurate representation of your configuration.

Now, let's run the updated playbook:

ansible-playbook /home/labex/project/test_config.yml

This should run without errors and provide you with information about your Ansible configuration.

Additionally, let's address the deprecation warning by updating our ansible.cfg file:

nano /home/labex/project/ansible.cfg

Add the following line under the [defaults] section:

interpreter_python = /usr/bin/python3

Your ansible.cfg file should now look something like this:

[defaults]
inventory = /home/labex/project/inventory
remote_user = labex
host_key_checking = False
stdout_callback = yaml
interpreter_python = /usr/bin/python3

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

Save and exit the editor.

Now, when you run the playbook again:

ansible-playbook /home/labex/project/test_config.yml

You should see the output without the deprecation warning, and it should correctly display your configuration settings.

Summary

In this lab, you've learned about Ansible configuration files and how to customize Ansible's behavior. Here are the key takeaways:

1. Ansible uses configuration files to control its behavior. The default configuration can be viewed using the ansible-config dump command.

2. You can create custom configuration files to override default settings. These files are typically named ansible.cfg and can be placed in different locations, with different priorities.

3. Important configuration settings include:

   • inventory: Specifies the path to the inventory file.
   • remote_user: Sets the default SSH user for connections.
   • host_key_checking: Controls SSH host key checking.
   • become and related settings: Control privilege escalation.

4. The ansible-config dump --only-changed command is useful for viewing only the settings that differ from the default configuration.

5. You can test your configuration changes by creating and running playbooks that display configuration information.

6. The --config option allows you to specify a particular configuration file when running Ansible commands, which can be useful for testing or when you need to use different configurations for different scenarios.

Understanding and being able to customize Ansible's configuration is crucial for adapting Ansible to your specific environment and requirements. As you continue working with Ansible, you'll likely find yourself adjusting these settings to optimize your automation workflows.

Practice by creating different configuration files for different scenarios. For example, you might create one configuration for testing environments where security settings are relaxed, and another for production environments with stricter security settings.

Remember, while some settings like disabling host_key_checking can be convenient for testing, they should be carefully considered in production environments where security is paramount. Always review your Ansible configuration as part of your overall system security strategy.

In future labs, you'll learn how to leverage these configuration settings in more complex scenarios, integrating them with roles, dynamic inventories, and other advanced Ansible features.