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.
