DevOps Automation Reusability

DevOps Automation Reusability

2025, Jun 26    
Share

Ansible collections explained: Why reusability is important in automation

If you aren’t familiar with or haven’t been using Ansible collections as much, this is a brief explanation of what an collection is.

Ansible collections are designed to help organise and reuse automation content more efficiently, especially in large enterprise environments.

They help you create more modular reusable content, making it easier to share across projects or teams. Collections also simplify installation, are versioned independently, enabling isolated updates, and track compatibility and dependencies.

You probably already use some of the Ansible collections available in the Automation Hub provided by Red Hat or partners, which offers a collection of certified, supported, and security-tested content. Alternatively, a custom collection that you create yourself will be specific to your organisation’s needs, tools, and processes, giving you full lifecycle control over it.

To install a collection or create your own, you need to use ansible-galaxy, which comes with the installation of Ansible.

Ansible Collections

As exmplained before Collections are a way to package and distribute reusable Ansible content, such as roles, modules, plugins, and documentation. You can also create your collection, which can include playbooks, roles, modules, templates, variables, and plugins.

ansible-galaxy collection init my_namespace.my_collection

Your folder structure will look like this

my_collection/
├── README.md
├── galaxy.yml
├── plugins/
│   ├── module_utils/
│   └── modules/
            ├── roles/
│   └── my_role/
│       ├── tasks/
│       │   └── main.yml
│       └── README.md
└── docs/

Ansible Roles

Organize your playbooks and tasks into reusable components called roles. Learn how to structure and use roles across multiple playbooks.

A role in Ansible is a way to organize tasks, variables, files, and templates for reuse across playbooks. It encapsulates specific functionality or configurations, making your automation code modular and easier to manage.

Ansible Modules

Modules are small units of code that Ansible uses to perform tasks on managed hosts.

Get familiar with Ansible modules, which are reusable units of code for executing tasks on managed nodes. Explore the wide range of built-in modules for operations like file manipulation, package management, and service management.

Using Ansible Inventories

Execute your playbooks against the inventory of hosts using the ansible-playbook command.

Understand options like limiting the hosts, specifying the inventory file, and verbose output.

To execute an Ansible playbook with specific options, use the ansible-playbook command. Here’s an example:

ansible-playbook myplaybook.yml -i inventory.yaml --limit webservers --verbose
  • myplaybook.yml: The playbook file to run.
  • -i inventory.yaml: Specifies the inventory file.
  • –limit webservers: Limits execution to hosts in the webservers group.
  • –verbose: Provides detailed output during execution.

Ansible Handlers

Learn about handlers, and tasks triggered by other tasks when changes occur.

Understand how to define and use handlers to restart services or perform other actions only when necessary.

Let’s say for example you need to run an Ansible playbook to change the apache.conf on your Apache server then you want to guarantee that the server gets restarted. Your handler can be implemented to restart Apache every time that configuration is modified.

In your role directory structure, you might have:

roles/
└── webserver/
    ├── tasks/
    │   └── main.yml
    └── handlers/
        └── main.yml

You might have a task to manage the Apache configuration file:

---
- name: Ensure Apache configuration file is present
  template:
    src: apache.conf.j2
    dest: /etc/apache2/apache.conf
  notify: Restart Apache

You implement the handler like this:

---
- name: Restart Apache
  service:
    name: apache2
    state: restarted

Ansible Galaxy

Ansible Galaxy is a community platform for sharing and downloading Ansible content, including roles and collections. It allows users to find pre-built automation components to speed up their playbook development, promoting reuse and collaboration across projects.

Collections function like plugins you can install in Ansible, enabling the use of native modules to execute tasks directly, rather than relying on shell command wrappers.

Using an Ansible collection instead of wrapping commands in shell tasks provides better maintainability, readability, and idempotence. Collections offer reusable modules tailored for specific tasks, reducing the risk of errors and ensuring consistent execution, while shell commands are harder to debug and may not be idempotent.

You can find asible community colleciton in here

You also can create your own following this steps here

You can verify the installation by running:

ansible-galaxy collection list

For example if you want to install kubernetes core collection, use the following command:

ansible-galaxy collection install community.kubernetes

Explanation:

  • community.kubernetes is the namespace and collection name for k8s.core.

  • This command downloads and installs the collection to your local Ansible environment, making its modules and plugins available for use in your playbooks.

Tutorial

Installing Collections Examples

For example, if you want to automate tasks related to Kubernetes, you can install the kubernetes.core collection as follows:

ansible-galaxy collection install kubernetes.core:<specific_version>

If you need to automate tasks on an IBM mainframe, you can use this collection:

ansible-galaxy collection install ibm.zos

Creating Your Own Collection

Now, let’s create our collection and understand the folder structure within:

ansible-galaxy collection init pamenon_org.gitops

Folder structure:

pamenon_org-gitops/
├── plugins/
├── roles/
├── playbooks/
├── galaxy.yml
└── README.md

  • Namespace (pamenon_org): This is like your organisation or user name. It groups collections logically and avoids name clashes with others. Think of it as your “brand” or “owner” of the collection.

  • Collection Name (gitops): The specific collection’s name within your namespace. It describes what the collection does — here, automation related to GitOps.

Directory Structure inside pamenon_org-gitops/

plugins/: Contains custom Ansible plugins like modules, filters, callbacks, or connection plugins you write and include in the collection.

roles/: Contains Ansible roles, which are reusable, modular sets of tasks for specific automation purposes (e.g., deploying apps, configuring servers).

playbooks/: An optional folder to include example or helper playbooks that use your roles or plugins.

galaxy.yml: Metadata file describing your collection (name, version, dependencies, author, etc.) — used when publishing or installing the collection.

README.md: Documentation file to explain what your collection does, how to use it, etc.

Creating Roles in Your Collection

Roles contain modular sets with their own tasks, variables, and templates.

Create two roles for the gitops collection like this:

cd pamenon_org.gitops
ansible-galaxy role init roles/argocd
ansible-galaxy role init roles/openshift_infra

Folder structure example:

roles/
├── argocd/
│   ├── defaults/
│   │   └── main.yml
│   ├── files/
│   ├── handlers/
│   │   └── main.yml
│   ├── meta/
│   │   └── main.yml
│   ├── tasks/
│   │   └── main.yml
│   ├── templates/
│   ├── tests/
│   │   ├── inventory
│   │   └── test.yml
│   └── vars/
│       └── main.yml
└── openshift_infra/
    ├── defaults/
    │   └── main.yml
    ├── files/
    ├── handlers/
    │   └── main.yml
    ├── meta/
    │   └── main.yml
    ├── tasks/
    │   └── main.yml
    ├── templates/
    ├── tests/
    │   ├── inventory
    │   └── test.yml
    └── vars/
        └── main.yml

Creating a Shared Security Role

You can create another role that will be shared between the other two roles for access and authorization called security.

ansible-galaxy role init roles/security

Role Design Plan

🔐 security role

Handles authentication and access setup.

Responsibilities:

  • oc login (auth to OpenShift)

  • Set up SSH keys for Git repo access

  • Export kubeconfig or credentials

  • Create any common secrets/certs used by other roles

🚀 argocd role

Depends on security for login and access.

Responsibilities:

  • Install Argo CD (e.g., with oc apply, Helm, or Operator)

  • Configure Argo CD CLI or custom resources

  • Set up Git repo access (private key, repo URL)

  • Sync applications if needed

🏗️ openshift_infra role

Also depends on security.

Responsibilities:

  • Create service accounts

  • Set network policies

  • Install internal certificates

  • Create secrets for apps or services

✅ Conclusion

Ansible Collections are a powerful way to structure, share, and scale your automation efforts. By embracing collections, you gain better modularity, version control, and reusability—essential for managing complex, enterprise-scale environments. Whether you’re using certified content from Ansible Galaxy or building custom collections tailored to your needs, this approach helps streamline collaboration, improve maintainability, and ensure consistent automation practices.

I hope you found this guide helpful—thanks for reading, and see you next time! 👋

This page was last update at 2025-07-22 16:00

# ansible # ansible galaxy # ansible collection # playbook # disconnected # devops # real-world