So collections are a new way to bundle Ansible content to make it more
manageable. So now we have different parties responsible for different
content in Ansible, so consider collections a distribution format for
Ansible content that may include playbooks,
roles,
modules, and even plugins. So we can have a number of
different types of collections.
For example,
we have a Cisco IOS collection with roles and playbooks only
dealing with Cisco IOS. So collections are all about how you
distribute content and update it asynchronously.
So when, let's say, Ansible 2.9 collections are not part of Ansible, and to use
them they need to be installed from the Ansible Galaxy, to install multiple
collections, you should use a requirement file, but from Ansible 2.10 onwards
there is better collection integration.
So there can be dependencies on other collections, and this can be done with
the requirements file, and they can install these if need be.
So these dependencies could be, for example, Python dependencies or a
system‑level library that required different versions of Ansible. So we have
over 100 different collections and dozens of certified platforms and
vendors, and you can create your own collections too that you can build and
distribute within your organization.
We also have subscription‑based collections that is
available through the Automation Hub.
So we have subscription‑only collections too. So to access subscription‑only
collections, you need an authentication stored in your ansible.cfg file. It's
kind of like a secret token that is used to protect your content, and the
token expires after 30 days of inactivity.
So we have many Red Hat partners, maybe over 50 or 60, and if you want to see
what collections are available from each of these partners,
you will need a subscription license for the Automation Platform.