Exposition et répartition

1. Problématique

Dans le chapitre Les containers, nous avons vu comment créer des images réutilisables de notre application eni-todo et comment, grâce aux containers, les déployer sur un ou plusieurs serveurs. Mais nous n’avons pas encore vu comment y accéder depuis un point d’entrée unique. Il faut résoudre plusieurs problèmes.

Tout d’abord, chaque container, une fois démarré, dispose de sa propre adresse IP sur un réseau local à la machine et non routé, c’est-à-dire non accessible depuis un autre point du réseau. Il faut trouver une méthode pour que l’application s’exécutant de manière isolée puisse être accessible via, par exemple, l’adresse IP du serveur.

Ensuite, le service applicatif eni-todo est maintenant réparti sur deux serveurs, au moins, afin de garantir sa disponibilité en cas de perte d’une des machines. Or, il faut un point d’accès unique : une adresse, qui renverra les requêtes sur un serveur ou l’autre, mais qui devra aussi être capable de détecter l’indisponibilité de l’application sur un ou plusieurs serveurs pour renvoyer le trafic vers ceux encore actifs.

Si le service doit être exposé sur Internet, il faut pouvoir lui associer une adresse IP publique....

1. Pourquoi utiliser un reverse proxy ?

Chaque container démarré sur le serveur dispose de sa propre adresse IP. Cette adresse peut être obtenue simplement avec la commande docker et le nom ou l’identifiant du container :

$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' 8233221aeda5 
172.17.0.2 

Depuis le serveur lui-même, il est possible de vérifier que le service tournant dans le container fonctionne, avec une simple requête curl :

$ curl -I http://172.17.0.2:8080 
HTTP/1.1 200 OK 

Pour le moment, tenter la même chose depuis l’adresse IP du serveur fonctionne aussi, car nous avons associé le port 8080 du serveur à celui du container que nous avons démarré. Empêcher un accès direct à l’application est une mauvaise idée. Tout comme démarrer plusieurs applications utilisant le port 8080. C’est d’ailleurs impossible : plusieurs applications ne peuvent écouter directement sur une même paire IP:Port.

On peut aussi démarrer le container en utilisant le réseau de l’hôte, c’est-à-dire du serveur. Dans ce cas, le container utilise les adresses et les ports du serveur, il n’y a plus d’isolation du réseau. Mais là encore, deux containers ne peuvent pas utiliser le même port.

$ docker run --network=host ... 

Nous pourrions envisager d’autres solutions, bas niveau, avec Netfilter, du NAT (Network Address Translation), mais nous retomberions sur les mêmes problèmes. Nous devons utiliser une solution permettant à plusieurs applications d’écouter sur le même port, via un point d’entrée unique.

Sachant que chaque container dispose d’une adresse IP unique sur un réseau non routé, chacun peut écouter sur le même port, par exemple 8080. Comment dès lors accéder à ce port depuis l’IP du serveur ?

La solution est d’utiliser un reverse proxy. Le but du reverse proxy est de concentrer les connexions extérieures en un point d’entrée unique pour les redistribuer vers le service interne voulu.

Le service devant être exposé sur Internet ou un intranet (réseau d’entreprise), on y accédera depuis...

1. Présentation

Maintenant que les services containerisés sont accessibles depuis l’adresse IP d’un hôte, il nous faut exposer l’ensemble de ces services, et donc des hôtes, à l’ensemble des clients, que ce soit sur le réseau d’entreprise (l’intranet) ou un réseau public (Internet). Les tests précédents ne concernaient qu’un seul hôte. Or, le service sera déployé sur au moins deux hôtes. Nous n’allons pas exposer directement un serveur applicatif sur Internet. Les services étant répartis sur plusieurs serveurs, un processus de décision est nécessaire afin de répartir la charge sur l’ensemble des services.

Un load balancer, ou répartiteur de charge, a pour but de répartir les connexions des clients sur plusieurs serveurs ou services, selon des critères de décision. Le répartiteur a, normalement, au moins deux interfaces réseau : une accessible depuis le réseau qui expose l’adresse IP aux clients, et une autre sur un sous-réseau interne dédié, par lequel il accède aux hôtes (on peut n’avoir qu’une seule interface si l’IP exposée est dans le même sous-réseau que les serveurs). 

Le répartiteur de charge a pour premier rôle celui...

1. Choix des produits

On a besoin, a minima, de trois produits pour mettre en place cette architecture. Le répartiteur de charge lui-même doit prendre en charge la connexion d’un client à un service et la renvoyer vers un hôte (l’hôte se chargeant, via son reverse proxy, de la renvoyer vers un container). S’agissant de gérer plusieurs types de protocoles et des règles en fonction de ces protocoles (mutualisation des adresses et routage en fonction des noms d’hôtes), ceci exclut d’office une solution basée uniquement sur les couches 3 et 4 du modèle OSI (Open Systems Interconnection). Ce qui signifie que pour son rôle de répartiteur, Keepalived ne peut pas être retenu. Nous utiliserons la meilleure solution actuelle : HAProxy.

Les adresses IP des services peuvent être configurées manuellement sur les interfaces idoines. Mais comment les faire basculer simplement d’un répartiteur à un autre ? C’est là que le protocole VRRP (Virtual Router Redundancy Protocol) montre toute sa puissance. Nous utiliserons le module associé de Keepalived, qui nous servira à gérer un routeur virtuel composé d’au moins deux routeurs physiques, et qui prendra en charge la haute disponibilité des adresses IP.

L’exposition d’une adresse IP sur Internet est différente d’une exposition sur un réseau privé. L’adresse doit être annoncée aux différents routeurs via des protocoles spécialisés comme OSPF et BGP. Ces protocoles peuvent être configurés à l’aide de Quagga.

2. HAProxy

1. Implémentation

Dans cette section, la simplicité est de mise pour une meilleure compréhension.

Les répartiteurs de charge sont basés sur VRRP (Keepalived). Ils vont porter les adresses IP publiques sur une interface réseau dédiée et directement exposée, et donc accessible, sur Internet. Cela signifie que nous allons directement configurer une ou plusieurs IP publiques sur cette interface, comme s’il s’agissait d’IP quelconques, et donc ces adresses seront visibles avec une commande ip addr show.

D’autres méthodes sont possibles comme configurer les adresses sur l’interface de loopback, modifier les tables ARP et la configuration dynamique du noyau pour accepter des paquets IP non configurés sur les interfaces. On peut aussi utiliser Quagga pour configurer les interfaces.

Mais comme nous avons utilisé la configuration VRRP pour la haute disponibilité de nos VIP, nous allons faire de même pour configurer nos adresses IP publiques. Quagga a pour rôle d’annoncer ces adresses aux autres routeurs, leur donnant ainsi la route pour y accéder depuis Internet.

Nos répartiteurs de charge se voient donc ajouter une troisième couche, OSPF, pour annoncer les IP publiques qu’ils portent sur Internet, celles qui ont été configurées comme VIP sur les routeurs maîtres VRRP.

2. Installation et configuration

Le package de Quagga installe tous les composants...