Skip to content
Shi edited this page Apr 13, 2025 · 4 revisions

TP8 : Docker Swarm & High availability

1. Publier une image Docker sur dockerHub

Documentez brièvement l'image que vous avez conçue et publiée sur le Docker Hub, ainsi que les vérifications effectuées pour valider son fonctionnement.

Tout d'abord, nous avons créé un Dockerfile basique avec la configuration suivante:

FROM nginx:1.25.4

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

Le fichier index.html :

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>WoodyToys Swarm Gang🐝</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

</head>
<body style="text-align:center; font-family:sans-serif;">
    <h1>🔥 Hello from Swarm-ready Web Server 🔥</h1>
    <p>Made with love by the l1-7 hive. Bzzzzzz🐝</p>
</body>
</html>

Puis nous avons build l'image avec la commande

docker build -t goatuser17/woodytoys-web:v1 .

Enfin nous avons créer un conteneur avec la commande docker run --rm --name woodytoys -d -p 8080:80 goatuser17/woodytoys-web:v1, et constater qu'il est bien accessible sur l'adresse http://www.l1-7.ephec-ti.be:8080/.

Une fois le compte docker créé, nous avons utilisé la commande docker login <username> et entré le mot de passe, puis nous avons publié l'image sur le Docker Hub avec la commande docker push goatuser17/woodytoys-web:v1.

Sur Docker Hub:

Sur une machine en local, on a testé également le bon fonctionnement de l'image:

2. Mise en place de votre Swarm

Documentez ce que vous avez mis en place pour obtenir votre Swarm. En particulier, faites, pour chaque configuration testée, un schéma qui représente votre service avec les différents noeuds du swarm, leurs rôles respectifs et les containers qu'ils font tourner. Notez, après chaque manipulation, vos observations et les conclusions que vous en tirez.

Mise en place du Swarm

Sur le VPS principal, qui a main-manager pour hostname, nous avons exécuté la commande docker swarm init, celle-ci créé le cluster, initialisé le node comme 'manager' et fourni le token pour les 'workers'.

Suite à cela, nous avons exécuté la commande docker info et regardé la partie Swarm:

Swarm: active
  NodeID: 00df17ej56jnwvx2fps2hqpoq
  Is Manager: true
  ClusterID: 2af11tamjbifs48roetsmkvrl
  Managers: 1
  Nodes: 3
  Data Path Port: Y
  Orchestration:
   Task History Retention Limit: 5

Les ports X et Y on été overts sur le VPS principal sur aux commandes sudo ufw allow Y/tcp et sudo ufw allow X/tcp.

Nous avons ensuite exécuté la commande docker node ls:

ID                            HOSTNAME         STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
asgm2wa3kkhovux4atvtyhng4     docker-desktop   Down      Active                          27.5.1
00df17ej56jnwvx2fps2hqpoq *   main-manager     Ready     Active         Leader           28.0.4
5jq1in53v02ikg5pk9g8uoq0e     vps-959192a6     Ready     Active                          28.0.4

Celle-ci montre les informations clés de tous les noeuds, notamment leur statut, leur disponibilité et leur role.

Réponses aux questions

  • Comment changer le type d'un node?

Pour changer le type d'un d'un node, on utilise docker node promote node1 nodeN ou docker node demote node1 nodeN pour la gestion rapide des types ou docker node update --[role, avilability, etc.] node1 pour une gestion plus avancée.

  • Quelles commandes docker node sont disponibles, et lesquelles pourraient vous être utiles ?

Celles qui seront le plus utiles à notre avis sont docker node ls pour un aperçu rapide des nodes, docker node ps pour voir les tâches en cours, docker node inspect pour voir les informations sur un node en particulier et docker node update pour modifier certains paramètres d'un node.

  • Après avoir lancé pour la première fois votre service, sur quels nodes ce service est-il exécuté? Comment avez-vous obtenu la réponse ?

Le service est exécuté sur les 2 nodes avec le status Ready, soit le node main-manager et le node vps-959192a6. Nous avons obtenu cette information en exécutant la commande docker service ps <service_name>.

  • Le service a été lancé sur un port spécifique. Sur quel(s) VPS ce port est-il ouvert ?

Le service a été lancé sur le port 8080 en écoutant le port 80 du services web et il est ouvert sur tout les nodes du Swarm. Avec un docker service ls, on peut le voir grâce wildcard *:8080->80/tcp.

ID             NAME       MODE         REPLICAS   IMAGE                         PORTS
ivkn5newfmg1   woodyweb   replicated   2/2        goatuser17/woodytoys-web:v1   *:8080->80/tcp
  • Que se passe-t'il si vous stoppez un node ? Et si vous aviez 'scalé' votre service à un seul replica et que vous stoppez le node sur lequel il tourne ?

Quand un on stoppe un node, il devient Down et le service continue de tourner sur les autres nodes Ready.

docker service ls:

ID                            HOSTNAME         STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
asgm2wa3kkhovux4atvtyhng4     docker-desktop   Down      Active                          27.5.1
00df17ej56jnwvx2fps2hqpoq *   main-manager     Ready     Active         Leader           28.0.4
5jq1in53v02ikg5pk9g8uoq0e     vps-959192a6     Down      Active                          28.0.4

vps-959192a6 est le node qui a été stoppé.

Une vision plus détaillée avec docker service ps woodyweb:

ID             NAME             IMAGE                         NODE           DESIRED STATE   CURRENT STATE            ERROR     PORTS
gz9dc5p7vhir   woodyweb.1       goatuser17/woodytoys-web:v1   main-manager   Running         Running 26 minutes ago     
nxt6ct3i10rs   woodyweb.2       goatuser17/woodytoys-web:v1   main-manager   Running         Running 5 minutes ago      
yhgi64uviv4y    \_ woodyweb.2   goatuser17/woodytoys-web:v1   vps-959192a6   Shutdown        Running 26 minutes ago     

Le service est toujours en cours d'exécution sur le node main-manager et le node vps-959192a6 est en état de Shutdown.

Si on avait 'scalé' le service à un seul replica et que le node sur lequel il tourne est stoppé, le service ne serait plus accessible car il n'y aurait plus de replica en cours d'exécution. Après un certain temps, le service serait redémarré sur un autre node Ready.

3. DNS Round robin

Documentez la mise en oeuvre du Round Robin DNS, et montrez qu'il fonctionne en documentant les commandes ou manipulations de validation.

Nous avons commencé par ajouter les lignes suivantes dans le fichier l1-7.zone du DNS:

web.l1-7.ephec-ti.be.   IN A   54.36.181.82 ; VPS Main
web.l1-7.ephec-ti.be.   IN A   54.36.182.1  ; VPS 2

Donc les enregistrements de type A qui pointent vers chaque noeuds du Swarm.

Puis nous avons rebuild le dns avec la commande docker compose down dns-l1-7 && docker compose up -d dns-l1-7. Nous avons ensuite vérifié que les enregistrements étaient bien pris en compte avec la commande for i in {1..5}; do dig +short web.l1-7.ephec-ti.be; echo "-----"; done.

En effectuant la commande à plusieurs reprises, nous avons pu constater que l'adresse IP retournée changeait à certains instants, ce qui prouve que le Round Robin DNS fonctionne.

Nous avons également testé l'accès au service via la commande curl http://web.l1-7.ephec-ti.be:8080/ et nous avons pu accéder au service sans problème.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>WoodyToys Swarm Gang🐝</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

</head>
<body style="text-align:center; font-family:sans-serif;">
    <h1>🔥 Hello from Swarm-ready Web Server 🔥</h1>
    <p>Made with love by the l1-7 hive. Bzzzzzz🐝</p>
</body>
</html>

4. Pour aller plus loin

Documentez vos recherches, manipulations et conclusions sur les trois points d'approfondissement proposés si vous les avez réalisés.

4.1. Sécurité

4.2. Configuration (et secrets)

4.3 Woodytoys

Clone this wiki locally