Using Ansible Galaxy for Role Management

Ansible Galaxy is a public repository — a central website and command-line tool — where the Ansible community publishes roles for free. A role is a structured directory of automation content: it bundles together tasks (the individual action steps that Ansible executes, like 'install Apache'), handlers (special tasks that run only when notified, like 'restart the firewall'), variables (configurable values, such as the port number for a service), templates (files with placeholders that get filled in dynamically), and default files. Each role is designed to do one thing well, such as configuring a web server, a database server, or a monitoring agent.

Before Galaxy existed, administrators had to write all their automation in flat playbooks. A playbook is a YAML file (a human-readable data format) that lists hosts and tasks. As playbooks grew, they became hard to read and harder to reuse. If you wanted to set up a web server for three different projects, you had to copy and paste the same tasks into three separate playbooks. If you found a bug, you had to fix it in all three places. Roles solved this by packaging automation into reusable components that you can share across projects and teams.

To download a role from Galaxy, you use the command ansible-galaxy install followed by the role's name, for example: ansible-galaxy install geerlingguy.nginx. This command reaches out to the Galaxy server (galaxy.ansible.com), downloads the role, and places it into a default directory called ~/.ansible/roles (the tilde represents your home directory). You can change this directory by editing the roles_path setting in your ansible.cfg configuration file. Once the role is installed, you reference it in a playbook like this:

- hosts: webservers
  roles:
    - geerlingguy.nginx

When Ansible runs this playbook, it automatically finds the role in the roles_path, executes all the tasks inside it, and applies those configurations to the servers in the webservers group. This saves you from writing the dozens of tasks needed to install Nginx, configure virtual hosts, and set up firewalls.

Managing roles works through three main operations: listing, updating, and removing. Use ansible-galaxy list to see which roles you have installed locally and what versions they are. Use ansible-galaxy install username.rolename --force to force an update to the latest version from Galaxy. Use ansible-galaxy remove username.rolename to delete the role from your system entirely. You can also specify a role file — a YAML file that lists multiple roles and their versions — using the -r flag, so you can install an entire set of dependencies for a project with a single command. Version pinning is crucial: you can write ansible-galaxy install geerlingguy.nginx,v3.0.0 to lock a specific version, preventing unexpected changes when the upstream role updates.

Why does this exist? Because writing automation from scratch for every service is slow, error-prone, and hard to maintain. Galaxy democratises automation: a junior administrator can download and use a role written by a senior engineer at a different company. It also enforces best practices, because the most popular roles are reviewed by the community and tested across many environments. What it replaces is the practice of storing all automation logic in monolithic playbooks, which were fragile and difficult to reuse.

For the EX294 exam, you must know the exact syntax of the ansible-galaxy command, the location of installed roles, how to specify version constraints, and how to use the requirements.yml file. You do not need to write roles from scratch on the exam — you only need to manage pre-existing ones.

At a medium-sized e-commerce company, the server team manages 200 Linux servers spread across three data centres. Every new web server needs to have exactly the same configuration: the Nginx web server with specific modules, a custom firewall rule set, log rotation settings, and a monitoring agent. The senior engineer creates a role called 'company.nginx-standard' and publishes it to a private section of Ansible Galaxy (or uses a mirror like automation hub).

When a junior admin is asked to set up a new server, they do not log in and type commands manually. Instead, they open a terminal on the control node and run the following commands:

Later, when the security team requires a new firewall rule, the senior engineer updates the role, bumps the version number to 2.1.0, and publishes it. The junior admin updates their local setup by running ansible-galaxy install company.nginx-standard,v2.1.0 --force. This push-button update model eliminates configuration drift — the problem of servers slowly becoming different from each other because of manual changes.

In a larger enterprise, the team uses a requirements.yml file that lists all roles needed for the entire infrastructure. This file is stored in the Git repository alongside the playbooks. When a new team member clones the repository, they run ansible-galaxy install -r requirements.yml and instantly have every role needed. This is exactly how CI/CD pipelines (automated software testing and deployment systems) work: the pipeline runs the install command before any automation jobs.

The key outcome is speed and consistency. What used to take a human two hours of repetitive typing now takes a machine 90 seconds. The company saves money, reduces human error, and ensures every server is compliant with security policies. For the EX294 exam, you will not be asked to manage a real company's servers, but you will be asked to simulate these exact steps in the exam environment.