Ansible OEL 8 DevOps · OEL 8 · Roles

AnsibleAnsible Galaxy

The public role registry, requirements.yml for pinning third-party roles, the install commands, plus how to publish your own roles either to galaxy.ansible.com or to a private hub.

Ansible Galaxy is the public registry for community roles and collections. Browse, install, and version-pin community-maintained code instead of writing everything from scratch. Common entries — geerlingguy.mysql, geerlingguy.docker, community.mysql — are battle-tested across thousands of users.

requirements.yml in your repo - name: geerlingguy.mysql version: 4.3.4 install ansible-galaxy resolves dependencies install -r requirements.yml fetch galaxy.ansible.com public role registry + private hubs ~/.ansible/roles/ downloaded here geerlingguy.mysql/ requirements.yml is committed to git · roles are not — re-fetched at deploy
BASH — install a single role
# Latest version, into ~/.ansible/roles
ansible-galaxy role install geerlingguy.mysql

# A specific version
ansible-galaxy role install geerlingguy.mysql,4.3.4

# Into a custom path (the project-local roles/ folder)
ansible-galaxy role install -p ./roles geerlingguy.mysql

# List what's installed
ansible-galaxy role list
# /home/deploy/.ansible/roles
# - geerlingguy.mysql, 4.3.4

# Remove
ansible-galaxy role remove geerlingguy.mysql

For any project bigger than a one-off, declare your role dependencies in requirements.yml — checked into git, installable in one command, exact-pinnable to a tag.

YAML — requirements.yml
---
# roles/requirements.yml — pin everything you depend on

# 1. From Galaxy by name
- name: geerlingguy.mysql
  version: 4.3.4

- name: geerlingguy.docker
  version: 7.4.0

# 2. From a public git repo (any host)
- name: company.proxysql
  src: https://github.com/example-org/ansible-role-proxysql
  scm: git
  version: v1.4.0          # tag — best for reproducibility

# 3. From a private git repo over SSH
- name: company.common
  src: git@gitlab.example.com:platform/ansible-role-common.git
  scm: git
  version: main            # OK for inner-source if you trust the branch

# 4. From a tarball URL
- name: legacy.role
  src: https://artifactory.example.com/legacy-role-1.2.0.tar.gz
BASH — install everything from requirements.yml
# install all roles into a project-local directory (the right approach)
ansible-galaxy role install -r roles/requirements.yml -p ./roles

# force re-install (if you bumped a version)
ansible-galaxy role install -r roles/requirements.yml -p ./roles --force

# typical .gitignore — DO commit requirements.yml, do NOT commit ./roles/
echo "roles/*" >> .gitignore
echo "!roles/requirements.yml" >> .gitignore
echo "!roles/our-roles" >> .gitignore   # if you mix in-tree + external roles
💡 Tip: Pin to tags, not to main. A role tagged v1.4.0 is reproducible — the same playbook applied a year from now still installs identical code. main can change underneath you and break things.
BASH — find roles
# search by keyword
ansible-galaxy role search mysql

# look at one role's metadata
ansible-galaxy role info geerlingguy.mysql
# author, description, supported platforms, dependencies, version history

# Or browse:  https://galaxy.ansible.com/
BASH — publish workflow
# 1. Develop the role in its own git repo
mkdir ansible-role-myrole && cd ansible-role-myrole
ansible-galaxy init .       # populate skeleton inside current dir

# 2. Push to GitHub (Galaxy reads from GitHub by default)
git init && git add . && git commit -m "Initial role"
git remote add origin git@github.com:yourname/ansible-role-myrole.git
git push -u origin main

# 3. Tag a release
git tag v0.1.0 && git push --tags

# 4. Sign in at galaxy.ansible.com with GitHub
#    → "Add my Content" → import the repo
#    → Galaxy will pick up the metadata from meta/main.yml
#    → Each new git tag becomes a new role version automatically
⚠ Warning: The repo name MUST start with ansible-role- for Galaxy auto-import. The role's Galaxy name then becomes <your-username>.<suffix> — for ansible-role-myrole at user jdoe, it's installable as jdoe.myrole.

For corporate environments that can't ship to public Galaxy, three options:

OptionWhat it isBest for
Direct git URLReference your private git repo in requirements.yml with scm: gitSmall teams; zero infra
Red Hat Automation HubHosted private registry from Red Hat (paid)Enterprises already on RH platform
Pulp + Galaxy NGOpen-source self-hosted private GalaxyAir-gapped or compliance-heavy shops
INI — ansible.cfg — point at a private hub
[galaxy]
server_list = my_hub, automation_hub, galaxy

[galaxy_server.my_hub]
url = https://galaxy.example.com/api/galaxy/
token = {{{{ lookup('env', 'MY_HUB_TOKEN') }}}}

[galaxy_server.automation_hub]
url = https://console.redhat.com/api/automation-hub/
auth_url = https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token = {{{{ lookup('env', 'AH_TOKEN') }}}}

[galaxy_server.galaxy]
url = https://galaxy.ansible.com/
✅ Tip: Most teams' simplest path is: keep your roles as private git repos and reference them in requirements.yml by URL + git tag. No infra to run, full versioning, fully reproducible. Move to a hub only when you have 30+ roles and need search/discovery.