On a beau concevoir des chaînes d’intégration et de déploiement continu pour que les mises à jour fréquentes de sites web soient facilitées, il arrive tout de même de temps en temps que des projets « zombies » traînent sur une plateforme hébergeant de nombreuses applications gérées par des équipes différentes. Et si vous faites correctement votre travail de maintenance d’infrastructure de votre côté,  ben parfois, on tombe sur un gros os.

Si vous pensez que l’article ne sert à rien ou presque, allez jusqu’au post-scriptum

Sur cette plateforme, les livraisons se font avec Helm. Depuis Helm 3, l’historique de livraison est stocké dans des secrets Kubernetes dans le namespace cible. Il faut savoir que lors d’une livraison, das les grandes lignes voilà ce que fait Helm :

1. « Compiler » les manifestes à partir des templates et des variables fournies (fichiers values, --set)
2. Comparer le résultat à celui de la précédente livraison
3. Interroger l’API Server pour vérifier la présence des objets de cette précédente livraison
4. Générer/supprimer/patcher les ressources concernées par des modifications, ce qui correspond de fait à la livraison
5. Stocker le résultat dans un nouveau secret quand la livraison s’est déroulée correctement.

C’est à l’étape de l’interrogation qu’on peut se retrouver dans un sacré blocage avec ce genre d’erreur :

Error: UPGRADE FAILED: unable to build kubernetes objects from current release manifest: resource mapping not found for name: "ing-pwapriv" namespace: "" from "": no matches for kind "Ingress" in version "extensions/v1beta1"
ensure CRDs are installed first
helm.go:84: [debug] resource mapping not found for name: "ing-pwapriv" namespace: "" from "": no matches for kind "Ingress" in version "extensions/v1beta1"

Au début j’ai pas trop compris, parce que je pensais que c’était les manifestes de livraison de l’application qui posaient problème, mais à l’évidence, la vérité était ailleurs. Et de fait, on a découvert que si les manifestes avaient bien été rafraîchis via un script un an auparavant, le commit contenait la mention magique [skip-ci]. Ce qui ne serait pas plus choquant que ça si dans le même temps l’agence web n’avait pas pris plus d’un an pour mettre à jour le site web… Ce qui veut dire que la dernière livraison contient des manifestes dont l’apiGroup de l’ingressRule n’existent plus.

Et là, ça a été l’aventure pour trouver une solution. On pourrait simplement « désinstaller » le site, et le réinstaller. Mais je suis moyennement fan, parce que ça va créer une indisponibilité alors qu’on pourrait s’en passer, même si on est confiant sur la sécurité des données (le volume NFS est en retain et la BDD ne bougera pas), je cherche une alternative.

Déjà quand on découvre le format du secret. Par défaut, quand on tente de récupérer le YAML ou le JSON du secret, on est face à un contenu encodé en bas64; jusque là, c’est normal. Mais il fait une taille conséquente, et quand on le décode… Ben c’est toujours illisible, et pour cause : c’est encore du base64. Mais si on le décode une deuxième fois, on est face à un truc illisible, en tout cas pour l’instant.

La gueule du contenu…

Car le résultat, si on le met dans un fichier, est au format GZIP. Une fois décodé, on est face… à un JSON qui contient, de manière sérialisée, les manifestes au format YAML, y compris le coupable. Oui, sérialisée. Après avoir épongée la grosse goutte de sueur qui venait de perler, j’entame la marche pour corriger :

1. Identifier la section de la loooongue chaîne de caractères correspondante au manifeste fautif,
2. La copier/coller dans un éditeur
3. Rétablir le formattage YAML (remplacer les \n par de vrais retours à la ligne)
4. Modifier le manifeste (non seulement la ligne de l’apiGroup, mais toute la définition de la partie service)
5. Reconvertir les retours à la ligne en \n pour retrouver la ligne unique
6. Remplacer la section fautive par la version corrigée dans le JSON.

Il ne reste ensuite qu’à recompresser et double/base64-iser le contenu dans une copie corrigée du manifeste du secret, et donc écraser l’historique. Le plus gros challenge dans ce foutoir est de ne pas se planter sur l’indentation. Une fois qu’on a modifié le secret, si on se rate on est bon pour supprimer/recréer le secret.

Avant de retenter la livraison, on peut justement vérifier avec helm get manifest, s’il n’y a pas d’erreur on peut dès lors retenter la livraison qui devrait passer (en tout cas ça a été bon pour moi), même si techniquement on vient de réécrire l’histoire. Et comme ça on évite le gros downtime de la désinstallation/réinstallation du site.

L’intérêt de se faire « mal »

Déjà, j’en ai appris beaucoup sur le process de livraison de Helm, parce que j’avoue que depuis que je m’en sers, je m’étais plutôt concentré sur les problèmes liés au templating, le reste c’était un peu « ta gueule c’est magique ». Surtout, les deux heures qu’ils m’aura fallu pour trouver cette solution sans interruption de service (le site était toujours debout, rien n’avait été modifié), elles auront été rentabilisées car trois autres sites ont depuis été pris du même mal, et là, on parle d’une dizaine de minutes grand max pour chaque nouvelle occurrence rencontrée. Et la méthode fonctionne quelque soit le type d’objet problématique (parce qu’entre temps, y’a les CronJobs et les PDB qui se sont mis à râler aussi, sinon c’est pas drôle).

Il y a plein de réflexions à avoir pour mieux se prémunir de ce genre d’erreurs, mais elles sont pour beaucoup spécifiques aux choix de design fait par le client, notamment la séparation du code du site de la gestion de la livraison (build docker & helm). La difficulté de devoir gérer quasiment 200 projets sur cette plateforme fait qu’on ne peut pas non plus éviter complètement les erreurs, notamment sur les quelques projets qui ne respectent pas les modèles qu’on a mis en place.

Je n’ai pas non plus complètement sorti la méthode de nulle part. Mais l’article qui m’a guidé vers la solution finale est avare en détail, parle du networking.k8s.io/v1beta1 (donc moins chiant à remplacer), ce qui fait qu’il a juste scripté le bousin sans plus de cérémonie. Au moins là on a les explications du pourquoi du comment

Post Scriptum

Ouais, vu ce que j’ai à dire encore après tout ça, ça tient pas sur une seule ligne. Dès le titre, certains auront pensé « mais en fait c’est dans la doc », « mais y’a un plugin ». Il s’avère que oui, sur la même page, on a la méthode manuelle complète, et la mention d’un plugin « kubemapapis » qu’ont d’ailleurs découvert les collègues vietnamiens quelques semaines plus tard, se facilitant dès lors très fortement la vie. Mais il se trouve que j’ai démarré l’écriture de cet article il y a pratiquement deux ans (j’ai même changé d’entreprise entre temps, c’est dire), la documentation n’était pas nécessairement aussi explicite à l’époque, et je pense que malgré tout, ma recherche de la solution manuelle permettant de se pencher sur le format des informations manipulées par Helm reste pertinente