Déployer un workflow Azure Logic Apps à l’aide d’un modèle Azure Resource Manager
Si vous utilisez Azure depuis un certain temps, vous avez probablement entendu parler d’Azure Resource Manager. Découvrons la fonction de Resource Manager et définissons ce qui constitue un modèle Resource Manager.
Qu’est-ce qu’Azure Resource Manager ?
Azure Resource Manager est l’interface qui permet de gérer et d’organiser les ressources cloud. Pensez à Resource Manager comme un moyen de déployer des ressources cloud.
Si vous connaissez les groupes de ressources Azure, vous savez qu’ils vous permettent de traiter des ensembles de ressources connexes en tant qu’une seule unité. Resource Manager est en charge d’organiser les groupes de ressources qui vous permettent de déployer, gérer et supprimer toutes les ressources en une seule action.
Pensez à des modèles financiers que vous exécutez pour vos analystes. Pour exécuter un modèle, vous risquez d’avoir besoin d’une ou plusieurs machines virtuelles, d’une base de données pour stocker les données et d’un réseau virtuel pour assurer la connectivité entre tous ces éléments. Avec Resource Manager, vous pouvez déployer ces ressources dans le même groupe de ressources, ainsi que les gérer et superviser ensemble. Lorsque vous avez terminé, vous pouvez supprimer toutes les ressources d’un groupe de ressources en une seule opération.
Qu’est-ce qu’un modèle Azure Resource Manager ?
Un modèle Resource Manager définit précisément toutes les ressources Resource Manager d’un déploiement. Vous pouvez déployer un modèle Resource Manager dans un groupe de ressources en une seule opération.
Un modèle Resource Manager est un fichier JSON qui se présente sous la forme d’une automatisation déclarative. Une automatisation déclarative signifie que vous définissez les ressources dont vous avez besoin, mais pas la façon de les créer. Autrement dit, vous définissez ce dont vous avez besoin, mais Resource Manager doit s’assurer que les ressources sont déployées correctement.
Vous pouvez comparer une automatisation déclarative à la façon dont les navigateurs web affichent les fichiers HTML. Un fichier HTML décrit les éléments qui apparaissent sur la page, mais ne décrit pas la façon de les afficher. La « façon » est la responsabilité du navigateur web.
Remarque
Certains utilisent le terme modèles ARM pour faire référence aux modèles Resource Manager. Nous préférons les noms complets modèles Azure Resource Manager ou modèles Resource Manager.
Pourquoi utiliser des modèles Resource Manager ?
L’utilisation de modèles Resource Manager accélère vos déploiements et les rend plus reproductibles. Par exemple, vous n’avez plus à créer une machine virtuelle dans le portail, attendre qu’elle ait finie, puis créer la machine virtuelle suivante et ainsi de suite. Resource Manager s’occupe de la totalité du déploiement pour vous.
Voici d’autres avantages à prendre en compte :
Les modèles améliorent la cohérence.
Les modèles Resource Manager vous fournissent un langage commun pour décrire vos déploiements. Quel que soit l’outil ou le kit SDK utilisé pour déployer le modèle, la structure, le format et les expressions à l’intérieur du modèle restent les mêmes.
Les modèles permettent d’exprimer des déploiements complexes.
Les modèles vous permettent de déployer plusieurs ressources dans le bon ordre. Par exemple, vous ne voudriez pas déployer une machine virtuelle avant de créer une interface réseau ou un disque de système d’exploitation. Resource Manager mappe chaque ressource et ses ressources dépendantes, puis crée d’abord les ressources dépendantes. Le mappage de dépendances permet de vous assurer que le déploiement se déroule dans le bon ordre.
Les modèles réduisent les tâches manuelles sujettes aux erreurs.
La création et la connexion manuelles des ressources peuvent prendre du temps, et il est facile de commettre des erreurs tout du long. Resource Manager permet d’assurer que les déploiements se déroulent de la même façon à chaque fois.
Les modèles sont constitués de code.
Les modèles expriment vos exigences sous forme de code. Pensez à un modèle comme un type d’infrastructure en tant que code pouvant être partagée, testée et versionnée comme n’importe quel autre composant logiciel. De plus, étant donné que les modèles sont du code, vous pouvez créer une « trace écrite » que vous pouvez suivre. Le code du modèle documente le déploiement. La plupart des utilisateurs gèrent leurs modèles avec un genre de système de gestion de révisions, comme Git. Quand vous changez de modèle, son historique de révision documente également l’évolution du modèle (et de votre déploiement) au fil du temps.
Les modèles favorisent la réutilisation.
Votre modèle peut contenir des paramètres qui sont remplis lorsque le modèle s'exécute. Un paramètre peut définir un nom d’utilisateur ou un mot de passe, un nom de domaine et ainsi de suite. Les paramètres de modèle vous permettent de créer plusieurs versions de votre infrastructure, comme la mise en lots et la production, tout en utilisant exactement le même modèle.
Les modèles peuvent être liés.
Vous pouvez lier des modèles Resource Manager ensemble pour les rendre eux-mêmes modulaires. Vous pouvez écrire des petits modèles qui définissent chacun une partie d’une solution et les combiner pour créer un système complet.
Les modèles qu’exécutent vos analystes financiers sont uniques, mais vous voyez des éléments communs dans l’infrastructure sous-jacente. Par exemple, la plupart des modèles nécessitent une base de données pour stocker les données. Un grand nombre de modèles utilisent les mêmes langages de programmation, frameworks et systèmes d’exploitation pour exécuter les détails. Vous pouvez définir des modèles qui décrivent chaque composant individuel, tel que le calcul, le stockage et la mise en réseau. Vous pouvez ensuite combiner les composants pour répondre aux besoins spécifiques de chaque analyste.
Que contient un modèle Resource Manager ?
Notes
Ici, vous allez voir quelques exemples de code qui vont vous donner une idée de la structure de chaque section. Ne vous inquiétez pas si ce que vous ne connaissez pas ce que vous voyez. Vous pouvez passer en revue les modèles d’autres utilisateurs et écrire vos propres modèles à mesure que vous gagnez en expérience pratique.
Vous avez peut-être utilisé JSON (JavaScript Object Notation) pour envoyer des données entre les serveurs et les applications web. JSON est aussi un moyen courant de décrire la configuration des applications et de l’infrastructure.
JSON nous permet d’exprimer les données stockées en tant qu’obje, comme une machine virtuelle, dans du texte. Un document JSON est essentiellement une collection de paires clé-valeur. Chaque clé est une chaîne. La valeur de la clé peut être une chaîne, un nombre, une expression booléenne, une liste de valeurs ou un objet (qui est une collection d’autres paires clé-valeur).
Un modèle Resource Manager peut contenir les sections suivantes :
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "",
"parameters": { },
"variables": { },
"functions": [ ],
"resources": [ ],
"outputs": { }
}
Bien que ces sections soient exprimées à l’aide de JSON, elles ne sont pas liées au langage JSON réel. Intéressons-nous en détail à chacune de ces sections.
Paramètres
Dans cette section, vous spécifiez les valeurs qui sont configurables quand le modèle s’exécute. Par exemple, vous pouvez autoriser vos utilisateurs de modèle à spécifier un nom d’utilisateur, un mot de passe ou un nom de domaine.
Voici un exemple qui illustre deux paramètres : l’un pour le nom d’utilisateur d’une machine virtuelle et l’autre pour son mot de passe.
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
},
"adminPassword": {
"type": "securestring",
"metadata": {
"description": "Password for the Virtual Machine."
}
}
}
Variables
Dans cette section, vous définissez les valeurs qui sont utilisées dans le modèle. Les variables peuvent vous aider à simplifier la gestion de vos modèles. Par exemple, vous pouvez définir un nom de compte de stockage une fois comme variable et utiliser cette variable dans le modèle. Si le nom de compte de stockage change, vous devez mettre à jour uniquement la variable.
Voici un exemple qui illustre quelques variables qui décrivent les fonctionnalités réseau d’une machine virtuelle.
"variables": {
"nicName": "myVMNic",
"addressPrefix": "10.0.0.0/16",
"subnetName": "Subnet",
"subnetPrefix": "10.0.0.0/24",
"publicIPAddressName": "myPublicIP",
"virtualNetworkName": "MyVNET"
}
Fonctions
Dans cette section, vous définissez les procédures que vous ne voulez pas répéter dans le modèle. Comme les variables, les fonctions peuvent vous aider à simplifier la gestion de vos modèles. Voici un exemple qui crée une fonction visant à créer un nom unique qui peut être utilisé lors de la création de ressources qui ont des critères de nommage global unique.
"functions": [
{
"namespace": "contoso",
"members": {
"uniqueName": {
"parameters": [
{
"name": "namePrefix",
"type": "string"
}
],
"output": {
"type": "string",
"value": "[concat(toLower(parameters('namePrefix')), uniqueString(resourceGroup().id))]"
}
}
}
}
],
Ressources
Dans cette section, vous définissez les ressources Azure qui composent votre déploiement.
Voici un exemple qui crée une ressource d’adresse IP publique.
{
"type": "Microsoft.Network/publicIPAddresses",
"name": "[variables('publicIPAddressName')]",
"location": "[parameters('location')]",
"apiVersion": "2018-08-01",
"properties": {
"publicIPAllocationMethod": "Dynamic",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsLabelPrefix')]"
}
}
}
Ici, le type de ressource est Microsoft.Network/publicIPAddresses. Son nom se lit à partir de la section des variables et son emplacement (ou sa région Azure) se lit à partir de la section des paramètres.
Étant donné que les types de ressource peuvent changer au fil du temps, apiVersion fait référence à la version du type de ressource que vous souhaitez utiliser. Comme les types de ressources évoluent et changent, vous pouvez modifier vos modèles pour utiliser les dernières fonctionnalités quand vous voulez.
Sorties
Dans cette section, vous définissez toutes les informations que vous voulez recevoir quand le modèle s’exécute. Par exemple, vous pouvez vouloir recevoir l’adresse IP ou le FQDN de votre machine virtuelle ; vous ne connaissez pas ces informations tant que le déploiement ne s’est pas exécuté.
L’exemple suivant montre une sortie nommée hostname. La valeur du FQDN est lue dans les paramètres d’adresse IP publique de la machine virtuelle.
"outputs": {
"hostname": {
"type": "string",
"value": "[reference(variables('publicIPAddressName')).dnsSettings.fqdn]"
}
}
Comment faire pour déployer un workflow Azure Logic Apps dans un modèle ?
Un workflow Azure Logic Apps est une ressource dans Azure. Ainsi, nous pouvons la déployer dans un modèle en l’ajoutant à la liste des ressources à déployer dans la section resources du modèle Resource Manager. Qu’ajoutons-nous exactement à la section resources pour définir le workflow ? Nous ajoutons à la section resources la définition de workflow JSON du workflow concerné. De fait, l’extrait de code JSON suivant montre un modèle Resource Manager permettant de déployer le workflow de base décrit dans l’unité précédente. Comme le montre la partie mise en surbrillance, la section resources contient la définition de workflow complète.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {},
"variables": {},
"resources": [
{
"type": "Microsoft.Logic/workflows",
"apiVersion": "2017-07-01",
"name": "HelloLogicAppsTemplate",
"location": "westus2",
"properties": {
"state": "Enabled",
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"contentVersion": "1.0.0.0",
"parameters": {},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"method": "GET",
"schema": {}
}
}
},
"actions": {
"Response": {
"runAfter": {},
"type": "Response",
"kind": "Http",
"inputs": {
"body": "Hello Logic Apps Template!",
"statusCode": 200
}
}
},
"outputs": {}
},
"parameters": {}
}
}
],
"outputs": {
"logicAppUrl": {
"type": "string",
"value": "[listCallbackURL(concat(resourceId('Microsoft.Logic/workflows/', 'HelloLogicAppsTemplate'), '/triggers/manual'), '2017-07-01').value]"
}
}
}
Nous pouvons déployer ce modèle en utilisant l’une des méthodes suivantes :
- Déployer à l’aide du portail Azure
- Déployer à l’aide du module PowerShell
Az - Déployer à partir de l’interface de ligne de commande (CLI) Azure
Dans ce module, nous allons déployer des modèles à l’aide d’Azure CLI et des commandes az deployment group.
Comment faire pour écrire un modèle Resource Manager ?
Les approches pour écrire des modèles Resource Manager sont nombreuses. Même si vous pouvez écrire un modèle à partir de zéro, il est courant de commencer avec un modèle existant et de le modifier selon vos besoins.
Voici quelques moyens d’obtenir un modèle de démarrage :
- Utiliser le portail Azure pour créer un modèle basé sur les ressources d’un groupe de ressources existant.
- Commencer avec un modèle que vous ou votre équipe avez créé dans un but précis.
- Commencez avec un modèle de démarrage rapide Azure. Vous verrez comment dans la prochaine partie.
Quelle que soit votre approche, l’écriture d’un modèle implique d’utiliser un éditeur de texte. Vous pouvez faire appel à votre éditeur préféré, mais l’extension Azure Resource Manager Tools de Visual Studio Code est spécialement conçue pour la création de modèles. Cette extension vous permet de parcourir plus facilement le code de votre modèle et de bénéficier de la saisie semi-automatique pour de nombreuses tâches courantes.
Quand vous allez explorer et écrire vos modèles, référez-vous à la documentation pour comprendre quels types de ressources sont disponibles et comment les utiliser.
Dans l’unité suivante, nous examinons plus en détail un modèle existant, puis le déployons à partir d’Azure CLI.