SCOP d'ingénieurs experts du logiciel libre depuis 2004
+33 1 70 61 60 16

HTTP Mirror : notre outil pour maquetter un proxy HTTP

Le routage HTTP, c'est bien, pouvoir le tester, c'est mieux. Cet article vous présente une procédure permettant de tester vos routages HTTP.

Notre prochain webinar

HTTP rulez

Le protocole HTTP, au-delà de son hégémonie, est fort pratique.

HTTP permet d'intervenir entre la couche application, et le client. Il est ainsi possible de router vers différentes applications (distinctes ou de multiples instances), de cacher, de gérer une partie de la sécurité avec les headers, et de chiffrer la communication avec TLS. La notion de routage devient primordiale avec l'adoption des architectures en micro services.

Proxy HTTP

Il existe plusieurs proxy HTTP, aucun ne couvrant 100% des possibilités. Parmi les classiques, nous avons Nginx ou HAproxy, et il y a des nouveaux fort prometteurs, comme Traefik ou Caddy .

Configurer un proxy HTTP peut être douloureux, mais c'est surtout la partie recettage qui est dramatique. Il n'est pas trivial de reproduire une préprod similaire à la prod, avec les noms de domaines, certificats TLS et IP. Il est ensuite complexe de savoir quelle couche est responsable de l'incident lorsque l'on constate une erreur. Les drames de régression sont d'autant plus sournois.

Pour reprendre la main sur son proxy, avoir des choses prévisibles et déterministes, il faut utiliser l'inévitable "infrastructure as code" : on configure comme on code, avec du versionning, des tests et même potentiellement de l'analyse statique (comme le propose Gixy ).

Miroir HTTP

Pour la partie versionning et provisioning, les outils existent, suivez les recommendations de votre chapelle. Pour la partie test, je vous propose un outil simple, http-mirror , un serveur web minimaliste qui se contente de raconter en JSON ce qu'il reçoit comme requête. Il répond à tout, sans se soucier des URLs. Il a l'intelligence et l'utilité d'un miroir, pas plus, ni moins.

Pour avoir un contexte crédible d'exécution d'un proxy et de ses services webs, il faut utiliser Docker, et son ami des architectes : docker-compose. Pour plus de réalisme, une pki est utilisée, pour avoir des certificats TLS arbitraires (et privés), qui ont la confiance du client.

Mettre en place une PKI juste pour une maquette n'est plus dramatique depuis que l'on a CFSSL qui remplace avantageusement easy-rsa fourni avec Open-VPN ou des machins interactifs avec le tant redouté OpenSSL. Ah oui, comme HAproxy ne sait pas causer sur STDOUT, il y a même un faux syslog pour entendre HAproxy crier quand il a mal.

Jouer avec la maquette

cd example/haproxy 

Donc, avec l'aide de cfssl, de docker-compose et d'http-mirror, il est possible de maquetter un routage vers deux domaines, un service caché derrière un préfixe, et une redirection d'http vers https.

Les certificats sont prémâchés, ce qui permet de lancer la maquette sans installer cfssl, qui n'a pas encore de paquets systèmes dans toutes les distributions (ça reste un gros blob golang).

Un Makefile permet de lancer les commandes en limitant le copier/coller. Il faut quand même le lire , hein.

La partie centrale est le fichier docker-compose.yml qui décrit l'architecture de la maquette : deux réseaux, un public et un privé, 5 serveurs, ne soyons pas chiche, les conteneurs, ça sert à ça. Nous avons donc un haproxy, un syslog en side kick (le haproxy est Batman, syslog est Robin), et trois serveurs applicatifs, qui sont en fait des http-mirrors. Pour pouvoir travailler tranquillement, le container haproxy mount le dossier courant, qui contient la conf et les certificats. Il est possible d'éditer la conf (en local, donc) et de relancer le service avec des kill -HUP dans le container.

make server 

Dans un autre terminal, un split, par exemple, on peut afficher le gros tas de logs, avec une couleur par container.

make logs 

Pour pouvoir tester tout ça, nous avons besoin d'un Curl, par ce qu'HTTP se test avec Curl et pas autrement : "Curl is law". Cette image a besoin de faire confiance dans l'autorité SSL que l'on a créée pour la maquette.

make build-curl-image 

Nous avons besoin d'un container qui va utiliser le réseau public déclaré dans docker-compose.

make curl 

Un petit curl, depuis le container, pour voir comment ça se comporte

curl -vL alice.example.com/api/plop 

plop est tout à fait arbitraire, ce que l'on test, c'est le préfixe /api , -v comme verbose, -L comme "follow location", pour avoir la redirection http vers https.


Mathieu Lecarme

Inscrivez-vous à notre newsletter

Mieux comprendre le monde du DevOps et de l'administration système.

Abonnez-vous à notre newsletter

Hébergement & Infogérance

  • ✓ Service Astreinte 24h/7j/365
  • ✓ Supervision, monitoring & Alertes
  • ✓ Mises à jour en continu
  • ✓ Certificat SSL letsencrypt
  • ✓ Hébergement dédié sécurisé en France
  • ✓ Backup vers datacenter distant
Découvrir notre offre

Expertise Technologique

Notre équipe possède une vaste expertise technologique.