Les actions Terraform, le « crochet » d'HashiCorp pour se rapprocher d'Ansible

Mieux déléguer le « Jour 2 » aux outils tiers

L’absence de prise en charge des actions « Jour 2 » pour soutenir les opérations continues et la gestion de la configuration « a été la plus grande lacune de Terraform », selon Erik Grina Raassum, ingénieur senior chez Sopra Steria.

Cependant, un autre utilisateur de Terraform Community Edition s’inquiète des perturbations potentielles liées à un changement aussi important dans la syntaxe HCL.

« Étant donné qu’il s’agit d’un bloc de premier niveau dans la syntaxe elle-même, les linters [et autres workflows] pourraient devoir être modifiés », anticipe Pato Arvizu, ingénieur en fiabilité des sites chez Asapp, Inc. Asapp est un éditeur d’un logiciel pour centre de contact infusé à l’IA. « Cela semble être une avancée positive, mais nous verrons ce qui devra être ajusté. »

Les actions Terraform pourraient aider à relier directement les politiques FinOps au workflow de provisionnement de l’infrastructure, par exemple, imagine Pato Arvizu. IBM et HashiCorp proposeront une version packagée d’un tel workflow dans le cadre d’une nouvelle intégration entre IBM Cloudability Governance et les tâches d’exécution Terraform déployées cette semaine.

Les actions Terraform créent un nouveau pont vers Ansible

Armon Dadgar qualifie les actions Terraform de « super-provisionneurs ». Ceux-là invoquent des actions tout au long du cycle de vie d’une ressource via des outils tiers tels qu’Event-Driven Ansible d’IBM Red Hat. Les actions Terraform répondent aux questions précédentes sur la manière dont Terraform, un langage déclaratif, pourrait miuex interagir avec Ansible, plus impératif (certains diront hybride), maintenant que HashiCorp et Red Hat font tous deux partie d’IBM.

« Il s’agit d’un tout nouveau workflow qui permet à Terraform de s’intégrer profondément à des systèmes de runbook tels qu’Ansible [qui peuvent] être utilisés à toutes sortes de fins », décrit Armon Dadgar. « Pensez à l’exécution d’un script sur une infrastructure existante. À la mise à niveau du micrologiciel. À la suppression des fichiers de log », illustre-t-il. « Toutes ces opérations n’impliquent pas de modification des ressources sous-jacentes, vous deviez donc configurer manuellement les actions impératives. Il existe tout un univers que nous voulons pouvoir prendre en charge avec cela ».

HashiCorp et Red Hat ont vanté les liens entre Terraform et Ansible Automation Platform. Toutefois, tout fournisseur Terraform tiers pourra exposer des actions spécifiques à la plateforme à l’aide du SDK Terraform, assure Armon Dadgar. À long terme, Terraform et Ansible feront partie d’une plateforme d’automatisation du cloud hybride qui intégrera également des outils tiers tels que Red Hat Developer Hub, ServiceNow et Jira.

« Ils font partie d’une expérience de plateforme plus large que nous essayons de proposer », indique Armon Dadgar. « Ce qui revient en fait à se demander : “Comment répondre aux besoins de ces différents profils et aux différentes expériences qu’ils souhaitent, tout en s’appuyant sur une infrastructure sous forme de code pour fournir [des ressources] à l’ensemble du parc hybride ?” ».

L’invocation de playbooks Ansible nécessite une mise à jour du provider officiel AAP. Elle sera disponible la semaine prochaine, d’après HashiCorp. Pour le moment, les « actions » peuvent appeler des FaaS (function as a service) Lambda sur AWS. Il faut configurer les arguments du provider afin d’en profiter.

Comme d’habitude avec HashiCorp, il faudra attendre que les éditeurs des providers et les Ops s’emparent de cette fonctionnalité pour statuer de son efficacité. Les versions beta de l’éditeur devraient être accompagnées du fameux panneau « attention, peinture fraîche ». Les clients, dont Visa, réclamaient une prise en charge plus dynamique des flux Ansible. Ils se manifestaient jusqu’alors par des appels API.

Terraform search, une fonctionnalité très attendue

Une autre fonctionnalité lancée en version bêta cette semaine, Terraform search, représente une mise à jour très attendue par les utilisateurs de Terraform, selon le CTO d’HashiCorp.

« Cela pourrait être le deuxième ticket créé sur GitHub [pour Terraform] » il y a 10 ans, avoue-t-il. « L’idée était essentiellement la suivante : “Pouvez-vous simplement m’indiquer un environnement, rechercher dans cet environnement, trouver ce qui s’y trouve, puis écrire le code Terraform pour moi ?” ».

Terraform search fera exactement cela. La fonctionnalité doit répondre à l’un des principaux défis pour encourager une approche centralisée de l’infrastructure as code au sein des grandes organisations, selon Ned Bellavance.

« Si vous avez une équipe qui a construit l’infrastructure à l’aide d’un autre outil et que vous souhaitez qu’elle passe à Terraform, vous pouvez désormais lui dire : “Très bien, montrez-moi ce que vous avez utilisé, et je vais maintenant lancer Terraform search pour retrouver tout cela et le mettre en conformité avec nos normes et les modules que nous voulons utiliser” », décrit-il.

Terraform search n’est pas une barre de recherche. C’est un mécanisme pour définir des requêtes afin de rechercher des ressources qui ne sont pas encore gérées par Terraform.

Ces requêtes sont définies à travers le nouveau bloc « list » à placer dans les fichiers .tfquery.hcl.

Les interrogations peuvent être exécutées depuis l’interface utilisateur de HCP Terraform ou à travers le CLI. Dans les deux cas, search renvoie les ressources trouvées et leur statut (gérées, inconnues, non gérées).

Ensuite, Terraform génère les blocs de code « import » et « resource » pour ces éléments. Après une phase de formatage du code (terraform fmt), la commande « terraform apply » permet de les ajouter aux fichiers de configuration.

Pour l’instant, HashiCorp prend en charge les imports en lot avec les providers AWS et Microsoft Azure.