Aller au contenu

Proxy

Table des matières

I. Recherches des solutions disponibles II. Configuration du réseau local III. Installation de docker sur les machines IV. Création des containers

I. Recherches des solutions disponibles

Pour permettre la redondance de notre service web nous allons mètre en place un reverse proxy NGINX qui va pouvoir gérer la charge du site et sa redondance.

  • Chaque "node" sera munie de debian 11 avec un container HTTPD (Docker)
  • Pour la synchronisation des fichiers ressources,ils seront donc hébergés sur le manager et déployer par le billet de RSYNC au "node"
Type Image Nombre de backup
Manager https://hub.docker.com/_/nginx 0
Node https://hub.docker.com/_/httpd 2

II. Configuration du réseau local

Pour créer un environnement dedié, notre système de clustering, nous avons eu l'ambition d'utiliser un routeur "CISCO 1800 serie" qui donnerais un sous-réseau 192.168.1.0/24. - Câble rouge : 2 nodes (Ordinateurs portables) - Câble vert : Uplink du réseau 10.0.4.0/19 - Autre câble : PC portable client

image routeur

La plage IP dans le sous réseau :

- Network: 192.168.1.0
- Mask: 255.255.255.0
- IP Node: 192.168.1.101

Le service web final sera accessible de l'extèrieur grâce au NAT.

L'interface Fastethernet 0 sera configurer avec l'ip 10.0.4.6/16. 

interface FastEthernet 0
ip address 10.0.4.6 255.255.229.0
no sh

Le routeur étant un routeur layer 3 nous pouvons gérer les VLANs, ici je vais définir le sous-réseau sur tous les ports du routeur/switch (1 - 8). 

interface vlan 1
ip address 192.168.1.1 255.255.255.0

Test de ping de la passerelle : 

ping 10.0.0.253

Ajout de la passerelle par default pour connaitre d'autre réseau (Internet 👌): 

ip route 0.0.0.0 0.0.0.0 10.0.0.253

Test de ping d'une ip externe et de la passerelle :

image routeur

LES SOUCIS!!

Bon... Au moment de la création du NAT plusieurs soucis sont apparue.

  • Le NAT doit être dynamique et non static pour laisser passer n'importe quelle IP du réseau 192.168.1.0/24
  • Le réseau 10.0.4.0/19 déconnecter 😐 (On vous pardonne.)

Au début,rien ne fonctionnait... nous avons donc procédé par étapes - Accès au réseau de la salle sur le routeur [OK] - Création d'un NAT static sur une seul IP [OK]

Et oui ça fonctionne ! Maintenant on va le faire en dynamique...

Spécifier à l'interface FastEthernet 0 de sa position dans le NAT (ici externe) 

interface FastEthernet0
ip nat outside

Même procédé pour l'interface Vlan 1 

interface vlan 1
ip nat inside

On configure le NAT dans la list ACL 2, overload permet le nattage dynamique et on accepte le réseau 192.168.1.0/24 a passer à travers 

ip nat inside source list 2 interface FastEthernet0 overload
access-list 2 permit 192.168.1.0 0.0.0.255

Redirection du port de la machine 192.168.1.100 sur le port du routeur 

ip nat inside source static tcp 192.168.1.100 80 10.0.4.6 80 extendable

III. Installation de docker sur les machines

Pour obtenir la dernière version de docker, il est important d'utiliser le dépôt de docker (apt ne donnera pas la dernière version de Docker) 

#Mise a jour des dépots actuelle
sudo apt-get update

#Installation des packages pour l'installation
sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

#Création d'un dossier pour la clé d'accès du dépot
sudo mkdir -p /etc/apt/keyrings

#Téléchargement de la clé
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

#Ajout de la source apt dans le fichier sources.list
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

#Mise a jour des dépots
sudo apt-get update

#Installation du daemon docker et de docker-compose (création de docker par fichier)
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
Doc: https://docs.docker.com/engine/install/ubuntu/

IV. Création des containers

Deux nodes seront avec un container HTTPD et le manager avec un NGINX. Une image est disponible sur le site "Docker HUB" : - https://hub.docker.com//httpd - https://hub.docker.com//nginx

  1. Installation de l’image de HTTPD sur les nodes:

Pour installer l’image 

docker pull httpd

Pour démarrer un container avec l’image HTTPD 

docker run -dit -restart always -v /http/:/user/local/apache2/htdocs/ --name httpd -p 80:80 httpd

Argument Explication
-d détacher : Exécuter le conteneur en arrière-plan et imprimer l'ID du container
-i interagir : Gardez STDIN ouvert même s'il n'est pas attaché
-t Allocate a pseudo-TTY
-restart always le container redémarre tout le temp si le pc node ou s’il y a des erreurs.
-v /http/:/user/local/apache2/htdocs/ Sert a redirigé le dossier www d’apache vers le node.
--name httpd Nom du container
-p 80 :80 Assigné le port du node à la machine.

Source : - https://docs.docker.com/engine/reference/commandline/run/ - https://hub.docker.com/_/httpd/

Démarrage du container :

Status du container :

  1. Explication et création du NGINX Proxy Pour permettre une redondance, nous avons configuré un serveur NGINX Proxy qui va lui afficher l'un des deux sites. En quelque explication, le serveur NGINX va faire une demander au sous serveur HTTPD sur les deux nodes et regarder si il sont en ligne.

Si oui alors il va rediriger le client sur le site le moins surchargé. On appelle cela du load-balancing! Bien sûr,il sera aussi sous Docker.

Lancement de l'image nginx : 

docker run -dit --restart always -v /nginx/nginx.conf:/etc/nginx/nginx.conf --name Nginx nginx

La configuration nginx va se situer dans le dossier /nginx de la machine physique.

  1. Configuration du proxy!

Le fichier de configuration est situé dans /nginx/conf.d/ 

  upstream server {
    server 192.168.1.101 weight=5;
    server 192.168.1.102 max_fails=3 fail_timeout=10s;
  }

  server {
    listen 80;

    location / {
      proxy_pass http://server;
    }
  }

La configuration ci-dessus fait écouter notre proxy sur le port 80 et de prendre le flux HTTP venant de la liste "upstream server". Les arguments weight sont la taille que le node peut accueillir.

V. Mise en place des fichiers partage.

Pour permettre une administration plus simplifiée nous avons mis en place un service sur le manager qui va deployer pour nous le site web sur tout les nodes.

Pour cela, un petit outil va regarder le statue des fichiers voir s'il a été édité, supprimer, crée, etc. S'il découvre une de ces actions dans le dossier voulu alors je demande une synchronisation par RSYNC qui lui va synchroniser les fichiers des deux machines.

  1. Création du service linux

Un service linux va se démarrer au démarrage de la machine, cela est très avantageux.

Édition du fichier de configuration du service. 

sudo nano /etc/systemd/system/update-rsync.service


[Unit]
Description=Sync all folder

[Service]
User=root
WorkingDirectory=/http
ExecStart=bash update.sh
Restart=always

[Install]
WantedBy=multi-user.target

Premier démarrage du service 

service update-rsync start

  1. Installation des dépendences 
    apt install inotify-tools sshpass rsync

sshpass va permettre d'automatiser le moment ou le mot de passe ssh est attendu. La meilleur façon aurait été d'utiliser des clés ssh pour éviter un mot de passe en clair (Qui est en plus de ça dans les ressources du serveur http 😐)

Le script est dans /http/update.sh 

#!/bin/bash

clear
while inotifywait -r -e modify,create,delete /http; do
    sshpass -p node rsync -r -av /http/* [email protected]:/http/
    sshpass -p node rsync -r -av /http/* [email protected]:/http/
done

  1. Ajout des fichiers du site web

Les fichiers du site web seront donc dans /http

VI. Test du site web

Dans le test ci-dessus,on peut voir que le node 1 & 2 est bien demander aléatoirement ou en fonction de la charge de chacun. Le site web est bien accessible depuis le manager sur l'ip 192.168.1.100 dans le réseau local et grâce au NAT l'ip 10.0.4.6 donne aussi accès au site web.

Conclusion

Tout n'a pas été simple, mais nous avons appris pas mal de chose, nous avons rarement utilisé nginx dans d'autres projets, mais le cas présent était très intéressant. De même pour la synchronisation de fichier avec RSYNC qui attendais ça place !

La partie qui a pris le plus de temps était le NAT, ne connaissant pas le NAT avec le routeur cisco cela nous à demander de la lecture de documentation et beaucoup de persévérance, mais ça a finit par fonctionner !

Notre site web est donc maintenant redondant, si l'un des deux node est hors ligne l'autre node saura prendre le relais avec les mêmes ressources automatiquement. Notre façon de travailler a été optimale, nous avons créé une maquette sous Virtualbox avec des instances de chaque image pour pouvoir revenir en arrière simplement.

Cela nous a fait gagner du temps avec le matériel physique, tout en sachant que les configs étaient fonctionnelle dans celle si. Moi (Thomas) a pu visualiser le fonctionnement de docker en condition réelle.