Plateforme d'infrastructure cloud

Ce que c'est

Une architecture multi-services sur Google Cloud : des services conteneurisés orchestrés par Kubernetes, derrière un reverse proxy Nginx, avec une pile Prometheus et Grafana qui surveille l'ensemble. Chaque élément est déclaré plutôt que configuré à la main, de sorte que le cluster peut être décrit, relu et recréé.

Les services sont indépendants — chacun se construit, se déploie et se dimensionne à son rythme — mais partagent les préoccupations de plateforme : comment le trafic les atteint, comment leur santé est jugée, ce qui se passe quand ils tombent, et qui l'apprend.

Des déploiements qui se vérifient

Un déploiement n'est pas terminé quand le conteneur démarre. Il est terminé quand le conteneur sert correctement — et ce sont deux événements distincts, séparés par une seconde ou par l'éternité. Les health checks comblent cet écart : l'orchestrateur sonde la nouvelle instance et ne bascule le trafic qu'une fois qu'elle répond correctement, si bien qu'un conteneur qui démarre puis échoue ne reçoit jamais de requête.

Le repli devient alors une propriété de la plateforme plutôt qu'une procédure d'urgence. Comme la définition de la version précédente est toujours déclarée et que le déploiement est incrémental, revenir en arrière est un changement d'état que l'orchestrateur sait déjà effectuer — pas une course pour se rappeler ce qui tournait une heure plus tôt.

• Les déploiements sont incrémentaux : une mauvaise version dégrade une fraction de la capacité, pas la totalité.
• Le trafic n'atteint qu'une instance ayant prouvé qu'elle peut servir, pas une instance simplement démarrée.
• Le repli est un état précédent déclaré : c'est pourquoi il est assez rapide pour être la première réponse et non la dernière.

L'observabilité comme prérequis, pas comme ajout

Prometheus collecte les métriques des services et du cluster lui-même ; Grafana en fait la vue que l'on regarde réellement pendant un incident ; l'alerting referme la boucle pour qu'un problème s'annonce au lieu d'attendre d'être remarqué. L'ordre compte — une instrumentation ajoutée après une panne est une instrumentation dont on ne disposait pas pendant la panne.

Le vrai test d'une pile de monitoring n'est pas de produire des tableaux de bord. C'est qu'au moment où quelque chose casse, le tableau de bord réponde à la première question posée. C'est ce qui a déterminé quelles métriques sont collectées et comment elles sont regroupées.

La bordure

Nginx se place devant comme seul élément exposé : il termine le TLS, répartit la charge entre les instances, et pose les en-têtes de sécurité qu'il est trivial d'ajouter au centre et fastidieux d'ajouter dans chaque service. Le mettre en bordure permet aux services derrière lui de parler HTTP en clair sur un réseau privé, sans jamais avoir à connaître les certificats.

C'est aussi le bon endroit pour les préoccupations réellement globales : limites de taille de requête, délais d'expiration, et quels noms d'hôte sont servis. Les imposer une fois, en amont, vaut mieux que les imposer six fois de façon incohérente.