# Les rôles Ansible

Les [rôles Ansible](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html) permettent d'organiser des tâches, handlers, fichiers, templates, variables, etc. selon une hiérarchie de fichier bien définie.

L'organisation de ces contenus en rôles favorise leur réutilisation et leur partage avec d'autres utilisateurs.

Plaçons-nous par exemple dans la perspective d'utiliser des playbooks pour déployer des applications web développées en PHP.

On pourrait être tenté d'écrire des playbooks décrivant toute la procédure d'installation :

- de la "stack" logicielle : LAMP (Linux, Apache, MySQL, PHP) ou LEMP (Nginx remplaçant Apache), avec de possibles variantes (utilisation de MariaDB au lieu de MySQL).
- de l'application elle-même : dans le cas de PHP, on peut citer entre autres WordPress (plateforme de création de sites), MediaWiki (moteur de wiki utilisé par Wikipédia), PostfixAdmin (interface web de gestion de Postfix), phpMyAdmin.

Écrire la procédure entière au sein d'un playbook pour chaque application donnerait lieu à beaucoup de répétition.

En effet, seule l'application installée, et quelques paramètres de configuration du serveur web, changeraient d'un playbook à l'autre.

Les includes et imports permettent de séparer du contenu et de le réutiliser, mais les rôles imposent une structure cohérente et favorisent l'encapsulation d'une fonctionnalité spécifique par rôle.

En bref, les avantages de l'utlisation des rôles sont :

- La réutilisabilité et la modularité : chaque rôle peut encapsuler toutes les tâches, les fichiers, les templates, et les handlers nécessaires pour une fonction spécifique (comme configurer un serveur web Nginx ou déployer une application WordPress).
- L'organisation et la maintenance : les rôles suivent une structure de répertoire standardisée, ce qui rend le code Ansible plus organisé et plus facile à appréhender.
- Le partage et la collaboration : les rôles peuvent être facilement partagés entre différents projets via des plateformes comme Ansible Galaxy.
- La gestion des dépendances et des variables : les rôles permettent de gérer facilement les dépendances entre les rôles ainsi que les variables par défaut spécifiques à chaque rôle, ce qui offre une grande flexibilité pour la personnalisation et la configuration.

## Exemple

> L'exemple complet est à retrouver sur [ce dépôt](https://git.hubbros.fr/bh/ansible-lemp-wordpress).

Si on souhaite déployer WordPress sur une stack LEMP avec Ansible, on peut organiser un playbook avec cette hiérarchie de répertoires et fichiers :

```
playbook-directory/
│
├── roles/
│   ├── nginx/
│   │   ├── tasks/
│   │   │   └── main.yml  # Tâches pour installer et configurer Nginx
│   │   ├── templates/
│   │   │   └── nginx-wordpress.conf.j2  # Template Nginx pour WordPress
│   │   └── handlers/
│   │       └── main.yml  # Handlers pour redémarrer Nginx
│   ├── php/
│   │   ├── tasks/
│   │   │   └── main.yml  # Tâches pour installer PHP et ses extensions
│   │   ├── handlers/
│   │   │   └── main.yml  # Handlers pour redémarrer PHP-FPM
│   │   └── templates/
│   │       └── php.ini.j2  # Template pour la configuration PHP
│   ├── mysql/
│   │   └── tasks/
│   │       └── main.yml  # Tâches pour installer MySQL/MariaDB et configurer la base de données
│   ├── wordpress/
│   │   ├── tasks/
│   │   │   └── main.yml  # Tâches pour installer WordPress et WP-CLI, configurer wp-config.php
│   │   └── templates/
│   │   │   └── wp-config-sample.php.j2  # Template pour wp-config.php
│   └── common/
│       └── tasks/
│           └── main.yml  # Tâches communes comme la mise à jour des paquets
│
├── hosts.ini  # Fichier d'inventaire
└── site.yml  # Playbook principal
```

### Contenu de `site.yml`

C'est le playbook qui va permettre de déployer la stack et l'application, en utilisant des rôles.

```yaml
---
- name: Déployer la stack LEMP + WordPress sur Debian 12
  hosts: all
  become: yes

  roles:
    - common
    - nginx
    - php
    - mysql
    - wordpress

```

Les tâches associées aux rôles référencés ici, et stockées sous `roles/<nom_role>/tasks/main.yml`, vont être exécutées dans l'ordre.

### Contenu de `roles/common/tasks/main.yml`

Ce fichier contient des tâches génériques, telles que la mise à jour du cache apt, et l'installation de paquets qui seront utiles pour la suite, sans être spécifiquement liés à un certain rôle.

```yaml
---
- name: Mettre à jour le cache apt
  ansible.builtin.apt:
    update_cache: yes

# Installer curl - pour télécharger WordPress et wp-cli
- name: Installer curl
  ansible.builtin.apt:
    name: curl
    state: present
```

### Contenu de `roles/nginx/tasks/main.yml`

Dans l'ordre, on va ici :

- installer Nginx,
- le démarrer,
- créer une configuration Nginx pour PHP - et plus spécifiquement WordPress, bien qu'elle soit utilisable avec des variations mineures pour d'autres applications PHP ; cette configuration est créé à partir d'un _template_
- supprimer le lien symbolique de la configuration par défaut, prévue pour servir uniquement des fichiers statiques (HTML, CSS, etc.),
- créer le lien symbolique permettant d'activer notre configuration,
- **enfin**, redémarrer Nginx

```yaml
---
- name: Installer Nginx
  ansible.builtin.apt:
    name: nginx
    state: present

- name: Démarrer le service Nginx
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: yes # S'assurer que le service MySQL démarre au boot

- name: Créer la config Nginx pour PHP + WordPress
  ansible.builtin.template:
    src: templates/nginx-wordpress.conf.j2
    dest: /etc/nginx/sites-available/nginx-wordpress.conf
    owner: root
    group: root
    mode: 0644

- name: Supprimer le lien symbolique `default` de sites-enabled
  ansible.builtin.file:
    path: /etc/nginx/sites-enabled/default
    state: absent

- name: Créer un lien symbolique de sites-available/nginx-wordpress.conf vers sites-enabled
  ansible.builtin.file:
    src: /etc/nginx/sites-available/nginx-wordpress.conf
    dest: /etc/nginx/sites-enabled/nginx-wordpress.conf
    state: link
  notify: restart nginx 

```

L'action de _redémarrer Nginx_ n'apparaît pas ici directement, mais sous la forme de la dernière ligne `notify: restart nginx`.

Elle fait référence à un handler défini dans un fichier placé également à un endroit standard&hellip;

### Contenu de `roles/nginx/hamdlers/main.yml`

C'est ce fichier qui contient le handler référencé dans le fichier précédent. Voici son contenu :

```yaml
---
- name: restart nginx
  ansible.builtin.service:
    name: nginx
    state: restarted
    enabled: yes # S'assurer que le service Nginx démarre au boot

```