Partie 1 : Présentation et prérequis
Partie 2 : Bases et premiers Playbook
Partie 3 : Les Variables
Partie 4 : Les Collections
––

Et voici la quatrième partie sur les collections, une nouvelles façon de gérer les modules, les rôles et les plugin qui s’inscrit dans un changement important sur les releases d’Ansible. On regarde ça de plus prêt.

Le code des exemples qui suivent sont toujours sur GitHub

Les Collections

Introduction

J’en avais rapidement parlé dans un précédent article, on va y revenir un peu plus en détail.
Les Collections permettent de regrouper du contenu Ansible (Playbook, rôles, modules, Plug-In…) dans des projets dédiés. À partir de la version 2.10, le projet Ansible (appelé ansible-base pour la version 2.10, et ansible-core pour la version 2.11 et les futures versions) se voit retrier une majorité de ses modules tiers qui sont donc répartis dans les Collections.

Pourquoi ce choix ? C’est assez simple, le projet Ansible devenait trop imposant. Le nombre d’issues et de PR sur le projet Github n’était plus raisonable, d’autant plus qu’ils concernaient majoritairement des modules dont la plupart étaient gérés par des tiers mainteneurs. Les raison détaillées ici : https://www.ansible.com/blog/announcing-the-community-ansible-3.0.0-package

Cette nouvelle façon de faire peut apporter les avantages suivants :

• Projet Ansible allégé
• Cycle de vie indépendant
• Gestion des collections déléguée (du moins pour certains)

Ces changements concernent principalement les développeurs, car côté utilisateur, il existe maintenant le Ansible community package ou Ansible Project qui suit une autre logique de versionning et qui intègrent toutes les collections maintenues. La version actuelle de Ansible Project est 4.7.0, elle intègre ansible-core 2.11 plus une version “freeze” des collections.
La version 5.0 est prévue pour fin novembre 2021.

Changements

Il existe trois types de collections :

• Celles intégrées dans le projet de base (ansible.builtin)
• Les collections maintenues par la communauté (community.)
• Celles gérées par les éditeurs (cisco, vmware etc.)

Liste exhaustive ici : https://github.com/ansible-collections

FQCN

Pour Fully Qualified Collection Name, représente le nom complet d’un Module, Role, Plug-in ou Playbook dans une Collection. Par exemple pour Grafana, le module qui permet de gérer les Datasource se nomme : community.grafana.grafana_datasource

Il est composé du namespace : community, de la collection : grafana et du content_name : grafana_datasource.
La liste des namespace est gérée par RedHat. Certains éditeurs ont leur namespace réservé comme Cisco ou VMware.

Note : Tous les modules qui n’ont pas encore été répartis dans des Collection et qui ne font pas partie de ansible-base se trouve dans les Collections :

• community.general
• community.network

Les Collections sont principalement hébergées sur GitHub, mais peuvent aussi l’être sur d’autres gestionnaire de code source. Ansible Galaxy a été revu pour prendre en compte les Collections et ainsi nous proposer un outil permettant de les gérer.

Mise à jour depuis 2.9 : Nouveau VirtualEnv

Si vous aviez installé via pip, vous ne pourrez pas le mettre à jour directement, il faudra le déinstaller puis le réinstaller.
Si Ansible est dans un VirtualEnv (vu dans l’article sur les prérequis), vous pouvez vous en créer un nouveau afin de conserver les deux versions d’Ansible (pratique pour des tests).

Création d’un nouveau VirtualEnv :

1

virtualenv -p /usr/bin/python3 ansible4

Activation du venv :

1

source ansible4/bin/activate

Installation Ansible 4.7.0 et jmespath (pour les filtres JSON) :

1
2

pip install ansible
pip install jmespath

En affichant la version, on affiche la version de ansible-core associée :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 (ansible210) jlg@DESKTOP-N97SPSR:~$ ansible --version
ansible [core 2.11.6] 
  config file = None
  configured module search path = ['/home/jlg/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/jlg/venv/ans/lib/python3.6/site-packages/ansible
  ansible collection location = /home/jlg/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/jlg/venv/ans/bin/ansible
  python version = 3.6.9 (default, Jan 26 2021, 15:33:00) [GCC 8.4.0]
  jinja version = 3.0.2
  libyaml = True

Première Collection

On peut vérifier que la Collection community.grafana est déjà présente :

1

ansible-galaxy collection install community.grafana

Dans un Play, on va indiquer que l’on souhaite charger cette Collection en ajoutant ceci à l’en-tête :

1
2
3
4
5
6
7
8

- name: Grafana
  hosts: tig
  remote_user: jlg
  become: true
  gather_facts: false

  collections:
    - community.grafana

Installation Grafana

Avant d’installer Grafana, on ajuste le premier play pour les prérequis :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

---
- name: Prerequisites
  hosts: tig
  gather_facts: yes
  remote_user: jlg
  become: true
  tasks:
    - name: Set timezone to Europe/Paris
      timezone:
        name: Europe/Paris
[...]
    - name: Add Grafana Apt key
      apt_key:
        url: https://packages.grafana.com/gpg.key
        state: present

    - name: Add Grafana stable Apt repository
      apt_repository:
        repo: deb https://packages.grafana.com/oss/deb stable main
        state: present

Puis on ajoute un Play à notre Playbook pour l’installation de Grafana :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

- name: Grafana
  hosts: tig
  remote_user: jlg
  become: true
  gather_facts: false

  collections:
    - community.grafana

  tasks:
    - name: Install Grafana OSS
      apt:
        force_apt_get: yes
        update_cache: yes
        pkg: grafana

    - name : Start Grafana service
      service:
        name: grafana-server
        enabled: yes
        state: started

Ajout d’une Datasource

La première étape de configuration de Grafana consiste à ajouter une Datasource. C’est depuis cette source de données que l’on va pouvoir créer des dashboards. Une Datasource peut être une base de données relationnelle (MySQL, Postgres …) ou encore une TSDB comme InfluxDB, ce qui est notre cas. On pourrait également penser à Prometheus pour ce cas.

Pour ajouter notre Datasource on va (enfin!) s’appuyer sur la collection Grafana. On ajoute ces tasks à la suite de l’installation :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

    - name: Ensure Influxdb datasource exists
      grafana_datasource:
        name: "influxdb"
        grafana_url: "http://127.0.0.1:3000"
        grafana_user: "admin"
        grafana_password: "admin"
        org_id: "1"
        ds_type: "influxdb"
        ds_url: "http://127.0.0.1:8086"
        database: "{{ influxdb_database_name }}"
        time_interval: ">10s"

Pour le nom de la database on réutilise la variable que l’on avait défini dans le précédent article.

Dans Grafana on peut maintenant voir la Datasource InfluxDB qui a été ajoutée :

On va s’arrêter là pour cet article, à bientôt pour la prochaine étape qui sera consacrée à la suite de la configuration avec la création de Dashboard et la collection des données avec Telegraf !