Contexte
Ce projet consistait à préparer l’infrastructure d’un site web pour une petite entreprise. Afin de séparer les responsabilités et de faciliter l’exploitation, les services web, base de données et DNS devaient fonctionner sur trois serveurs distincts.
J’ai retenu une infrastructure locale virtualisée et automatisée. Cette approche permet de reconstruire l’environnement à partir des fichiers du projet, sans configurer manuellement chaque serveur.
Objectifs techniques
- déployer trois machines Linux avec des rôles distincts ;
- automatiser l’installation et la configuration des services ;
- publier l’application derrière un virtual host Apache ;
- permettre à l’application de résoudre et joindre le serveur MySQL ;
- documenter l’architecture, ses flux et sa procédure de déploiement.
Architecture retenue
flowchart LR
CLIENT[Poste client]
DNS["Serveur DNS<br/>BIND 9<br/>192.168.10.30"]
WEB["Serveur Web<br/>Apache + PHP<br/>192.168.10.10"]
DB["Serveur de données<br/>MySQL<br/>192.168.10.20"]
CLIENT -->|"DNS — UDP/TCP 53"| DNS
CLIENT -->|"HTTP — TCP 80"| WEB
WEB -->|"DNS — UDP/TCP 53"| DNS
WEB -->|"MySQL — TCP 3306"| DB
| Composant | Rôle | Technologie | Adresse |
|---|---|---|---|
| Serveur Web | Hébergement de l’application | Apache et PHP | 192.168.10.10 |
| Serveur de données | Stockage des données applicatives | MySQL | 192.168.10.20 |
| Serveur DNS | Résolution directe et inverse | BIND 9 | 192.168.10.30 |
Les machines utilisent un réseau privé VirtualBox. Vagrant orchestre leur démarrage dans l’ordre DNS, base de données, puis serveur Web afin de respecter les dépendances entre les services.
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 avec les triggers Vagrant.
DNS
- installation automatisée de BIND 9 ;
- création d’une zone directe pour les services web, base de données et DNS ;
- création de la zone inverse associée au réseau privé ;
- configuration des serveurs applicatifs pour interroger le DNS 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 ;
- création du virtual host et du fichier de connexion à la base de données.
Base de données
- installation et configuration de MySQL ;
- création de la base applicative et d’un compte d’exploitation ;
- autorisation des connexions depuis le réseau de laboratoire ;
- import automatisé du schéma et des données initiales.
Exploitation
- ajout de commandes de contrôle pour la résolution DNS et le service HTTP ;
- documentation des procédures de déploiement, d’arrêt, de reprovisionnement et de suppression de l’environnement ;
- description des flux, ports et dépendances techniques.
Points techniques rencontrés
Orchestration des dépendances
Problème : le serveur Web dépend du DNS interne et de la base de données lors de son fonctionnement.
Analyse : un démarrage indépendant des machines ne garantit pas que les services nécessaires soient déjà créés et configurés.
Solution : ajout de triggers Vagrant pour démarrer les VM dans l’ordre DNS → base de données → Web.
Résultat : une seule commande lance la création et le provisionnement de l’ensemble de l’architecture dans l’ordre attendu.
Résolution du serveur de données
Problème : l’application doit joindre MySQL par son nom DNS plutôt que par une adresse codée en dur.
Analyse : les serveurs doivent utiliser le résolveur interne et la zone DNS doit contenir un enregistrement pour la base de données.
Solution : configuration de BIND, ajout de l’enregistrement correspondant et
paramétrage de systemd-resolved sur les VM applicatives.
Résultat : le serveur Web peut résoudre le nom du serveur MySQL sur le réseau privé.
Résultats
- trois machines virtuelles spécialisées sont décrites comme du code ;
- les services DNS, HTTP/PHP et MySQL sont installés automatiquement ;
- le schéma et les données applicatives sont importés pendant le provisionnement ;
- l’application utilise le DNS interne pour accéder à la base de données ;
- le déploiement complet est déclenché par une commande Vagrant unique ;
- les procédures d’utilisation et de vérification sont documentées.
Compétences démontrées
- administration et configuration de services Linux ;
- conception d’une architecture réseau trois tiers ;
- automatisation d’infrastructure avec Vagrant et Bash ;
- configuration de BIND, Apache, PHP et MySQL ;
- compréhension des flux DNS, HTTP et MySQL ;
- diagnostic des dépendances entre services ;
- rédaction d’une documentation technique reproductible.
Retour d’expérience
Ce projet m’a permis de mieux comprendre les dépendances d’une application web distribuée, notammen le rôle central du DNS et l’importance de l’ordre de provisionnement.
Il m’a également appris à transformer une installation manuelle en environnement reproductible et documenté.
Pour aller plus loin, je limiterais le compte applicatif aux seuls droits CRUD, j’externaliserais les secrets actuellement présents dans les scripts et j’ajouterais des tests automatisés de disponibilité.
Une évolution vers HTTPS, un filtrage réseau entre les tiers et une intégration continue renforcerait également la solution.