Noah LamontMe contacter
Retour aux projets
2024·DevOps·Projet école — équipe 3

Architecture distribuée avec Ansible

Déploiement automatisé d'une app multi-services (Redis + Postgres + Poll + Worker + Result) sur 5 VMs Linux bare-metal — sans Docker, idempotent et reproductible.

AnsibleLinuxPostgreSQLRedisUTM
Architecture distribuée avec Ansible
Architecture distribuée avec Ansible · case study
01

Contexte

Projet Epitech, équipe de 3 — orchestration automatisée d'une application distribuée microservices sur 5 VMs Linux dédiées, en bare-metal (sans conteneurs). Système de vote temps réel avec cache, persistance, traitement asynchrone et frontend.

02

Problème

Configurer 5 machines distinctes à la main, chacune avec son rôle et ses dépendances réseau, sans erreurs ni divergence entre environnements : long, répétitif, et impossible à rejouer fidèlement la semaine suivante.

03

Solution

Playbooks Ansible idempotents qui provisionnent l'ensemble en quelques minutes : Redis (cache), PostgreSQL (data avec users/grants), Poll (collecte de votes), Worker (traitement asynchrone), Result (API + frontend). Tout en natif — systemd, networking, firewall, secrets — sans aucun conteneur.

04

Défis techniques

Défi 1

Idempotence stricte des playbooks

On doit pouvoir rejouer le déploiement à blanc, ou sur un état partiellement déployé, et toujours obtenir la même configuration finale. Chaque tâche conçue pour être convergente, pas répétitive.

Défi 2

Ordre de déploiement et dépendances inter-services

Les workers attendent le cache, le frontend attend l'API, l'API attend la base : graphe de dépendances explicite dans l'inventaire et les rôles, avec gestion propre des secrets et des variables d'environnement entre VMs.

Défi 3

Bare-metal sans containers

Tout ce que Docker masque normalement — systemd, networking inter-VM, règles firewall, packages système — passe ici en clair dans les playbooks. Plus exigeant, mais c'est précisément l'objectif pédagogique : comprendre ce qu'on automatise.

05

Apprentissages

  • Sans conteneurs, on apprend ce que Docker fait pour nous — précieux pour débugger le jour où la magie se casse.
  • L'idempotence n'est pas un détail : c'est ce qui rend l'IaC réellement fiable, pas juste pratique.
  • Entre « ça marche » et « ça se rejoue à blanc dans 6 mois », il y a un gouffre que seule l'automation honnête comble.