Archives par étiquette : haproxy

docker – liens entre container suite

Maintenant que nous avons la bonne version de docker, nous pouvons modifier le fichier context.xml de l’application pour pointer sur le hostname de redis :

On va aussi modifier le démarrage du serveur d’applications pour créer un lien vers redis:

tomcat et redis sont maintenant connectée sans avoir besoin de connaître l’ip de chacun.

Et voici le script de démarrage complet :

Nous avons donc réussi à déployer des applications qui sont connectées entre elles, sans connaître les ips de chacune à l’avance. En termes de scalabilité, il devient aisé de rajouter un serveur d’application. Il faut juste démarrer un nouveau conteneur et le linker au haproxy.

Dans un prochain article, nous essayerons de voir comment faire fonctionner un cluster de redis avec docker.

Les sources sont à jour ici: https://github.com/BenoitCharret/session-webapp/tree/article_3

docker – liens entre container

Une chose qui m’a posé problème dans l’article sur le load balacing est que en fonction de l’ordre de démarrage des conteneurs, il fallait modifier le fichier de configuration haproxy.cfg pour avoir les bonnes ips. Je me suis donc intéressé aux liens entre conteneurs et j’ai un peu fait évoluer les choses. Tout d’abord, j’ai commencé par donné des noms à mes conteneurs applicatifs:

Je vais donc avoir un conteneur 1 avec un nom appA et un conteneur 2 avec un nom appB (les conteneurs étant les mêmes). J’ai ensuite construit une nouvelle image haproxy en repartant de zéro pour  apporter quelques modifications au script de démarrage. J’ai d’abord redéfini le Dockerfile:

J’installe le paquet haproxy et je modifie quelques éléments de la configuration. Notamment, je désactive le mode daemon. J’ajoute un script sh qui servira de base au lancement de l’image et j’expose le port 80. Le fichier script va construire la configuration au démarrage en fonction des conteneurs qui seront linkés. En regardant la documentation sur les links, on voit que pour chaque lien déclarer, docker va pousser des variables d’environnement dans le conteneur parent.

Exemple avec la commande

j’obtiens les valeurs suivantes

Je peux donc me servir de ces valeurs pour construire ma configuration à la volée. La seule valeur supplémentaire dont j’ai besoin est de connaître le nombre de liens que je vais ajouter. Je vais donc introduire la variable UPSTREAMS

on voit bien que je vais ajouter autant de ligne server… que de $UPSTREAMS en me basant sur les valeurs successives de $APP?_PORT_8080_TCP_ADDR Cela donne avec deux liens:

Pour lancer un conteneur avec des liens, on utilise la syntaxe suivante (dans un docker run):

container_name étant le nom défini à la suite de la commande
–name link_name étant le nom qui sera utilisé dans le conteneur parent

Ce qui donne par exemple :

Il est maintenant plus facile de rajouter des serveurs applicatifs. Il faut lancer un conteneur supplementaire un un nom et le linker avec le haproxy:

 

Il ne me reste plus qu’a travailler sur le lien entre les serveur applicatifs et la base redis.

Comme d’habitude les sources sont ici: https://github.com/BenoitCharret/session-webapp. J’ai ajouté un script start_all.sh et stop_all.sh pour simplifier la mise en route.

load balancing haproxy sous docker

Après avoir créé une première image contenant une application basique sous tomcat, je vais tester une montée en charge. Pour cela, nous allons lancer 2 containers tomcat et mettre en place un HA proxy (il s’agit d’un load balancer logiciel qui va répartir la charge entre les 2 containers tomcat.

Je vais utiliser l’image suivante : https://index.docker.io/u/dockerfile/haproxy.

Il y a juste à surcharger la configuration pour l’adapter à nos besoins:

j’ai repris le fichier de l’image et j’ai ajouté la partie en bas. On va donc faire du round robin  entre nos 2 serveurs tomcat qui sont ensuite définis. J’ai gardé la partie stats pour vérifier que tout se passe bien.

En démarrant un container, on obtient le résultat suivant:

 

Le serveur ne trouve aucun serveur « backend ». C’est ce que l’on constate aussi en regardant les stats:

stats1

En démarrant un container tomcat, on peut voir que les choses s’améliorent:

 

stats2

On a maintenant un premier backend. Et effectivement, en allant sur le site, j’obtiens bien la page voulue

hello1

Je lance maintenant le deuxième:

stats3

Nous avons maintenant une infrastructure avec 2 serveur tomcat et un load balancer devant.

En lancant une commande de type :

On voit bien l’alternance des serveurs dans les logs et dans les stats.

stats4

Les sources de l’exemple sont disponible ici: git.