Orchestrer Apache et MariaDB en un seul playbook Ansible

Il est temps de rassembler tout ce qu’on a appris depuis le début de cette formation. Le lab découverte de cette formation traitait Apache et MariaDB avec deux playbooks séparés, exécutés l’un après l’autre, avec des mots de passe en clair. On va maintenant écrire une version unique, orchestrée, qui déploie toute l’infrastructure Nordika en un seul run — exactement le genre de fiche de vol complète qu’un vrai contrôleur enverrait à toute une escadrille en une seule transmission.

L’objectif : un seul playbook, plusieurs rôles, tout organisé

Plutôt qu’un fichier monolithique, on structure ça avec deux rôles (comme vu en section 6) : apache et mariadb, chacun ciblant le bon groupe d’hôtes, avec des tags pour pouvoir rejouer une seule partie si besoin.

ansible/
├── ansible.cfg
├── inventaire.yaml
├── .vault_pass.txt
├── group_vars/
│   └── databases.yml   # chiffré avec Vault
├── roles/
│   ├── apache/
│   │   ├── tasks/main.yml
│   │   ├── handlers/main.yml
│   │   └── templates/nordika.conf.j2
│   └── mariadb/
│       ├── tasks/main.yml
│       └── handlers/main.yml
└── playbook_nordika_complet.yaml

L’inventaire : deux groupes distincts

# inventaire.yaml
all:
  hosts:
    nrd-web1:
      ansible_host: <IP>
    nrd-db1:
      ansible_host: <IP>
  children:
    webservers:
      hosts:
        nrd-web1:
    databases:
      hosts:
        nrd-db1:

Le rôle mariadb, avec ses secrets vaultés

# roles/mariadb/tasks/main.yml
---
- name: Installer MariaDB
  ansible.builtin.apt:
    name:
      - mariadb-server
      - python3-pymysql
    state: present
    update_cache: yes
  tags: install

- name: Démarrer MariaDB
  ansible.builtin.service:
    name: mariadb
    state: started
    enabled: yes
  tags: install

- name: Définir le mot de passe root
  community.mysql.mysql_user:
    name: root
    host: localhost
    password: "{{ mysql_root_password }}"
    login_unix_socket: /run/mysqld/mysqld.sock
    check_implicit_admin: true
    priv: "*.*:ALL,GRANT"
  tags: config

- name: Créer la base applicative
  community.mysql.mysql_db:
    name: "{{ app_db }}"
    state: present
    login_user: root
    login_password: "{{ mysql_root_password }}"
  tags: config

- name: Créer l'utilisateur applicatif
  community.mysql.mysql_user:
    name: "{{ app_user }}"
    password: "{{ app_password }}"
    priv: "{{ app_db }}.*:ALL"
    host: "%"
    state: present
    login_user: root
    login_password: "{{ mysql_root_password }}"
  tags: config

Les variables mysql_root_password et app_password viennent de group_vars/databases.yml, chiffré avec Vault exactement comme au TP 8 — aucun secret en clair dans ce rôle.

Le rôle `apache`, avec son handler

On reprend tel quel le rôle créé au TP 6 :

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

- 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
  tags: config

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

Le playbook principal : orchestrer les deux rôles

# playbook_nordika_complet.yaml
---
- name: Déployer l'infrastructure complète de Nordika
  hosts: webservers:databases
  become: yes
  gather_facts: yes

  tasks:
    - name: Vérifier la connectivité avant tout déploiement
      ansible.builtin.ping:
      tags: always

- name: Déployer la partie web
  hosts: webservers
  become: yes
  roles:
    - role: apache
      tags: apache

- name: Déployer la partie base de données
  hosts: databases
  become: yes
  roles:
    - role: mariadb
      tags: mariadb

Remarquez la structure : trois plays dans un seul playbook (souvenez-vous de la leçon 3.1 : un playbook est une liste de plays). Le premier vérifie juste la connectivité sur toute la flotte concernée (webservers:databases, le pattern d’union vu en 2.5), le deuxième déploie Apache uniquement sur webservers, le troisième déploie MariaDB uniquement sur databases. Chaque groupe ne reçoit que ce qui le concerne.

Exécuter le tout

ansible-playbook playbook_nordika_complet.yaml -i inventaire.yaml

Grâce à ansible.cfg (configuré au TP 8), le Vault se déverrouille automatiquement, sans option supplémentaire.

Rejouer une seule partie avec les tags

Si seule la configuration Apache doit être retouchée, pas besoin de repasser par l’installation ni par MariaDB :

ansible-playbook playbook_nordika_complet.yaml -i inventaire.yaml --tags "apache,config"

Un déploiement plus prudent, avec `serial`

Sur un parc plus large que notre lab à deux machines, on ajouterait serial (vu en 9.2) au niveau des plays webservers et databases, pour ne pas risquer tout le parc en une seule vague :

- name: Déployer la partie web
  hosts: webservers
  become: yes
  serial: "30%"
  roles:
    - role: apache
      tags: apache

Ce qu’il faut retenir

Un playbook réel combine souvent plusieurs plays, chacun ciblant le bon sous-ensemble de la flotte.
Les rôles (section 6), les tags (9.1), le Vault (section 8) et les handlers (section 5) se combinent naturellement dans un seul fichier d’orchestration.
tags: always sur une vérification de connectivité initiale est un bon réflexe avant tout déploiement multi-groupes.
Sur un vrai parc, serial reste le filet de sécurité qui évite de tout casser d’un coup.