Dernier sorti, éteins les lumières | de Daniel Fratte | décembre 2022

Comment automatiser le provisionnement des ressources cloud pour les environnements de développement et de test

Dans le contexte de rendre l’information et la technologie cloud plus durables, il y a beaucoup de place pour les outils, les techniques et les principes qui permettent une utilisation optimale de l’infrastructure cloud.

Dans cet esprit, je jouais avec l’idée simple que les environnements de développement et de test pourraient ne pas être nécessaires lorsque les ingénieurs, les analystes qualité, etc. ne sont pas là pour les utiliser. Ainsi, le nom de cet article m’a fait penser… si je travaille à mon bureau et que je suis le dernier sorti, on me demande probablement (logiquement) d’éteindre toutes les lumières.

Pourquoi n’activerais-je pas et n’éteindrais-je pas les environnements cloud que je ne serai pas là pour utiliser pendant les heures creuses ou les week-ends ?

Lambda saver est une expérience simple qui vise à répondre à ce cas d’utilisation (et à mon besoin interne d’en savoir plus sur les rouages ​​du « cloud »). Il s’agit d’une fonction qui peut être invoquée pour activer et désactiver les environnements de développement et de test selon un calendrier spécifique.

La solution consiste essentiellement à créer un AWS Event Bridge règle pour 9h00 et 18h00 Cela déclencherait l’exécution d’un AWS Lambdaqui démarrera/arrêtera les environnements de développement et de test en conséquence en fonction des balises associées à ces instances de calcul.

Cette solution résume des détails tels que la périodicité de la règle d’événement, l’infrastructure sous-jacente et le service cloud utilisé pour héberger ces environnements, l’état initial de ces instances lorsque la fonction est invoquée, la technique utilisée pour les identifier, le chemin vers la production et les tests. stratégie utilisée, parmi d’autres qui sont ignorées en raison de la nature expérimentale d’une preuve de concept.

Le code lambda lui-même a intégré les balises nécessaires à travers lesquelles je souhaite filtrer ces environnements.

Dans ce cas, ce sont Env=dev et Env=test. Au début, j’ai essayé l’invocation lambda pour inclure les balises dans le cadre de la charge utile de l’appel, mais je n’ai pas trouvé de moyen fiable de déclencher un événement planifié pour une invocation lambda avec une telle charge utile. Ainsi, j’ai décidé de les conserver dans la base de code pour le moment, même si cela pose une contrainte en termes de balises sur lesquelles vous souhaitez filtrer.

De plus, il existe d’autres moyens d’obtenir la même fonctionnalité. Planificateur d’instances AWS peut être une très bonne alternative. Cela nécessite également que les instances que vous ciblez soient étiquetées et que vous définissiez la période, le calendrier, entre autres ressources.

Ce qu’il faut retenir, c’est que l’inefficacité du cloud prend généralement la forme de petits problèmes dispersés qui, ensemble, ont un impact très important sur notre facture cloud (et en termes d’émissions de carbone également).

Vous pouvez commencer à les aborder de manière pragmatique en analysant le contexte actuel de votre équipe et en remettant en question vos propres hypothèses sur pourquoi vous faites ce que vous faites de la façon dont vous le faites. En savoir plus sur ce processus de détection des inefficacités dans une entrée de suivi.

Comme d’habitude, le code est disponible ici et tous les commentaires et améliorations sont les bienvenus.