Modulariser les modèles

  • 4 minutes

Quand vous utilisez des modèles Azure Resource Manager, il est préférable de les diviser en composants individuels.

Pour cela, la méthode de base est l’utilisation de modèles liés.

Cela vous permet de fractionner la solution en composants ciblés et de réutiliser ces différents éléments dans différents déploiements.

Modèle lié

Ajoutez une ressource de déploiement à votre modèle principal pour lier un modèle à un autre.

"resources": [
  {
      "apiVersion": "2017-05-10",
      "name": "linkedTemplate",
      "type": "Microsoft.Resources/deployments",
      "properties": {
          "mode": "Incremental",
          <link-to-external-template>
      }
  }
]

Modèle imbriqué

Vous pouvez également imbriquer un modèle dans le modèle principal, utiliser la propriété du modèle et spécifier la syntaxe du modèle.

Cela permet d’obtenir une sorte de modularisation, mais la division des différents composants peut aboutir à un fichier principal de plus en plus grand, car tous les éléments se trouvent dans ce même fichier.

"resources": [
  {
    "apiVersion": "2017-05-10",
    "name": "nestedTemplate",
    "type": "Microsoft.Resources/deployments",
    "properties": {
      "mode": "Incremental",
      "template": {
        "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
        "contentVersion": "1.0.0.0",
        "resources": [
          {
            "type": "Microsoft.Storage/storageAccounts",
            "name": "[variables('storageName')]",
            "apiVersion": "2015-06-15",
            "location": "West US",
            "properties": {
              "accountType": "Standard_LRS"
            }
          }
        ]
      }
    }
  }
]

Notes

Vous ne pouvez pas utiliser de paramètres ni de variables définis dans le modèle imbriqué lui-même pour les modèles imbriqués. Vous pouvez seulement utiliser les paramètres et les variables du modèle principal.

Les propriétés que vous fournissez pour la ressource de déploiement varient selon que vous liez un modèle externe ou que vous imbriquez un modèle inline dans le modèle principal.

Modes de déploiement

Quand vous déployez vos ressources avec des modèles, vous avez trois options :

  • valider. Cette option compile les modèles, valide le déploiement, vérifie que le modèle fonctionne (par exemple, qu’il n’y a pas de dépendance circulaire) et que la syntaxe est correcte.
  • mode incrémentiel (par défaut). Cette option déploie uniquement tout ce qui est défini dans le modèle. Elle ne supprime ni ne modifie les ressources qui ne sont pas définies dans le modèle. Par exemple, si vous avez déployé une machine virtuelle avec un modèle, puis renommé la machine virtuelle dans le modèle, la première machine virtuelle déployée reste après la réexécution du modèle. Il s’agit du mode par défaut.
  • mode complet : Resource Manager supprime les ressources qui existent dans le groupe de ressources, mais n’est pas spécifié dans le modèle. Par exemple, seules les ressources définies dans le modèle sont présentes dans le groupe de ressources après le déploiement du modèle. Une meilleure pratique consiste à utiliser ce mode pour les environnements de production afin d’obtenir une idempotence dans vos modèles de déploiement.

Quand vous utilisez PowerShell pour le déploiement, pour définir le mode de déploiement, utilisez le paramètre Mode, conformément à l’exemple de modèle imbriqué plus haut dans cette rubrique.

Notes

Une bonne pratique est d’utiliser un seul groupe de ressources par déploiement.

Notes

Vous pouvez uniquement utiliser le mode de déploiement incremental pour les modèles liés et imbriqués.

Modèle externe et paramètres externes

Pour établir un lien à un modèle externe et un fichier de paramètres, utilisez templateLink et parametersLink.

Quand vous liez un modèle, vérifiez que le service Resource Manager peut y accéder.

Par exemple, vous ne pouvez pas spécifier de fichier local ou de fichier uniquement disponible sur votre réseau local.

Vous pouvez fournir seulement une valeur URI (Uniform Resource Identifier) qui comprend HTTP ou HTTPS.

Vous pouvez éventuellement placer votre modèle lié dans un compte de stockage et utiliser l’URI pour cet élément.

Vous pouvez également fournir le paramètre inline. Toutefois, vous ne pouvez pas utiliser à la fois des paramètres inline et un lien vers un fichier de paramètres.

L’exemple suivant utilise le paramètre templateLink :

  "resources": [
    {
      "name": "linkedTemplate",
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2018-05-01",
      "properties": {
          "mode": "Incremental",
          "templateLink": {
              "uri":"https://linkedtemplateek1store.blob.core.windows.net/linkedtemplates/linkedStorageAccount.json?sv=2018-03-28&sr=b&sig=dO9p7XnbhGq56BO%2BSW3o9tX7E2WUdIk%2BpF1MTK2eFfs%3D&se=2018-12-31T14%3A32%3A29Z&sp=r"
          },
          "parameters": {
              "storageAccountName":{"value": "[variables('storageAccountName')]"},
              "location":{"value": "[parameters('location')]"}
          }
      }
    },

Sécurisation d’un modèle externe

Même si le modèle lié doit être disponible en externe, il n’a pas besoin d’être mis à la disposition du public.

À la place, vous pouvez ajouter votre modèle à un compte de stockage privé accessible uniquement au propriétaire du compte de stockage, en créant des jetons de signature d’accès partagé (SAS) pour permettre l’accès pendant le déploiement.

Vous ajoutez ce jeton SAP à l’URI pour le modèle lié.

Même si le jeton est transmis sous la forme d’une chaîne sécurisée, l’URI du modèle lié, y compris le jeton SAS, est enregistré dans les opérations de déploiement.

Pour limiter l’exposition, vous pouvez également définir une date d’expiration pour le jeton.