This project has been created as part of the 42 curriculum by raphalme.

42 Inception

Description

Le but de ce projet est de s'initier à l'administration système et à la virtualisation via Docker. Il consiste à mettre en place une infrastructure complète composée de plusieurs services interconnectés, où chaque service tourne dans son propre conteneur dédié.

L'architecture est composée de :

• Mandatory part (Partie Obligatoire) :
  • Un serveur web NGINX (TLS v1.2/v1.3 uniquement).
  • Une base de données MariaDB.
  • Un site WordPress (via PHP-FPM).
• Bonus part :
  • Un cache Redis pour WordPress.
  • Un serveur FTP.
  • Un site statique simple.
  • Une interface de gestion de base de données (Adminer).
  • Un service de monitoring ou autre service utile (Dashboard/Filebrowser).

Instructions

Prérequis

• Docker
• Docker Compose
• Make

Installation et Exécution

Cloner le dépôt et se rendre dans le dossier racine.

Pour lancer la partie obligatoire :

cd mandatory
make

Pour lancer la partie bonus :

cd bonus
make

Pour arrêter et nettoyer les conteneurs :

make down
# ou pour tout nettoyer (volumes inclus)
make fclean

Description du Projet

Ce projet utilise Docker pour créer un environnement isolé et reproductible. Chaque service est défini par son propre Dockerfile et l'ensemble est orchestré via docker-compose.yml. Cela permet de garantir que l'application fonctionne de la même manière quel que soit l'environnement hôte.

Choix techniques

• Alpine Linux / Debian : Images de base légères (Alpine) ou stables (Debian Buster/Bullseye) pour minimiser l'empreinte et la surface d'attaque.
• Docker Compose : Utilisé pour orchestrer le démarrage des conteneurs et la création des réseaux/volumes.

Comparaisons et Concepts

Virtual Machines vs Docker

Caractéristique	Machine Virtuelle (VM)	Docker (Conteneurs)
Isolation	Isolation complète (OS complet invité)	Isolation des processus (partage du noyau hôte)
Ressources	Lourdes (CPU/RAM dédiés à l'OS invité)	Légères
Démarrage	Lent (boot de l'OS)	Rapide (démarrage de processus)
Portabilité	Dépend de l'hyperviseur	Haute portabilité (partout où Docker tourne)

Les conteneurs sont préférés ici pour leur légèreté et la facilité de déploiement de micro-services.

Secrets vs Variables d'Environnement

• Variables d'Environnement : Pratiques pour la configuration non sensible, mais visibles via docker inspect.
• Secrets (Docker Secrets) : Mécanisme sécurisé pour gérer les données sensibles (mots de passe, clés SSH) qui ne sont montés qu'au moment de l'exécution dans /run/secrets. Dans ce projet, nous utilisons un fichier .env pour simuler la gestion des secrets, bien que les Docker Secrets soient recommandés pour la production en mode Swarm.

Docker Network vs Host Network

• Docker Network (Bridge) : Crée un réseau virtuel isolé pour les conteneurs. Ils peuvent communiquer entre eux par nom de service, mais sont isolés du réseau extérieur sauf ports exposés. C'est le mode par défaut et sécurisé.
• Host Network : Le conteneur partage la stack réseau de l'hôte. Pas d'isolation réseau, performances natives, mais risques de conflits de ports.

Docker Volumes vs Bind Mounts

• Docker Volumes : Gérés par Docker (dans /var/lib/docker/volumes/). Indépendants de la structure de fichiers de l'hôte, plus faciles à sauvegarder/migrer, et fonctionnent sur tout OS.
• Bind Mounts : Lient un fichier ou dossier spécifique de l'hôte vers le conteneur. Dépendent de l'OS et du chemin absolu de l'hôte. Utiles pour le développement (partage de code source). Dans ce projet, nous utilisons des Volumes nommés pour la persistance des données (MariaDB, WordPress).

Ressources

Références

• Documentation Docker Officielle
• Documentation NGINX
• Documentation WordPress

Utilisation de l'IA

L'intelligence artificielle (notamment les LLM comme gemini/Copilot) a été utilisée pour :

• Rédaction : Aide à la structuration de ce fichier README.