6.2 : Créer son premier rôle

En 6.1, on a vu la théorie de la structure d’un rôle. Passons à la pratique : transformons le playbook Apache du TP 5 (installation, template, handler) en un vrai rôle réutilisable.

Générer le squelette avec ansible-galaxy init

Plutôt que de créer chaque dossier à la main, Ansible fournit une commande qui génère toute l’arborescence standard d’un coup :

mkdir roles && cd roles
ansible-galaxy init apache

roles/apache/
├── README.md
├── defaults/
│   └── main.yml
├── handlers/
│   └── main.yml
├── meta/
│   └── main.yml
├── tasks/
│   └── main.yml
├── templates/
├── tests/
├── files/
└── vars/
    └── main.yml

Tous les fichiers main.yml sont générés vides (avec juste un commentaire ---) : à vous de les remplir.

Déplacer les tâches dans tasks/main.yml

On reprend exactement les tâches du TP 5, sans le hosts: ni le become: (qui restent définis dans le playbook appelant, pas dans le rôle lui-même) :

# roles/apache/tasks/main.yml
---
- name: Installer Apache
  ansible.builtin.apt:
    name: apache2
    state: present
    update_cache: yes

- name: Déployer le VirtualHost depuis le template
  ansible.builtin.template:
    src: nordika.conf.j2
    dest: /etc/apache2/sites-available/nordika.conf
  notify: Redémarrer Apache

- name: Activer le site
  ansible.builtin.command: a2ensite nordika.conf
  args:
    creates: /etc/apache2/sites-enabled/nordika.conf
  notify: Redémarrer Apache

Remarquez le chemin du template : nordika.conf.j2, sans templates/ devant. À l’intérieur d’un rôle, Ansible sait déjà chercher dans le dossier templates/ automatiquement — pas besoin de préciser le chemin complet comme on le faisait dans un playbook classique.

Déplacer le handler

# roles/apache/handlers/main.yml
---
- name: Redémarrer Apache
  ansible.builtin.service:
    name: apache2
    state: restarted

Déplacer le template

cp templates/nordika.conf.j2 roles/apache/templates/

Définir les valeurs par défaut

Pour rendre le rôle réutilisable, on remplace les valeurs qui étaient jusqu’ici écrites en dur (server_domain, apache_port) par des defaults :

# roles/apache/defaults/main.yml
---
apache_port: 80
server_domain: "nordika.local"

Et dans le template, rien ne change : on garde {{ apache_port }} et {{ server_domain }}, exactement comme en section 5.

Le playbook devient minimaliste

# playbook_apache_role.yaml
---
- name: Déployer l'infrastructure web de Nordika
  hosts: webservers
  become: yes
  roles:
    - apache

Surcharger un default sans toucher au rôle

C’est là que le vrai bénéfice apparaît. Pour un serveur qui doit avoir un domaine différent, pas besoin de modifier le rôle : on surcharge simplement le default via host_vars, exactement comme n’importe quelle autre variable vue en section 2 et 4 :

# host_vars/nrd-web2.yml
server_domain: "site-client-b.nordika.local"
apache_port: 8080

Le rôle reste identique, intact, réutilisable pour n’importe quel autre serveur — seule la configuration change, à l’extérieur du rôle.

Passer une variable directement dans l’appel du rôle

Autre façon de personnaliser, utile pour une valeur ponctuelle propre à un playbook précis plutôt qu’à un hôte :

---
- name: Déployer le site vitrine
  hosts: webservers
  become: yes
  roles:
    - role: apache
      vars:
        server_domain: "vitrine.nordika.local"

Vérifier que tout fonctionne

ansible-playbook playbook_apache_role.yaml -i inventaire.yaml -v

Le comportement doit être strictement identique à celui du TP 5 — c’est normal, on n’a fait que réorganiser le code, pas changer sa logique.

Ce qu’il faut retenir

• ansible-galaxy init <nom> génère la structure standard d’un rôle en une commande.
• À l’intérieur d’un rôle, les chemins vers templates/ et files/ sont implicites — pas besoin de les préfixer.
• Les defaults sont le levier principal de personnalisation d’un rôle, sans jamais avoir à le modifier.
• Un rôle bien conçu reste inchangé d’un projet à l’autre — seule la configuration autour de lui varie.

Dans la prochaine leçon, on va plus loin : plutôt que d’écrire soi-même un rôle pour tout, on regarde comment récupérer et réutiliser un rôle déjà écrit par la communauté, via Ansible Galaxy.