Provider Terraform AzAPI : usages et cas pratiques

Article coécrit par David Frappart et Souha Bel Haj Hassine

Dans ce nouvel article, nous allons parler du formidable provider AzAPI.

Au programme :

• Découverte du provider Terraform AzAPI
• A quels besoins il répond
• Comment fonctionne Terraform
• Comment Terraform s’intègre dans le cycle de vie de l’Infrastructure as Code

Présentation de Terraform AzAPI Provider

Avant de nous plonger dans l’AzAPI provider, nous vous proposons un peu d’archéologie Cloud.

Retour sur les anciennes versions de Terraform

En tant que solution Cloud agnostique, Terraform peut fonctionner avec plusieurs Cloud providers (et d’autres fournisseurs en lien avec l’infrastructure IT, de près ou de loin).

En raison de ce développement horizontal, les binaires Terraform ont été séparées en deux :

• Binaires Terraform
• Binaires des providers

On note le « s » à la fin de « providers », puisqu’il y en a plus d’un. Une liste de providers, maintenue par Hashicorp ou un écosystème de partenaires, est disponible sur la registry Terraform.

De fait, puisqu’un provider doit être mis à jour pour chaque nouvelle ressource Cloud, il peut arriver que le développement ne permette pas une disponibilité de ces ressources dans le provider Terraform dès la mise à disposition de ladite ressource.

Sachant cela, il existe depuis longtemps des “workaround” pour passer outre ces limites. Par exemple, nous avons à notre disposition les null resources, qui utilisent le provider du même nom.

Comme son nom l’indique, la ressource ne crée rien, mais permet en revanche d’exécuter une commande CLI localement à travers une autre fonctionnalité de Terraform appelée le provisioner local-exec. Dans un monde Azure, nous utilisons ce provisionner avec une commande az cli ou Azure PowerShell.

Ci-dessous, un exemple d’une commande « az cli » pour passer la création d’AGIC, avant que celui-ci ne soit disponible dans le provider Terraform AzureRM.

Une autre solution de contournement, spécifique à Azure et au provider AzureRM, est l’usage de la ressource Template. Avec le temps, le provider AzureRM a enrichi ses ressources et propose à présent les ressources templates suivantes :

• azurerm_management_group_template_deployment
• azurerm_resource_deployment_script_azure_cli
• azurerm_resource_deployment_script_azure_power_shell
• azurerm_resource_group_template_deployment
• azurerm_subscription_template_deployment
• azurerm_template_deployment
• azurerm_tenant_template_deployment

Cependant, quelle que soit la solution de contournement utilisée, les ressources Azure créées ne sont pas complètement visibles dans le state Terraform, ce qui implique un impact important dans la gestion du cycle de vie des ressources Cloud.

On note toutefois une évolution dans le bon sens vis-à-vis des ressources de type azurerm_resource_group_template_deployment puisque Terraform essaye de détruire les ressources associées au template ARM lors de l’exécution d’un Terraform destroy.

Malgré tout, en éternels exigeants, nous espérons mieux (et probablement moins de az cli ou de template ARM), et c’est ici que le provider AzAPI entre en jeu.

Le provider AzAPI

Le provider AzAPI est relativement récent par rapport à l’existence du provider AzureRM. L’idée est de fournir une disponibilité à Day 0 des ressources Azure et de compléter de cette manière le provider AzureRM.

Ceci étant dit, par où commencer ?

La réponse (évidente) est bien entendu la documentation incluse dans les pages de la registry Terraform. On y trouve les informations de base pour configurer le provider, comme on pourrait s’y attendre, mais au final, peu d’informations sur les ressources :

Avec ces quelques informations, les ressources à Day 0 ne sont pas encore là. Il nous faut donc chercher ailleurs.

Il est important de se rappeler que le provider AzAPI est fourni spécifiquement par les équipes Microsoft. On devrait donc trouver naturellement davantage d’information sur les pages de documentation Azure.

Pour quelqu’un ayant déjà écrit des templates ARM, la documentation à avoir dans ses marque-pages est la page ARM template reference. A l’origine, on y trouvait uniquement les exemples de configuration JSON correspondant aux différentes ressources Azure.

Puis est arrivée l’évolution d’ARM (bicep), et la page a été augmentée avec des exemples de ressources décrites dans le nouveau DSL de Microsoft.

Dernièrement, les équipes Microsoft ont ajouté la partie relative à AzAPI, décrivant les ressources en Hashicorp Terraform Language.

Après cette petite acculturation avec le provider, passons maintenant à l’usage.

Travailler avec le provider AzAPI

Configurer le provider AzAPI

Pour commencer, nous devons écrire la configuration du provider. Le block provider devrait ressembler à ceci :

Notez qu’il est fort probable que les credentials pour AzAPI soient les mêmes que pour le provider AzureRM.

En ce qui concerne le versioning du provider, il nous faut définir le block Terraform :

On notera ici la source du provider, pour laquelle nous devons spécifier « azure/azapi ». Pour le moment, rien de complexe.

Passons à présent aux ressources.

Exemples d’utilisation d’azAPI

Création d’une ressource

Le résolveur DNS privé n’est pas encore supporté par le provider AzureRM, mais est cependant disponible avec les API REST ARM. Il est donc possible de le déployer avec Terraform en utilisant la ressource AzAPI azapi-resource.

Mise à jour de ressource

La ressource CDN est supportée par le provider AzureRM. Néanmoins, la propriété identity permettant de lui associéer une identité managée (System Assigned ou User Assigned) ne l’est pas encore. Nous utilisons donc la ressource AzAPI azapi_update_resource en complément de la ressource AzureRM azurerm_cdn_profile afin d’ajouter la partie identité.

Action sur une ressource

Comme expliqué plus haut, la ressource azapi_resource_action permet d’effectuer des actions sur les ressources Azure. Dans cet exemple, nous l’utilisons afin d’arrêter/stopper une application web existante :

Limitations et considérations pour le cycle de vie IaC

Les ressources et actions qui ne sont pas encore supportées par les APIs ARM ne sont pas supportées par AzAPI… Et c’est tout.

De facto, puisqu’une ressource est définie en tant qu’objet d’API, on peut donc établir l’hypothèse que les ressources sont disponibles à Day 0 avec le provider AzAPI.

D’un point de vue lifecycle (cycle de vie), il est important de considérer les créations de ressources ainsi que les updates de ressources.

Concernant ces derniers, la documentation du provider dans la registry Terraform spécifie ceci :

En clair, supprimer une ressource AzAPI de type update ne rebascule pas sur la configuration antérieure de la ressource Azure. Il n’y a donc rien d’autre à faire que de supprimer la ressource azapi_update_resource lorsque l’on est en mesure d’intégrer la nouvelle feature directement avec le provider Terraform.

Pour les ressources créées, c’est un peu moins évident. Si la ressource est utilisée, il ne sera pas possible de faire une suppression sans impacter les utilisateurs.

Dans ce cas, l’hypothèse la plus vraisemblable est une suppression du state de la ressource azAPI, puis une définition à travers le provider Terraform, suivie d’une opération d’import.

Bien que la manipulation du state soit bien documentée, elle reste toutefois fastidieuse. Pour cette raison, on pourrait décider de garder les créations de ressources pour des usages hors production.

Notre avis sur azAPI

Les ressources d’AzAPI se reposent finalement sur du JSON body = jsonencode qui est moins lisible et plus verbeux que le HCL. Malgré ces limitations, le provider AzAPI reste très utile puisqu’il permet d’être à jour avec les APIs REST et évite ainsi aux fans et habitués de Terraform de devoir utiliser d’autres outils d’IaC.

Vous souhaitez être accompagnés sur vos projets de transformation numérique ? Contactez-nous !