Ansible Galaxy

Ansible Galaxy is the public registry of community roles, and ansible-galaxy role install pulls a role into your project the way pip pulls a package. The catch is that anyone can publish, so the real skill is vetting. A role with one star, last updated three years ago, and no tests is a liability you are installing directly into your deploy path. Pin versions and read the source before you trust someone else's role to configure your servers.

A good community role saves weeks — the standard nginx, PostgreSQL, and Docker roles are battle-tested across thousands of installs. An abandoned one costs more than writing your own, because you inherit its bugs and its assumptions and own them from the moment you adopt it.

ansible-galaxy role install

ansible-galaxy role install installs a named role into your roles path. The name carries a namespace — geerlingguy.nginx — where the prefix identifies the author and the suffix the role. By default it lands in ~/.ansible/roles, or in the project roles/ directory if you configure a roles_path. From there the role is callable by name, exactly like one you wrote yourself; once installed, Ansible does not distinguish a Galaxy role from a local one.

# pulls geerlingguy.nginx into the configured roles path
$ ansible-galaxy role install geerlingguy.nginx

Run ad-hoc like this, the role installs on the one machine you ran it on — useful to try a role, wrong as the way your project records its dependencies. For that you want the install declared in a file every environment reads.

requirements.yml for Roles

Declare every external role and its version in requirements.yml, then run ansible-galaxy role install -r requirements.yml to install the whole set at once. This file is the reproducible record — the equivalent of a lockfile for your role dependencies. CI installs from it, the next engineer installs from it, and everyone resolves the identical roles. Without it, each laptop and each runner installs whatever happened to be latest the day it ran, and the playbook "works on my machine" for reasons nobody can reconstruct.

# requirements.yml
roles:
  - name: geerlingguy.nginx
    version: "3.1.4"      # a git tag, never floating HEAD
  - name: geerlingguy.postgresql
    version: "3.5.2"

Each role names a pinned version. Install from this file in CI and every environment gets the exact same code, every time, with the file itself serving as the reviewed, committed record of what your project depends on.

Vetting a Community Role

Before adopting a role, check recent commit activity, open-issue rot, test presence — Molecule or a CI pipeline — download count, and whether it supports your OS. A role with commits this month, few stale issues, real tests, and a million downloads is a different proposition from one that last moved in 2021 with twelve open issues and no tests. And vet the source, not just the badges: read the tasks for a hidden command: shelling out, or an assumption about your distribution that does not hold. You are putting this code in your deploy path; treat it like code you would review.

Pinning Versions

Install a specific git tag — version: "3.1.4" — never floating HEAD. A pinned version means a re-run installs identical code and an upstream change cannot silently alter your deploy. Leave it unpinned and a later install pulls whatever the author pushed since, so a deploy behaves differently with no commit on your side to explain it. Unpinned community roles are a supply-chain surprise waiting to happen — the surprise arrives on the day you can least afford it, in the middle of a deploy you did not change.

Roles Path and Layout

Installed roles land in the configured roles_path. Keep your own roles in the repo's roles/ directory, committed, and keep external ones declared in requirements.yml and installed in CI rather than vendored into the repo. That split keeps the boundary clean: the repo holds the roles you wrote and a manifest of the ones you borrowed, without checking in a copy of someone else's source that you can never cleanly update. The dependency is declared; the code is fetched fresh from the pinned tag each time.