Module 1 — Ansible : provisionner un serveur réel, à distance

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 10 minutes

---

Ce qu’Ansible résout

Les modules précédents ont automatisé la construction d’images (Docker) et le déploiement d’infrastructure (Terraform). Ansible répond à un troisième besoin : configurer des serveurs déjà existants — installer des paquets, déposer des fichiers de configuration, gérer des services — de façon déclarative (on décrit l’état voulu, pas la suite d’étapes pour y arriver) et répétable (relancer le même playbook doit être sans danger).

Particularité importante : contrairement à Terraform ou Docker, Ansible n’a besoin d’aucun agent installé sur les machines gérées — il se connecte simplement en SSH et exécute de courts scripts Python temporaires. C’est ce qui le rend si simple à adopter sur un parc de serveurs existant.

Comment ce module a été démontré

Un vrai serveur cible a été mis en place — un conteneur Ubuntu 24.04 avec un serveur SSH actif, accessible uniquement depuis un réseau Docker isolé créé pour cette démonstration — et un contrôleur Ansible séparé (un autre conteneur, avec Ansible et un client SSH installés) s’y connecte réellement en SSH, exactement comme il se connecterait à un vrai serveur de production.

$ ansible webservers -m ping
target | SUCCESS => {
    "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3.12" },
    "changed": false,
    "ping": "pong"
}

Le module ping ne teste pas ICMP — il vérifie que la connexion SSH fonctionne et que Python est disponible sur la cible (Ansible en a besoin pour exécuter ses modules). C’est le premier test à lancer avant tout playbook.

L’inventaire : quelles machines gérer

inventory.ini

[webservers]
target ansible_host=ansible-target ansible_user=deploy ansible_password=deploy ansible_ssh_common_args='-o StrictHostKeyChecking=no'

Un inventaire réel regrouperait des dizaines ou centaines de serveurs par rôle ([webservers], [databases], [loadbalancers]) — permettant de cibler un playbook sur exactement le bon sous-ensemble de machines.

Le playbook

playbook.yml

- name: Provisionner un serveur web
  hosts: webservers
  become: true

  vars:
    site_message: "Déployé par Ansible"

  tasks:
    - name: Mettre à jour le cache apt
      apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Installer nginx
      apt:
        name: nginx
        state: present

    - name: Déployer la page d'accueil personnalisée
      copy:
        content: "<h1>{{ site_message }}</h1>\n"
        dest: /var/www/html/index.html
      notify: Redémarrer nginx

    - name: S'assurer que nginx est démarré et activé
      service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Redémarrer nginx
      service:
        name: nginx
        state: restarted

become: true demande l’élévation de privilèges (l’équivalent de sudo) pour les tâches qui en ont besoin. Le handler (Redémarrer nginx) n’est déclenché que si une tâche qui le notify a réellement changé quelque chose — pas à chaque exécution.

Exécution réelle

$ ansible-playbook playbook.yml

TASK [Installer nginx] **********************************
changed: [target]

TASK [Déployer la page d'accueil personnalisée] *********
changed: [target]

TASK [S'assurer que nginx est démarré et activé] ********
changed: [target]

RUNNING HANDLER [Redémarrer nginx] **********************
changed: [target]

PLAY RECAP ***********************************************
target : ok=6  changed=4  unreachable=0  failed=0

Vérification indépendante, directement sur la cible :

$ cat /var/www/html/index.html
<h1>Déployé par Ansible</h1>

$ ss -tlnp
LISTEN  0  511  0.0.0.0:80  users:(("nginx",pid=647,fd=5))

nginx tourne réellement, sert réellement le contenu déployé par le playbook.

Le principe le plus important : l’idempotence

Relancer exactement le même playbook, sans rien changer :

$ ansible-playbook playbook.yml

TASK [Installer nginx] **********************************
ok: [target]

TASK [Déployer la page d'accueil personnalisée] *********
ok: [target]

TASK [S'assurer que nginx est démarré et activé] ********
ok: [target]

PLAY RECAP ***********************************************
target : ok=5  changed=0  unreachable=0  failed=0

changed=0 : aucun handler ne se déclenche, nginx n’est pas inutilement redémarré. C’est la propriété d’idempotence : chaque module Ansible (apt, copy, service…) vérifie d’abord l’état réel de la machine avant d’agir, et ne fait quelque chose que si l’état réel diverge de l’état déclaré. C’est ce qui rend sûr de relancer un playbook en boucle (par exemple, toutes les nuits, pour corriger toute dérive de configuration) sans risquer de redémarrages ou réinstallations inutiles à chaque fois.

Prochaine étape

Module 2 : Ansible avancé — boucles, conditions, faits système