Chaque Cloud provider (Azure, AWS, Google Cloud…) a sa propre structure tarifaire et offre des options de tarification différentes. De fait, dans un environnement multicloud, gérer efficacement ses coûts et optimiser l’utilisation de ses ressources peut vite relever du casse-tête. Il est pourtant primordial de surveiller et d’analyser ses dépenses de manière globale, d’identifier les ressources sous-utilisées (ou sur-utilisées) et de prendre des mesures pour optimiser sa gouvernance. En utilisant des outils s’articulant autour de Terraform, Mathieu Minet, Ingénieur Cloud & DevOps, a développé une solution ingénieuse de gestion multicloud capable de répondre très efficacement à cet enjeu de simplification de la gestion du cycle de vie des ressources.
Pourquoi la gestion du cycle de vie des ressources dans ce contexte multicloud peut devenir complexe ?
Dans le cas où un client a déjà une infrastructure multicloud (avec un environnement public ou privé), chaque provider lui propose une interface spécifique pour gérer des ressources. Il peut ainsi savoir qu’il dépense 800 euros par mois sur GCP (Google Cloud Plateform), 900 euros sur Azure, et que toutes ses équipes gèrent l’administration de leur abonnement (par exemple). En revanche le client ne sait pas pour quel projet les ressources sont dédiées. Donc en termes de facturation il va avoir du mal à répercuter les coûts sur les équipes ou les services.
Il s’agit de la problématique principale, mais ce n’est pas la seule. En effet, il est difficile d’estimer combien coûtent les ressources elles-mêmes avec les « calculettes » fournies par chaque Cloud provider. Ces dernières sont en effet compliquées à utiliser car elles proposent absolument tous les paramètres de chaque ressource. Il est alors difficile de connaître tout de suite les bons paramètres à utiliser.
Quelle solution as-tu trouvé pour contourner ces problèmes liés à la gestion multicloud ?
Terraform permet de répondre à ces deux enjeux de gestion multicloud. Plus précisément cet outil est capable de déployer automatiquement n’importe quel type de ressource en s’affranchissant des interfaces web des Cloud providers. Il est ainsi possible de gérer ces ressources de multiples façons, en leur apposant par exemple des « étiquettes » (des tags) pour pouvoir les tracer. Chaque ressource peut ainsi se voir attribuer soit un environnement, soit un projet, et être associée à un outil budgétaire. Par exemple, toutes les ressources qui sont taguées par Terraform avec « service x » seront facturées au service x ou au service associé à celui-ci.
Terraform permet également de savoir qui utilise les ressources (parfois couteuses), si elles sont vraiment encore nécessaires pour tel ou tel projet, et si elles peuvent éventuellement être supprimées. Il devient alors aisé de gérer le cycle de vie de ces ressources, que ce soit pour la création, la modification ou la suppression de celles-ci.
Prenez rendez-vous pour échanger avec nos experts Terraform !
Terraform est également utile pour gérer des ressources en amont de projet ?
Oui car Terraform fonctionne de la manière suivante : il possède un fichier dans lequel toutes les ressources nécessaires sont déclarées, avec les paramètres définis. Via un appel API vers le Cloud provider associé, il va vérifier depuis son code les différences entre la demande déclarée (le fichier de configuration) et ce qui est éventuellement déjà en place chez le provider. Ainsi, il ne va mettre en œuvre que ce qui est strictement nécessaire. Il peut alors détruire ou recréer des ressources si besoin, dans le bon ordre et de façon totalement autonome (dans la limite de ce qui lui est déclaré et des dépendances de certaines ressources entre-elles). Et comme il est possible de taguer les ressources par projet, par service ou par environnement, le suivi est très facile à condition de penser à mettre en œuvre cette pratique.
De même, dans un contexte de move to cloud avec des ressources initialement on-premise, les organisations peuvent créer « à la main » de nouvelles ressources sur des plateformes Cloud, puis opérer la migration… et finalement ne plus savoir à qui appartient telle ou telle ressource. Dans un projet move to cloud qui intègre Terraform, le problème ne se pose pas puisque toutes les ressources sont fabriquées avec de l’IaC (Infrastructure as Code). Sans un suivi complet de toutes les ressources déployées dans le Cloud, la promesse initiale d’une économie de coût apportée par l’externalisation de celles-ci n’est plus mesurable.
Peux-tu nous donner un peu plus de détails sur la solution de que tu as conçue et ses perspectives ?
Prenons le cas de ressources déjà déployées mais peu suivies qu’il faut réintégrer dans Terraform pour mieux gérer le cycle de vie de celles-ci, ainsi que la facturation. Grâce à l’ID de chaque ressource, Terraform est capable d’identifier à quel type elle appartient, depuis quel provider, et de créer du code IaC pour la prendre en charge. Pour autant avant la version 1.5 ce n’est pas une procédure standard, la démarche étant unitaire. Il fallait donc industrialiser la méthode avec l’outil TerraCognita, qui fait du « reverse Terraform ». Le principe est simple : TerraCognita va scanner via une API l’ensemble des ressources déployées dans les ressources groupes, puis les réintégrer dans le fichier state (de référence) de Terraform en produisant le code associé. Terraformer permet également de faire ce genre de manipulation. Ces manipulations vont donc devenir de l’histoire ancienne avec l’annonce de l’intégration IaC des ressources déployés hors Terraform dans la toute dernière version.
J’ai également mis en place une chaîne d’intégration basée sur Terraform pour déployer des ressources, complétée avec Tflint, Infracost et TFSec. Tflint est un linter qui va me permettre de faire une vérification syntaxique et sémantique de tout mon code et de m’assurer qu’il est propre. Infracost de son côté va me servir pour faire une estimation du coût de mes ressources depuis les paramètres du code. Car si les Cloud providers peuvent vous dire combien coûte votre écosystème à un instant T, ils sont incapables de simuler le coût d’une architecture qui n’est pas encore déployée, à l’instar d’un devis comme c’est le cas avec Infracost.
TFSec quant à lui me permet de m’assurer que chaque ressource déployée est sécurisée et ne présente pas une configuration qui pourrait permettre à un programme malveillant de l’attaquer. Il utilise pour cela une base de connaissances de méthodes sécurisées pour le déploiement de différentes ressources, et peut même me dire de façon très fine combien vont me coûter les options de sécurisation. J’ai également testé le scanner de sécurité Checkov (développé par PRISMA Cloud), ce dernier semble encore plus exigeant que TFSec. Hashicorp va d’ailleurs proposer prochainement un workshop orienté DevSecOps en proposant d’utiliser Checkov.
Tous ces outils sont intégrés en cascade dans ma chaine qui est valable pour tous mes projets Terraform, c’est une solution sur étagère. Elle va ainsi d’abord jouer mon Tflint qui, si le code est bon, va déclencher le scan de sécurité. Si toutes les ressources créées respectent les normes de sécurité selon TFsec, Infracost va alors se déclencher, le tout automatiquement. Il est donc tout à fait possible d’initier un projet GitHub et d’utiliser directement ma chaîne CI/CD via les GitHub Actions.
Enfin la prochaine étape consiste à créer une chaîne CI/CD dans le cadre des développements de modules Terraform (donc pas uniquement pour les projets de déploiement/gestion des ressources). Avec l’intégration du scanner de sécurité Checkov à la place, ou en parallèle, de TFSec.
Vous souhaitez échanger avec nos experts autour de vos enjeux et de la gestion du cycle de vie des ressources dans un contexte multicloud, c’est par ici !
Sans un suivi complet de toutes les ressources déployées dans le Cloud, la promesse initiale d’une économie de coût apportée par l’externalisation de celles-ci n’est plus mesurable.