Passer à Kubernetes en une seule bascule

ClickFortify a démarré sur une seule VM sous docker-compose. Il tourne aujourd’hui sur Kubernetes dans GCP et se déploie via ArgoCD. Cet article porte sur le passage de l’un à l’autre, et sur la raison pour laquelle je l’ai finalement réalisé en une seule bascule plutôt que par une migration progressive.

Le produit ne peut pas faire de pause

ClickFortify collecte les clics publicitaires sur du trafic réel, les évalue et écrit des exclusions dans Google Ads et Meta. Les clics arrivent jour et nuit. Un plan de migration qui exige une fenêtre de maintenance, ou qui laisse le tracker à moitié sur une stack et à moitié sur l’autre, coûte du vrai budget à de vrais annonceurs.

La question n’était donc pas « comment tout déplacer ? » mais « comment faire de la bascule une étape unique, petite et réversible ? ».

D’abord, un chemin de déploiement fiable

Avant de déplacer le moindre trafic, le cluster devait disposer d’un chemin de déploiement en lequel j’avais confiance. La configuration GitOps repose sur trois dépôts : l’application, les manifestes déployés par ArgoCD et l’infrastructure de la plateforme. Le plan initial gardait les manifestes dans le monorepo de l’application. Je les en ai sortis parce qu’ArgoCD reclone le dépôt à chaque rafraîchissement et que le monorepo est volumineux, parce que la plateforme a son propre cycle de vie et ses propres relecteurs, et parce que la CI de l’application n’a alors aucun accès au dépôt de la plateforme.

C’est important pour une bascule. Si le nouvel environnement est déployé exactement comme il le sera ensuite, le vérifier dès le premier jour revient aussi à vérifier le processus de release.

Un jeu parallèle de noms d’hôte de staging

Le plan retenu comportait trois étapes :

1. Déployer l’intégralité de la nouvelle stack sur le cluster derrière un jeu parallèle de noms d’hôte de staging, comme stage.example.com.
2. La vérifier à cet endroit.
3. Rediriger les noms d’hôte de production vers le cluster en une seule bascule.

Rien n’a changé en production pendant les tests du nouvel environnement. L’ancienne VM continuait de servir chaque requête réelle, et les noms d’hôte de staging me donnaient un endroit où éprouver la nouvelle stack de bout en bout.

Pas de migration de données, et le revers de la médaille

Les deux environnements utilisaient les mêmes bases de données. C’est ce qui a rendu possible une bascule unique : pas de copie à lancer, pas de synchronisation à maintenir cohérente, et aucun moment où les deux stacks divergeaient sur les données. Au changement DNS, la nouvelle stack lisait et écrivait déjà les mêmes lignes que l’ancienne.

Le revers, c’est que l’environnement de staging n’a jamais été un vrai bac à sable. Tout ce qu’il écrivait atterrissait dans les données de production. Les tests utilisaient un espace dédié réservé à cet usage, et aucun script d’un vrai client n’a jamais été pointé vers le tracker de staging.

Pourquoi le worker est resté à zéro

Le worker est le service qui exécute les tâches planifiées. Sur une base de données partagée, deux workers signifient que chaque tâche planifiée s’exécute deux fois : les e-mails partent deux fois, les nettoyages suppriment deux fois. Le worker du nouvel environnement est donc resté à zéro réplica pendant toute la période de staging.

# Illustrative: keep the new side's worker off until the flip
kubectl scale deployment worker --replicas=0

La bascule, et vérifier qu’elle tient

La bascule elle-même était un changement DNS : les noms d’hôte de production ont été pointés vers le cluster. Auparavant, j’ai vérifié que les digests des images en cours d’exécution sur le cluster correspondaient à ce que je comptais livrer.

Ensuite, la vérification la plus importante portait sur le tracker. Il se trouve derrière un CDN et un reverse proxy, et retrouver la véritable IP du visiteur derrière eux est exactement le genre de chose qui casse quand la topologie change. Après la bascule, le trafic réel du tracker montrait de vraies IP de visiteurs et aucune adresse de nœud CDN. Une fois ce point confirmé, les noms d’hôte de staging ont été supprimés.

Juste après la bascule, le retour arrière consistait à faire la même opération en sens inverse : repointer les noms d’hôte vers l’ancienne VM, que j’avais arrêtée plutôt que supprimée.

Ce que je conseillerais à quelqu’un qui fait la même migration

1. Si les deux environnements peuvent partager les bases de données, faites-le. Cela supprime la migration de données et réduit la bascule à un seul changement DNS.
2. Recensez chaque tâche planifiée et assurez-vous qu’elle s’exécute à un seul endroit pendant le staging, même si cela empêche de répéter un service à l’avance.
3. Videz ou exportez les tâches en file d’attente et les tâches différées avant la bascule. Elles vivent en dehors de la base de données.
4. Définissez la vérification avant la bascule, et faites-la porter sur du trafic réel, pas sur des endpoints de santé.