Iris 3 : labellisation automatique pour maîtriser les coûts

En 2018, DoiT International a publié Iris, un projet open-source dédié à la labellisation automatique des ressources sur Google Cloud. J'ai aujourd'hui le plaisir d'annoncer Iris 3, enrichi de nouvelles fonctionnalités et reposant sur une implémentation modernisée.

Iris attribue automatiquement des labels aux ressources Google Cloud pour produire des rapports de facturation plus simples et plus détaillés.

Chaque ressource Google Cloud de l'organisation GCP reçoit des labels générés automatiquement qui reflètent ses caractéristiques. Par exemple, une instance Google Compute Engine reçoit des labels comme [iris_name:nginx] et [iris_region:us-central1]. (Le préfixe est configurable.)

Cela peut surprendre, mais sans ces labels, l'information n'est tout simplement pas disponible dans les données de facturation.

Avec ces labels, vous pouvez créer des rapports dans votre outil d'analyse de facturation préféré.

Voyons comment Iris peut vous faire gagner du temps lors de la création de rapports sur vos factures cloud, à travers deux systèmes de reporting :

1. La Cloud Management Platform de DoiT International
2. La Billing Console de Google Cloud

DoiT Cloud Management Platform

Dans l'interface Cloud Reports de la Cloud Management Platform, créez un rapport sur la période et les champs de votre choix, puis cliquez sur la puce Labels pour sélectionner le ou les noms de labels, par exemple iris_instance_type. Cliquez sur la nouvelle puce de label (iris_instance_type) pour filtrer par valeurs spécifiques. À ce stade, vous pouvez aussi exclure les ressources non labellisées, par exemple celles des projets qu'Iris 3 a été configuré pour ignorer.

Faites ensuite glisser la puce de label vers le panneau de gauche pour définir le regroupement, et le tour est joué.

Reporting par type d'instance dans la Cloud Management Platform

J'aimerais évidemment vous compter parmi nous chez DoiT, mais tout le monde n'y est pas encore — vous pouvez donc faire la même chose dans les rapports de facturation natifs de GCP.

Dans une vue de la Billing Console, créez un rapport sur la période et les champs de votre choix, puis cliquez sur Labels dans le panneau en bas à droite et saisissez le nom de votre ou vos clés de label, par exemple iris_instance_type. Vous pouvez sélectionner des valeurs spécifiques à ce stade pour filtrer. (Les ressources non labellisées seront automatiquement exclues.) Remontez ensuite à Grouping et saisissez à nouveau votre label.

Reporting par type d'instance dans la Billing Console

À ce jour, les types de ressources suivants sont pris en charge :

• Instances Compute Engine (y compris preemptible et celles créées par les Managed Instance Groups), Disks et Snapshots. (Labels : nom, région, zone et type d'instance)
• Buckets Cloud Storage (nom)
• Instances CloudSQL (nom et région)
• Datasets et tables BigQuery (nom et emplacement)
• Instances BigTable (nom, région et zone)
• Topics et Subscriptions PubSub (nom)

Vous pouvez facilement ajouter d'autres types de labels et de ressources. Voir les instructions ici.

Iris fonctionne à la fois selon une planification et au moment de la création des ressources :

• Tous les types de ressources sont labellisés selon une planification, toutes les 12 heures (configurable). Certains types — instances Cloud SQL et boot disks créés avec une instance — sont labellisés uniquement selon la planification.
• La plupart des ressources sont également labellisées dès leur création : Iris 3 le fait en écoutant les logs de Google Cloud Operations.

Iris apporte des améliorations significatives, à la fois par l'ajout de fonctionnalités et grâce à une nouvelle plateforme sous-jacente.

Nouvelles fonctionnalités

• Labellisation des Topics et Subscriptions PubSub, ainsi que des instances Cloud SQL
• Une option pour copier automatiquement les labels du projet sur chaque ressource du projet
• Une option pour choisir les projets à labelliser (si seuls certains projets en ont besoin, ce qui permet aussi de réduire les coûts) ; ou, à l'inverse, pour labelliser les ressources de tous les projets de l'organisation entière
• Une option pour réduire les coûts en utilisant uniquement la labellisation planifiée, sans labellisation à la demande
• Développement et configuration des plugins bien plus simples. (Détails ici.)
• Tests automatisés pour la qualité
• Corrections de bugs, optimisations et améliorations. (Détails ici.)

Nouvelle plateforme

Mais le changement le plus important, et la raison du nouveau nom et du fork du repo, c'est le portage de Python 2 vers la version Python 3 de Google App Engine Standard Environment. Le langage Python 2 est en fin de vie et n'est plus supporté depuis janvier 2020, et la version Python 2 de GAE est dépréciée depuis encore plus longtemps.

Google s'est engagé à fournir un support à long terme pour la version Python 2 de GAE, en raison des clients historiques qui auraient des difficultés à migrer. Mais développer de nouvelles fonctionnalités sur cette ancienne version oscille entre le difficile et l'impossible : les outils de développement et de déploiement, les runtimes et les API accusent leur âge. De plus, Google ne peut plus s'engager à corriger l'ensemble des failles de sécurité, ce qui constitue un signal d'alarme majeur pour une application web.

La migration a nécessité de nouvelles API : entre autres changements, la prise en charge des Task Queues a été supprimée et PubSub a été utilisé à la place.

Mieux encore, c'était l'occasion d'une réécriture complète avec un style de code propre et standard, une duplication de code réduite et d'autres améliorations qui faciliteront la vie des développeurs et des contributeurs aux pull requests.

Cette version réside dans un repo distinct, sous un nouveau nom.

En effet, beaucoup d'utilisateurs préfèrent rester sur la version Python 2 de GAE aussi longtemps que possible — bien qu'elle soit obsolète ! — en raison de ses différences notables avec la version Python 3.

Le 3 n'est évidemment pas un numéro de version : c'est un hommage à la plateforme GAE Python 3.

Téléchargez Iris 3 depuis GitHub et suivez les instructions pour le déployer, le développer ou le tester. J'attends avec impatience vos retours et vos signalements de problèmes. Et surtout, consultez le fichier TODO.md et envoyez quelques pull requests !

GCP Auto-Tag est un autre projet open-source de DoiT dédié à la labellisation automatique des instances et des disques à leur création.

Les différences :

• Contrairement à Iris 3, GCP Auto-Tag ajoute des labels avec l'e-mail du créateur et, pour les disques, le nom de l'instance à laquelle le disque est rattaché
• GCP Auto-Tag labellise les boot disks à la création, en même temps que l'instance.
• Contrairement à Auto-Tag, Iris 3 ajoute des labels avec un nom, une zone, une région et un type d'instance.
• Iris 3 prend en charge davantage de types de ressources.
• Iris 3 couvre plusieurs projets au sein d'une organisation et copie les labels du projet sur les ressources.
• Iris 3 labellise même les ressources créées avant son déploiement.

Pour aller plus loin sur Iris :

• Un article sur le suivi des coûts par région ou par d'autres champs. Cet article porte sur reOptimize, mais le même principe s'applique à la nouvelle Cloud Management Platform de DoiT
• Bonnes pratiques de labellisation des ressources.