Automatiser la gestion de ses serveurs VPS avec Ansible

Pourquoi Ansible pour une flotte de VPS ?

Quand on gère plusieurs serveurs, la tentation naturelle est d'écrire des scripts Bash. C'est rapide à démarrer, mais les scripts ne sont pas idempotents : relancez-les deux fois et vous risquez de dupliquer des entrées, d'écraser des fichiers ou de casser une configuration qui fonctionnait. Fabric améliore l'ergonomie Python mais reste dans la même logique impérative. Puppet et Chef sont des outils puissants, mais ils imposent un agent sur chaque nœud, un serveur maître à maintenir, et une courbe d'apprentissage significative pour une équipe qui veut juste garder ses VPS cohérents. Ansible se positionne différemment. Il fonctionne en mode push, via SSH, sans rien installer sur les hôtes cibles. Chaque playbook décrit un état final plutôt qu'une séquence d'actions. Si vous l'exécutez une seconde fois sur un serveur déjà configuré, Ansible ne modifie rien : c'est la propriété d'idempotence, et elle est fondamentale pour opérer une flotte en confiance. Pour une agence web qui livre des projets sur des VPS clients, ou pour une équipe DevOps qui standardise des environnements de staging et de production, Ansible représente le rapport effort/bénéfice le plus favorable du marché : une syntaxe YAML accessible, une communauté massive, et une intégration naturelle dans les pipelines CI/CD existants.

8 raisons de choisir Ansible pour vos serveurs VPS

Agentless via SSH : aucun daemon à installer sur vos hôtes. Ansible se connecte en SSH avec vos clés existantes, ce qui réduit la surface d'attaque et élimine la dette de maintenance liée aux agents.
Idempotence native : chaque module Ansible garantit que relancer un playbook sur un système déjà configuré ne produit aucun changement parasite. Vous pouvez exécuter vos playbooks en toute sécurité sur une flotte en production.
Syntaxe YAML lisible : les playbooks se lisent comme de la documentation. Un développeur qui ne connaît pas Ansible comprend ce que fait un rôle en quelques minutes, ce qui facilite la revue de code et l'onboarding.
Inventaire dynamique : en plus des fichiers statiques hosts.ini, Ansible peut interroger votre fournisseur cloud ou une API interne pour construire l'inventaire à la volée. Idéal quand les VPS apparaissent et disparaissent fréquemment.
Rôles réutilisables : la structure roles/ permet de packager une configuration (nginx, PostgreSQL, durcissement SSH) et de la réutiliser d'un projet à l'autre sans copier-coller de playbook.
Ansible Vault pour les secrets : les mots de passe, clés API et certificats sont chiffrés directement dans le dépôt Git avec ansible-vault. Fini les secrets en clair dans les scripts ou les variables d'environnement non versionnées.
Ansible Galaxy : un écosystème de rôles communautaires (geerlingguy, devsec) couvre les cas d'usage les plus courants. Plutôt que d'écrire un rôle de durcissement SSH de zéro, vous en importez un audité par des milliers d'utilisateurs.
CI/CD compatible : un playbook s'exécute depuis une pipeline GitHub Actions ou GitLab CI avec exactement la même commande qu'en local. Chaque merge sur main peut déclencher automatiquement le déploiement de la configuration sur votre flotte.

Prérequis : ce dont vous avez besoin avant de commencer

Avant d'écrire votre premier playbook, quelques prérequis sont à vérifier côté machine de contrôle et côté serveurs cibles. Côté machine de contrôle (votre poste local ou un VPS dédié à l'orchestration), vous avez besoin de Python 3.8 ou supérieur et d'Ansible 2.14 minimum. Ansible ne fonctionne pas nativement sur Windows en tant que machine de contrôle : si vous êtes sous Windows, utilisez WSL2 ou un conteneur Docker. Côté serveurs VPS cibles, les prérequis sont minimalistes : un accès SSH avec un utilisateur disposant des droits sudo, Python 3 installé (présent par défaut sur Debian 11+, Ubuntu 20.04+ et Rocky Linux 8+), et votre clé publique SSH déjà déployée sur chaque hôte. Si vous partez de serveurs fraîchement provisionnés, l'accès root initial suffit pour la première passe de configuration. Organisez votre espace de travail dans un dépôt Git dès le départ. Versionner votre inventaire et vos playbooks est la seule façon de savoir quelle configuration a été appliquée à quelle machine, et quand. Un fichier ansible.cfg à la racine du projet permet de centraliser les paramètres (chemin de l'inventaire, utilisateur distant, clé SSH) pour éviter de les répéter sur la ligne de commande.

De l'installation à votre premier playbook en 7 étapes

Installer Ansible sur la machine de contrôle

La méthode recommandée est pip install ansible dans un environnement virtuel Python, ce qui vous donne la dernière version stable indépendamment de votre distribution. Sous Debian/Ubuntu, apt install ansible fonctionne aussi mais installe souvent une version plus ancienne. Vérifiez avec ansible --version que l'installation est correcte et notez le chemin vers la configuration.

Créer l'inventaire avec vos groupes de serveurs

Créez un fichier inventory/hosts.ini et organisez vos VPS en groupes logiques : [web] pour vos serveurs applicatifs, [db] pour les bases de données, [mail] pour les serveurs de messagerie. Chaque hôte est renseigné par son IP ou son nom DNS, avec éventuellement ansible_user=ubuntu si l'utilisateur SSH diffère. Les groupes facilitent l'application de rôles ciblés.

Tester la connectivité avec le module ping

Avant tout playbook, validez que l'inventaire est correct et que SSH fonctionne : ansible -i inventory/hosts.ini all -m ping. Chaque hôte doit répondre pong. Si une machine échoue, vérifiez le nom d'utilisateur, la clé SSH et que Python 3 est disponible sur la cible. Ce test de base vous évite de déboguer un playbook alors que le problème est dans le transport.

Écrire un playbook de durcissement initial

Créez playbooks/hardening.yml avec trois tâches essentielles : créer un utilisateur d'administration non-root avec sa clé publique, modifier sshd_config pour désactiver l'authentification par mot de passe et le login root direct, puis configurer ufw avec une politique par défaut deny et les seuls ports autorisés (22, 80, 443). Utilisez les modules user, lineinfile et ufw d'Ansible.

Lancer en mode dry-run avec --check

Avant d'appliquer le playbook sur vos serveurs, exécutez ansible-playbook --check playbooks/hardening.yml. Le flag --check simule l'exécution sans rien modifier : Ansible vous indique exactement quelles tâches auraient produit un changement (changed) et lesquelles n'auraient rien fait (ok). Corrigez les éventuelles erreurs de syntaxe ou de logique avant l'application réelle.

Appliquer et vérifier l'idempotence

Lancez le playbook sans --check pour l'application réelle. Notez le nombre de tâches changed. Relancez immédiatement une seconde fois : si votre playbook est correctement écrit, le compteur changed doit être à zéro. Cette vérification d'idempotence est le critère de qualité fondamental d'un playbook Ansible. Un playbook qui produit des changements au second run cache un bug de logique.

Refactoriser en rôle réutilisable

Une fois le playbook stabilisé, convertissez-le en rôle avec ansible-galaxy init roles/hardening. Déplacez les tâches dans roles/hardening/tasks/main.yml, les variables par défaut dans defaults/main.yml et les handlers (comme le rechargement de sshd) dans handlers/main.yml. Le rôle devient un bloc réutilisable que vous pouvez appliquer à n'importe quel groupe d'hôtes depuis n'importe quel projet.

Gérer les secrets avec Ansible Vault

Dans une flotte de serveurs, les secrets sont partout : mots de passe de base de données, clés API de services tiers, certificats TLS, jetons d'accès aux registres Docker. La tentation de les stocker en clair dans les fichiers de variables est forte, surtout quand on travaille seul. C'est un risque majeur dès que le dépôt devient partagé ou qu'un développeur quitte l'équipe. Ansible Vault chiffre vos fichiers de variables directement dans le dépôt Git. La commande ansible-vault create vars/secrets.yml ouvre un éditeur et chiffre le résultat avec un mot de passe maître (ou une clé de coffre). Le fichier chiffré est versionnable en toute sécurité : sans le mot de passe, son contenu est illisible. Pour une équipe, il est recommandé d'utiliser un fichier de mot de passe (--vault-password-file ~/.vault_pass) plutôt que de taper le mot de passe à chaque exécution. Ce fichier est stocké hors du dépôt et distribué via un gestionnaire de secrets comme HashiCorp Vault ou votre pipeline CI/CD. GitHub Actions et GitLab CI permettent de stocker le mot de passe Vault en tant que secret d'environnement, ce qui rend l'exécution des playbooks en pipeline aussi simple qu'en local. Une bonne pratique : séparez vos variables en deux fichiers — vars/main.yml pour les valeurs non sensibles (noms de domaines, ports, versions) et vars/secrets.yml chiffré pour les secrets. Vos playbooks lisent les deux, et seul secrets.yml nécessite le Vault.

Si certains de vos VPS sont derrière un NAT strict ou un pare-feu qui bloque les connexions SSH entrantes depuis votre machine de contrôle, le mode push d'Ansible ne fonctionne pas. La solution est ansible-pull : installez Ansible sur chaque hôte cible, configurez un cron ou un timer systemd qui exécute ansible-pull -U <url-du-dépôt> à intervalles réguliers. Chaque serveur tire lui-même sa configuration depuis Git et l'applique localement. C'est l'inverse du mode habituel, mais l'idempotence et les rôles fonctionnent exactement de la même façon. Utile aussi pour des environnements air-gapped où seul le serveur a accès au dépôt interne.

Aller plus loin : inventaire dynamique et AWX

Un inventaire statique hosts.ini convient parfaitement pour une flotte stable. Mais si vous provisionnez et détruisez des VPS fréquemment — pour des environnements de staging éphémères ou des projets clients à durée limitée — maintenir le fichier à la main devient une source d'erreurs. L'inventaire dynamique résout ce problème : Ansible peut interroger une API (votre fournisseur cloud, Netbox, un script personnalisé) pour construire la liste des hôtes à la volée avant chaque exécution. Le plugin community.general.cobbler ou un script Python qui retourne du JSON structuré suffisent dans la plupart des cas. Pour les équipes qui veulent une interface graphique et un contrôle d'accès par rôle, AWX (la version open source de Red Hat Ansible Automation Platform) ou Semaphore (plus léger, adapté aux petites équipes) offrent une UI web pour gérer les inventaires, déclencher des playbooks, planifier des runs et auditer les exécutions passées. AWX s'installe sur un VPS dédié et expose une API REST : vous pouvez déclencher un playbook depuis une pipeline CI, depuis un webhook ou depuis un bouton dans votre outil interne. L'adoption de ces outils marque la transition d'une administration Ansible personnelle vers une pratique d'équipe structurée, où chaque exécution est tracée, approuvée et associée à un utilisateur identifié.

Conclusion : une infrastructure déclarative et reproductible

Ansible n'est pas un outil magique, mais il répond précisément au problème quotidien de toute équipe qui administre plusieurs VPS : comment s'assurer que l'état réel de chaque serveur correspond à ce qui était prévu, sans passer des heures à comparer des configurations manuellement ? En adoptant une approche déclarative — décrire ce que vous voulez plutôt que comment l'obtenir — vous gagnez en reproductibilité, en traçabilité et en confiance. Un nouveau collaborateur peut comprendre l'état de votre infra en lisant les playbooks. Un serveur qui tombe peut être reconstruit depuis zéro en quelques minutes avec le même inventaire. Un audit de sécurité devient une lecture de YAML plutôt qu'une inspection machine par machine. Commencez petit : un playbook de durcissement initial appliqué à vos VPS existants. Versionnez-le, testez l'idempotence, puis ajoutez des rôles au fil des besoins. L'investissement initial est modeste, et les gains en temps et en fiabilité deviennent évidents dès la deuxième ou troisième machine gérée.