Bicep vs Terraform
Quelle solution IaC pour Azure ?
No notes for this slide
Agenda
Introduction rapide
Première grosse différence
Seconde grosse différence
Conclusion
No notes for this slide
Introduction
No notes for this slide
Introduction
De quoi parle-t-on au juste ?
Deux outils d’Infrastructure-as-Code:
- Bicep , un DSL open-source par Microsoft
- Terraform , un outil qui a 2 versions
- La version originale d’HashiCorp en BSL
- Le fork OpenTofu open-source propulsé par la Fondation Linux
Avec plusieurs points communs
- Mode déclaratif (vs impératif)
- Un workflow similaire: validate, plan/what-if, apply
- Deux syntaxes qui se ressemblent
No notes for this slide
Un exemple de code tout simple
Avec Bicep
var myProject = 'my-project'
resource rg 'Microsoft.Resources/resourceGroups@2023-07-01' = {
name: 'rg-${myProject}'
location: 'canadaeast'
}
output rgName string = rg.nameAvec Terraform
locals { my_project = "my-project" }
resource "azurerm_resource_group" "rg" {
name = "rg-${local.my_project}"
location = "canadaeast"
}
output "rg_name" { value = azurerm_resource_group.rg.name }No notes for this slide
Ce n’est pas juste une question de multi-cloud
No notes for this slide
Première différence
Le mode d’exécution
(Qu’est-ce qui se passe lorsque chaque outil tourne ?)
No notes for this slide
On commence par une démo !
- Organisation du repo
- Lancement en Bicep (avec un déploiement et un scope)
az deployment sub create -n deploy-tf-vs-bicep -l canadaeast -f main.bicep -p location=canadaeast
- Petit parcours du code Bicep, et montrer le déploiement dans le portail (avec le template ARM)
- Lancement avec Terraform (pas de fichier ni de scope à préciser, ni de déploiement)
- Petit parcours du code
- Explication de la différence de comportement
- Côté Bicep, un seul appel d'API et tout se passe dans Azure
- Côté Terraform, de multiples appels
No notes for this slide
No notes for this slide
Limitation à l'API Resource Manager
- Impossible de créer des blobs
- Impossible de créer des objets dans Azure Ad (App Registrations, groupes, etc.)
- Montrer le deployment script
Organisation du code
- En Bicep, 1 fichier = 1 déploiement
S'il y a du temps, montrer le module isEven (Bicep en priorité)
- Dé-commenter le code dans resources.bicep
- Transformer la variable en output Expliquer la différence sur les fichiers (non variablilisés en Bicep)
Seconde différence
State ou pas de state ?
No notes for this slide
Qu’est-ce que le state ?
Un aspect spécifique à
Un fichier JSON avec toute notre infra
En local par défaut …
… mais il faut le mutualiser …
… et le sécuriser
A quoi sert le state ?
A éviter les collisions
Lier la configuration à l’infrastructure
Stocker des meta-data comme les dépendances…
…et d’autres trucs qui ne sont pas des ressources
No notes for this slide
On retourne dans le portail !
Tests à faire
- Dé-commenter le "some-container" et re-déployer
- Re-commenter le "some-container" et déployer à nouveau
- Changer le nom logique d'une ressource (le rg)
- What-if en Bicep: pas de changement
- Apply en tf: suppression du rg (il faut utiliser le bloc moved)
- Créer un container "test" à la main et faire un apply en tf
- Importer le container avec tf import 'module.static_website.azurerm_storage_container.test' et l'id dans l'erreur
- Tout renommer
- Terraform: tf apply -var project=nouveau-nom (il supprime et re-créé tout)
- Bicep: changer la variable project dans le main.bicep (il duplique à côté)
- Tout déployer dans Canada Central
- Terraform: tf apply -var location=canadacentral (propose de tout recréer)
- Bicep az deployment sub create -n deploy-tf-vs-bicep -l canadaeast -f main.bicep -p location=canadacentral (renvoie une erreur)
No notes for this slide
Et là, qu’est-ce que ça change ?
Possibilité de supprimer des ressources
Attention aux changements hors IaC
qui ne viennent par forcément du portail
Moins facile de faire du refactoring
On peut y stocker autre chose que des ressources Azure
Changements hors IaC
- Exemple des App Services avec le certificat dans le KV
D’autres différences ?
No notes for this slide
Quelques petits "détails"
Qui ne doivent pas guider votre choix
Fonctionnalités de chaque langage (boucles, fonctions, etc.)
Intégration dans Visual Studio Code
Eco-système: linters, etc.
No notes for this slide
Quelques vérités pas toujours vraies
Tout est possible dans Azure avec Bicep dès le premier jour
Seul Bicep est supporté par Microsoft
Montrer le static website avec un deployment script en Bicep Toute nouvelle feature doit être dans le provider AzureRm pour passer en GA
Conclusion
Il va falloir faire un choix maintenant
No notes for this slide
S’il fallait en choisir un
Je choisirais Terraform/OpenTofu en premier…
…s’il y a une vraie volonté de faire de l’IaC
Pas de changement dans le portail
Adopté par plusieurs personnes
No notes for this slide
Faites du Bicep si…
Vous faites encore des templates ARM
Pour remplacer certains scripts PowerShell/Azure CLI
Pour les problèmes de type
Bicep va continuer d’évoluer
Deployment stacks
Extensibilité
No notes for this slide
Derniers conseils avant la fin
Quelque soit la solution utilisée
Découpez/modulez votre code
Exécutez le (souvent)
La sandbox est votre amie
Le GitOps votre chemin
Votre objectif: avoir confiance
Cf ce talk (en anglais) sur le test de code IaC
No notes for this slide
Des questions
Quelques liens
tf-bicep-slides.xmi.fr
xaviermignot/azure-terraform-vs-bicep
blog.xmi.fr
@mignotxavier
No notes for this slide
