École 42 · 100/100
Inception
Une infrastructure conteneurisée construite de zéro : NGINX, WordPress et MariaDB, chacun dans son propre conteneur Docker, sans image préconstruite.
Inception est le projet d'administration système du cursus 42 : construire une infrastructure conteneurisée à partir de Dockerfiles écrits soi-même, sans image Docker Hub préconstruite (seule l'image de base du système est autorisée). Pour être validé, chaque service doit tourner dans son propre conteneur avec un vrai processus au premier plan, redémarrer proprement après un crash, et toute la stack doit se reconstruire de zéro à la demande, en soutenance, sans intervention manuelle.
Architecture
Trois services communiquent sur un réseau Docker dédié, mais un seul est joignable de l'extérieur : NGINX expose uniquement le port 443 et fait office de point d'entrée TLS. WordPress tourne en PHP-FPM derrière lui, et MariaDB reste accessible uniquement en interne.
Les données de la base et les fichiers WordPress sont persistés sur deux volumes montés sur l'hôte, en dehors du réseau Docker, pour survivre à un arrêt complet de la stack.
Automatisation TLS
NGINX génère son propre certificat auto-signé au moment de la construction de l'image, limité à TLS 1.2/1.3 avec une liste de chiffrements restreinte, et vérifie la validité de sa configuration avant de démarrer.
Installation WordPress
Le conteneur WordPress installe l'application au premier démarrage de façon entièrement automatisée avec wp-cli : téléchargement du cœur, attente active de la disponibilité de la base de données, configuration, création d'un compte administrateur et d'un second utilisateur, sans intervention manuelle.
Une limite assumée
Le dépôt contient un dossier secrets destiné à Docker Secrets, mais il n'est pas encore branché dans la configuration : les identifiants transitent aujourd'hui par un fichier .env en clair. C'est une amélioration identifiée plutôt qu'un point aveugle, et la prochaine étape naturelle du projet.
Ce que ça m'apporte aujourd'hui
Avoir construit cette infrastructure Dockerfile par Dockerfile, plutôt que de lancer des images toutes faites, est exactement l'instinct qui m'a poussé à gérer l'infrastructure de ce site en Terraform plutôt qu'à la main dans la console AWS : comprendre ce qui tourne réellement, pas juste l'utiliser en boîte noire. C'est aussi directement utile chez Fair3, où Docker et S3 font partie de la stack au quotidien : docker-compose n'est plus une abstraction magique.
Ça a aussi construit un vrai réflexe de réduction de surface d'attaque : n'exposer qu'un seul point d'entrée (NGINX) et garder la base de données strictement interne n'est pas qu'un détail de configuration, c'est la première question à se poser sur n'importe quelle infrastructure. Et avoir identifié moi-même la limite du .env en clair plutôt que de la découvrir en audit m'a appris à chercher activement ce genre de faille, pas seulement à la corriger quand on me la signale.