Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger).
Maintenant il me faut faire un script d’arrêt des containers, on va donc arrêter un container qui a le status à OK et qui a une charge de 0.
Voici le script que je propose, ce script permet en plus de fixer notre bug sur la précédente version ;) .
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger).
On va utiliser le fichier dynamique fait par ./build_haproxy.bash qui se trouve dans /docker/app/haproxy.cfg (merci de regarder l’épisode précédent n°13 afin de mieux comprendre). Pour le lancement de haxproxy la dernière fois que l’on a vu cela c’était dans le n°10 , la commande était alors :
docker run -d --link my-server4-1 --link my-server4-2 --link my-server4-3 --link my-server4-4 -p 80:80 --name mon-haproxy-v15b my-haproxy-v15
Maintenant on n’a plus besoin de lien car les IP sont écrites par les serveurs eux-mêmes. On a seulement à faire un partage de fichier.
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger).
Je pense avoir trouvé une alternative à confd & etc , c’est consul-haproxy .
[root@localhost ~]# yum install consul
Modules complémentaires chargés : ulninfo
dockerrepo | 2.9 kB 00:00:00
ol7_UEKR3 | 1.2 kB 00:00:00
ol7_UEKR4 | 1.2 kB 00:00:00
ol7_latest | 1.4 kB 00:00:00
dockerrepo/primary_db | 15 kB 00:00:00
(1/2): ol7_latest/x86_64/updateinfo | 812 kB 00:00:01
(2/2): ol7_latest/x86_64/primary | 16 MB 00:00:17
ol7_latest 14264/14264
Aucun paquet consul disponible.
Erreur : Rien à faire
Misère, cela commence fort … sinon j’ai aussi vu une configuration un peu complexe avec vagrant.
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger).
Maintenant je pense que je vais travailler avec confd et etcd pour faire de la reconfiguration dynamique du serveur HAproxy. L’idée c’est que les etcd informent le confd des changements, et si changement il y a le confd refait le fichier de configuration haproxy.cfg. Puis il relance HAproxy.
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger).
Petit résumé rapide de mes précédents posts, à noter que grâce au tag Docker on peut retrouver tous les articles sur le sujet.
| Post n° | Intérêt | Résumé |
|---|---|---|
| 1 | 20% | Mauvaise installation à cause de la partition Docker. Mais début des commandes sous Docker : docker run , docker rmi, docker run, docker ps, |
| 2 | 70% | On voit l’intérêt de l’ajout de la partition Btrfs, on découvre le fichier Dockerfile qui est utilisé pour faire les docker build. |
| 3 | 70% | On a vu la redirection de port avec l’option -p . Et aussi docker search qui permet de voir tous les containers existant. On a aussi l’installation du container PostgreSQL. |
| 4 | 50% | Installation du container PostgreSQL mais pas comme je l’aurai voulu car je n’arrive pas à initialiser les utilisateurs dans le Dockerfile. Et les sources de server.c . |
| 5 | 30% | Découverte de la commande docker run swarn. J’ai pas vraiment approfondi la notion. |
| 6 | 60% | Un nouveau serveur : server2.c , on découvre la commande docker exec env. On a aussi la création d’un server3.c qui exploite les liens entre containers (--link) |
| 7 | 10% | Un échec complet sur l’installation de HAproxy. |
| 8 | 80% | Bonne configuration de NGINX et de HAproxy. |
| 9 | 10% | Un échec complet sur la redirection des logs syslog vers un autre serveur. |
| 10 | 90% | La création d’un server5.c qui permet de faire des insertions dans la base, d’envoyer des logs à syslog et de tester les configuration de HAproxy et Nginx. |
Il y a eu des hauts des des bas dans cette découverte de Docker.
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger).
On va dire que ce pas va être un pas de coté. Mon but va être d’améliorer le server4 pour en faire un server5 (source server5.c). Mais je vais aussi faire un programme de stress : client_stress.c afin de bien vérifier tout le fonctionnement.
Voici donc les amélioration sur server5.c :
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger). Sachant que celui-ci c’est 100% échec :( .
Cette fois je vais m’attaquer au logs, et pour ce faire je vais monter un container faisant uniquement du syslog. Voici l’architecture cible que je veux :
Je vais partir sur un ubuntu pour faire plus simple.
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger).
Je me suis planté complètement avec HAProxy, pour l’instant je n’ai pas compris mes erreurs car je n’ai pas réussi à avoir accès au logs. Mon étape va être de voir si avec l’autre server de répartition de charge : nginx, j’arrive à faire mieux.
On commence par le téléchargement de la version :
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger). Sachant que celui-ci c’est 100% échec :( .
J’ai repoussé plusieurs fois l’installation de HAproxy maintenant je vais devoir le faire. Pour cela je vais m’appuyer sur mon server4.c qui va recevoir la charge du HAproxy. Je vais lancer 4 server4 qui vont écouter sur 4 ports différents (8080/tcp, 8081/tcp, 8082/tcp, 8083/tcp) .
Attention ceci est mon brouillon avant de faire une belle documentation sur Docker (il y a à boire et à manger).
On passe donc à l’étape de l’installation de HAProxy, l’installation cible est la suivante (il va falloir que j’améliore mon server.c (que l’on va appeler server2.c) afin d’avoir une connexion avec la base de donnée):
Voici un nouveau server2.c , mais avant cela il faut installer le RPM qui permet de faire de dev :