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

Seconde partie de la série d’article consacrée à Ansible. L’objectif est toujours le même, monter en puissance sur l’outil en s’appuyant sur des cas d’usages. De même que pour la partie prérequis, ce sera un mélange de bonnes pratiques provenant de l’éditeur mais aussi de mon retour d’expérience.
Dans cet article, on revient sur les bases du produit ainsi que sur la réalisation d’un premier Playbook. On va commencer le déploiement du Stack TIG (Telegraf, InfluxDB, Grafana) pour la supervision d’un environnement VMware (vCenter + ESXi), ce sera notre fil rouge :)

Pour rappel, les prérequis c’est ici.

Le code des exemples qui suivent est sur GitHub

Introduction et objectifs d’Ansible

J’avais déjà eu l’occasion de faire une rapide introduction à Ansible dans la première partie, ici on va approfondir en citant quelques cas d’usage, puis on couvrira principales fonctionnalités avec une explication plus théorique.

A l’origine, le produit a été développé pour la gestion de la configuration de serveurs Linux. Il est sans agent, il s’appuie donc sur SSH pour l’accès aux nœuds (serveurs qui seront gérés par Ansible). Une fois connecté sur les nœuds, c’est du code Python qui est exécuté. Pour moi les points forts du produit :

• Agentless
• Utilisation de SSH qui va permettre d’accéder également à des équipements réseaux ou de sécurité et ainsi élargir le panel des nœuds gérés.
• Exécution de code Python (2 et 3), qui est présent par défaut sur une majorité de système

On notera également qu’il est possible de gérer des nœuds Windows avec PowerShell mais également n’importe quel équipement ou application que l’on peut accéder via des web services (Rest API par exemple). Dans ce dernier cas, le code Python est exécuté en local.
Si vous avez réalisé les étapes listées dans les prérequis, vous devez avoir un environnement Ansible prêt pour écrire vos premiers Playbook. Comme vous l’avez vu, c’est plutôt simple à mettre en place. Un Playbook s’exéucte un peu à la manière script Python ou PowerShell, avec la commande ansible-playbook suivi du Playbook :

1

ansible-playbook playbook.yml

Cas d’usage

Un des cas d’usage le plus souvent cité quand on parle d’Ansible, c’est le déploiement et la configuration, sur un serveur Linux, d’un ensemble applicatif (par exemple serveur web + base de données). Du fait de l’idempotence native des modules, on peut rejouer le Playbook sur le serveur Linux, il n’y aura pas d’incidence, au contraire on corrigera une éventuelle dérive de la configuration.

En vrac, quelques cas d’usages:

• Automatiser le déploiement d’équipements réseaux
• Déploiement de machines virtuelles
• Configuration de serveurs ESXi
• Déploiement d’un stack applicatif

Composants

• Control Node : Là où on installe Ansible.
• Managed Nodes : Equipements pilotés à distance. Ils sont listés dans le fichier Inventory
• Tower : Portail web de pilotage. AWX est l’Upstream de Tower.
• Playbook : Description de la configuration souhaitée
• Modules : Code qui est exécuté sur les nœuds

On reviendra sur les Playbook et Modules un peu plus loin dans l’article.

Fichiers nécessaires

Pour commencer on va parler des fichiers les plus importants, ceux qui sont suffisants pour faire un premier Playbook qui sera fonctionnel.

Playbook

Dans le Playbook on décrit la configuration que l’on souhaite retrouver appliquée sur les nœuds. A la différence d’un script, on décrit des états que l’on souhaite obtenir, plutôt que des tâches précises à exécuter.
Les Playbook sont écrits en YAML, un langage proche du JSON. Explication sur la syntaxe ici : https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html

Inventaire

C’est dans le fichier d’inventaire que l’on déclare les nœuds qui pourront être accédés avec le Playbook. Il en existe un par défaut : /etc/ansible/hosts.

Le fichier inventaire peut être sous deux formats :

• Fichier .ini
• Fichier .yml

Format .ini

Vous retrouverez plus souvent l’inventaire sous le format .ini, mais le second n’est pas à ignorer car suivant l’inventaire souhaité, il peut apporter davantage de souplesse.

Dans notre exemple où l’on va déployer le stack TIG, voici à quoi pourrait ressembler le fichier inventaire en .ini :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[tig]
influxdb ansible_host=192.168.1.10
telegraf ansible_host=192.168.1.11
grafana ansible_host=192.168.1.12

[webservers]
nginx01.domain.local
nginx02.domain.local

dns01.domain.local

Si on décompose le fichier :

• [tig] est le nom du groupe et qui intégère les 3 lignes suivantes. Le groupe peut-être utilisé dans le Playbook.
• influxdb est le nom que l’on souhaite donner au host. Il peut également être utilisé dans le Playbook.
• ansible_host est une variable associée au host, chaque variable est séparée par un espace, puis on indique sa valeur précédé de =. Dans ce cas c’est l’ip du host.

J’ai ajouté un second groupe (qui ne servira pas dans notre exemple) pour montrer que l’on peut en créer autant que l’on souhaite. Il n’est pas indispensable de préciser l’ip du host si on une résolution de nom fonctionnelle.

Et enfin, un host qui n’appartient à aucun groupe, là encore il ne sera utilisé dans l’exemple

Pour la démonstration, on va installer les 3 produits sur le même serveur, donc on ne mettra qu’une seule ligne.

Format YAML

Voici l’équivalent en YAML :

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

all:
  hosts:
  children:
    tig:
      hosts:
        influxdb:
            ansible_host: 192.168.1.10
        telegraf:
            ansible_host: 192.168.1.11
        grafana:
            ansible_host: 192.168.1.12
    webservers:
      hosts:
        nginx01.domain.local:
        nginx02.domain.local:
    dns01.domain.local:

Je pense que c’est suffisament clair pour comprendre la logique de ce format. A noter que les mots clés “all”, “hosts” et “children” sont réservés. Point important, “all” est implicitement présent dans le fichier inventaire.ini, il correspond à l’ensemble des hosts présent dans l’inventaire.

Inventaire dynamique

Je ne vais pas rentrer dans les détails sur les inventaires dynamiques dans cet article, car on n’en aura pas besoin tout de suite. Mais sachez que c’est très pratique qu’un inventaire puisse être géré depuis une source de données externe. Deux exemples :

• Un serveur vCenter, permet d’avoir une liste VM à jour dans l’inventaire
• Un IPAM qui sert de Source of Truth, comme l’excellent NetBox

Je vous encourage à vous rendre sur la documentation officielle pour approfondir la gestion des inventaires avec Ansible : https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html

Mode interactif

La fonction première d’Ansible est bien d’exécuter des Playbook, mais à des fins de test/debug, il est possible de l’utiliser en mode interactif. Par exemple si on souhaite savoir si un nœud est accessible :

1

ansible grafana --inventoy inventory.ini --user jlg -m ping

Ici on se connecte à l’hôte grafana qui est défini dans le fichier d’inventaire inventory.ini avec l’utilisateur jlg. Sur cet hôte on exécute le module ping.

Résultat attendu :

1
2
3
4
5
6
7

grafana | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

On retrouve la documentation de chaque module via la commande :

1

ansible-doc ping

Ou directement sur le site d’Ansible : https://docs.ansible.com/ansible/latest/modules/modules_by_category.html

Un autre exemple est l’utilisation du module command qui est celui par défaut (on a donc pas besoin de le préciser). Ce module attend un argument qui correspond à la commande à exécuter sur l’hôte. Exemple :

1

ansible grafana --inventory inventory.ini --user jlg -a hostname

Comme indiqué, on ne précise pas le nom du module command car il est sélectionné par défaut, cependant on précise l’argument avec -a, ici il va donc exécuter la commande hostname et nous renvoyer le résultat :

1
2

grafana | CHANGED | rc=0 >>
tig

Enfin, la fonctionnalité la plus utile en mode interactif est la découverte et l’affichage des Facts. Je reviendrai plus en détail sur les Facts et variables avec Ansible dans le prochain article. Ce qu’il faut retenir ici, c’est la capacité qu’a Ansible à découvrir des informations sur le nœud géré et à les enregistrer dans des variables. Par exemple :

• Informations Hardware, CPU, mémoire, disques, réseau etc…
• Informations systèmes comme les adresses IP, nom et version de l’OS
• Et plein d’autres choses

Le mieux étant encore de le tester, pour cela on exécute le module setup, sans argument :

1

ansible grafana --inventoy inventory.ini --user jlg -m setup

Le résultat est très long, voici une partie :

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

grafana | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "192.168.x.x"
        ],
        "ansible_all_ipv6_addresses": [
            "fe80::20c:xxxx:xxxx:xxxx"
        ],
        "ansible_apparmor": {
            "status": "enabled"
        },
        "ansible_architecture": "x86_64",
        "ansible_bios_date": "02/27/2020",
        "ansible_bios_version": "6.00",
        "ansible_cmdline": {
            "BOOT_IMAGE": "/boot/vmlinuz-5.4.0-42-generic",
            "maybe-ubiquity": true,
            "ro": true,
            "root": "UUID=4ac4c187-b2ed-49ff-aa93-5b4ac3f13156b"
        },

On peut également appliquer un filtre afin de limiter l’affichage, ici un exemple pour affichier les points de montage :

1

ansible grafana --inventory inventory.ini --user jlg -m setup -a 'filter=ansible_mounts'

Toutes ces informations vont pouvoir être réutilisées plus tard dans le Playbook, par exemple si vous souhaitez faire un contrôle sur une version d’OS avant d’exécuter un tâche.

Composition d’un Playbook

On arrive maintenant au Playbook, on va rester simple ici aussi, le but étant d’introduire le concept.

Voici le Playbook que l’on va exécuter :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

---
- name: Prerequisites
  hosts: tig
  gather_facts: yes
  remote_user: jlg
  become: true
  tasks:
    - name: Set timezone to Europe/Paris
      timezone:
        name: Europe/Paris
    
    - name: Local packages should be up-to-date
      apt:
        pkg: "*"
        state: latest

    - name: Add InfluxData Apt key
      apt_key:
        url: https://repos.influxdata.com/influxdb.key
        state: present

    - name: Add stable InfluxData Apt repository
      apt_repository:
        repo: "deb https://repos.influxdata.com/{{ ansible_facts['distribution']|lower }} {{ ansible_facts['distribution_release'] }} stable"
        state: present

- name: InfluxDB
  hosts: tig
  remote_user: jlg
  become: true
  gather_facts: false
  tasks:
    - name: Install InfluxDB
      apt:
        update_cache: yes
        pkg: influxdb

    - name: Service started and enabled
      service:
        name: influxdb
        enabled: yes
        state: started

Même si un Playbook a le mérite d’être compréhensible, il mérite quelques explications 😊

1. Configuration de la Timezone
2. Mise à jour de tous les paquets
3. Ajout du Repository apt d’InfluxData (éditeur de de InfluxDB et Telegraf) avec la clé associée
   • Ici on a exemple de l’utilisation des Facts vu plus haut avec la récupération de l’OS (ubuntu) et de la version (focal)
4. Si InfluxDB n’est pas présent, on l’installe.
   • Ici on précise present et non pas latest, on veut que InfluxDB soit installé, si c’est déjà le cas, on ne souhaite pas le mettre à jour.
5. Enfin on démarre le service et on l’active (démarrage automatique)

Play

Un Playbook est divisé en plusieurs Play, ici on en retrouve deux, le premier commence dès le début avec :

1

- name: prerequisites

Le fait qu’il commence par un tiret indique que c’est une liste, et donc qu’il est proabable qu’il y en est plusieurs.

Un Play correspond à une liste de tâches qui seront exécutées suivant les informations dans l’en-tête. Ces tâches seront exécutées dans l’odre, sur chacun des nœuds. Cependant le traitement se fait en parallèle sur les nœuds (si on a précisé un groupe au lieu d’un hôte simple).

En-tête

Une en-tête par Play, la première :

1
2
3
4
5

- name: Prerequisites
  hosts: tig
  gather_facts: yes
  remote_user: jlg
  become: yes

On retrouve des informations qu’on avait déjà pu préciser dans le mode interactif comme le host (ou groupe de hosts, on aurait pu mettre all ou grafana). On retrouve aussi l’utilisateur pour se connecter exéucter les actions. On y précise quelques informations supplémentaires comme le fait qu’on récupère les Facts, ainsi que le besoins d’obtenir une élévation de privilège (become).

Task

C’est avec les Tasks qu’on indique quel est l’état souhaité sur le nœud. Si on regarde la première Task :

1
2
3

    - name: Set timezone to Europe/Paris
      timezone:
        name: Europe/Paris

Le nom indiqué est optionnel et servira notamment pour obtenir un affichage clair, mais aussi de marqueur si on souhaite relancer le Playbook depuis une tâche précise. Ensuite vient l’appel du module timezone auquel on passe un argument correspondant à la Timezone.

L’objectif de cette Task est donc de configurer la Timezone indiqué en argument, sur le host. Si la configuration est déjà correct, il remontera un statut Ok, si il doit la modifier, il précisera Changed. On s’attend donc à ce que si on relance le Playbook, le statut sera Ok

Module

Enfin le module est le composant qui renferme le code Python qui sera exécuté sur le nœud, c’est lui qui doit être idempotent et donc s’assurer de ne faire des modifications que si nécessaire. Les modules sont accessibles directement sur Github : https://github.com/ansible/ansible/tree/stable-2.9/lib/ansible/modules.

Exécution du Playbook

Enfin, on peut exécuter ce premier Playbook avec la commande suivante :

1

ansible-playbook playbook.yml --inventory inventory.ini -K

Cette fois on ne précise pas d’utilisateur ni de nœud sur lequel exécuter le Playbook, ces informations sont indiquées dans l’en-tête des Plays. On a cependant ajouté l’option -K afin que le prompt nous sollicite pour saisir le mot de passe permettant l’élevation de privilège (sudo par défaut).

Je vous encourage à le relancer plusieurs fois afin de voir la différence.

Cya!