Setting Up Multi-Node Ansible Lab for RHCE Exam Prep Practice

Published On: 15 July 2025

Objective

Preparing for the Red Hat Certified Engineer (RHCE) exam is not just about reading the official documentation or completing online tutorials, it is about doing. In the RHCE exam (especially under RHEL 9), candidates are expected to demonstrate real-world automation skills using Ansible, Red Hat's powerful configuration management tool. And what better way to sharpen these skills than by building your own multi-node Ansible lab environment? The objective of this blog is to guide RHCE aspirants through the step-by-step process of creating a practical, hands-on Ansible lab environment using multiple virtual machines, helping them simulate real-world scenarios and master automation tasks essential for the RHCE exam. In this blog, we will walk you through setting up a practical and reusable Ansible lab, right from scratch. Whether you are just beginning your RHCE prep or refining your Ansible automation prowess, this guide will help you simulate a real-world enterprise-like environment at home.

Why a Multi-Node Lab Matters for RHCE Prep

One of the key components of the RHCE exam is your ability to manage multiple systems using Ansible. That includes pushing configurations, managing roles and playbooks and automating administrative tasks all from a control node.

A multi-node lab mimics this setup and gives you a safe, controlled environment to:

  • Write and test playbooks across different hosts
  • Practice inventory management and host grouping
  • Experiment with Ansible roles and variable precedence
  • Get hands-on with error troubleshooting and debugging

Let's learn how you can build this lab on your own hardware or virtualization software.

Prerequisites: What You Need

Few basic resources are required:

  • A physical machine (8 GB RAM minimum, 16 GB recommended)
  • Virtualization software like VirtualBox, KVM or VMware Workstation
  • RHEL 9 ISO (you can use the Red Hat Developer subscription to access it)
  • Internet access for YUM/DNF repository access

We will learn to create:

  • 1 Control Node (Ansible installed)
  • 2–3 Managed Nodes (Remote hosts Ansible will control)

Step 1: Setting Up the Virtual Machines

Purpose: Create virtual machines that will simulate a real-world environment: one control node and multiple managed nodes.

Why It Matters: RHCE expects you to automate and manage multiple systems using Ansible. You need to replicate that setup to practice effectively.

Create the following virtual machines:

a. Control Node

  • OS: RHEL 9
  • RAM: 2–4 GB
  • Disk: 20 GB
  • Network: NAT + Host-Only Adapter
  • Hostname: control.example.com

b. Managed Nodes

  • OS: RHEL 9
  • RAM: 1–2 GB per node
  • Disk: 10 GB
  • Network: Host-Only Adapter
  • Hostnames: node1.example.com, node2.example.com

During setup ensure:

  • All nodes are on the same private network.
  • You can ping from the control node to managed nodes.

Step 2: Initial Configuration

Purpose: Standardize hostnames, enable internal name resolution via /etc/hosts, and install basic tools.

Why It Matters: Proper hostname setup ensures Ansible playbooks can identify and communicate with each node. Tools like vim, net-tools, and bash-completion streamline your work during playbook writing and troubleshooting.

Once all VMs are running, perform the following on each:

Set Hostname

sudo hostnamectl set-hostname control.example.com    # Sets the system hostname for the control node

Repeat accordingly for other nodes.

Update /etc/hosts

Update the /etc/hosts file on each node with the following:

192.168.56.101 control.example.com control
192.168.56.102 node1.example.com node1
192.168.56.103 node2.example.com node2

Install Base Packages

Install essential utilities:

sudo dnf install -y vim net-tools bash-completion   # Installs basic utilities: text editor, network tools, and tab completion

Step 3: Install and Configure Ansible

Purpose: Install Ansible on the control node so it can manage the remote systems.

Why It Matters: Without Ansible, there is no automation! Confirming it is installed and working is critical before proceeding to automation tasks.

On Control Node:

sudo dnf install -y ansible  # Installs Ansible from the default RHEL repository
ansible --version            # Verifies Ansible installation and version

Ensure Ansible is properly installed and accessible.

Step 4: SSH Key-Based Authentication

Purpose: Set up password-less SSH from the control node to each managed node.

Why It Matters: Ansible uses SSH to execute commands. If SSH access is not configured, playbooks will fail. Password-less SSH is required for uninterrupted automation.

Ansible relies on SSH for communication. Set up key-based SSH access from the control node to all managed nodes.

ssh-keygen     # Generates a new SSH key pair
ssh-copy-id node1.example.com     # Copies your public key to node1 for password-less SSH
ssh-copy-id node2.example.com     # Copies your public key to node2

Test connectivity:

ssh node1.example.com  # Confirms password-less SSH access

You should connect without entering a password.

Step 5: Configure the Ansible Inventory

Purpose: Define managed hosts and group them in an inventory file.

Why It Matters: Inventory files allow you to organize hosts into logical groups like webservers, dbservers, etc., and assign common variables. This mimics real-world Ansible usage in enterprise setups.

Create a custom inventory file:

sudo mkdir /etc/ansible/labs    # Creates a new directory for custom inventory files
sudo vim /etc/ansible/labs/inventory    # Opens a new inventory file in Vim

Sample inventory:

[webservers]
node1.example.com

[dbservers]
node2.example.com

[all:vars]
ansible_user=root     # Specifies SSH user for all hosts

You can now test connectivity:

ansible -i /etc/ansible/labs/inventory all -m ping     # Sends ping module to all hosts to verify connectivity

If everything is configured correctly, you will see a "pong" from each node.

You can also follow a guided lab setup provided by the RHCSA.GURU here: RHCE Lab Setup – Remote Host Configuration. This hands-on lab walks you through configuring remote managed nodes in your Ansible lab and aligns closely with the objectives of the RHCE exam under RHEL 9. It's a great supplemental resource to validate your own setup and ensure you're aligning with industry-standard practices.

Step 6: Start Practicing with Playbooks

Purpose: Write and run your first playbook to install software (e.g., Apache) on a target group.

Why It Matters: Writing playbooks is core to the RHCE exam. Starting small helps you understand Ansible syntax, module usage, and execution flow.

Begin with simple tasks like installing a package:

---
- name: Install httpd on web servers
  hosts: webservers
  tasks:
    - name: Install Apache
      dnf:
        name: httpd
        state: present

Save it as webserver.yml and run:

ansible-playbook -i /etc/ansible/labs/inventory webserver.yml     # Executes the playbook on the target group

You can then expand to include:

  • Service management (start/enable services)
  • File management (copy, template, fetch)
  • User/group management
  • Role creation and usage

Step 7: Version Control with Git (Optional but Recommended)

Purpose: Track changes to your playbooks using Git.

Why It Matters: Using Git is a DevOps best practice. It's not required for RHCE, but highly valuable in real jobs. It also helps you avoid accidental changes and maintain a backup history.

If you are serious about your automation journey, consider using Git to version-control your playbooks and roles. This adds a professional touch and prepares you for DevOps-style workflows.

Install Git:

sudo dnf install -y git       # Installs Git for version control

Create a local Git repo and start tracking your Ansible directory.

Step 8: Backup and Snapshots

Take periodic snapshots of your VMs especially before major configuration changes. This will save time and help you avoid redoing everything from scratch if something breaks.

If you use KVM, virt-manager offers snapshot functionality. VirtualBox also allows easy snapshot creation.

Realistic Lab Enhancements

If you want to take your lab to the next level then consider:

  • Adding a third managed node for database or file server roles:
    • Purpose: To simulate more realistic enterprise environments, you can add a third managed node and assign it a specific role like hosting a database or acting as a file server. It mirrors real-world infrastructure where automation is not just about web servers, but also about backend systems like databases or shared file storage.
  • Setting up a local YUM repository:
    • Purpose: In real enterprise environments systems do not always access the internet directly. Instead, they use an internal YUM/DNF repository server. Setting up one lets you mimic such secure and restricted environments. It teaches repository management and helps in environments where there is limited or no internet access. Useful for troubleshooting package deployment failures.
  • Implementing Ansible roles and Galaxy:
    • Purpose: Roles in Ansible provide a modular and reusable way to organize tasks, variables, handlers, templates and files. Ansible Galaxy is a community repository of pre-built roles. Encourages DRY (Don't Repeat Yourself) automation practices and prepares you for complex role-based architecture often seen in production.
  • Writing custom modules or filters (Python-based):
    • Purpose: Although Ansible has hundreds of built-in modules, sometimes you will need custom logic. You can write custom Ansible modules or Jinja2 filters using Python. It helps by adding flexibility to your automation.
  • Testing Ansible Vault for secure credential handling:
    • Purpose: Ansible Vault lets you encrypt sensitive data, like passwords, API keys or SSH private keys, so they are not stored in plaintext inside your playbooks or Git repositories.

Troubleshooting Tips

Use -vvv for verbose debugging:

ansible-playbook -vvv -i inventory playbook.yml  # Adds verbosity to see what's happening

Validate YAML syntax:

yamllint playbook.yml     # Lints YAML files to catch syntax errors

Log output for future reference:

ansible-playbook -i inventory playbook.yml | tee playbook.log    # Logs all output to playbook.log file

Conclusion

Building your own multi-node Ansible lab is the best way to prepare for the RHCE exam. It gives you hands-on experience with real-world automation tasks in a safe, flexible environment. Every playbook you run and every issue you troubleshoot sharpens your skills. This setup not only boosts your exam readiness but also builds confidence for real-world sysadmin and DevOps roles. You learn by doing and this lab ensures you're doing the right things. The more you automate, the more natural it becomes. Happy automating and best of luck on your RHCE journey!