👨‍💻 Projet Docker Swarm pour la Résilience

📌 Objectif

Concevoir et mettre en place un cluster Docker Swarm robuste sur des machines virtuelles Debian. Ce cluster est dédié à la Planification de la Continuité d'Activité (PCA) et à la Reprise d'Activité (PRA) pour garantir la disponibilité des services critiques.

---

🖥️ Environnement

• 4 VMs Debian 13 (console) en réseau local (IP statiques)
• 1 Nœud Manager : Orchestration et répartition des charges (192.168.58.155)
• 2 Nœuds Workers : Exécution des conteneurs applicatifs (192.168.58.156 & 192.168.58.157)
• 1 Serveur NFS : Stockage persistant et hébergement des volumes (192.168.58.158)

---

🚀 Job 01 — Configuration Réseau & Installation Docker

1️⃣ Configuration des IP Statiques

Sur chaque machine, éditer le fichier d'interfaces :

nano /etc/network/interfaces

Exemple pour le Manager (adapter l'adresse pour les autres VMs) :

# Configuration réseau
allow-hotplug ens32
iface ens32 inet static
    address 192.168.58.155
    netmask 255.255.255.0
    gateway 192.168.58.2

Relancer le service réseau :

systemctl restart networking

2️⃣ Changement des noms d'hôtes (Hostnames)

Pour s'y retrouver facilement dans le cluster Swarm :

# Sur le Manager
hostnamectl set-hostname manager
# Sur le Worker 1
hostnamectl set-hostname worker1
# Sur le Worker 2
hostnamectl set-hostname worker2

3️⃣ Installation de Docker (Manager & Workers uniquement)

apt update && apt install curl -y
curl -fsSL [https://get.docker.com](https://get.docker.com) -o get-docker.sh
sh get-docker.sh
systemctl enable --now docker
docker --version

---

🗄️ Job 02 — Stockage Persistant (Serveur NFS)

🎯 Objectif

Transformer la 4ème VM (192.168.58.158) en "disque dur réseau" (PRA) pour héberger les volumes critiques du cluster.

1️⃣ Sur le serveur NFS (IP: .158)

Installation du service :

apt update
apt install nfs-kernel-server -y

Création des dossiers pour les volumes de notre Stack :

mkdir -p /mnt/swarm_nfs/db
mkdir -p /mnt/swarm_nfs/web
mkdir -p /mnt/swarm_nfs/workspace

Gestion des permissions (Ouverture totale pour l'accès des conteneurs Docker) :

chown nobody:nogroup /mnt/swarm_nfs/*
chmod -R 777 /mnt/swarm_nfs/

Déclaration des partages sur le réseau (autoriser le sous-réseau 192.168.58.0/24) :

nano /etc/exports

Ajouter ces lignes à la fin :

/mnt/swarm_nfs/db           192.168.58.0/24(rw,sync,no_subtree_check,no_root_squash)
/mnt/swarm_nfs/web          192.168.58.0/24(rw,sync,no_subtree_check,no_root_squash)
/mnt/swarm_nfs/workspace    192.168.58.0/24(rw,sync,no_subtree_check,no_root_squash)

Application de la configuration :

exportfs -arv
systemctl restart nfs-kernel-server

2️⃣ Sur les clients (Manager, Worker 1, Worker 2)

Installation de l'outil permettant de lire le NFS :

apt update && apt install nfs-common -y

---

🐝 Job 03 — Initialisation du Cluster Docker Swarm

1️⃣ Sur le Nœud Manager

Création du cluster :

docker swarm init --advertise-addr 192.168.58.155

(Copier la commande docker swarm join --token ... générée en retour).

2️⃣ Sur les Nœuds Workers

Rejoindre le cluster en collant la commande récupérée :

docker swarm join --token SWMTCKN-1-... 192.168.58.155:2377

3️⃣ Vérification

Sur le Manager, s'assurer que les 3 nœuds sont présents et "Ready" :

docker node ls

---

🐳 Job 04 — Déploiement des Services (Stack)

🎯 Objectif

Déployer une stack en haute disponibilité avec persistance des données.

1️⃣ Fichier docker-compose.yml

Créer le fichier sur le Manager :

nano docker-compose.yml

2️⃣ Déploiement et vérification

Lancer la stack sur le cluster depuis le Manager :

docker stack deploy -c docker-compose.yml swarm_stack

Suivre le démarrage des conteneurs (attendre que les réplicas soient à 1/1 ou 2/2) :

docker service ls

---

🔥 Job 05 — Procédures de Tests (PCA / PRA)

1️⃣ Validation du fonctionnement normal

Accéder aux services depuis le navigateur (en utilisant l'IP d'un Worker, ex: 192.168.58.156) :

• Serveur Web Nginx : http://192.168.58.156

  

• VSCode Server : http://192.168.58.156:8443 (Mot de passe : admin)

  

2️⃣ Simulation perte d'un conteneur (Auto-guérison)

Pour simuler un crash logiciel, nous avons ciblé un conteneur Nginx sur l'un des nœuds et forcé son arrêt brut :

# Sur le Worker hébergeant Nginx
docker kill 2438176a5895

Résultat : Le Manager Swarm détecte instantanément l'arrêt inattendu (code erreur 137). Il crée automatiquement une nouvelle instance Nginx (Starting puis Running) pour maintenir notre consigne de haute disponibilité (replicas: 2). Le service ne subit qu'une micro-coupure.

---

3️⃣ Vérification PCA (Continuité d'activité)

Pour tester la résilience de l'infrastructure face à une panne matérielle sévère, nous avons simulé une coupure électrique sur le nœud worker1 alors qu'il hébergeait notre base de données critique MariaDB.

# Sur le nœud Worker 1
shutdown now

Résultat : Le Manager détecte la perte complète du nœud. Pour assurer la continuité du service, il réaffecte automatiquement et instantanément la tâche de la base de données vers le nœud survivant (worker2).

---

4️⃣ Vérification PRA (Reprise d'activité)

Le plan de Reprise d'Activité (PRA) repose entièrement sur notre stockage déporté. Lors du basculement (PCA) illustré à l'étape précédente, la nouvelle instance de la base de données créée sur worker2 s'initialise.

Grâce à notre architecture, ce nouveau conteneur va instantanément se reconnecter au volume réseau hébergé sur notre serveur NFS dédié.

Résultat : La base de données redémarre avec l'intégralité de ses données intactes. Le service reprend son fonctionnement normal sans aucune perte d'information, malgré la destruction totale de son serveur d'origine.

---

👨‍💻 Auteur

Alexandre Kegresse
Formation Administrateur d’Infrastructures Sécurisées
La Plateforme – Cannes