UTDON (UpToDateOrNot??) - Un outil qui permet de surveiller le niveau d’obsolescence de vos services en ligne.
Si comme moi vous utilisez beaucoup de services opensource auto-hébergés :
- grafana, prometheus, drone, borgwarehouse, gitea, healthchecks, matrix …
Il est assez compliqué d’avoir un cluster à jour.
Ce projet à pour origine, un shell… L’opération paraissait simple, mais il existe tellement de manières de gérer les versions d’une application web.
Le principe
Il s’agit de trouver une manière simple pour comparer la version de production et la dernière version disponible sur Github.
Chaque application, on parlera plutôt de services car vous pouvez avec plusieurs instances d’une même application, est définie dans un “contrôle”.
Pour définir un “contrôle”, vous devez spécifier :
- l’emplacement du code source sur “github.com”
- l’url de l’application en production. Plus exactement, l’url qui permet de présenter la version exécutée. Le numéro de version peut-être présent sur la page d’accueil, les application modernes proposent toujours un point d’entrée API (ex: /api/1/version).
- et pour chacun de ces emplacements, la méthode d’extraction du numéro de version. Pour Github c’est toujours la même chose mais il est parfois nécessaire de l’adapter pour obtenir une cohérence avec le tag du container correspondant.
Je ne vous ai pas menti, la gestion des versions n’est pas un problème simple dans un processus d’automatisation.
Quand je parle d’adaptation, je vais vous citer un exemple concret:
Pour un projet donné, la version “tag” sur github donnée par les développeurs est “v1.2.0”.
L’entrée API de leur application renvoie le json {version: "1.2.0"}, déjà il existe une incohérence : “v1.2.0” et “1.2.0”. De plus, le tag attribué au container mis à disposition par l’équite est “v1.2.0”.
Ici j’ai deux problèmes, comparer v1.2.0 et 1.2.0 et décider de la chaîne à conserver. Si je choisi d’effecteur une comparaison avec 1.2.0 seulement, “utdon” le permet.
Quand je vais appeler l’entrée API utdon permettant de donner la dernière version disponible, à partir de ma chaîne CI/CD par exemple, je vais me retrouver avec “1.2.0”, mais le tag du container à récupérer est “v1.2.0”.
Au final pour arranger tout le monde dans la chaîne, je ferai donc une comparaison sur la base “v1.2.0”. Ma chaine CI/CD pourra ainsi récupérer la bonne version du container, fournie par “utdon”.
Dans certains cas les developpeurs n’ont pas prévu de point d’entrée API pour donner la version exécutée, mais cette information est parfois disponible dans le contenu html de la page de login… D’autres fournissent un point d’entrée API donnant comme résultat Json {"major":1,"minor":94,"patch":1}.
Tous ces cas particuliers sont gérés par l’extracteur “utdon”, qui vous donne d’ailleurs l’intégralité de la liste des tags fournis par les développeurs. Ceci permet d’obtenir une vision d’ensemble sur la manière dont sont gérées les versions par l’équipe de développement.
L’extracteur permet aussi de ne suivre qu’un type de version, par exemple “LTS” (Long term support). Un produit dispose de plusieurs branches, la version LTS du produit en question est “10.x.x”. Vous pouvez fixer la règle du “10.*” et ainsi ne suivre que ce niveau majeur de version. Si le produit propose d’autres “releases” sur les autres branches, il n’y aura pas d’alerte.
Une fois enregistré, vous pouvez demander l’exécution du processus de comparaison (état de la production/état du dépôt Github):
- en utilisant l’interface proposée par UTDON
- ou bien en appelant, avec curl par exemple, le point d’entrée API indiqué (bouton “//” sur le contrôle).
En pratique
“Utdon” ne fait qu’effectuer une comparaison et appeler des ressources externes avec le résultat de la comparaison: “0” pour OK, “1” pour KO.
Deux types d’égalité, “stricte” ou “approximative”. “Approximative” est déclenchée quand la partie de la chaîne de la version de production ou de la version Github est incluse dans l’autre partie de la comparaison. Quand c’est strictement égal, le badge est vert, sinon il est orange. Mais avec les possibilités de l’extracteur, vous devriez pouvoir vous arranger à toujours obtenir une égalité stricte.
Utdon ne dispose pas de système d’alerte, Il existe tellement de systèmes de surveillance (monitoring) très bien fait qu’il m’a semblé inutile de me lancer dans la compétition :)
Le produit peut aussi appeler un point d’entrée API d’une chaîne CI/CD, pour les mises à jour automatique, par exemple.
Les paramètres de ces deux fonctionnalités peuvent évoluer selon vos besoins de production (créer une “issue”).
Exemple
Une fois les contrôles créés, vous pouvez mettre en place une tâche automatisée de comparaison (cron), qui s’exécutera, par exemple, tous les jours à 7h00.
0 7 * * * john curl -s -k -H "Authorization: $(cat /etc/secrets/myUtdonToken.secret)" https://my.utdon.url.mondomain/api/v1/action/compare/all/1
Pour accéder aux points d’entrées de l’API “utdon”, vous devez disposer d’un token. Dans cet exemple, ce token est situé sur la machine qui exécute le processus dans le fichier “/etc/secrets/myUtdonToken.secret”. Cette information est disponible sur l’interface, une fois connecté. Chaque utilisateur dispose de son propre token.
La tâche appelle le point d’entrée de votre instance “utdon” : “/api/v1/action/compare/all/1”. Ce point d’entrée effectue la comparaison pour chacun des contrôles accessibles (“all”) et exécute aussi la mise à jour de l’état du monitoring “/1” en envoyant en paramétre “0” ou “1” selon le resultat de comparaison.
Pour le monitoring, je fais appelle à un système de “ping”, en l’occurence “healthchecks”. Si la comparaison est approximativement ou strictement égale, le système appelle le monitoring avec le parametre “0” pour “tout va bien”, dans le cas contraire “1”, pour “il existe un écart”.
Le contrôle
A partir du contrôle, vous pouvez le modifier, le supprimer, afficher les commandes curl associées, effectuer une comparaison.
Pour obtenir le tableau du dernier processus de comparaison, cliquer sur le “badge d’état”.
Intégration dans une chaîne CI/CD
Une fois la comparaison effectuée, vous disposez du point d’entrée API : “/api/v1/action/lastcomparegitrelease/{controlUUID}” qui permet d’obtenir uniquement l’information sauvegardée de la dernière release disponible sur Github.com de cette application et utilisable dans un pipeline CI/CD.
Ceci est un exemple de pipeline CI/CD :
- Démarrage du processus de mise à jour de l’application dans la chaîne CI/CD
- Récupération du git de deploiement, ce dépôt contient un descriptif à jour de mon application et la manière de la déployer sur kubernetes.
- Appel du point d’entrée “utdon” : /api/v1/action/lastcomparegitrelease/{controlUUID} qui donne la dernière version disponible sur Github
- Comparaison de cette version à la version disponible dans le descriptif de mon déploiement
- si différent:
- Mise à jour du descriptif de mon application
- Téléchargement de l’image container vers la registry interne
- Mise à jour du “deployment” kubernetes et application
- Kubernetes démarre une instance avec la nouvelle version, si tout va bien, arrêt de l’instance existante, l’application est à jour
- Appel du point d’entrée “utdon” (appel décalé pour laisser le temps du démarrage) : /api/v1/action/compare/{controlUUID}/1, utdon envoi le résutat au monitoring.
Le code source du projet
Documentation en Français et en Anglais (voir entête du README.md)
+++