Organizing and Distributing Ansible Code Using Collections

1. The Classic Playbook

The following HTTP server examples illustrate how an Ansible playbook evolves as infrastructure requirements grow. We begin with a playbook designed specifically for Red Hat systems, then extend it to support Debian. This progression demonstrates the Ansible logic lifecycle and highlights the maintenance consequences in enterprise environments.

1.1 RedHat-only Playbook

Initially, the administrator needs to configure Apache on Linux systems running RedHat. The playbook uses two basic Ansible modules and runs in root mode.

---
- name: Install and configure Apache on RedHat systems
  hosts: webservers
  become: true
  tasks:
    - name: Install Apache
      ansible.builtin.yum:
        name: httpd
        state: present

The playbook looks straightforward. It’s easy to read and use. Full control over configuration steps is exposed to the user, who can define target servers, root operations, and other low-level technical details.

1.2 Debian-only Playbook

Another system required handling Debian packages, so this new playbook was created.

---
- name: Install and configure Apache on Debian systems
  hosts: webservers
  become: true
  tasks:
    - name: Install Apache
      ansible.builtin.apt:
        name: apache2
        state: present

Again, it’s a trivial playbook with just a change to the package manager and the Apache package name. Let’s combine both to maintain only one playbook with universal Debian/RedHat logic.

---
- name: Install Apache on RedHat and Debian systems
  hosts: webservers
  become: true
  tasks:
    - name: Install Apache on RedHat
      ansible.builtin.yum:
        name: httpd
        state: present
      when: ansible_os_family == "RedHat"

    - name: Install Apache on Debian
      ansible.builtin.apt:
        name: apache2
        state: present
      when: ansible_os_family == "Debian"

The combined version is a little more complex, harder to read, and more fragile. However, it is still a very simple example. In real life, the code will be much more complex, and exposing such code to others becomes risky.

In the next step, I’ll present how to encapsulate the code in a fundamental Ansible element — the Role. For the price of a few additional development steps, an Ansible Role provides more benefits in enterprise environments.