Part 1 : Presentation and prerequisites
Part 2 : Basics and first Playbook
Part 3 : Variables
Part 4 : Collections
––
Here is the fourth part of the series and it is about Collections! A new way to deal with modules, roles and plugins. It is a recent feature which is part of a larger change in Ansible’s releases.
The code regarding the examples is on GitHub
Collections
Introduction
I had already introduced the subject in a previous article, now it’s time to go deeper.
The Collections allow us to group together Playbook, roles, modules and plug-ins. This is useful for editors to group their Ansible content into one project.
Starting with Ansible 2.10, a wild range of modules has been removed from the Ansible project (called ansible-base for 2.10 and ansible-core for following versions) and are now a dedicated Collection project.
Why this choice? It’s rather simple actually, the Ansible project started to be too large and therefore too hard to maintain. When you had a look on the github project issues, it was mainly about modules. Those modules were, for the vast majority, maintained by dedicated teams, so it makes sense to have them split in different projects. You can find a detailed explanation here: https://www.ansible.com/blog/announcing-the-community-ansible-3.0.0-package
This new way of working can provide the following benefits:
- A lightened Ansible Project
- Independent life cylce (for both Ansible and Collections)
- Dedicated teams to work for Collections
These changes will mostly impact core devs as there is now the Ansible community package (also called Ansible Project) for end-users. This bundle includes a defined version of ansible-core and a freezed version of collections. The 5.0 version should be released at the end of this month (November 2021).
Changes
There are three types of collection:
- ansible.builtin.: still in the core project
- community.: maintain by the community in dedicated project
- cisco., vmware. etc.: maintain by editors
Exhaustive list here: https://github.com/ansible-collections
FQCN
For Fully Qualified Collection Name, it indicates the full name of a Module, Role, Plug-in or Playbook in a Collection. Let’s take the Grafana collection, the module that allows to manage Datasources is named: community.grafana.grafana_datasource
It consists of a namespace : community, a collection : grafana and a content_name : grafana_datasource.
The namespace list is managed by RedHat. Some editors have their namespace reserved like Cisco or VMware
Note: Even if ansible content tends to be split among collections, there are still lot in the general purpose collections:
- community.general
- community.network
Most of the collections are hosted on GitHub. Ansible Galaxy has been updated to be able to manage collections.
Update from 2.9: New VirtualEnv
If you have installed Ansible with pip, you won’t be able to upgrade in 2.10+, you will have to uninstall it.
If you have created a VirtualEnv to install Ansible, then you can create a new one for the newer versions. You can still keep the old one, it may be useful for testing purposes.
Creation of a newVirtualEnv:
|
|
Activation:
|
|
Installation of Ansible 4.7.0 and jmespath (for JSON filters):
|
|
While displaying the Ansible version, you can see the associated ansible-core version:
|
|
Using collection
We can try to install the collection, if it’s already installed we will be notified:
|
|
In a Play, we will specify we want to collection to be loaded:
|
|
Grafana installation
Now we can continue our Playbook. Before installation Grafana, we will add some prerequisites:
|
|
Then we add a new play with the installation:
|
|
Add a Datasource
The first step after the installation of Grafana is adding a Datasource. To be able to create dashboards, we need a datasource. A datasource can be a relational DB (MySQL, Postgres …) or a TSDB like InfluxDB. There are other choices, here is a list: https://grafana.com/docs/grafana/latest/datasources/
To add a datasource we will use the Grafana collection. We add this task after the installation part:
|
|
For the database name we will use the variable which has been defined in the previous article.
In Grafana we can now see the newly added InfluxDB Datasource:
In the next article we will see the rest of the configuration as well as the dashboard import and the data gathering with Telegraf!