Skip to main content
In this lesson we’ll cover Ansible collections: the mechanism that delivers most of Ansible’s vendor-specific modules, roles, plugins, and playbooks. Collections let you extend base Ansible functionality with packages tailored to vendors and platforms. Picture yourself as a network engineer managing a large estate of devices from cisco.nxos, Juniper, and Arista. While Ansible includes general networking modules, real-world automation typically requires vendor-specific capabilities—this is exactly the gap filled by collections. A collection packages specialized content—modules, roles, plugins, and playbooks—into one
A presentation slide titled "One Self-Contained Package" with the subtitle "Specialized content, shipped as one unit." A graphic on the right shows a "One Collection" card listing Modules, Roles, and Plugins.
self-contained unit optimized for a particular vendor or platform. Each collection is published under a two-part name: namespace.name. You use that name both to install the collection and when referring to its content in playbooks.
A slide illustrating that every collection has a two-part name, shown as two cards labeled "namespace" (who publishes it) and "name" (what it covers). A button reading "Install it by that name" and a small KodeKloud logo appear below.
The namespace appears first. For vendor collections the namespace is typically the vendor (for example, cisco.ios for Cisco IOS device modules). Use the collection’s name to install it and to reference its modules.
Collections were introduced in Ansible 2.10. Manage them with ansible-galaxy collection commands whether you’re using ansible-core or the bundled ansible package. See the official docs: https://docs.ansible.com/ansible/latest/collections/index.html

​
What’s inside a collection?

Collections group related content types so you can distribute vendor-specific automation cleanly:

​
Common ansible-galaxy collection commands

​
Referencing collection modules (FQCN)

Modules included in collections can be invoked by their fully qualified collection name (FQCN): namespace.collection.module_name. Using the FQCN avoids ambiguity and makes playbooks explicit. Example: calling the ios_config module from cisco.ios using its FQCN:
Alternatively, declare the collection at the play level so you can use short module names without repeating the namespace:

​
Best practices

  • Use the collections: list in your play to avoid repeating FQCNs when multiple tasks use the same collection.
  • Pin collection versions in automation or documentation to ensure reproducible runs.
  • Inspect collection CHANGELOGs and release notes before upgrading—vendor modules can introduce breaking changes.
  • When sharing playbooks, include a requirements.yml for collections so others can install dependencies automatically. Example requirements.yml:
Install from that file with:
Always validate collection upgrades in a test environment before applying them in production. Module behavior, parameter names, or connection plugins can change between major releases.

​
Quick reference

  • Collections were introduced in Ansible 2.10 to simplify distribution of vendor-specific content.
  • Install and manage collections with ansible-galaxy collection.
  • Use FQCNs (namespace.collection.module) for explicitness, or declare collections in the play to use short names.
  • Always document or pin collection dependencies for repeatable automation.
Further reading and references:

Watch Video

Practice Lab