Infrastructure as code (IaC)
Gérez l'infrastructure via le code et le contrôle de version. Les définitions d'infrastructure sont versionnées, revues et déployées comme du code applicatif. Permet des environnements reproductibles et réduit la dérive de configuration.
Du template au resource group
param env string
param planSku string
resource kv 'Microsoft.KeyVault/vaults@2023-07-01' = { … }
resource st 'Microsoft.Storage/storageAccounts@2023-05-01' = { … }
resource sb 'Microsoft.ServiceBus/namespaces@2022-10-01-preview' = { … }
resource plan 'Microsoft.Web/serverfarms@2023-12-01' = { … }
resource func 'Microsoft.Web/sites@2023-12-01' = { … }
resource appi 'Microsoft.Insights/components@2020-02-02' = { … }
$ az deployment group what-if -g rg-crx-prod-weu -p prod.bicepparam
Resource changes: 6 to create.
rg-crx-prod-weu
0/6 ressourcesExemple illustratif
Choisir l'outil
Les trois sont des options matures. Le bon choix dépend de votre présence dans le cloud et des compétences déjà présentes dans l'équipe.
Bicep
Le langage de Microsoft pour Azure Resource Manager. Syntaxe concise, prise en charge des nouvelles fonctionnalités Azure dès leur sortie et aucun fichier d'état à gérer, car Azure lui-même fait foi. Notre choix par défaut pour les environnements 100 % Azure.
Terraform
Un outil multicloud doté d'un vaste écosystème de providers. Il conserve un fichier d'état qui doit être stocké de façon sécurisée, par exemple dans un compte Azure Storage avec verrouillage. Un bon choix si vous gérez aussi d'autres clouds ou des services comme GitHub par le code.
Templates ARM
Le format JSON vers lequel Bicep est compilé. Toujours entièrement pris en charge, mais verbeux ; les templates existants peuvent être décompilés en Bicep comme point de départ d'une migration.
Les pratiques qui gardent le code d'infrastructure maintenable
- Modules. Des briques réutilisables pour les schémas courants, comme une function app avec son stockage, son monitoring et son identité.
- Un template, plusieurs environnements. Les différences entre Dev, Test et Production se trouvent dans des fichiers de paramètres, pas dans des copies du template.
- Prévisualiser chaque modification. Exécutez what-if (Bicep) ou plan (Terraform) dans la pull request, pour que les relecteurs voient exactement ce qui sera créé, modifié ou supprimé.
- Aucune modification manuelle dans le portail. Les modifications dans le portail créent des dérives. Tout passe par le code, et des exécutions what-if planifiées révèlent les dérives très tôt.
- Des garde-fous avec Azure Policy. Les policies imposent le nommage, les régions autorisées, les tags et les bases de sécurité, quelle que soit la personne qui déploie.
- Des identités plutôt que des secrets. Les identités managées et les références Key Vault tiennent les chaînes de connexion et les clés à l'écart des templates.
Et Dynamics 365 et Dataverse ?
Les solutions Dynamics 365 et Power Platform ne se déploient pas avec Bicep ou Terraform : elles voyagent via leur propre pipeline. En revanche, les environnements, les stratégies DLP et les paramètres du locataire peuvent être gérés avec le fournisseur Terraform Power Platform, et les ressources Azure qui les entourent, comme Functions, Service Bus et Key Vault, se prêtent parfaitement à l'infrastructure as code. Les deux pipelines peuvent fonctionner côte à côte.
Voir ALM & CI/CD pour Dynamics 365