Terraform fait déjà partie des flux de travail GitOps de certaines entreprises, mais une nouvelle fonctionnalité de validation continue pourrait accroître les chevauchements avec des outils tels qu’Argo CD et Flux.
HashiCorp a lancé la semaine dernière une nouvelle fonctionnalité de validation continue en bêta publique pour Terraform Cloud, qui pourrait élargir les possibilités d’utilisation de la plateforme dans le cadre d’une approche GitOps.
La validation continue fait suite à une autre fonctionnalité introduite en juin, appeléedétection de dérive (Detection Drift),en disponibilité générale pourTerraform Cloud Businessdepuis le mois dernier. La détection de dérive vérifie si des modifications ont été apportées aux configurations d’état de l’infrastructure en dehors du flux de travail Terraform. La validation continue, elle, élargit cette fonction pour effectuer des contrôles de santé perpétuels en prenant en compte un plus large ensemble de critères.
Par exemple, la validation continue de Terraform peut détecter si une ressource utilise une image Amazon Machine Image (AMI) approuvée, une image HashiCorp Packer ou un certificat de sécurité valide.
« Il peut y avoir une vulnérabilité de sécurité qui vous oblige à déployer une nouvelle version pour une image [de machine] », explique Meghan Liese, directrice principale du marketing produit chez HashiCorp, lors d’un point presse. « [La validation continue de Terraform] vérifiera que l’image déployée est la dernière version promue, et si ce n’est pas le cas, elle enverra une notification. »
Parallèlement à cette notification, la détection de dérive de Terraform Cloud proposera aux utilisateurs des options de remédiation automatisées. Cette fonctionnalité n’a pas été spécifiquement mentionnée, mais elle pourrait suivre, suivant l’éditeur. La version self-managed de Terraform Enterprise profitera également de la validation continue dans une prochaine version.
Terraform et l’approche GitOps : plus de questions que de réponses définitives
Selon les analystes, ces mises à jour pourraient permettre à Terraform de remplacer les outils GitOps au niveau des applications, comme Argo CD et Flux.
Sur le spectreDevOps, l’approche GitOps se situe un peu plus à gauche – plus proche des développeurs de logiciels – que Terraform, qui est axé sur l’infrastructure, avance Meghan Liese, interrogé sur le sujet. Lorsque SearchIToperations [propriété de Techtarget, également propriétaire du MagIT] a demandé directement au cours du briefing si la validation continue pouvait remplacer Argo CD, elle n’a pas pris position.
« C’est possible, mais j’ai besoin d’en savoir plus sur les détails [de ce scénario] », répond-elle.
Mais pour l’analyste d’IDC Jim Mercer, qui a insisté auprès de Meghan Liese sur ce point, ces questions restent ouvertes. La validation continue de Terraform ressemble à une réconciliation de dérive de cluster, connue sous le nom d’autoguérison dans Argo CD ou de commande de réconciliation dans Flux, avance-t-il.
« On a vraiment l’impression que cela empiète sur quelque chose comme Argo dansune approche GitOps, pour tenter d’arrêter la dérive de la configuration », déclare Jim Mercer. « Je ne sais pas quel est le câblage exact, mais cela ressemble pour moi à un réconciliateur ».
La grande différence – pour l’instant – c’est qu’Argo s’autorépare et Flux applique automatiquement l’état souhaité d’un clusterKubernetesou d’une application dès qu’une dérive est détectée. De son côté, la détection de dérive et la validation continue de Terraform Cloud notifient un administrateur de la dérive et exigent qu’il prenne des mesures pour y répondre.
Ainsi, comme dans le cas des mises à jour de Boundary, qui poussent le fournisseur dans la gestion des accès privilégiés, et d’une nouvelle passerelle API, qui amène Consul dans un nouveau segment de la mise en réseau cloud-native, ce n’est pas encore un équivalent exact aux solutions concurrentes établies. Mais Terraform Cloud pourrait le devenir si HashiCorp décide de s’engager dans cette voie, selon l’analyste d’IDC.
Selon un autre analyste, HashiCorp pourrait faire un pas de plus vers l’approche GitOps.
« Ils ont les pièces – ils ont même un opérateur Terraform qui fonctionne sur Kubernetes qui, connecté à la validation continue, peut très bien faire des choses liées à l’approche GitOps aujourd’hui », avance Gregg Siegfried, analyste chez Gartner. « Mais d’un autre côté, Terraform est beaucoup plus complet que cela. HashiCorp pourrait également considérer l’approche GitOps comme une distraction. »
Un client de Terraform Cloud qui a présenté son cas d’usage lors de Haschiconf Global utilise déjàl’infrastructure as codedans le cadre d’un flux de travail GitOps, où un outil maison joue le rôle que jouerait Argo CD ou Flux pour les applications Kubernetes. Il a déclaré qu’il était prêt à envisager Terraform pour remplacer ces outils.
« Notre équipe support n’a pas accès aux ressources de production, car nous utilisons une infrastructure immuable. Mais nous envisagerons d’inclure ce type de contrôle et de validation de manière automatisée », déclare Andrew Rau, vice-président et responsable des services cloud chez BOK Financial, lors d’une interview après sa présentation. « Ce n’est pas parce que nous avons ce produit [Kubernetes GitOps] développé en interne que nous allons le conserver – et si nous n’avons pas à gérer le code [dans Terraform Cloud], tant mieux. »
Terraform Cloud intègre OPA et des fonctionnalités « no-code »
Si Hashicorp peut se poser en alternative aux autres solutions GitOps, Open Policy Agent (OPA), le rival de son propre système de gestion des politiques, Sentinel, s’impose. Si bien que l’éditeur ait annoncé la prise en charge native du moteur de policy as code.
« Nous pensons que Sentinel est le meilleur moyen d’exécuter des politiques. Nous avons écrit son langage spécifique au domaine de manière à le rendre hautement personnalisable et très granulaire », affirme-t-elle dans sa présentation. « Cependant, nous reconnaissons qu’il y a tout un marché autour dupolicy as code, et nous y avons un certain nombre de partenaires. [Terraform] devrait être l’endroit où les politiques sont appliquées, mais nous ne nous soucions pas vraiment du cadre de politique que les [utilisateurs] choisissent ».
« Sentinel est utilisé dans d’autres produits que Terraform, mais de nombreuses organisations ont opté pour OPA et elles ne veulent pas écrire deux fois les règles. »
Gregg SiegfriedAnalyste chez Gartner
Gregg Siegfried, lui, perçoit cela comme un probable glas pour Sentinel.
« Sentinel est utilisé dans d’autres produits que Terraform, mais de nombreuses organisations ont opté pour OPA et elles ne veulent pas écrire deux fois les règles », observe l’analyste de Gartner. « Lorsque HashiCorp a créé Sentinel, OPA était beaucoup moins mature. Et [avant Terraform] la détection des dérives était disponible, si vous vouliez appliquer une politique au-delà de la planification et du déploiement, vous deviez de toute façon utiliser autre chose. »
Enfin, un nouveau flux de travail de provisionnement no code pour Terraform Cloud, également présenté en version bêta la semaine dernière, ajoute une interface utilisateur graphique aux registres privés Terraform. Les administrateurs des opérations IT peuvent utiliser cette interface pour publier un catalogue de modules Terraform à disposition des développeurs sans qu’ils aient à comprendre le langage spécifique (DSL) de Terraform.
Un utilisateur de Terraform se montre réticent à cette idée et affirme que, selon lui, les ingénieurs logiciels devaient comprendre l’infrastructure as code.
« Si vous ne pouvez pas me dire comment [votre application] fonctionne sur l’infrastructure que vous ciblez... vous ne comprenez pas le comportement de votre charge de travail sous contrainte », tranche Martin Eggenberger, architecte en chef chez Monster Worldwide Inc, propriétaire du site Web d’embauche et de recrutement Monster.com.
C’est peut-être un idéal, selon Gregg Siegried, mais la démarche d’HashiCorp s’inscrit dans la tendance desplateformes DevOps,stimulée par la rareté des compétences approfondies en infrastructure chez les développeurs de logiciels.
« Il faut que votre équipe chargée du cloud ou de la plateforme construise des modules approuvés », ajoute-t-il. « C’est un moyen d’élargir l’accès à ces modules, de la même manière que l’intégration de ServiceNow à Terraform vous permet de demander des ressources sans nécessairement connaître l’environnement Terraform. Cela ne supprime pas votre besoin d’une certaine expertise, mais cela peut réduire votre besoin de diffuser cette expertise aussi largement ».
