L'un des aspects que j'apprécie le plus dans mon rôle de CTO chez DoiT International, ce sont mes échanges quotidiens avec nos clients. Ils sont souvent éclairants et m'apprennent toujours quelque chose de nouveau.
La semaine dernière, j'ai repéré un ticket d'un de nos clients qui se demandait quelle était la meilleure manière d'intégrer Google Cloud Platform à Slack.
Plus précisément, il voulait recevoir des notifications dans son canal Slack dès qu'une activité se produisait sur l'un de ses projets Google Cloud : démarrage ou arrêt d'instance, création ou suppression de bucket, etc. Plutôt sympa comme idée, non ? Une recherche rapide sur google.com n'ayant rien donné, j'ai dû trouver moi-même la façon la plus rapide et la plus simple d'intégrer Slack à Google Cloud Platform.
Heureusement, il existe une solution élégante et 100 % serverless, que je vais tenter de détailler dans ce billet. Et mieux encore : nous publions aujourd'hui gSlack en open source. Vous pouvez le déployer dans votre propre projet GCP en quelques minutes et recevoir instantanément des notifications personnalisables dans votre canal Slack.
gSlack repose sur Stackdriver Logging — la plateforme de logging centralisée de Google, qui permet de stocker, rechercher, analyser et surveiller les données et événements de logs issus de Google Cloud Platform (et d'Amazon Web Services), ainsi que de déclencher des alertes. La plupart des services cloud de Google y envoient leurs logs. Je m'intéressais en particulier aux Activity Logs, qui recensent les modifications apportées à l'environnement Google Cloud Platform.
Voici à quoi cela ressemble dans la Google Cloud Console :
Interface de Google Stackdriver Logging
L'une des fonctionnalités les plus astucieuses de Stackdriver Logging est sa capacité à exporter automatiquement les nouvelles entrées de logs vers Google Cloud Storage, Google BigQuery et Google Pub/Sub. Il suffit de configurer un export, et tout le reste se fait comme par magie.
Il me fallait un transport capable de relayer les entrées de logs entre Stackdriver Logging et Slack ; Pub/Sub semblait l'option idéale pour ce cas d'usage. Si vous ne le connaissez pas, Pub/Sub est le service de messagerie temps réel entièrement managé de Google, qui permet d'échanger des messages entre applications indépendantes.
Mettre en place un export Pub/Sub se résume à configurer un filtre de logs (je n'ai besoin que des logs de type activity, d'où le logName="projects/doit-playground/logs/cloudaudit.googleapis.com%2Factivity") et le nom du topic Pub/Sub vers lequel envoyer les messages :
Configuration du sink Pub/Sub
Désormais, dès qu'une nouvelle entrée apparaît dans Stackdriver Logging, elle est automatiquement transmise à mon topic Pub/Sub. Plutôt sympa, non ?
Restait à mettre un peu de glue entre Pub/Sub et Slack, pour que les nouveaux messages publiés sur Pub/Sub soient relayés sous forme de notifications Slack. Heureusement, Google propose désormais (en bêta) Cloud Functions — un environnement serverless pour créer et connecter des services cloud. Concrètement, vous codez une function en NodeJS, déclenchée par l'un des triggers pris en charge : nouveau fichier dans un bucket, requête HTTP ou (vous l'aviez deviné !) — nouveau message dans un topic Pub/Sub !
Notre flux complet ressemble donc à ceci : Stackdriver Logging enregistre une activité dans notre projet, l'envoie automatiquement à un topic Pub/Sub qui, à son tour, déclenche une Cloud Function envoyant un message au canal Slack via le SDK NodeJS officiel de Slack.
Schéma d'architecture de gSlack
Pour configurer Cloud Functions, il vous faudra uploader une archive zip contenant le code et votre fichier package.json :
Configuration de Google Cloud Functions
Pour éviter d'envoyer dans le canal Slack chaque entrée de log d'activité (certaines ont peu d'intérêt) et mieux formater les messages publiés sur Slack, j'ai opté pour un autre service managé de Google : Google Cloud Datastore.
Google Cloud Datastore est une base NoSQL documentaire managée, conçue pour le scaling automatique, les hautes performances et la simplicité de développement. Elle s'intègre nativement à Cloud Functions et propose une interface pratique pour modifier rapidement les entrées (kinds et properties dans la terminologie de Datastore).
Il nous faut un service comme Google Cloud Datastore pour stocker de manière persistante la configuration runtime de gSlack, notamment la définition des messages à publier et leur rendu dans Slack.
Édition des données de Datastore via l'interface intégrée
Pour chaque ensemble d'entrées de logs, vous devrez configurer test, message et le slackChannel sur lequel publier la notification.
Le test doit être une expression JS valide qui renvoie un booléen. S'il renvoie true, le test passe et le message part vers Slack. Par exemple, pour ne conserver que les messages issus de Google Compute Engine et suivre les événements start et stop d'instances, on peut utiliser le test suivant :
$.protoPayload.serviceName==='compute.googleapis.com' && ( $.protoPayload.methodName==='v1.compute.instances.start' || $.protoPayload.methodName==='v1.compute.instances.stop') && $.operation.lastDe même, le message doit être un template de chaîne JS valide. Il sera évalué pour produire le message envoyé. Par exemple :
Instance '${$.protoPayload.resourceName.split('/').slice(-1)[0]}' was ${$.protoPayload.methodName==='v1.compute.instances.start'?'started':'stopped'} at zone '${$.resource.labels.zone}' by '${$.protoPayload.authenticationInfo.principalEmail}' in project '${$.resource.labels.project_id}'Résultat : la notification ci-dessous arrive dans Slack. Lors de mes tests, il s'écoule environ 5 secondes entre l'événement réel et la réception du message dans le canal Slack.
Notification Slack réelle
Vous pouvez ajouter autant de tests et de messages que vous le souhaitez, et parser différents services Google Cloud Platform : Compute Engine, App Engine, Cloud Storage, BigQuery, et même Billing. Le dépôt gSlack en propose d'ailleurs plusieurs exemples.
Le code complet ainsi que les instructions de déploiement sont disponibles sur le dépôt gSlack sur GitHub. N'hésitez pas à le starrer ou à proposer une pull request pour améliorer gSlack ;-)
Comme toujours, vous pouvez me joindre à [email protected] pour me faire part de vos suggestions et idées.
P.S. Merci à Shahar Frank, Cloud Architect chez DoiT International, qui a codé l'intégralité de cet exemple en quelques heures et m'a aidé à préparer ce billet.