Ansible Galaxy Tutorial: Leveraging Community Roles for Faster Automation

In network automation, you want things to be efficient, right? Managing tons of devices from different vendors takes effective tools, and let's be honest, writing Ansible playbooks from scratch for every single task is a major time drain. That's where Ansible Galaxy comes in, a central place for ready-made automation content from the community and vendors, built to make your job easier and faster.

If you already know the basics of Ansible playbooks, checking out Galaxy is the next logical step to really speed up your network automation. This guide will walk you through what Galaxy gives you, how to use its roles and collections, and how CloudMyLab fits into your practice.

• Ansible Galaxy at a Glance
• What is Ansible Galaxy?
• Why Use Ansible Galaxy?
• What is an Ansible Galaxy Role?
• What is an Ansible Galaxy Collection?
• Roles vs Collections: Which One Should You Use?
• Why Roles and Collections Matter to Network Engineers
• What are Galaxy Namespaces?
• How to Use Galaxy: Practical Steps
• Managing Dependencies with requirements.yml
• Troubleshooting ansible-galaxy Errors
• Uploading Your Own Role to Ansible Galaxy
• Why Choose Galaxy Over Alternatives?
• Choosing the Right Galaxy Setup for Your Team

Ansible Galaxy at a Glance

Before you pull down a single role, here is how the three places you can host Ansible content compare on cost, support, and what they are actually built for.

Galaxy is the right starting point for almost everyone. It is free, it has the widest selection, and the official vendor collections you actually need (cisco.ios, arista.eos, junipernetworks.junos) are published there. The catch is quality. Some roles are abandoned. Some collections drift behind their upstream modules. There is no SLA when something breaks at 2 a.m.

If you are running Ansible at scale and need a production safety net, CloudMyLab's hosted Ansible automation lab gives you a sandbox to test new Galaxy collections against virtual Cisco, Juniper, and Arista devices before you let them touch production. That is the gap most teams need to fill — Galaxy gives you the content, but you still need a safe place to validate it. For a deeper comparison of how the open-source CLI stacks up against the paid platform, see Ansible CLI vs Ansible Automation Platform.

What is Ansible Galaxy?

Ansible Galaxy serves as a central repository for Ansible content. It contains:

• Ansible Roles: Pre-packaged automation for specific tasks or configurations (like setting up NTP or handling VLANs).
• Ansible Collections: Introduced in Ansible 2.9+, these are bigger bundles. They can hold multiple roles, modules (the actual code that does things), plugins (that add features to Ansible), and documentation.

This stuff is built and kept up-to-date by the community – individual engineers, the core Ansible team at Red Hat, and network vendors like Cisco, Juniper, and Arista. For network engineers like you, Galaxy is a library of proven automation you can reuse instead of building common tasks from zero.

Why Use Ansible Galaxy?

You've probably run a show run playbook before—but what if you need to automate complex tasks like:

• Backing up Cisco configs
• Upgrading IOS images
• Deploying standard SNMP or NTP configs across hundreds of routers

Writing these from scratch can be tedious. Instead, you can reuse roles and collections from Galaxy that others (including Cisco!) have already tested and published.

Read more: Depending on your environment’s size, you can run these tasks using the Ansible CLI for simplicity or the Ansible Automation Platform for enterprise-scale management. Learn the differences in this Ansible CLI vs Ansible Automation Platform comparison.

What is an Ansible Galaxy Role?

A role is a neatly packaged set of automation tasks, structured for reusability. It includes:

• Tasks (in tasks/main.yml) showing the automation steps.
• Variable definitions (in defaults/main.yml for defaults and vars/main.yml for role-specific variables).
• Templates (in the templates/ directory) using Jinja2 to generate configuration files.
• Handlers (in handlers/main.yml) that run when notified, often for things like restarting services.
• Static files (in the files/ directory) to be copied to devices.
• Metadata (in meta/main.yml) about the role, who made it, and if it needs other roles.

Roles make things modular, keeping your playbooks cleaner and easier to handle by putting complex bits into reusable packages.

Ansible Galaxy Role Example: Real-time

You want to configure NTP on 500 Cisco routers. You can use a role like:

ansible-galaxy install network-ntp

Then in your playbook:

- hosts: cisco_routers
roles:
  - cisco_ios_vlan

Note: cisco_ios_vlan is a sample name

What is an Ansible Galaxy Collection?

Ansible Collections are the newer, standard way to package Ansible content (started with Ansible 2.9). They're bigger than roles – a single collection can have multiple roles, custom modules (like vendor-specific ones for device APIs), plugins (for things like inventory or connections), and docs.

Collections use a <namespace>.<collection_name> format (like cisco.ios or junipernetworks.junos). This helps avoid naming clashes and tells you who made or maintains the content. Collections make it easier to share full, integrated automation solutions from vendors and the community.

Example:

ansible-galaxy collection install cisco.ios

Installing cisco.ios gets you modules like cisco.ios.ios_config, cisco.ios.ios_command, cisco.ios.ios_facts, plus any roles or plugins included in that collection.

Read more: To ensure these collections run consistently across different systems, use Ansible Execution Environments, which package dependencies into containers. Explore Understanding Ansible Execution Environments for setup and benefits.

Roles vs Collections: Which One Should You Use?

Why Roles and Collections Matter to Network Engineers

Roles are tactical, collections are strategic. Together, they let you automate everything from one-off tweaks to enterprise-wide deployments while following community best practices.

Using them effectively helps you out in several ways:

• Save a ton of time: Use automation that's already built and tested instead of writing everything from scratch.
• Help standardize things: Implement configs the same way every time, using community or vendor best practices.
• Speed up your learning: Look at the code in well-built community and vendor contributions to see how others do it.
• Make teamwork easier: Share standard automation units within your team or contribute back to the wider community.
• Scale your automation faster: Apply automation to many devices confidently using reliable, pre-built pieces.

What are Galaxy Namespaces?

A namespace in Ansible Galaxy is a unique name (usually for an organization, vendor, or person) that groups related content, specifically collections.

Examples of Popular Namespaces:

• cisco, arista, junipernetworks (or juniper): Vendor-specific content.
• ansible: Content from the core Ansible team (like ansible.netcommon).
• community: Content maintained by the wider community (like community.general).

ansible-galaxy collection list

How to Use Galaxy: Practical Steps

Read more: For an enhanced CLI experience when managing Galaxy content, try Ansible Navigator, a tool for running and debugging Ansible tasks. Learn more in our Ansible Navigator guide.

Install a Role in Galaxy

Install a single role (using a namespace is best practice now):

ansible-galaxy install .

Roles usually land in ~/.ansible/roles. You can check or change this path in your ansible.cfg file using the roles_path setting:

[defaults]
roles_path = ~/.ansible/roles:/etc/ansible/roles:/opt/custom_roles

To see what roles are installed on your system:

ansible-galaxy role list

For air-gapped or offline environments, you can download a collection archive without installing it, copy the .tar.gz to your target host, and install it from disk:

ansible-galaxy collection download cisco.ios
ansible-galaxy collection install cisco-ios-5.3.0.tar.gz

This pattern is essential for regulated networks where the Ansible control node has no outbound internet access. For a fuller treatment of execution environments and how to bundle collections into reproducible containers, see Ansible Execution Environment.

Install a Collection in Galaxy

As described earlier, you may install collections using ansible-galaxy collection install:

ansible-galaxy collection install cisco.ios

You can grab a collection archive (.tar.gz) without installing it right away, which is handy for offline setups:

ansible-galaxy collection download cisco.ios

Then, install the downloaded file later:

ansible-galaxy collection install cisco.ios-*.tar.gz

To list installed collections (and see their versions and where they are):

ansible-galaxy collection list

Collections usually go into ~/.ansible/collections/ansible_collections/<namespace>/<collection_name> or in a project's collections/ directory if you use a requirements.yml file.

To remove a collection:

ansible-galaxy collection remove cisco.ios

Note that older Ansible versions did not support uninstall for collections. If the command fails, check your ansible-core version. On anything from 2.10 onward it works.

Managing Dependencies with requirements.yml

Installing collections one at a time on the command line is fine for tinkering. For any project that lives longer than a weekend, you want a requirements.yml file that lists every dependency, pins versions, and gets committed to Git. Without it, you are one upstream release away from a broken pipeline.

A minimal requirements.yml looks like this:

---
collections:
  - name: cisco.ios
    version: "5.3.0"
  - name: cisco.nxos
    version: ">=5.0.0,<6.0.0"
  - name: ansible.netcommon
    version: "6.1.0"
  - name: community.general
    version: ">=8.0.0"

roles:
  - name: geerlingguy.docker
    version: "7.0.0"
  - src: https://github.com/your-org/ansible-role-internal-baseline
    name: internal_baseline
    version: "v1.4.2"
    scm: git

To install everything in the file:

ansible-galaxy install -r requirements.yml

That command handles both collections and roles in one pass. If you only want to install collections (for example, in a CI step that does not need roles), use the explicit form:

ansible-galaxy collection install -r requirements.yml
ansible-galaxy role install -r requirements.yml

A few practical rules for requirements.yml that save you from real production incidents:

• Pin versions. Floating versions (>=5.0.0) work until a vendor ships a breaking change in a minor release — which happens more often than you would expect. Pin to exact versions for anything production-adjacent.
• Commit the file to Git. Treat it the same way you treat requirements.txt for Python or package.json for Node.
• Install into the project, not the user home. Use -p ./collections or set collections_path so dependencies stop leaking across projects.
• Refresh deliberately. When you bump a version, test the playbook against a lab before you merge. Vendor collections occasionally rename modules or change parameter defaults across major versions, and you do not want to find that out from a change ticket.

For network teams running Ansible against live infrastructure, the wrong place to discover that cisco.ios 6.0 changed the default for save_when is during a Friday afternoon change window. Pin, test in a sandbox, then merge.

Read more: How you write and structure your Ansible playbooks totally impacts how well they scale. Read our article on the best practices for Ansible playbooks.

Real-World Example: Automating NTP Config

Let's set up NTP servers on devices in your cisco_routers inventory group using modules from the cisco.ios collection.

Playbook configure_ntp.yml:

---
- name: Configure NTP on Cisco routers
  hosts: cisco_routers
  gather_facts: false
  collections: # Tell Ansible which collections this playbook uses
    - cisco.ios

  tasks:
    - name: Set NTP server configuration
      cisco.ios.ios_config: # Use the Full Collection Name (FQCN) for the module
        lines:
          - ntp server 192.168.1.10
          - ntp server 192.168.1.11
        save_when: modified

This playbook uses the ios_config module to push NTP settings and saves the config if changes are made. Done in minutes, not hours.

Troubleshooting ansible-galaxy Errors

Most Galaxy issues fall into a handful of categories. Here is what tends to go wrong and how to fix it without burning a Saturday.

"Collection not found" or "no matching version"

The collection name is wrong, the version pin does not match anything published, or the registry you are pointing at does not have the collection. Check what is actually available:

ansible-galaxy collection list cisco.ios

If you are using a private server, make sure ~/.ansible/galaxy_token or your ansible.cfg [galaxy] section is configured for the right URL.

"Module not found" after install

The collection installed, but Ansible cannot find a module from it. Almost always this is a Fully Qualified Collection Name (FQCN) issue. Old playbooks reference ios_config directly. Modern playbooks should reference cisco.ios.ios_config:

tasks:
  - name: Push NTP config
    cisco.ios.ios_config:
      lines:
        - ntp server 192.168.1.10
        - ntp server 192.168.1.11
      save_when: modified

The collections: keyword at the play level used to let you skip the FQCN, but FQCN is the recommended style going forward. Use it everywhere and you avoid this class of problem entirely.

"Duplicate role" or "duplicate collection" warning

You have the same collection installed in two paths, usually ~/.ansible/collections/ and a project-local ./collections/. List everything to confirm:

ansible-galaxy collection list

Then remove the one you do not want, or set collections_path in ansible.cfg so only one path is searched.

"Role was not found" when running a playbook

The playbook references a role by short name, but the role is installed under a different name. Roles installed from a Git URL pick up the repository name, not the role name. Either install with --role-name:

ansible-galaxy role install git+https://github.com/your-org/ansible-role-baseline.git --role-name internal_baseline

Or set the name explicitly in requirements.yml:

roles:
  - src: https://github.com/your-org/ansible-role-baseline
    name: internal_baseline

Connection or proxy errors against galaxy.ansible.com

Behind a corporate proxy, ansible-galaxy does not always pick up your environment proxy variables. Set them explicitly:

export https_proxy=http://proxy.example.com:3128
ansible-galaxy collection install cisco.ios

For air-gapped environments where there is no path to public Galaxy at all, download collections on a host that does have access, copy the archives across, and install from local files. For deeper performance and execution debugging, Optimize Ansible Performance covers strategies that apply once your collections install cleanly.

Uploading Your Own Role to Ansible Galaxy

Sharing your useful automation helps the community. Here's how:

Create Role in VS Code

ansible-galaxy init my_custom_role

Create a GitHub Repository - Name it like: ansible-role-my_custom_role

Push Role to GitHub - Push your role files to GitHub, including a meta/main.yml with basic info.

Create a Galaxy Account - Create an Ansible Galaxy account if you don't have one.

Link Your GitHub Account - Go to your Galaxy Settings → GitHub Integration, and then authorize access to your GitHub repositories.

Import Your Role - Import your role from GitHub via "My Content" -> "Add Content". Your role becomes available on Galaxy. It'll be listed under your namespace like

my_namespace.my_custom_role

To Install Your Role - Others can install it using:

ansible-galaxy install my_namespace.my_custom_role

Why Choose Galaxy Over Alternatives?

While custom Python scripts (using libraries like Netmiko or NAPALM) offer detailed control, and vendor-specific tools (like Cisco DNA Center, Arista CloudVision) provide integrated experiences within their ecosystems, Ansible Galaxy offers advantages for scalable and standardized multi-vendor automation:

Galaxy content is often designed and tested for large environments, enabling consistent management of many devices. This scale is hard to achieve reliably with custom scripts without significant engineering. Using community or vendor content encourages using established automation patterns, making your work more maintainable. Galaxy benefits from the collective knowledge of thousands of engineers and direct vendor contributions, providing access to ongoing maintenance and support through collection maintainers. It excels in multi-vendor environments. A single Ansible control node with collections like cisco.ios and junipernetworks.junos can orchestrate changes across a heterogeneous network within one workflow, which is difficult with separate vendor tools.

While Python scripting offers flexibility and vendor tools deep integration, Ansible Galaxy provides a balance with reusable, standardized, community-supported content ideal for scaling network automation across diverse environments efficiently.

Choosing the Right Galaxy Setup for Your Team

The right Galaxy setup depends on your team size, your compliance environment, and whether you are running Ansible against production. Here is a decision matrix that maps team profiles to the setup that matches.

The most common mistake is using Galaxy without a requirements.yml. Engineers install collections on their laptops, push playbooks to Git that run cleanly locally, and the CI runner (or a teammate on a different machine) has a different version installed and gets a different result. Pinning versions in a committed file fixes that, for free, in five minutes.

The second most common mistake is testing new Galaxy content directly against production. A community collection can be perfectly fine on the version you originally tried, then ship a new module default in the next release that quietly changes behavior on your gear. Test in a sandbox first — every time. CloudMyLab's hosted Ansible automation lab gives you a pre-built environment to validate new collections against virtual Cisco, Juniper, and Arista devices before they touch your real network. For broader context on where automation labs fit into a network engineer's day, see Network Automation Proofs of Concept and Cloud-Based Training Labs.

If your time is worth more than the subscription, or you already know you want a place to test Galaxy content safely without rebuilding it locally, start a CloudMyLab free trial and skip the lab setup. For the broader picture of why network automation matters and how Galaxy fits into it, see Network Automation: Critical for IT.

Learning Resources

• Get Started: Ansible Setup Guide – Step-by-step environment setup.
• Understand Modules: Ansible Modules Explained – Guide to module types and usage.
• Official Documentation: https://docs.ansible.com/ – Comprehensive Ansible resource.
• Hands-On Practice: Red Hat Ansible Labs – Interactive labs for learning.
• Community Support: https://forum.ansible.com/ – Connect with Ansible experts.

FAQ

What is Ansible Galaxy?

It's a website and command-line tool (ansible-galaxy) for finding, sharing, and managing reusable Ansible content, primarily roles and collections.

What's the difference between a role and a collection?

A role is a standardized way to structure automation for a specific task or component. A collection is a broader package that can contain multiple roles, modules, plugins, and documentation, often used to distribute content from a specific vendor or community. Collections are the newer standard.

Where are Roles and Collections Stored?

The roles usually go into ~/.ansible/roles/. Check or change the path in ansible.cfg using roles_path.
The collections typically land in ~/.ansible/collections/ansible_collections/. Use ansible-galaxy collection list to confirm the exact paths on your system.

How do I install content from Galaxy?

Use the ansible-galaxy install command for roles (ansible-galaxy install <namespace>.<role_name>) or collections (ansible-galaxy collection install <namespace>.<collection_name>). You can also install multiple dependencies using a requirements.yml file (ansible-galaxy install -r requirements.yml).

Do I need internet access to use Galaxy content?

You need internet access to install content from https://galaxy.ansible.com/ . Once installed, you can use the content locally. For air-gapped environments, you can download collection archives first and install them offline.

Can I use Galaxy content for network devices from different vendors?

Yes, many collections are vendor-specific (like cisco.ios, junipernetworks.junos, arista.eos), allowing you to use modules and roles tailored for those devices. Other collections like ansible.netcommon provide modules that work across multiple vendors.

How do I contribute my own automation to Galaxy?

You need to structure your automation as a role or collection, store it in a public GitHub repository, and then import it into your Ansible Galaxy account.

What is requirements.yml and why do I need it?

requirements.yml is a YAML file that lists every collection and role your project depends on, along with pinned versions and source URLs. You commit it to Git so that any teammate or CI runner can reproduce your exact dependency set with one command (ansible-galaxy install -r requirements.yml). Without a requirements.yml, every install is a moving target and your playbooks are one upstream release away from breaking.

What is the difference between Ansible Galaxy and Automation Hub?

Ansible Galaxy at galaxy.ansible.com is free and open, hosting community and vendor content with no quality gate. Automation Hub is part of Red Hat Ansible Automation Platform, contains only Red Hat-certified collections, and comes with a vendor support contract. Most teams start on public Galaxy and adopt Automation Hub when they need certified content under support. The two can coexist in the same requirements.yml.

Can I host my own private Ansible Galaxy server?

Yes. The open-source galaxy_ng server is the same software that powers public Galaxy and Automation Hub, and you can self-host it inside your network. Teams use private Galaxy servers for three reasons: hosting internal-only collections that cannot leave the network, operating in air-gapped environments with no path to galaxy.ansible.com, or proxying public collections internally for compliance reasons.