En tant que société d'observabilité, New Relic crée et maintient des agents en plusieurs langages qui sont spécifiques à la technologie afin de collecter les données télémétriques des environnements de nos clients. Lorsque ces équipes d'agents publient manuellement de nouvelles mises à jour, elles effectuent de nombreuses vérifications pour s'assurer que le processus n'introduit aucune régression causée par une erreur humaine. Pour réduire le temps nécessaire au déploiement d'une nouvelle version, l'équipe chargée des agents Kubernetes a entièrement automatisé le processus de publication des agents logiciels. Le workflow réutilisable des actions GitHub permet de suivre les dépendances vulnérables, de rédiger la documentation nécessaire et d'effectuer la synchronisation avec des partenaires comme Amazon Elastic Kubernetes Service (Amazon EKS) où qu'ils soient. Autrefois, l'envoi des mises à jour de notre intégration Kubernetes était manuel et prenait jusqu'à deux semaines ; aujourd'hui, c'est un processus automatisé qui prend une heure par semaine.
Diminution du temps de réponse en cas d'incident de sécurité
L'une des principales difficultés que nous rencontrions provenait de la réponse aux vulnérabilités de sécurité : nous ne réagissions à une vulnérabilité que lorsqu'un client contactait l'assistance technique mondiale (GTS) et que le problème s'avérait grave. Cela entraînait la frustration des clients vis-à-vis de nos intégrations et le stress des développeurs, car nous étions obligés d'arrêter le travail prévu pour corriger les logiciels.
Dans le cadre de notre pipeline d'intégration continue (CI), nous avons mis en place des outils d'analyse de code pour nous tenir informés des dernières vulnérabilités découvertes dans notre base de code. Nous avons activé CodeQL pour la recherche des vulnérabilités dans la base de code et nous utilisons Trivy pour nous assurer que les images Docker n'incluent pas de vulnérabilités injectées à partir de l'image de base et de la bibliothèque qui l'accompagne.
L'un de nos cas d'utilisation courants consiste à détecter les vulnérabilités dans notre image de base (Alpine). Ce processus nous alerte des problèmes actuels à résoudre. En combinant l'analyse des vulnérabilités avec la gestion automatique des dépendances, nous sommes en mesure d'apporter des correctifs à la base de code automatiquement sans avoir besoin d'interaction humaine. Nos workflows sont exécutés chaque semaine, ce qui signifie que les clients reçoivent une version corrigée dans la semaine suivant la disponibilité du correctif.
Comme exemple concret de l'amélioration de nos temps de réponse, notre dashboard de sécurité nous alerte des vulnérabilités de sécurité suivantes dans alpine : 3.18.4 (l'image que nous utilisions alors dans l'intégration nri-Kubernetes) :
Ces vulnérabilités ont été corrigées dans alpine:3.18.5 du 30 novembre 2023 et alpine:3.19.0 du 7 décembre 2023. Renovate, notre outil universel de gestion des dépendances, a créé des demandes de tirage pour les deux versions le jour même de leur sortie respective et elles ont été incluses dans la version du 8 décembre 2023, soit un jour après la sortie d'alpine:3:19.0.
Les trois images alpines mentionnées présentaient deux autres vulnérabilités qui ont été détectées par la suite :
- CVE-2023-6129 le 9 janvier 2024
- CVE-2023-6237 le 15 janvier 2024
Ces deux vulnérabilités en attente sont actuellement signalées dans notre dashboard de sécurité.
Dès qu'un correctif est publié par Alpine, nos clients peuvent s'attendre à une version corrigée de notre intégration dans un délai d'une semaine.
Fournissez un support de pointe pour la dernière version de Kubernetes
La prise en charge des nouvelles versions de Kubernetes implique la mise à jour des outils de test tiers et l'exécution de tests de conformité approfondis pour garantir qu'une nouvelle version de Kubernetes n'apporte pas de modifications majeures à notre intégration. Un problème courant que nous devons valider est une API Kubernetes en version alpha ou bêta, car des modifications peuvent y être apportées sans préavis.
Grâce à notre outil de gestion des dépendances entièrement automatisé, une fois que les outils sont en place, nous pouvons y accéder immédiatement. En outre, nos tests de conformité étant entièrement automatisés, nous pouvons accélérer le temps de validation, ce qui nous permet d'être à la pointe du support Kubernetes.
Lorsqu'une nouvelle version de Kubernetes est disponible, il est essentiel de mettre à jour notre workflow de test pour intégrer la dernière version. Renovate, notre outil de gestion des dépendances, a automatiquement ouvert une demande de tirage (PR) pour mettre à jour Minikube vers la dernière version. Nous utilisons minikube pour démarrer rapidement un cluster, puis nous exécutons des tests de bout en bout, et enfin toute la batterie de tests dans chaque version de Kubernetes que nous prenons en charge. Une fois ce minikube mis à jour avec la dernière version de Kubernetes, nous activons les tests pour cette version dans notre framework de test. Si les tests confirment que l'intégration fonctionne comme prévu, nous pouvons déclarer la prise en charge de la dernière version de Kubernetes. En raison de nos workflows automatisés, nous avons mis à jour notre suite de tests pour exploiter la dernière version de Kubernetes le jour même où Minikube a annoncé sa sortie. Cela nous a permis de tester la compatibilité en un jour et de communiquer que notre intégration Kubernetes était compatible avec la dernière version sept jours après la sortie de minikube.
Synchronisez la dernière version de l'agent avec les modules complémentaires AWS EKS Anywhere
New Relic prend en charge le programme partenaire Amazon EKS Anywhere en proposant l'agent Kubernetes en tant que module complémentaire prêt à l'emploi pour le cluster Amazon EKS Anywhere. Nous avons développé un workflow GitHub Actions pour ouvrir automatiquement une demande de tirage lorsque nous publions une nouvelle version de notre agent. Ainsi, les utilisateurs finaux d'Amazon EKS Anywhere disposent de la toute dernière version de l'agent, ce qui garantit que New Relic continue de réussir les tests de conformité les plus récents et d'être un partenaire techniquement validé d'Amazon EKS Anywhere.
Automatisez le changelog, les communications et la documentation
La création et la mise à jour de la documentation sont une perte de temps importante. Pour assurer la cadence hebdomadaire des nouvelles versions, nous devions mettre à jour tous les canaux de communication pour nos parties prenantes internes, ainsi que nos clients et partenaires externes. Afin d'automatiser les communications avec toutes ces parties prenantes, nous avons créé un workflow réutilisable qui est exécuté chaque semaine et met automatiquement à jour les notes de version, envoie des messages sur les dernières versions dans les canaux Slack internes des parties prenantes de New Relic et met à jour la documentation des développeurs.
Notre propre workflow GitHub compile ensuite la documentation et les notes de version, et envoie des messages sur tous les canaux. Pour mieux communiquer avec les parties prenantes internes, nous avons créé notre propre robot d'agent Kubernetes associé au workflow GitHub Actions, afin que nos clients et partenaires puissent être automatiquement informés des mises à jour des versions.
Conclusion
Un pipeline CI facilite la vie des développeurs, mais ce n'est pas son seul avantage : les clients ont aussi accès à des logiciels de pointe qui sont plus sécurisés et mieux documentés.
S'il est efficace, le pipeline CI ne se limite pas à simplement créer l'automatisation dans le processus de publication de l'agent, mais il améliore aussi les tests pour garantir qu'aucune régression n'a lieu au cours du processus, la détection et résolution rapides des vulnérabilités de sécurité, et la notification claire et efficace de toutes les parties prenantes.
Étapes suivantes
Découvrez notre intégration Kubernetes open source et consultez notre documentation pour bien démarrer et obtenir la visibilité voulue sur votre cluster Kubernetes.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.
