Déploiement automatisé d'une architecture web trois tiers

Projet en bref

Contexte

Ce projet consistait à préparer l’infrastructure d’un site dynamique en séparant ses responsabilités techniques. L’application, la base de données et la résolution DNS devaient fonctionner sur trois serveurs distincts, tout en communiquant sur un réseau privé.

J’ai choisi de modéliser ce laboratoire avec Vagrant et VirtualBox. Les machines et leurs configurations peuvent ainsi être reconstruites à partir des fichiers du dépôt, sans répéter manuellement chaque installation.

Objectifs techniques

• Déployer trois serveurs Linux avec des rôles spécialisés ;
• automatiser l’installation et la configuration de chaque service ;
• publier une application PHP avec un virtual host Apache ;
• permettre à l’application de joindre MySQL par un nom DNS interne ;
• documenter les composants, les dépendances et les flux réseau.

Architecture retenue

flowchart LR
    CLIENT["Poste utilisateur"]

    subgraph LAB["Réseau privé — 192.168.10.0/24"]
        DNS["DNS<br/>BIND 9<br/>192.168.10.30"]
        WEB["Web<br/>Apache + PHP<br/>192.168.10.10"]
        DB["Données<br/>MySQL 8<br/>192.168.10.20"]
    end

    CLIENT -->|"Résolution DNS<br/>UDP/TCP 53"| DNS
    CLIENT -->|"Consultation du site<br/>HTTP 80"| WEB
    WEB -->|"Résolution du nom de la base<br/>UDP/TCP 53"| DNS
    WEB -->|"Requêtes applicatives<br/>TCP 3306"| DB

    style DNS fill:#eff6ff,stroke:#2563eb
    style WEB fill:#fff7ed,stroke:#ea580c
    style DB fill:#ecfdf5,stroke:#059669

Le lancement du serveur Web déclenche celui de la base de données, qui déclenche à son tour celui du DNS. L’environnement est donc construit dans l’ordre DNS → base de données → Web.

Travaux réalisés

Infrastructure

• Définition des trois machines virtuelles dans un Vagrantfile ;
• attribution d’adresses IP privées fixes et de noms d’hôte dédiés ;
• dimensionnement des ressources selon le rôle de chaque serveur ;
• orchestration de l’ordre de démarrage entre les machines.

Service DNS

• Installation automatisée de BIND 9 ;
• création d’une zone directe pour les services DNS, Web et MySQL ;
• création de la zone inverse du réseau privé ;
• configuration des serveurs applicatifs pour utiliser le résolveur interne.

Service Web

• Installation d’Apache, PHP et du connecteur PHP pour MySQL ;
• activation du module Apache rewrite ;
• déploiement automatisé des sources de l’application ;
• configuration du virtual host et des paramètres de connexion à MySQL.

Base de données

• installation et configuration de MySQL ;
• création de la base de données et du compte applicatif ;
• écoute du service sur le réseau du laboratoire ;
• import automatique du schéma et du jeu de données initial.

Exploitation

• Mise en place d’un déploiement complet avec une commande unique ;
• définition de contrôles pour la résolution DNS et la réponse HTTP ;
• documentation des flux, des ports et des commandes d’administration ;
• identification des écarts de sécurité à corriger avant une mise en production.

Difficultés et choix techniques

Orchestrer les dépendances entre serveurs

Problème — Démarrage de services interdépendants

Le serveur Web dépend de la résolution DNS et de la base de données, mais un lancement indépendant des VM ne garantit pas que ces services soient déjà disponibles.

Solution et résultat : des triggers Vagrant chaînent le démarrage des machines. Une seule commande construit les trois serveurs dans l’ordre requis et réduit les opérations manuelles.

Résoudre le serveur MySQL par son nom

Problème — Dépendance à une adresse IP codée en dur

L’application devait contacter la base par un nom DNS afin de dissocier sa configuration de l’adresse du serveur.

Solution et résultat : la zone BIND contient un enregistrement dédié à MySQL, et les serveurs utilisent le résolveur interne. L’application peut joindre la base avec son nom de domaine sur le réseau privé.

Rendre le provisionnement reproductible

Problème — Multiplication des configurations manuelles

L’installation de plusieurs services sur des machines distinctes augmente le risque d’oubli et d’écart entre deux déploiements.

Solution et résultat : chaque rôle dispose de son script Bash. L’installation des paquets, la génération des configurations et l’import des données sont exécutés automatiquement par Vagrant.

Résultats

L’environnement obtenu est décrit comme du code, reconstruit de manière cohérente et documenté pour son exploitation. Le serveur Web résout le nom de la base via le DNS interne, accède aux données importées et publie l’application sur le réseau du laboratoire.

Compétences démontrées

• Administration d’Ubuntu Server ;
• conception d’une architecture Web distribuée ;
• virtualisation avec VirtualBox ;
• automatisation d’infrastructure avec Vagrant et Bash ;
• configuration de BIND, Apache, PHP et MySQL ;
• gestion des zones DNS directe et inverse ;
• analyse des flux DNS, HTTP et MySQL ;
• diagnostic de dépendances entre services ;
• rédaction de documentation technique reproductible.

Retour d’expérience

Ce projet m’a permis de mieux comprendre les dépendances d’une application Web distribuée, notamment le rôle du DNS dans les communications entre services. Il m’a également appris à transformer une suite d’installations manuelles en un environnement cohérent, reproductible et documenté.

Avec davantage de temps, je limiterais le compte MySQL aux seules opérations nécessaires, j’externaliserais les secrets et j’ajouterais des tests automatisés de disponibilité. La mise en place de HTTPS, d’un filtrage réseau entre les tiers et d’une intégration continue renforcerait également la solution.