On doit faire serveur HTTP statique. Le but est de dockériser une image apache, ici en version 7.2 rouvée sur le site dockerhub. Cette version ne devrait pas posé de problème par rapport à la version du webcast de 2016.
- Pour lancer la demo:
il suffit de lancer ces deux commandes dans le répertoire où se trouve le Dockerfile :
$ docker build -t res/apache_php .$ docker run -p 9090:80 res/apache_php Ici, 9090 est le port souhaité
Ensuite il faut taper notre addresse local avec le port souhaité dans notre navigateur web, ici : localhost:9090
- Template différent de celui du webcast :_
On a utilisé ce bootstrap : https://onepagelove.com/bolt et on l'a modifié un peu.
- Ce qu'il faut faire dans le Dockerfile:
On va télécharger ou récuperer le docker souhaité avec le FROM, ici un serveur apache qui peut lire du php:
FROM php:7.2-apache
Puis on copie à l'interieur de notre propre docker, le contenu souhaité avec COPY :
COPY content/ /var/www/html/
- où se trouvent les fichiers de configuration d'Apache.
Il suffit d'utiliser la commande exec -itet de demander d'acc au bash pour pourvoir se trouver dans le noyaux linux du conteneur et ainsi nivaguer comme on veut: docker exec -it NOM_DU_DOCKER /bin/bash
Ensuite il faut se trouver dans etc/apache2/ avec la commande cd etc/apache2/puis faire un ls pour voir tout les fichier de config. On peut les lire avec la commande more.
On a du crée et dockerisé un serveur http dynamique avec le framweork express. La tâche était de renvoyer une liste d'objet aléatoire au format JSON.
- Pour la démo:
il suffit de lancer ces deux commandes dans le répertoire où se trouve le Dockerfile :
$ docker build -t res/express_students_php .$ docker run -p 9090:80 res/express_students_php On va utiliser la version 14.17.0 de NodeJs
- Ggénérez un contenu dynamique et aléatoire et renvoyez une charge utile JSON au client.
En lançant le docker dans express-image, ça renvoit un nom aléatoire.
- Différent contenu que le webcast.
On renvoie une liste d'animaux, avec leur 'modèle', leur age et leur prénom.
pour trouver l'ip, on va plutôt faire un docker inspect NOM_DOCKER | grep -i IPAdd, docker-machine marche pas.
Une fois le docker lancé avec la commande docker run -p 9090:3000, on peut y accéder avec localhost:9090
Ici, le but est d'avoir accès au serveur statique de l'étape et du serveur dynamique de l'étape 2 via un reverse proxy. On pourra donc accéder aux deux sans faire de port mapping
- Pour la démo:
Pour tout faire fonctionner, vu qu'on utilise des ip hardcodées, il faut lancer les conteneur docker dans le bon ordre et faire attention que les ip sont les mêmes que ce qui est marqué dans le .conf du docker reversProxy.
Soit:
docker build -t res/apache-static .
docker run res/apache-staticpuis:
docker build -t res/express-dynamic .
docker run res/express-dynamicet enfin:
docker build -t res/apache_rp .
docker run -p 8080:80 res/apache_rpPour tester le reverse il faut modifier le /etc/hosts en agjoutant la ligne 192.169.99.100 res.demo.ch demo.res.ch:8080 pour être redirigé sur le site statique demo.res.ch:8080/api/students/ pour le site dynamique
- Expliquer et de prouver que les serveurs statiques et dynamiques ne peuvent pas être atteints directement (le reverse proxy est un point d'entrée unique dans l'infra).
On a un message d'erreur si on ne spécifie pas le chemin, on tombe sur la configuration du virtualhost qui ne va pa nous laisser accéder au contenu. Pour y accéder on peut lui spécidier un chemin via le telnet, avec le host. Dans une barre d'addresse du navigateur on ne peut pas directement.
- Expliquer pourquoi la configuration statique est fragile et doit être améliorée.
Parce que les ip qu'on a mit dans la configuration peuvent facilement changer.
On a ajouté un script pour que le site web afficher une phrase différente toute les 5 secondes dans l'exemple de page statique de l'étape 1, phrase générée à l'aide de notre serveur express de l'étape 2.
il faut construire les 3 images suivantes dans l'ordre, leur Dockerfile a été modifié pour possédé l'app VIM et ainsi pouvoir facilement modifier les fichiers des containers.
docker build -t res/apache_php .
docker build -t res/express_students .
docker build -t res/apache_rp .docker run -d --name apache_static res/apache_php
docker run -d --name express_static res/express_students
docker run -d -p 8080:80 --name apache_rp res/apache_rp- Pour la démo:
Toutes les 2 secondes, le text change avec un type, un genre et un animal différent.
- Contenu des réponses:
Ici nous devions résoudre le problème d'ip hardcodé que nous avions utilisé pour l'étape 3. Pour ce faie utiliser un des variables d'environnement qui contiendront l'ip du serveur dynamique et statique, que l'on va pouvoir initialiser au moment de lancer le container qui contienr le reverse proxy.
- Trouver un moyen de remplacer la configuration statique du reverse proxy (adresses IP codées en dur) par une configuration dynamique.
Il a fallut modifier le Dockerfile!
Ainsi qu'ajouter le foreground de manière différente que dans le webcast étant donné qu'on est sur apache 7.2
- Utiliser l'approche présentée dans le webcast (variables d'environnement et script PHP exécuté au démarrage du conteneur de reverse proxy) ou une autre approche. L'exigence est que vous n'ayez pas à reconstruire l'image Docker du proxy inverse lorsque les adresses IP des serveurs changent.
Le config template, qui permete de donner l'ip au moment de run le container
- Etre en mesure de faire une démonstration de bout en bout avec un scénario bien préparé. Assurez-vous que vous pouvez démontrer que tout fonctionne correctement lorsque les adresses IP changent !
Il faut lancer plusieurs container aléatoirement pour être sûr que le fait d'entrer les adresse ip en dur ne puisse pas marche, par contre il faudra quand même les données au moment du run
- Vous êtes en mesure d'expliquer comment vous avez mis en œuvre la solution et de nous guider à travers la configuration et le code.
Par exemple, de cette manière:
docker run -d -e STATIC_APP=172.17.0.5:80 -e DYNAMIC_APP=172.17.0.8:3000 --name apache_rp2 -p 8080:80 res/apache_rpIci, pas besoin de créer un autre repo pour cette partie, car il suffit d'utiliser des commandes docker pour avoir une app graphique qui permet de contrôler notre environnement docker.
On a trouver sur le web, sur https://www.portainer.io/ , un container qui permete de faire tout ça, Il suffit de lancer les deux commande suivante:
pour pull l'image portaineer
docker pull portainer/portainer-ceet encuite lancer le container selon le tutoriel du site (ici sous linux)
docker run -d -p 8000:8000 -p 9000:9000 --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ceEnsuite il suffit d'y accéder, ici, sur localhost:9000, de créer un utilisateur et un mot de passe
Puis de se connecter
Nous avon sutiliser NGINX pour le load balancing
il suffit de créer un container docker Nginx comme avec un dockerfile contenant ces info :
FROM nginx
EXPOSE 80
COPY nginx.conf /etc/nginx/puis de le build avec la commande
$docker build -t res/load-balancing .ensuite, pour l'exemple, il faut lancer deux container de chaque serveur, soit 2 serveur statique et 2 serveur dynamique.
Il faut faire attention à leur ip vu que l'on va informer le container NGINX de leur ip lorsqu'on les ajoutre dans le fichier conf de nginx.
Il n'y plus qu'à lancer le container :
docker run res/load-balancingpuis tester l'adresse demo.res.ch ou demo.res.ch/api/students
Nginx utilise la méthode round-robin par défault pour le load balancing. pour forcer la méthode du "Sticky sessions" , il faut rajouter la ligne:
hash $remote_addr.Le plus gros inconvénient de l'utilisation de l'algorithme round robin dans l'équilibrage de charge est que l'algorithme suppose que les serveurs sont suffisamment similaires pour gérer des charges équivalentes. Si certains serveurs ont plus de CPU, de RAM ou d'autres spécifications, l'algorithme n'a aucun moyen de distribuer plus de demandes à ces serveurs. Par conséquent, les serveurs ayant une capacité moindre peuvent être surchargés et tomber en panne plus rapidement tandis que la capacité des autres serveurs reste inactive.