Solution de monitoring
| Présentation et définition du projet
Étant en alternance depuis 5 ans dans la même entreprise, j’évolue dans une équipe de développeurs. De 2021 à 2023, je réalisais déjà des missions au sein de cette équipe dans le cadre d’une alternance dans le but d’obtenir le diplôme « Gestionnaire en Maintenance et support informatique ». En 2023, mon projet de fin d’études consistait à mettre en place une solution de surveillance au sein de l’équipe. En effet, avant ce travail, nous n’avions pas de solution dont nous étions propriétaires excepté un outil interne « swchecker_monitor » mais celui-ci ne correspondait pas à nos attentes (pas d’interface, alerte par mail et langage perl).
Ainsi, après avoir réalisé une étude de cas approfondie, nous avions choisi d’utiliser l’association des outils Prometheus et Grafana. Prometheus est un outil de surveillance qui centralise toutes les données que nous voulons surveiller. Pour cela, il a besoin d’exportateurs sur les cibles, qui lui mettent à disposition les métriques. Il est très utilisé et doté d’une forte communauté, on retrouve beaucoup de documentations.
Prometheus se démarque aussi par sa structure de stockage de données basée sur un modèle de séries temporelles. Cela rend l’outil très efficace en termes de stockage et de récupération de données de métriques. Cet outil est entièrement open-source et peut être associé à Grafana qui va nous servir pour la visualisation des données. Il est lui aussi très populaire, car il a été téléchargé plus de 43 millions de fois en une seule année (2021).
Cette solution nous a permis de mettre en place de nombreuses sondes et alertes mais nous avions besoin d’améliorer différents aspects. En effet, j’avais installé la solution en 2022 sur une machine virtuelle en utilisant des services systemd mais l’architecture ne répondait plus aux besoins.
Ainsi, je vais détailler un projet de migration de cette solution de monitoring d’une architecture monolithique vers une architecture micro-services hébergée sur une machine virtuelle. Ce projet a été réalisé dans le cadre du projet de fin d’études que je devais réaliser pour valider le diplôme “Administrateur Système DevOps”.
| Contexte
Ce projet intervenait dans un contexte de migration de tous les outils et les environnements dans le Cloud. La nouvelle solution a donc été mise en place dans ce nouvel environnement Cloud.
| Objectifs
L’objectif du projet était de migrer l’architecture de la solution de monitoring basée sur Prometheus/Grafana vers une architecture micro-services utilisant Podman avec le code applicatif géré dans un répertoire versionné.
Ensuite, l’objectif était d’intégrer une continuité de déploiement de telle sorte à automatiser la mise en production lorsqu’un développeur modifie le code applicatif.
Enfin, j’ai dû aussi dans le cadre de ce projet exploiter cette nouvelle version de solution de surveillance en ajoutant de nombreuses sondes et alertes.
J’ai dû aussi migrer les sondes et alertes d’un ancien outil de surveillance interne (swchecker_monitor) qui continuait de fonctionner, ainsi que surveiller les conteneurs associés aux micro-services.
| Enjeux
L’enjeu principal était de mettre en place une solution plus résiliente, plus flexible et qui saura s’adapter à des futurs besoins croissants.
Il était aussi attendu de profiter de la migration de la solution dans le Cloud pour pouvoir ajouter de nouvelles sondes afin de surveiller ce nouvel environnement.
| Risques
Lorsque j’ai choisi de migrer l’application web de monitoring, j’ai dû prendre en considération que tous les efforts actuels de l’équipe sont orientés vers la migration des outils et de l’environnement vers le cloud. C’est un grand projet très transverse à fort impact et critique avec un objectif temps serré (grosse contrainte de temps et de coût). Cependant, les ressources et les priorités ne sont pas en faveur de la migration des applications web intervenant plus tard.
J’ai rapidement identifié un risque majeur, l’accès au Cloud Azure et au service AKS qui permettrait d’orchestrer la solution avec Kubernetes managé. En effet, le Cloud est récent dans l’entreprise et seule une équipe IT a accès au service AKS à ce jour. Ainsi, prenant en compte ce point, j’ai décidé de migrer la solution sur une machine dédiée du Cloud en utilisant un orchestrateur local.
| Etapes du projet
Cahier des charges
La réalisation du cahier des charges permet de s’assurer de couvrir tous les aspects dont nous avons besoin au sein de la migration de la solution de surveillance.
L’objectif était aussi de pouvoir anticiper et mettre en place un planning de tâches. Pour cela, nous avons commencé par réaliser deux « diagrammes pieuvres » qui nous ont servi de support pour réaliser nos analyses fonctionnelles.
Le cahier des charges complet est disponible (cf. lien). Il met en avant l’utilisation de docker-compose (l’orchestrateur retenu était finalement podman-compose) pour l’orchestration des conteneurs, l’implémentation de CI/CD avec Jenkins, ainsi que la gestion des dépendances via Artifactory et Subversion.
Plannification
Après concertation avec ma tutrice, nous avions décidé d’organiser des points environ toutes les deux semaines afin de discuter des avancées de mon projet.
Ces points m’ont été très utiles, car ils m’ont permis de prendre du recul, d’avoir un avis extérieur et de suivre mon avancement. En effet, j’ai réalisé un diagramme de GANTT que je mettais à jour avant chaque point avec ma tutrice. Ce projet m’a demandé une certaine réflexion sur l’organisation à établir avant le commencement de mon projet. J’ai travaillé sur cette mission avec un temps alloué d’environ 50%. Afin de visualiser clairement le cheminement de mon projet, j’ai établi une « road map » avant le début de la réalisation technique.
Etat des lieux
Dans un premier temps, j’ai établi l’état des lieux de la solution actuelle en schématisant l’architecture.
Comme abordé précédemment, cette architecture présentait des limites. En effet, le code n’est pas dans un répertoire versionné et cela présentait un risque de perte du code menant à une interruption de service. L’évolutivité n’était pas optimale car les modifications et la gestion des services étaient manuelles. Cela augmente le risque d’erreurs lié aux nombreuses manipulations humaines. On observait aussi que dans cette architecture nous étions obligés d’avoir une interruption de services lors d’une modification.
Enfin, custom-exporter était un script bash exécuté sur la machine à défaut d’exportateurs conteneurisés avec une image Python.
Mise en place des services conteneurisés
L’entreprise a mis à disposition un artifactory jfrog. jfrog est un gestionnaire de référentiel universel qui permet dans notre cas de gérer nos images Podman. Dans le cadre de mon projet, nous avons demandé un dépôt dédié. Celui-ci présente une base d’images docker courantes comme debian, Python ou encore Prometheus et Grafana qui m’ont permis de constituer mes services conteneurisés.
Répertoire Subversion
J’ai créé un répertoire Subversion afin de mettre tous les fichiers de configuration qui vont être nécessaires à la solution de monitoring. Les fichiers sont essentiellement au format yaml et json.
L’utilisation d’un répertoire Subversion nous permet une gestion efficace des versions, offrant un historique complet des modifications et la possibilité de récupérer des versions antérieures. De plus, cela nous permet une gestion des branches et des tags, ainsi que la mise en place d’une intégration continue de déploiement.
Orchestrateur Podman
Podman est un outil développé par RedHat, permettant l’orchestration de conteneurs et de pods. C’est une alternative à docker qui s’avère sécurisée avec des approches de conteneurs sans droit root par exemple.
Sur une instance, j’ai commencé par créer des images Debian en important les exécutables Prometheus/Grafana (+ fichiers de configuration). Cependant, je me suis renseigné et informé sur le fait de pouvoir utiliser les images officielles de Prometheus/ Grafana ainsi qu’une image pour chaque service associé.
Cette stratégie d’implémentation représente plusieurs avantages comme la fiabilisation, la bonne compatibilité entre les différents services ou encore la simplification des mises à jour.
Podman a été privilégié car nous utilisons un environnement Cloud avec des machines Redhat. J’ai rédigé le podman-compose.yml comprenant les différents services nécessaires au fonctionnement de la solution de monitoring.
Mise en place d'une CI/CD
Le répertoire Subversion nous permet de versionner notre code, mais aussi de mettre en place à l’aide de Jenkins une automatisation d’intégration et de déploiement continue.
Cela permet d’automatiser la mise en production d’une nouvelle version suite à un commit effectué dans la branche « trunk » du répertoire Subversion. L’objectif a été de créer une automatisation qui va d’abord contrôler s’il n’y a pas d’erreur de syntaxe ou d’indentation dans les fichiers de configuration avant de déployer une nouvelle version. J’ai utilisé les outils « amtool » et « promtool » qui ont été développés par la Cloud Native Computing Foundation. Ces utilitaires permettent ainsi de vérifier les fichiers de configuration au format yaml suivants : prometheus.yml (fichier central permettant de renseigner toutes les cibles) alerts.yml (fichier permettant de définir toutes les règles d’alertes) alertmanager.yml (fichier permettant de définir les mécanismes de notifications).
Si une erreur est remontée, le pipeline Jenkins s’arrête et la nouvelle version n’est pas déployée en production.
Ce projet m’a permis de capitaliser de l’expérience dans la compétence « Ci/Cd« .
| Les acteurs
J’ai beaucoup développé cette solution en autonomie. Mon tuteur d’entreprise a participé au niveau de la gestion du projet.
| Les résultats
Cette migration vers une architecture micro-services a permis de rendre la solution plus robuste et plus évolutive. La mise en place d’automatisation et de versionnement de code ont permis de fiabiliser et améliorer les cycles de vie de l’application.
Figure: Architecture micro-services finale
| Les lendemains du projet
Ce projet a permis de rendre la solution beaucoup plus industrialisée et de nombreuses sondes sont ajoutées continuellement.
Concernant le support, le fait d’avoir des alertes permet de faciliter la compréhension de certains incidents ou encore anticiper des incidents en cascade. La solution de monitoring a pour projet d’évoluer encore. En effet, il est prévu d’améliorer et d’automatiser le déploiement des exportateurs avec l’outil Ansible.
| Mon regard critique
C’est un projet qui m’a permis de beaucoup apprendre et mettre en place concrètement des pratiques DevOps. Je me rends compte que ces pratiques permettent d’améliorer une solution mais aussi le confort de l’environnement d’un développeur. Je trouve ça très satisfaisant et utile d’avoir un déploiement complètement automatisé.
Ce travail m’a aussi permis de me rendre compte de l’importance d’un cahier des charges dans un projet conséquent. En effet, je me suis rendu compte que celui-ci m’a vraiment été utile et m’a permis de traiter tous nos besoins sans m’éloigner des enjeux définis.