Ansible Yum Module: Manage Red Hat Packages

Modern infrastructure operations depend on automation not only for efficiency, but also for repeatability. Among the many tasks automated in daily workflows, package management is one of the most frequent. For systems based on RPM package formats such as Red Hat Enterprise Linux (RHEL), CentOS, AlmaLinux, Rocky Linux, and older versions of Fedora, Ansible provides a native module that integrates directly with the yum package manager.

While newer systems may rely on dnf under the hood, the yum module in Ansible remains fully functional due to backward compatibility. In practice, it continues to be the primary interface for managing packages on RPM-based systems through Ansible playbooks.

Let's see some of the usual package management you can do with Yum module in Ainsible.

RHCE Ansible EX294 Exam Preparation Course

Learn all the essentials of Ansible with this hands-on tutorial series. It is ideal for RHCE Ansible EX294 exam preparation.

Linux HandbookAhmed Alkabary

Installing and removing packages declaratively

The most common use of the yum module is to ensure that specific packages are present or absent on a system. Unlike imperative shell tasks that install software unconditionally, Ansible modules operate declaratively. This means administrators specify the desired end state, and Ansible ensures that the system reflects that state.

- name: Ensure Apache is installed
  ansible.builtin.yum:
    name: httpd
    state: present

This task confirms that the httpd package is installed. If it is already present, no changes are made. If it is missing, it will be installed.

Removing package, in our case the Apache package, is also straightforward:

- name: Remove Apache if no longer required
  ansible.builtin.yum:
    name: httpd
    state: absent

This is how you can install and remove a package cleanly and idempotentlyon the command line just by changing the value of the state parameter.

Working with multiple packages

Administrators frequently need to install or remove multiple packages in one task. The yum module accepts a list as the name argument:

- name: Install common utilities
  ansible.builtin.yum:
    name:
      - git
      - wget
      - curl
    state: present

This example ensures that Git, wget, and curl are all installed on the target system. The task will only trigger a change if one or more of the listed packages are not already present.

Keeping packages up to date

Another common requirement is to upgrade packages to their latest available version in the configured repository. Here's how you can do it using the yum module:

- name: Upgrade nginx to the latest version
  ansible.builtin.yum:
    name: nginx
    state: latest

This guarantees that the latest available version of nginx is installed. It is particularly useful in playbooks designed to bring systems to a known and up-to-date state before deployment.

Installing RPM files directly

In addition to repository-based installations, the yum module can also handle local RPM packages. This is useful when installing custom software or vendor packages not found in public repositories.

- name: Install a local RPM
  ansible.builtin.yum:
    name: /tmp/package-name.rpm
    state: present

If the RPM has unmet dependencies, yum will attempt to resolve them using the system’s configured repositories.

It is also possible to disable GPG signature checking when required, such as in development environments or controlled test scenarios:

- name: Install without GPG checks
  ansible.builtin.yum:
    name: /tmp/unsigned-package.rpm
    disable_gpg_check: true
    state: present

This should be used cautiously and avoided in production systems.

Repository-aware behavior

Ansible separates package management from repository configuration. If custom or third-party repositories are required, the yum_repository module should be used to define them explicitly:

- name: Add a third-party repository
  ansible.builtin.yum_repository:
    name: example
    description: Example Repository
    baseurl: https://repo.example.com/centos/$releasever/os/$basearch/
    gpgcheck: true
    gpgkey: https://repo.example.com/RPM-GPG-KEY-example
    enabled: true

This step is often necessary when deploying systems in air-gapped environments or when using hardened baselines with restricted repository access.

Coordinating with services and handlers

Package installation is often tied to service management. A typical pattern is to notify a handler that starts or restarts a service after the package has been installed or upgraded:

- name: Install Apache
  ansible.builtin.yum:
    name: httpd
    state: present
  notify: Restart Apache

handlers:
  - name: Restart Apache
    ansible.builtin.service:
      name: httpd
      state: restarted

This mechanism ensures that service restarts only occur when required, reducing unnecessary churn during routine deployments.

Platform awareness and compatibility

Although many RPM-based systems now rely on dnf internally, the yum module continues to operate correctly.

From my experience, you are bound to encounter a legacy CentOS system, often still running CentOS 7 or earlier where yum is the default and only available package manager.

For Fedora and RHEL 8+ systems, the dnf binary is usually a drop-in replacement that maintains CLI compatibility, and Ansible handles this transparently.

However, if you are seeking full consistency, the dnf module is available as an alternative, with nearly identical syntax and behavior. For most use cases, the choice between yum and dnf is a matter of policy rather than absolute technical necessity.

Wrapping Up

Whether used in simple playbooks or integrated into large-scale CI/CD pipelines, the yum module remains an essential component of system provisioning workflows. Its compatibility with RHEL and its derivatives makes it a practical choice for both legacy environments and modern deployments.

If you are already familiar with yum commands, adopting the Ansible module is a natural progression. It introduces structure without removing control, and supports fine-grained state management without requiring custom shell logic.