AdminII TP8 Docker Swarm & Haute Disponibilité - dudleydehenau/Ephec GitHub Wiki

TP8 : Docker Swarm & Haute Disponibilité

1. Publier une image Docker sur Docker Hub

Avant de pouvoir déployer notre service sur le Swarm, il nous faut une image sur Docker Hub auquel un noeud peut accéder.

1.1. Construction de notre image Docker "de production"

On crée un petit fichier index.html

<!DOCTYPE html>
<html>
<head>
    <title>Mon App Swarm!</title>
</head>
<body>
    <h1>Bienvenue sur mon service Nginx via Docker Swarm!</h1>
    <p>Cette page est servie par une instance Nginx gérée par Swarm.</p>
    <p>Version 1.0</p>
</body>
</html>

qu'on lie à notre Dockerfile

FROM nginx:1.25.4

COPY ./index.html /usr/share/nginx/html/index.html

Et on peut contruire l'image

docker build -t votre_user_dockerhub/mon-app-swarm:1.0 .

Un petit test en local pour vérifier que tout fonctionne comme prévu:

docker run -d -p 8081:80 votre_user_dockerhub/mon-app-swarm:1.0

shot_1748697077

1.2. Publication de l'image sur Docker Hub

Une fois l'image construite et testée on se connecte sur Docker Hub et l'on y push notre image.

docker login

Puis, on pousse notre image :

docker push votre_user_dockerhub/mon-app-swarm:1.0

On a vérifié sur l'interface web de Docker Hub que notre image était bien présente. Pour s'assurer qu'elle était accessible depuis "n'importe où", on l'a testée en la tirant depuis notre second VPS

  1. Mise en place de notre Swarm

2.1. Initialisation du Swarm

Sur notre premier VPS, que nous avons désigné comme manager initial, on lance la commande :

docker swarm init --advertise-addr 192.168.1.200

shot_1748699381

Et on exécute sur les autres vps la commande qui est retournée

docker swarm join --token <TOKEN_RECUPERE> <IP_DU_VPS_MANAGER>:2377

shot_1748699424

Docker info pour vérifier que tout fonctionne : shot_1748699714

2.2. Gestion des Nœuds

docker node ls

shot_1748699765

2.3. Docker Service : Notre application en action !

On a créé notre service web en utilisant l'image poussée précédemment sur Docker Hub. On le réplique deux fois pour qu'il tourne sur nos deux VPS :

docker service create --name mon-web-service -p 8080:80 --replicas 2 votre_user_dockerhub/mon-app-swarm:1.0

Pour voir où tournent nos conteneurs (les "tâches" du service) :

docker service ps mon-web-service

On peut aussi vérifier avec docker ps sur chaque VPS. La publication des ports se fait sur tous les nœuds du Swarm grâce au "routing mesh". On peut donc accéder à notre service via http://192.168.1.200:8080 et http://192.168.1.201:8080.

4.Mise à jour d'un service

Redimentionnement :

docker service scale mon-web-service=3

shot_1748701188

shot_1748701244

Mise a jour de l'image :

Modifié index.html
Reconstruit l'image avec un nouveau tag : ciran0_dockerhub/mon-app-swarm:2.0.
Poussé cette nouvelle version sur Docker Hub. 

    docker service update --image votre_user_dockerhub/mon-app-swarm:2.0 mon-web-service
Swarm effectue une mise à jour progressive (rolling update) évite les interruptions.

shot_1748701768

5.Test de résilience

Que se passe-t-il si un nœud tombe ? On a simulé cela en arrêtant Docker sur l'un de nos VPS (par exemple sudo systemctl stop docker sur swarm-worker01). Le service est resté accessible via l'IP du manager. 3. DNS Round Robin

Round Robin consiste à associer plusieurs adresses IP (celles des différents noeuds de notre swarm) à un même nom de domaine (FQDN) via plusieurs enregistrements DNS de type A. Par exemple :

monservice.l2-6.ephec-ti.be. IN A 192.168.1.200 monservice.l2-6.ephec-ti.be. IN A 192.168.1.201

Lorsqu'un client résout monservice.l2-6.ephec-ti.be., le serveur DNS lui renvoie l'une des IP, distribuant ainsi la charge.

⚠️ **GitHub.com Fallback** ⚠️