IaC : les différences entre les templates ARM et Terraform
Les templates ARM et Terraform sont des fichiers populaires dans le cadre d'une configuration d'une infrastructure as code. Découvrez un exemple de VM Ubuntu Server dans chaque approche et apprenez les avantages et inconvénients de ces outils.
L’infrastructure as code est la pratique par laquelle les administrateurs IT documentent la configuration de l’infrastructure pour une application ou un service dans un template. Bien que le concept soit loin d’être nouveau, la qualité des outils associés s’est considérablement améliorée, notamment quand il s’agit d’utiliser les ressources de fournisseurs de cloud comme Microsoft Azure.
Deux des outils d’infrastructure as code (parfois appelés IaC) les plus populaires à utiliser avec Azure sont les modèles natifs Azure Resource Manager (ARM) et HashiCorp Terraform. Les utilisateurs d’Azure se doivent de comparer les modèles ARM et l’approche Terraform pour décider quel produit est le mieux adapté à leur environnement. Suivez ces exemples d’ARM et de Terraform, puis explorez les avantages et les inconvénients de ces outils IaC.
Prérequis
Pour commencer à évaluer les modèles ARM et Terraform associés à Microsoft Azure, installez les éléments suivants sur votre machine :
- Microsoft Visual Studio Code et Azure Resource Manager Template Extension pour Visual Studio Code ;
- Terraform et Azure PowerShell – le shell interactif Azure Cloud Shell est préinstallé ; et
- Un compte Microsoft Azure.
Les templates (modèles) Azure Resource Manager
Les templates ARM sont des documents JSON qui définissent chaque aspect de l’infrastructure. Par exemple, une ressource IT pour une nouvelle machine virtuelle (VM) indique sa taille, ses informations d’identification, sa version et le stockage attaché, etc. Tous ces éléments sont configurés à partir du même fichier JSON.
Vous trouverez ci-dessous un exemple de modèle ARM pour une VM Ubuntu Server :
# JSON
...
{
"name": "ubuntuVM1",
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2019-07-01",
"location": "[resourceGroup().location]",
"properties": {
"hardwareProfile": {
"vmSize": "Standard_A2_v2"
},
"osProfile": {
"computerName": "ubuntuVM1",
"adminUsername": "adminUsername",
"adminPassword": "adminPassword123"
},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "latest"
},
"osDisk": {
"name": "ubuntuVM1-OSDisk",
"caching": "ReadWrite",
"createOption": "FromImage"
}
},
...
Les administrateurs IT qui sont familiers avec le formatage JSON trouveront cet exemple familier : Microsoft dispose d’un schéma bien défini qui doit permettre de créer aisément des templates ARM dans Visual Studio Code. Ouvrez un nouveau document JSON et tapez arm et vous pourrez générer un template vierge auquel vous pourrez adjoindre des ressources.
Ces documents IaC peuvent être incroyablement longs et verbeux, mais cela est nécessaire pour configurer chaque détail de l’infrastructure. L’extrait de code ci-dessus pour la seule VM Ubuntu et ses dépendances provient d’un fichier JSON de 167 lignes.
Les admins déploient ces configurations à partir d’une session Azure CLI ou Azure PowerShell authentifiée. Les exemples de cet article utilisent Azure PowerShell. Exécutez la cmdlet New-AzResourceGroupDeployment dans le fichier template une fois que celui-ci et un groupe de ressources ont été déployés.
Si le modèle est valide, toutes les ressources définies se déploient dans ce groupe de ressources lorsque la cmdlet est exécutée. Si l’une des ressources définies est détruite, relancez le fichier template — sans y apporter de modifications – pour la restaurer.
HashiCorp Terraform
Terraform est un outil populaire auprès des équipes DevOps, car il peut appliquer des configurations sur diverses plateformes cloud, telles qu’Azure, AWS et Google Cloud Platform, mais il existe également des solutions communautaires et expérimentales pour PostgreSQL, VMware et même Active Directory.
Terraform est un produit multicloud. Les administrateurs qui maîtrisent la création d'une infrastructure chez un fournisseur particulier peuvent écrire des ressources Terraform pour celui-ci. Le processus est relativement similaire d’une plateforme à l’autre.
En général, les configurations Terraform sont écrites dans le langage déclaratif propriétaire d’HashiCorp appelé HashiCorp Configuration Language (HCL). Par conséquent, la courbe d’apprentissage de Terraform est plus élevée que celle des templates ARM qui reposent sur un formatage plus courant, à savoir JSON.
Un exemple illustre la différence entre les fichiers JSON des modèles ARM et la structure HCL de Terraform. Le code Terraform ci-dessous crée le même déploiement de VM que nous avons fait dans le template ARM :
# HCL
resource "azurerm_linux_virtual_machine" "example" {
name = "ubuntuVM1"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
size = "Standard_F2"
admin_username = "adminUsername"
admin_password = "adminPassword123"
disable_password_authentication = false
network_interface_ids = [
azurerm_network_interface.example.id,
]
os_disk {
caching = "ReadWrite"
storage_account_type = "Standard_LRS"
}
source_image_reference {
publisher = "Canonical"
offer = "UbuntuServer"
sku = "16.04-LTS"
version = "latest"
}
}
Les modèles ARM sont tous créés dans un seul fichier. En revanche, Terraform évalue chaque ressource du répertoire avec une extension. tf – et le fera pour chaque commande qui exécute la ressource, ce qui permet aux administrateurs de diviser les ressources en fichiers séparés pour faciliter leur supervision. Par exemple, un ingénieur peut écrire et définir l’infrastructure en tant que code à travers trois fichiers – qui doivent tous disposer d’une extension de fichier. tf :
- subnets.tf
- security_groups.tf
- virtual_machines.tf
Les administrateurs IT peuvent authentifier le fournisseur (provider en VO) Azure Terraform à l’aide du CLI ou d’un Service Principal, qui est une application d’authentification dans Azure Active Directory. Une fois l’authentification configurée, exécutez le code Terraform avec la commande init, suivie de terraform apply. Terraform devrait renvoyer le résultat suivant :
➜ ~ terraform apply
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# azurerm_linux_virtual_machine.example will be created
+ resource "azurerm_linux_virtual_machine" "example" {
+ admin_password = (sensitive value)
+ admin_username = "adminUsername"
+ allow_extension_operations = true
+ computer_name = (known after apply)
+ disable_password_authentication = false
+ id = (known after apply)
+ location = "eastus"
+ max_bid_price = -1
+ name = "ubuntuVM1"
+ network_interface_ids = (known after apply)
+ priority = "Regular"
+ private_ip_address = (known after apply)
+ private_ip_addresses = (known after apply)
+ provision_vm_agent = true
+ public_ip_address = (known after apply)
+ public_ip_addresses = (known after apply)
+ resource_group_name = "ata-rg"
+ size = "Standard_A2_v2"
+ virtual_machine_id = (known after apply)
+ zone = (known after apply)
+ os_disk {
+ caching = "ReadWrite"
+ disk_size_gb = (known after apply)
+ name = (known after apply)
+ storage_account_type = "Standard_LRS"
+ write_accelerator_enabled = false
}
+ source_image_reference {
+ offer = "UbuntuServer"
+ publisher = "Canonical"
+ sku = "16.04-LTS"
+ version = "latest"
}
}
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value:
Tapez yes pour déployer les ressources de la configuration souhaitée dans la souscription Azure à laquelle vous vous êtes connecté. À l’instar des templates ARM, Terraform rétablit une configuration modifiée à l’état désiré si vous relancez la commande terraform apply. Cette capacité est utile lorsque quelqu’un supprime manuellement un fichier de ressources ou met le système hors configuration. Vous pouvez voir la sortie de la commande terraform apply sur la Figure 3.
En cas de besoin, exécutez la commande terraform destroy et entrez yes – tout comme avec terraform apply – pour détruire toutes les ressources créées par Terraform.
Pourquoi l’infrastructure as code ?
Rédiger les exigences et les étapes d’un déploiement IT sous la forme d’un document formaté et apprendre à utiliser un outil IaC représente un travail considérable. Mais les avantages sont multiples.
Les administrateurs informatiques peuvent stocker le code utilisé pour piloter l’infrastructure avec le code source des applications dans l’outil de contrôle de version. Ces responsables peuvent suivre chaque modification apportée à l’infrastructure, réduire la taille de chaque déploiement et recréer chaque environnement à partir de zéro de manière cohérente.
D’autres équipes au sein d’une organisation, comme celle dédiée à la sécurité, bénéficient également de l’infrastructure as code. Elles peuvent trouver de nouvelles vulnérabilités et identifier les serveurs affectés sans avoir à scanner chaque serveur et conteneur du SI de l’entreprise, par exemple.
Templates ARM vs Terraform : avantages et inconvénients
Il y a des avantages non négligeables à s’appuyer sur l’infrastructure as code pour définir une architecture IT. Il y a également des inconvénients plus ou moins « gênants », selon les cas d’usage et les exigences de la DSI.
Comme l’illustrent les deux exemples déroulés plus haut, le mode de déploiement des ressources cloud, ici dans Azure, diffère suivant l’outil utilisé. Pour choisir le vôtre, tenez compte des feuilles de route et des fonctionnalités du produit. Par exemple, les templates Azure Resource Manager supportent nativement les nouvelles fonctionnalités de la plateforme cloud, dès que Microsoft les met à disposition ou les commercialise. Terraform est logiciel ouvert sous licence MPL 2.0. Pour prendre en charge ces nouvelles capacités, cela demande qu’un membre de la communauté Terraform, qu’il soit un éditeur ou non, les ajoute dans le référentiel Azure Terraform.
L’avantage des templates ARM dans le cloud Azure est aussi leur principale limite. En effet, ils ne peuvent être utilisés qu’avec les ressources de Microsoft.
Mais il faut bien différencier ces modèles du service Azure Resource Manager en lui-même. Le service prend également en charge les templates Terraform. Par ailleurs, la firme a introduit en préversion le langage de domaine spécifique Bicep. Cette syntaxe déclarative pensée comme une abstraction par-dessus les templates JSON serait plus simple à manipuler et faciliterait la réutilisation du code. Contrairement à JSON, Bicep sert uniquement à définir des ressources ou documenter des API dans Azure. Enfin, Microsoft étoffe peu à peu son offre Azure Arc, qui permet d’employer et d’administrer ces trois types de templates depuis le service Azure Resource Manager pour piloter des ressources Azure, des serveurs Linux ou Windows, des clusters Kubernetes, et des instances de bases de données SQL et PostgreSQL (en préversion), qu’ils soient déployés sur site ou dans d’autres cloud (GCP ou AWS).
De leur côté, les utilisateurs de Terraform peuvent, par défaut, déployer la même configuration sur Azure, AWS, des serveurs sur site et d’autres emplacements avec un seul type de fichier et une seule syntaxe.
Les gabarits ARM et Terraform fournissent différentes méthodes pour les variables, les conditions et la logique interne. Les administrateurs système doivent se former pour comprendre le fonctionnement d’un instrument IaC et optimiser son usage.
L’Infrastructure as code a déjà fait ses preuves par rapport à la maintenance manuelle des systèmes IT. Avec une architecture correctement définie, cette tâche s’avère relativement simple. Quand ce n’est pas le cas, le passage aux templates Terraform, ARM ou autres oblige votre DSI à réévaluer des segments d’applications en production. Et si de prime abord, ce problème peut avoir des conséquences techniques et financières, c’est aussi un bon moyen de revoir et d’optimiser une infrastructure existante.
