Configure ansible.cfg and Project Defaults

AnsibleBeginner
Practice Now

Introduction

Ansible looks for configuration in a predictable order. A project-level ansible.cfg is important because it makes commands repeatable no matter which shell session runs them.

In this lab, you will create a small project, write ansible.cfg, define inventory defaults, add shared variables, and run your first Ansible checks from the project directory.

Create a Minimal Project and Inventory

In this step, you will create the directories and inventory file needed for project-level Ansible configuration. This lab starts from a fresh VM, so you will build only the files needed here.

Create the project structure.

cd /home/labex/project
mkdir -p rhce-ansible/{inventory,group_vars,playbooks}

This lab keeps the project small on purpose. inventory will hold the managed host list, group_vars will hold variables that Ansible loads automatically, and playbooks is reserved for later automation files.

Enter the project directory.

cd rhce-ansible

Create an inventory with one local managed host.

cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
EOF

The host name node1 is an inventory alias, not a separate VM. The ansible_connection=local setting makes Ansible run modules on this same RHEL system while still letting you practice group targeting.

Write ansible.cfg for the Project

In this step, you will create ansible.cfg. The [defaults] section controls common behavior. Setting inventory means you do not need to type -i inventory/hosts for every command.

Before running commands in this step, return to the project directory so relative paths refer to the Ansible project.

cd /home/labex/project/rhce-ansible

Write the configuration file.

cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
remote_user = labex
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
stdout_callback = default
EOF

Each setting removes one repeated command-line choice. inventory points at the static inventory file, remote_user sets the default login user, host_key_checking = False avoids SSH host key prompts in lab environments, and interpreter_python = auto_silent lets Ansible select Python without noisy discovery warnings.

Ask Ansible which configuration file it is using.

ansible --version | sed -n '1,4p'

The output should include config file = /home/labex/project/rhce-ansible/ansible.cfg.

This is an important habit: if Ansible is reading a different configuration file, later commands may use a different inventory, callback, or connection behavior than the lab expects.

Inspect Inventory Through Project Defaults

In this step, you will test whether ansible.cfg really points Ansible at your inventory. Because the inventory path is configured, this command does not need the -i option.

Before running commands in this step, return to the project directory so relative paths refer to the Ansible project.

cd /home/labex/project/rhce-ansible

Display the inventory graph.

ansible-inventory --graph

The graph should show the managed group and the node1 host.

The graph view is useful before running commands because it shows the inventory after Ansible has parsed it. If a group or host is missing here, a playbook target will not find it either.

List host variables for node1.

ansible-inventory --host node1

You should see ansible_connection set to local.

The host view shows resolved host variables, not just the raw inventory line. Later labs use the same command to troubleshoot whether variables came from inventory, group_vars, or host_vars.

Add Shared Variables

In this step, you will add variables for all managed hosts. Files under group_vars are loaded automatically when their names match inventory groups or all.

Before running commands in this step, return to the project directory so relative paths refer to the Ansible project.

cd /home/labex/project/rhce-ansible

Create group_vars/all.yml. YAML uses key: value pairs. Keep a space after each colon.

cat > group_vars/all.yml <<'EOF'
project_owner: labex
baseline_message: Managed by the RHCE Ansible prep project
EOF

The file name all.yml has special meaning: Ansible applies it to every inventory host. Because this is YAML, indentation and the space after each colon are part of making the file valid.

Use the debug module to print one variable from the managed host.

ansible managed -m ansible.builtin.debug -a 'var=baseline_message'

The output should include the message from group_vars/all.yml.

The ad hoc command has three parts: managed is the host pattern, -m selects the module, and -a passes the module argument. A successful result proves the configured inventory and variable loading are working together.

Run a Connectivity Check

In this step, you will run the ping module. This is not ICMP ping; it is an Ansible module that checks whether Ansible can execute Python on the target host.

Before running commands in this step, return to the project directory so relative paths refer to the Ansible project.

cd /home/labex/project/rhce-ansible

Run the check against the managed group.

ansible managed -m ansible.builtin.ping

A successful result includes pong.

Ansible's ping module is a module execution test, not a network ICMP ping. It proves Ansible can reach the host, start Python, and return a module result.

Save a small proof file from an ad hoc command. The copy module writes content to a destination path.

ansible managed -m ansible.builtin.copy -a 'content=ansible_cfg_ready dest=/home/labex/project/rhce-ansible/config-check.txt mode=0644'

When this command reports changed, Ansible created or updated the file. If you run it again with the same content and mode, the result should become ok because the desired state already exists.

Summary

You created a project-level ansible.cfg, confirmed Ansible loads the configured inventory, added shared variables, and ran ad hoc module checks. Later labs will build on this repeatable project configuration.