TP : Infrastructure as Code avec Bicep (validation locale et what-if)

Ce que vous allez apprendre dans ce TP

• Écrire un module Bicep paramétré
• Valider avec bicep build, lint et des règles
• Prévisualiser avec what-if et déployer

Introduction #

Ce que vous allez apprendre dans cette section

• Écrire un module Bicep paramétré
• Valider avec bicep build, lint et des règles
• Prévisualiser avec what-if et déployer

Contexte. L'équipe veut que chaque environnement soit décrit en code et vérifié avant déploiement. Vous écrivez et testez le modèle localement.

Prérequis : Azure CLI avec Bicep (az bicep install) ; PSRule pour Azure facultatif ; un abonnement d'essai seulement pour les deux dernières étapes  ·  Durée estimée : 45 min

Un modèle Bicep paramétré, validé localement et prêt à être déployé par pipeline.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Écrire le modèle

   Pourquoi ? Les décorateurs (@allowed, @minLength) refusent les mauvaises valeurs avant tout déploiement.

   Créez main.bicep : stockage ZRS en production et LRS sinon, accès public désactivé, plan App Service Linux et sorties.

2. 2. Compiler et analyser

   Pourquoi ? Le linter signale les mauvaises pratiques (secrets en sortie, versions d'API anciennes, emplacements codés en dur).

   Compilez en ARM JSON, lancez le linter et inspectez le JSON généré.

3. 3. Tester les règles de sécurité

   Pourquoi ? PSRule pour Azure vérifie le modèle contre le Well-Architected Framework sans aucun abonnement.

   Analysez le modèle avec PSRule (conteneur) et corrigez un avertissement si besoin.

4. 4. Prévisualiser et déployer (abonnement d'essai)

   Pourquoi ? Le what-if montre exactement ce qui changera ; un second déploiement identique ne modifie rien (idempotence).

   Créez un groupe, lancez le what-if, déployez, relancez le what-if puis supprimez le groupe.

Niveau de difficulté : ●●●○○ (3/5)