Afin de savoir si le déploiement d’un système s’est bien déroulé, il est nécessaire de le monitorer ou le superviser. Cela permet de prendre des décisions plus rapides, comme le rollback automatique d’une application si celle-ci ne fonctionne pas.
Les deux dernières étapes de notre pipeline de livraison continue sont donc le monitoring de l’application, afin de savoir si celle-ci fonctionne correctement ou présente des erreurs, ainsi que l’activation de notifications en cas de problème, pour avoir un feedback rapide.
Supervisez votre application avec Prometheus
Dans cette section, vous allez ajouter dans GitLab la récupération des métriques de l’application. Lors du déploiement de l’application, des métriques sont exposées par Prometheus, qui est un des composants de notre stack technique.
Je vous invite à suivre les manipulations présentées dans la vidéo ci-dessous.
Vous pouvez maintenant observer vos métriques.
Ces métriques sont très utiles pour prendre des décisions sur le déploiement en production. Ici, nous voyons que les connexions HTTP se font bien et nous sommes donc confiants sur la mise en production.
D’autres types de métriques sont aussi accessibles via GitLab, afin de prendre des décisions et voir la productivité de l’équipe.
Par exemple, lors du précédent chapitre, vous avez déployé un environnement Canary afin d’analyser le comportement de l’application. Pour voir comment cet environnement se comporte et si celui-ci est viable, allez dans le menu Operations, puis Environments. Vous devriez voir votre nouvel environnement canary et voir les métriques associées.
Pour voir la performance et la productivité de l’équipe, GitLab intègre aussi des métriques concernant le code, les issues, ou encore le temps d’exécution des tests. Ces différentes métriques sont disponibles dans le menu Analytics, sous-menu Value stream.
Les métriques les plus intéressantes sont celles qui fournissent des indicateurs sur la vélocité et la productivité de l’équipe. Par exemple, il est possible de voir le temps entre la création d’une issue et sa résolution dans la rubrique Review.
Il est aussi possible de voir le temps de déploiement sur les différents environnements. Plus cette valeur est petite, plus il est facile de déployer sur les environnements.
Il y a aussi d’autres métriques qui existent concernant le code. Par exemple, vous pouvez voir le nombre de commits, ainsi que les différents contributeurs dans le menu Repository, sous-menu Contributors.
Il est aussi intéressant de voir le nombre de commits par jour, pour évaluer le temps de travail de chaque développeur. Cette métrique est disponible dans le même menu, sous-menu Charts.
Surveillez vos logs applicatifs grâce à Elasticsearch
Une étape importante après la mise en production est de surveiller les logs applicatifs à l’affût de bugs et autres attaques de sécurité que l’application pourrait subir.
Pour toutes vos applications, le mieux est de centraliser les logs applicatifs dans un dépôt central dans lequel vous pourrez naviguer à la recherche de bugs. L’avantage d’avoir un dépôt central est de pouvoir avoir tous les logs à la même place, de pouvoir faire des corrélations, mais aussi de garder une trace si jamais l’application devait être piratée.
La plus connue des applications de centralisation des logs est Elasticsearch. Malheureusement, Elasticsearch n’est qu’un dépôt de logs. Il est nécessaire d’avoir une interface pour pouvoir requêter ce dépôt. L’interface naturelle d’Elasticsearch est Kibana, qui permet de naviguer dans ces logs et de pouvoir avoir des dashboards contenant des métriques sur le nombre de bugs d’application, mais aussi des informations applicatives sur le nombre d’utilisateurs connectés, ou encore des graphiques sur la sécurité des applications.
Cette dernière fonctionnalité est pour moi une des plus importantes car elle permet de mettre en place une gestion de l’information des événements de sécurité, aussi appelée SIEM (Security Information and Event Management). Un SIEM désigne :
les capacités de collecte, d’analyse et de présentation de l’information provenant du réseau et des dispositifs de sécurité ;
les applications de gestion des identités et des accès ;
les outils de gestion des vulnérabilités et de conformitéaux politiques ;
le système d’exploitation, la base de données et les journaux d’application ;
les données sur les menaces externes.
Elasticsearch permet de mettre en place rapidement et simplement un SIEM sur vos applications.
Le SIEM est généralement utilisé au sein d’un SOC (Security Operations Center) qui est une plateforme permettant la supervision et l’administration de la sécurité du système d’information au travers d’outils de collecte, de corrélation d’événements et d’intervention à distance.
L’objectif d’un SOC est de détecter, analyser et remédier aux incidents de cybersécurité à l’aide de solutions technologiques et d’un ensemble de démarches. Ils surveillent et analysent l’activité sur les réseaux, les serveurs, les terminaux, les bases de données, les applications, les sites web et autres systèmes, à la recherche de signaux faibles ou de comportements anormaux qui pourraient être le signe d’un incident ou d’un compromis en matière de sécurité. Le SOC doit veiller à ce que les incidents de sécurité potentiels soient correctement identifiés, analysés, défendus, enquêtés et signalés.
Diagnostiquez la performance de votre application PetClinic
Dans cette section, nous allons regarder comment l’observabilité peut être utile dans une application distribuée. La version que nous manipulons depuis le début de ce cours est une version microservice qui déploie plusieurs conteneurs.
Ce genre d’architecture s’appelle un système distribué, car les fonctionnalités sont distribuées à travers plusieurs services. Ce type d’architecture est plus complexe que les architectures traditionnelles 3-tiers, car un ou plusieurs services peuvent être responsables de goulots d’étranglement sans que le diagnostic soit facile.
Dans le cas d’une architecture traditionnelle, les problèmes de performance peuvent être liés au serveur d’application comme Tomcat ou Apache, soit liés à l’interface (Angular, React), ou encore liés à la base de données. Ces problèmes peuvent être aussi dus au réseau informatique mal dimensionné. Dans une architecture distribuée, chaque service peut être responsable d’une dégradation de performance. Dans ce cas, pour diagnostiquer le problème, il faudrait passer sur chacun des services et regarder si ce service est responsable de problèmes de performance. Si l’application est composée d’une dizaine de microservices, voire plus, le diagnostic devient quasiment impossible.
C’est pourquoi, depuis quelques années, le terme d’observabilité est de plus en plus utilisé. Le but est d’avoir des métriques complètes de chaque service et les mettre en corrélation afin d’avoir une vue holistique de l’application, et non service par service.
L’observabilité est aussi très utile dans de larges systèmes distribués complexes basés sur des microservices où la détection de goulots d’étranglement peut être compliquée. Généralement, des techniques comme le distributing tracing sont utilisées.
Lors du déploiement de l’application PetClinic, une application d’observabilité, Zipkin, a été déployée.
Zipkin est accessible sur le port 9411 sur Play-with-Docker. Si, dans un premier temps, vous allez sur l’application PetClinic déployée sur le port 8080 pour générer un peu de trafic, puis que vous retournez sur Zipkin, voici les traces que vous pouvez obtenir.
Mettez en place des notifications Slack
La dernière étape du pipeline de livraison continue est l’étape de feedback rapide. Cette étape est celle qui va nous permettre de faire le lien entre la production (ops) et les développeurs (dev). C’est une étape qui donne de la visibilité aux développeurs sur des problèmes qu’il peut y avoir en production. Plus rapide est la détection des problèmes, plus rapide est leur correction.
Cette étape est le lien final qui permet d’avoir notre amélioration continue durant tout le cycle de vie de l’application. GitLab permet l’intégration avec beaucoup d’applications tierces. L’intégration la plus simple est l’intégration email. Je vous invite à suivre les manipulations présentées dans la vidéo ci-dessous.
En résumé
La supervision du comportement d’une application permet de s’assurer qu’une application fonctionne correctement et de prendre des décisions rapides.
Prometheus permet de récupérer des métriques de votre application.
Elasticsearch permet la surveillance de vos logs applicatifs.
La mise en place de notifications, grâce à Slack, permet d’avoir un feedback rapide en cas de problème.
Ce dernier chapitre conclut notre cours sur l’intégration continue et la livraison continue.
Bravo ! Vous voici à présent au terme de ce cours. J’ai été ravi de travailler sur ce cours et j’espère qu’il vous permettra de réaliser vos projets ! Avant de nous quitter, je vous invite à tester vos connaissances dans le quiz clôturant cette seconde partie du cours.
