Gestion des rôles Ansible

1. Variables de rôle

Ces variables possèdent une priorité haute. Il n’est pas possible de les remplacer par des variables d’inventaire. Elles ne sont donc pas destinées à être modifiées quand elles sont utilisées dans un playbook. Elles sont généralement utilisées par le fonctionnement interne du rôle.

Les variables de rôle sont définies sous la forme d’une paire valeur/clé dans le fichier main.yml qui doit être situé dans le dossier vars. Des références à ces variables sont présentes dans le fichier YAML du rôle : {{ nom_de_variable }}.

2. Variables par défaut

Les variables par défaut sont déclarées sous la forme d’une paire valeur/clé dans le fichier main.yml qui doit être situé dans le dossier defaults.

Ces variables ont la priorité la plus basse de toutes les variables disponibles. Elles peuvent donc être facilement remplacées par d’autres variables. Elles servent à définir des valeurs par défaut pour les variables qui sont utilisées dans un « play ». Elles offrent, ainsi, la possibilité de configurer le rôle ou bien de personnaliser...

1. Fonctionnement des rôles

L’appel de rôles s’effectue avec le mot-clé roles :

--- 
- hosts: servers 
  roles: 
  - apache 

Lorsqu’un rôle est spécifié dans un playbook, ses tâches, ses gestionnaires (handlers), ses variables et ses dépendances seront importées dans cet ordre.

Toutes les tâches du rôle peuvent faire référence aux fichiers, aux modèles Jinja2 ou bien aux fichiers tâches dans le rôle sans invoquer un chemin relatif ou absolu. En effet, Ansible Engine les cherche dans les sous-répertoires files, templates ou tasks du rôle.

Lorsque vous utilisez une section roles afin d’importer des rôles dans un « play », les rôles sont exécutés en premier avant toutes les tâches définies pour ce « play ».

2. Contrôle de l’ordre d’exécution

Jusqu’ici, dans un playbook, pour chaque « play » présent, les tâches s’exécutent dans l’ordre de la liste des tâches. Ensuite, tous les gestionnaires (handlers) notifiés sont exécutés.

Si un playbook comporte des rôles, les tâches de rôle sont alors ajoutées au début de la liste des tâches. Chaque rôle exécute à tour de rôle ses tâches.

Si vous avez besoin d’exécuter certaines tâches avant les rôles, le « play » peut contenir une section pre_tasks. Ainsi, toutes les tâches listées dans cette section s’exécutent avant que des rôles ne soient exécutés. Si l’une de ces tâches notifie un gestionnaire, les tâches de gestionnaire s’exécutent avant les rôles ou les tâches normales....

1. Présentation des rôles système

L’objectif des rôles système est de normaliser la configuration des sous-systèmes RHEL/CentOS sur différentes versions à partir de la version 6.10 et plus. Ceci permet de simplifier la gestion de configuration.

Depuis la version 7.4 de RHEL/CentOS, un paquet RPM rhel-system-roles fourni de base, contient un certain nombre de rôles. Concernant, la version 8, ce paquet est présent dans le dépôt AppStream.

1. Création de la structure du dossier

La recherche des rôles s’effectue, par défaut, dans un sous-dossier nommé roles qui est situé dans le dossier dans lequel se trouve votre playbook. Si Ansible Engine ne trouve pas le rôle à cet endroit, alors il examine les dossiers spécifiés par la variable roles_path. La liste des dossiers à rechercher est séparée par un caractère deux-points. La valeur par défaut de cette variable est :

~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles 

Dans ~/.ansible/roles, vous pouvez stocker vos propres rôles tandis que le système peut avoir, dans /usr/share/ansible/roles, des rôles disponibles pour tous les utilisateurs qui accèdent au nœud de contrôle.

Arborescence

Vous pouvez, tout d’abord, concevoir un dossier racine qui se nomme /ansible par exemple. Il va englober les projets Ansible :

[root@server1 ~]# ll /ansible 
total 8 
drwxr-xr-x. 4 root root 4096 3 avril 03:17 app1 
drwxr-xr-x. 4 root root 4096 3 avril 03:53 app2 
[root@server1 ~]# 

Les dossiers /ansible/app1 et /ansible/app2 sont deux projets distincts Ansible.

Le projet /ansible/app1 a une arborescence comme suit :

[root@server1 ~]# tree /ansible/app1 
/ansible/app1 
├── ansible.cfg 
├── group_vars 
│   └── serveurs 
├── host_vars 
│   └── server2.staff.local 
├── inventories 
│   ├── production.ini 
│   └── stagging.ini 
├── install_app1.yml 
└── roles 
├── vars 
│   └── ext_vars.yml 
└── vault-files 
   └── pw-file 
[root@server1 ~]# 

Il comporte :

1. Ansible Galaxy