Ansible Galaxy and Collections

So far we've used modules like ansible.builtin.dnf without explaining the ansible.builtin part. That's a collection. Since Ansible 2.10, collections are the central packaging and distribution unit — bundling modules, roles, and plugins together. Understanding collections is mandatory "advanced" knowledge for modern Ansible.

Why collections exist

Before 2.10, every module lived in one giant Ansible package — hard to maintain, slow to release, everyone tied to a single release schedule. Collections split that apart: each vendor/community packages its own modules + roles + plugins into a separate collection, released independently.

A collection bundles:

   <namespace>.<collection>
   ├── modules/       the modules (e.g. amazon.aws.ec2_instance)
   ├── roles/         the roles
   ├── plugins/       filter/lookup/callback plugins (Article 12)
   └── playbooks/     sample playbooks

Examples: amazon.aws (AWS management modules), community.general (all kinds of community modules), ansible.posix (POSIX tools). ansible.builtin is the always-available core collection — containing dnf, copy, service, template...

FQCN: calling a module explicitly

FQCN (Fully Qualified Collection Name) is the full way to call: namespace.collection.module. For example:

   ansible.builtin.dnf            namespace=ansible, collection=builtin, module=dnf
   amazon.aws.ec2_instance        create EC2
   community.general.timezone     set timezone

Why use FQCN instead of a short name (dnf)?

• Explicit: you know which collection a module comes from.
• Avoids name clashes: two collections may have a module of the same name; FQCN pinpoints it.
• It's a recommended best practice (Article 15). Short names still work (Ansible guesses), but FQCN is safer, especially in shared roles/collections.

ansible-core vs ansible: which package contains what

This is an easy point of confusion when installing (Article 2):

• ansible-core — just the core: engine + ansible.builtin. Lean.
• ansible (full package) — ansible-core plus a curated set of collections (community.general, amazon.aws, ansible.posix...). This is why after pip install ansible, you already have many collections:

ansible-galaxy collection list

Collection           Version
amazon.aws           10.1.2
ansible.posix        2.1.0
community.general    11.4.2

community.general, for example, has up to ~575 modules (ansible-doc -l community.general). If you install ansible-core, you have to install the collections you need yourself.

Install collections from Galaxy

Ansible Galaxy (galaxy.ansible.com) is the community repository of collections and roles. Install a collection:

ansible-galaxy collection install community.general

But the professional way is to declare it in requirements.yml (put under Git to reproduce the environment):

collections:
  - name: community.general
  - name: amazon.aws
    version: ">=10.0.0"
roles:
  - name: geerlingguy.docker      # role from Galaxy

Then:

ansible-galaxy install -r requirements.yml          # both roles and collections
ansible-galaxy collection install -r requirements.yml

Nothing to do. All requested collections are already installed.

requirements.yml is a best practice (Article 15): everyone on the team installs the exact same collection/role versions, the environment is reproducible — like another language's package.json/requirements.txt.

Enterprises also have Automation Hub (Red Hat-certified/supported collections) alongside Galaxy (community). Same mechanism, different source and level of guarantee.

Use a collection in a playbook

Once installed, use a collection's module/role via FQCN:

- hosts: localhost
  tasks:
    - name: Create EC2 (module from amazon.aws)
      amazon.aws.ec2_instance:
        name: web
        instance_type: t2.micro
        image_id: ami-xxxx

    - name: Set timezone (module from community.general)
      community.general.timezone:
        name: Asia/Ho_Chi_Minh

Interesting: recall the dynamic AWS inventory in Article 3 (amazon.aws.aws_ec2) — that's a plugin from the amazon.aws collection. And Ansible can be used to create cloud infrastructure too (not just configure it), via modules like amazon.aws.ec2_instance.

Create your own collection

Like creating a role (Article 8), you scaffold your own collection to package internal company modules/roles/plugins:

ansible-galaxy collection init mycompany.infra

It builds the mycompany/infra/ structure with plugins/, roles/, galaxy.yml (metadata). Build it into a .tar.gz (ansible-galaxy collection build), then publish to Galaxy/Automation Hub or install internally. This is how you share automation at organizational scale — bundling your custom modules (Article 11) and plugins (Article 12) into a shared collection.

🧹 Cleanup

A sample requirements.yml is in the nghiadaulau/ansible-series repo, directory 09-collections.

Wrap-up

A collection is Ansible's modern packaging unit (since 2.10): it bundles modules, roles, plugins under one namespace (amazon.aws, community.general, ansible.builtin). Call via FQCN (namespace.collection.module) for clarity and to avoid clashes — a best practice. ansible-core has only the core; the ansible package bundles many collections. Install from Galaxy with ansible-galaxy collection install, declare in requirements.yml for reproducibility. Create your own collection with ansible-galaxy collection init to package internal automation.

Before writing your own modules/plugins (Articles 11, 12), we'll solve a real need every project has: managing secrets (passwords, API keys) safely. Article 10: Ansible Vault.