Ansible Galaxy: the Content Hub
Ansible Galaxy (galaxy.ansible.com) is the public registry where the community publishes reusable roles and collections, and the ansible-galaxy CLI is the client used to search, download, and install that content locally into a project. Rather than writing an Nginx-hardening role from scratch, a team can run ansible-galaxy install geerlingguy.nginx and get a battle-tested, community-maintained role instantly, the same way developers pull dependencies from npm or PyPI instead of reimplementing them.
Cricket analogy: It's like the IPL player auction pool where franchises pick proven talent such as Rashid Khan rather than developing every bowler through their own academy from zero.
Collections: the Modern Packaging Unit
A Collection is a distributable format that bundles multiple roles, modules, plugins, and playbooks together under a single namespace.name identifier, such as community.general or ansible.posix, and it is the packaging unit Ansible has standardized on since Ansible 2.10 split most modules out of the core ansible package. Collections are installed with ansible-galaxy collection install and referenced in tasks using their fully qualified collection name (FQCN), for example community.general.ufw, which avoids naming collisions between similarly named modules from different vendors.
Cricket analogy: It's like a full team squad announced with a shirt-number and surname system to avoid confusion between two players named Sharma on the same roster.
# requirements.yml
collections:
- name: community.general
version: ">=8.0.0"
- name: ansible.posix
version: "1.5.4"
roles:
- name: geerlingguy.nginx
version: "3.1.4"Run ansible-galaxy collection install -r requirements.yml (or role install -r requirements.yml for roles) in CI so every environment resolves the exact same pinned versions, rather than relying on whatever happens to be installed locally.
Fully Qualified Collection Names in Practice
Using the FQCN form, such as ansible.builtin.copy instead of bare copy, is now considered best practice because it makes explicit exactly which collection provides a module, avoids ambiguity when two installed collections ship a module with the same short name, and makes playbooks more portable since the collection_paths lookup no longer needs to guess. Ansible's ansible.builtin collection covers the modules that used to ship in ansible-core itself, like file, template, and command.
Cricket analogy: It's like a scorecard listing 'V Kohli (India)' instead of just 'Kohli,' since there could be another Kohli playing domestic cricket for a different state side.
Relying on short module names like copy without ansible.builtin. can silently break if a third-party collection installed later happens to also ship a module named copy and takes precedence in the collection search path.
- Ansible Galaxy (galaxy.ansible.com) is the public registry for community roles and collections; ansible-galaxy is the CLI client.
- A Collection bundles roles, modules, plugins, and playbooks under one namespace.name identifier, e.g. community.general.
- Collections became the standard packaging format after Ansible 2.10 split most modules out of ansible-core.
- Install collections with ansible-galaxy collection install, ideally pinned via a requirements.yml file for reproducibility.
- Fully Qualified Collection Names (FQCN), like ansible.posix.mount, avoid ambiguity between similarly named modules.
- ansible.builtin is the collection covering the modules that historically shipped in ansible-core.
- Pin exact collection and role versions in CI to guarantee reproducible automation runs.
Practice what you learned
1. What is the primary purpose of Ansible Galaxy?
2. What does a Collection bundle together?
3. Why use a fully qualified collection name like ansible.posix.mount instead of just mount?
4. Which file is typically used to pin exact collection and role versions for reproducible installs?
Was this page helpful?
You May Also Like
Ansible Roles Explained
Learn what Ansible roles are, why they exist, and how their standard directory layout lets you package reusable, shareable automation.
Role Dependencies
Learn how to declare dependencies between Ansible roles using meta/main.yml, and understand ordering, deduplication, and pitfalls.
Reusable Role Design
Practical principles for writing Ansible roles that are genuinely reusable across projects, teams, and environments.
Testing Roles with Molecule
Learn how Molecule automates spinning up test instances, converging a role, and verifying results to give roles real automated tests.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics