Partager via

Créer et déployer des workflows d’application logique monolocataire en utilisant Logic Apps avec Azure Arc (préversion)

  • Article

Notes

Cette fonctionnalité est en préversion et est soumise aux conditions d’utilisation supplémentaires des préversions de Microsoft Azure.

Avec Logic Apps avec Azure Arc, vous pouvez créer et déployer des flux de travail d’application logique monolocataire sur une infrastructure Kubernetes que vous utilisez et gérez. Vos applications logiques s’exécutent dans un emplacement personnalisé mappé à un cluster Kubernetes avec Azure Arc sur lequel vous avez installé et activé le bundle d’extensions de la plateforme Azure App Service.

Par exemple, ce cluster peut être un service Azure Kubernetes, un Kubernetes nu ou une autre configuration. Le pack d’extensions vous permet d’exécuter des services de plateforme tels qu’Azure Logic Apps, Azure App Service et Azure Functions sur votre cluster Kubernetes.

Pour plus d’informations, consultez la documentation suivante :

Prérequis

Cette section décrit les conditions préalables courantes pour toutes les approches et tous les outils que vous pouvez utiliser pour créer et déployer vos workflows d’application logique. Les conditions préalables spécifiques à l’outil s’affichent en même temps que les étapes correspondantes.

  • Compte Azure avec un abonnement actif. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit.

  • Un environnement Kubernetes équipé d’un cluster Kubernetes avec Azure Arc et un emplacement personnalisé où vous pouvez héberger et exécuter Azure Logic Apps, Azure App Service et Azure Functions.

    Important

    Veillez à utiliser le même emplacement de ressource pour votre environnement Kubernetes, l’emplacement personnalisé et l’application logique.

    Lorsque vous créez l’extension de pack App Service sur votre cluster Kubernetes, vous pouvez modifier le comportement de mise à l’échelle par défaut pour l’exécution de vos workflows d’application logique. Lorsque vous créez l’extension à l’aide de la commande Azure CLI az k8s-extension create , veillez à inclure le paramètre de configuration keda.enabled=true :

    az k8s-extension create {other-command-options} --configuration-settings "keda.enabled=true"

    Pour plus d’informations, consultez la documentation suivante :

  • Votre propre identité Microsoft Entra

    Si vos workflows doivent utiliser des connexions hébergées sur Azure, comme Office 365 Outlook ou le Stockage Azure, votre application logique doit utiliser une identité Microsoft Entra pour l’authentification. Logic Apps avec Azure Arc peut s’exécuter sur n’importe quelle infrastructure, mais elle a besoin d’une identité qui a l’autorisation d’utiliser des connexions hébergées sur Azure. Pour configurer cette identité, créez une inscription d’application dans Microsoft Entra ID que votre application logique utilise comme identité.

    Remarque

    La prise en charge des identités managées n’est pas disponible actuellement pour Logic Apps avec Azure Arc.

    Pour créer une inscription d’application Microsoft Entra avec Azure CLI, suivez ces étapes :

    1. Créez une inscription d’application à l’aide de la commande az ad sp create.

    2. Pour passer en revue tous les détails, exécutez la commande az ad sp show.

    3. À partir de la sortie des deux commandes, recherchez et enregistrez l’ID client, l’ID d’objet, l’ID de locataire et les valeurs de clé secrète client que vous devez conserver pour une utilisation ultérieure.

    Pour créer une inscription d’application Microsoft Entra avec le portail Azure, suivez ces étapes :

    1. Créez une inscription d’application Microsoft Entra avec le portail Azure.

    2. Une fois la création terminée, recherchez la nouvelle inscription d’application dans le portail.

    3. Dans le menu d’inscription, sélectionnez Vue d’ensemble, puis enregistrez l’ID client, l’ID de locataire et les valeurs de clé secrète client.

    4. Pour trouver l’ID d’objet, en regard du champ Application gérée dans l’annuaire local, sélectionnez le nom de l’inscription de votre application. Dans la vue Propriétés, copiez l’ID de l’objet.

Créer et déployer des applications logiques

Selon que vous souhaitez utiliser Azure CLI ou Visual Studio Code, sélectionnez l’onglet correspondant pour passer en revue les conditions préalables et les étapes spécifiques.

Avant de commencer, vous devez disposer des éléments suivants :

Vérifier l’environnement et la version de l’interface CLI

  1. Connectez-vous au portail Azure. Vérifiez que votre abonnement est actif en exécutant la commande suivante :

    az login

  2. Vérifiez votre version d’Azure CLI dans un terminal ou une fenêtre de commande en exécutant la commande suivante :

    az --version

    Pour obtenir la version la plus récente, consultez les notes de publication les plus récentes.

  3. Si vous ne disposez pas de la dernière version, mettez à jour votre installation en suivant le guide d’installation pour votre système d’exploitation ou votre plateforme.

Installer l’extension Azure Logic Apps (Standard) pour Azure CLI

Installez l’extension Azure Logic Apps (Standard) monolocataire en préversion pour Azure CLI en exécutant la commande suivante :

az extension add --yes --source "https://aka.ms/logicapp-latest-py2.py3-none-any.whl"

Créer un groupe de ressources

Si ne disposez pas encore d’un groupe de ressources pour votre application logique, créez-en un en exécutant la commande az group create. À moins d’avoir déjà défini un abonnement par défaut pour votre compte Azure, veillez à utiliser le paramètre --subscription avec le nom ou l’identificateur de votre abonnement. Sinon, vous n’avez pas besoin d’utiliser le paramètre --subscription.

Conseil

Pour définir un abonnement par défaut, exécutez la commande suivante et remplacez MySubscription par le nom ou l’identificateur de votre abonnement.

az account set --subscription MySubscription

Par exemple, la commande suivante crée un groupe de ressources nommé MyResourceGroupName à l’aide de l’abonnement Azure nommé MySubscription à l’emplacement eastus :

az group create --name MyResourceGroupName 
   --subscription MySubscription 
   --location eastus

Si votre groupe de ressources est correctement créé, la sortie affiche la valeur de provisioningState comme étant Succeeded :

<...>
   "name": "testResourceGroup",
   "properties": {
      "provisioningState": "Succeeded"
    },
<...>

Créer une application logique

Pour créer une application logique avec Azure Arc, exécutez la commande az logicapp create avec les paramètres nécessaires suivants. Les emplacements de ressources doivent tous être identiques pour votre application logique, votre emplacement personnalisé et votre environnement Kubernetes.

Paramètres Description
--name -n Nom unique pour votre application logique
--resource-group -g Nom du groupe de ressources dans lequel vous souhaitez créer votre application logique. Si vous n’en avez pas, créez un groupe de ressources.
--storage-account -s Compte de stockage à utiliser avec votre application logique. Pour les comptes de stockage dans le même groupe de ressources, utilisez une valeur de chaîne. Pour les comptes de stockage dans un groupe de ressources différent, utilisez un ID de ressource. 
az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation

Pour créer une application logique avec Azure Arc au moyen d’une image Azure Container Registry (ACR) privée, exécutez la commande az logicapp create avec les paramètres nécessaires suivants :

az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation 
   --deployment-container-image-name myacr.azurecr.io/myimage:tag
   --docker-registry-server-password MyPassword 
   --docker-registry-server-user MyUsername

Afficher les détails de l’application logique

Pour afficher les détails de votre application logique avec Azure Arc, exécutez la commande az logicapp show avec les paramètres nécessaires suivants :

az logicapp show --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Déployer l’application logique

Pour déployer votre application logique avec Azure Arc en utilisant le déploiement du fichier zip Kudu d’Azure App Service, exécutez la commande az logicapp deployment source config-zip avec les paramètres nécessaires suivants :

Important

Assurez-vous que votre fichier zip contient les artefacts de votre projet à la racine. Ces artefacts comprennent tous les dossiers de flux de travail, les fichiers config tels que host.json, connections.json et tout autre fichier associé. N’ajoutez pas de dossiers supplémentaires ni ne placez d’artefacts dans des dossiers qui n’existent pas déjà dans la structure de votre projet. Par exemple, cette liste montre un exemple de structure de fichier MyBuildArtifacts.zip :

MyStatefulWorkflow1-Folder
MyStatefulWorkflow2-Folder
connections.json
host.json

az logicapp deployment source config-zip --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --src MyBuildArtifact.zip

Démarrer l’application logique

Pour démarrer votre application logique avec Azure Arc, exécutez la commande az logicapp start avec les paramètres nécessaires suivants :

az logicapp start --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Arrêter l’application logique

Pour arrêter votre application logique avec Azure Arc, exécutez la commande az logicapp stop avec les paramètres nécessaires suivants :

az logicapp stop --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Redémarrer l’application logique

Pour redémarrer votre application logique avec Azure Arc, exécutez la commande az logicapp restart avec les paramètres nécessaires suivants :

az logicapp restart --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Supprimer l’application logique

Pour supprimer votre application logique avec Azure Arc, exécutez la commande az logicapp delete avec les paramètres nécessaires suivants :

az logicapp delete --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Configurer l’authentification de connexion

Actuellement, les clusters Kubernetes avec Azure Arc ne prennent pas en charge l’utilisation d’une identité managée d’application logique pour authentifier les connexions d’API managées. Vous créez ces connexions gérées et hébergées par Azure quand vous utilisez des connecteurs managés dans vos workflows.

À la place, vous devez créer votre propre inscription d’application dans Microsoft Entra ID. Vous pouvez ensuite utiliser cette inscription d’application comme identité pour les applications logiques déployées et exécutées dans Logic Apps avec Azure Arc. Pour plus d’informations, consultez les prérequis de haut niveau.

À partir de l’inscription de votre application, vous avez besoin de l’ID client, de l’ID d’objet, de l’ID de locataire et de la clé secrète client. Si vous utilisez Visual Studio Code pour le déploiement, vous avez une expérience intégrée pour configurer votre application logique avec une identité Microsoft Entra. Pour plus d’informations, consultez Créer et déployer des workflows d’application logique - Visual Studio Code.

Toutefois, si vous utilisez Visual Studio Code pour le développement, mais que vous utilisez des pipelines Azure CLI ou automatisés pour le déploiement, procédez comme suit.

Configurer les paramètres de connexion et d’application dans votre projet

  1. Dans le fichier connections.js de votre projet d’application logique, recherchez l’objet authentication de la connexion managée. Remplacez le contenu de cet objet par les informations d’inscription de votre application, que vous avez générées précédemment dans les prérequis de haut niveau :

    "authentication": {
   "type": "ActiveDirectoryOAuth",
   "audience": "https://management.core.windows.net/",
   "credentialType": "Secret",
   "clientId": "@appsetting('WORKFLOWAPP_AAD_CLIENTID')",
   "tenant": "@appsetting('WORKFLOWAPP_AAD_TENANTID')",
   "secret": "@appsetting('WORKFLOWAPP_AAD_CLIENTSECRET')"
}

  2. Dans le fichier local.settings.json de votre projet d’application logique, ajoutez l’ID client, l’ID d’objet, l’ID de locataire et la clé secrète client. Après le déploiement, ces paramètres deviennent les paramètres de votre application logique.

    {
   "IsEncrypted": false,
   "Values": {
      <...>
      "WORKFLOWAPP_AAD_CLIENTID":"<my-client-ID>",
      "WORKFLOWAPP_AAD_OBJECTID":"<my-object-ID",
      "WORKFLOWAPP_AAD_TENANTID":"<my-tenant-ID>",
      "WORKFLOWAPP_AAD_CLIENTSECRET":"<my-client-secret>"
   }
}

Important

Pour les scénarios ou environnements de production, veillez à protéger et à sécuriser ces secrets et informations sensibles, par exemple en utilisant un coffre de clés.

Ajouter des stratégies d’accès

Dans Azure Logic Apps monolocataire, chaque application logique a une identité à laquelle les stratégies d’accès accordent des autorisations pour utiliser les connexions managées et hébergées par Azure. Vous pouvez configurer ces stratégies d’accès à l’aide des déploiements d’infrastructure ou du portail Azure.

Modèle ARM

Dans votre modèle Azure Resource Manager (ARM), incluez la définition de ressource suivante pour chaque connexion d’API managée et fournissez les informations suivantes :

Paramètre Description
<connection-name> Nom de votre connexion d’API managée, par exemple office365
<object-ID> ID d’objet de votre identité Microsoft Entra, précédemment enregistré pendant l’inscription d’application
<ID de locataire> ID de locataire de votre identité Microsoft Entra, précédemment enregistré pendant l’inscription d’application 
{
   "type": "Microsoft.Web/connections/accessPolicies",
   "apiVersion": "2016-06-01",
   "name": "[concat('<connection-name>'),'/','<object-ID>')]",
   "location": "<location>",
   "dependsOn": [
      "[resourceId('Microsoft.Web/connections', parameters('connection_name'))]"
   ],
   "properties": {
      "principal": {
         "type": "ActiveDirectory",
         "identity": {
            "objectId": "<object-ID>",
            "tenantId": "<tenant-ID>"
         }
      }
   }
}

Pour plus d’informations, consultez la documentation Microsoft.Web/connections/accesspolicies (modèle ARM).

Portail Azure

Pour cette tâche, utilisez votre ID client précédemment enregistré en tant qu’ID d’application.

  1. Dans le portail Azure, recherchez et sélectionnez votre application logique. Dans le menu de votre application logique, sous Flux de travail, sélectionnez Connexions pour afficher une liste de toutes les connexions dans les flux de travail de votre ressource d’application logique.

  2. Sous Connexions d’API, sélectionnez une connexion, office365 dans cet exemple.

  3. Dans le menu de la connexion, sous Paramètres, sélectionnez Stratégies d’accès>Ajouter.

  4. Dans le volet Ajouter une stratégie d’accès, dans la zone de recherche, recherchez et sélectionnez votre ID client précédemment enregistré.

  5. Lorsque vous avez terminé, sélectionnez Ajouter.

  6. Répétez ces étapes pour chaque connexion Azure hébergée dans votre application logique.

Automatiser le déploiement de DevOps

Pour générer et déployer vos applications logiques avec Azure Arc, vous pouvez utiliser les mêmes pipelines et processus que pour les applications logiques monolocataires. Pour automatiser les déploiements d’infrastructure à l’aide de pipelines pour DevOps, apportez les modifications suivantes au niveau de l’infrastructure pour les déploiements avec et sans conteneur.

Déploiement standard (non conteneur)

Si vous utilisez zip deploy pour le déploiement d’applications logiques, vous n’avez pas besoin de configurer un registre Docker pour héberger des images de conteneur. Bien que les applications logiques sur Kubernetes s’exécutent techniquement sur des conteneurs, Logic Apps avec Azure Arc gère ces conteneurs pour vous. Pour ce scénario, effectuez les tâches suivantes lors de la configuration de votre infrastructure :

Dans votre modèle Azure Resource Manager (ARM), incluez les valeurs suivantes :

Élément Propriété JSON Description
Emplacement location Veillez à utiliser le même emplacement de ressources (région Azure) que votre emplacement personnalisé et votre environnement Kubernetes. Les emplacements de ressources doivent tous être identiques pour votre application logique, votre emplacement personnalisé et votre environnement Kubernetes.

Remarque : cette valeur n’est pas la même que le nom de votre emplacement personnalisé.
Genre d’application kind Le type d’application que vous déployez afin que la plateforme Azure puisse identifier votre application. Pour Azure Logic Apps, ces informations ressemblent à l’exemple suivant : kubernetes,functionapp,workflowapp,linux
Emplacement étendu extendedLocation Cet objet nécessite le "name" de votre emplacement personnalisé pour votre environnement Kubernetes et "type" doit être défini sur "CustomLocation".
ID de ressource du plan d’hébergement serverFarmId L’ID de ressource du plan App Service associé, mis en forme comme suit :

"/subscriptions/{subscriptionID}/resourceGroups/{groupName}/providers/Microsoft.Web/serverfarms/{appServicePlanName}"
Chaîne de connexion de stockage AzureWebJobsStorage La chaîne de connexion de votre compte de stockage

Important : Vous devez fournir la chaîne de connexion pour votre compte de stockage dans votre modèle ARM. Pour les scénarios ou environnements de production, veillez à protéger et à sécuriser ces secrets et informations sensibles, par exemple en utilisant un coffre de clés.

Modèle ARM

L’exemple suivant décrit un exemple de définition de ressource Logic Apps avec Azure Arc que vous pouvez utiliser dans votre modèle ARM. Pour plus d’informations, consultez la documentation Microsoft.Web/sites template format (JSON).

{
   "type": "Microsoft.Web/sites",
   "apiVersion": "2020-12-01",
   "name": "[parameters('name')]",
   "location": "[parameters('location')]",
   "kind": "kubernetes,functionapp,workflowapp,linux",
   "extendedLocation": {
      "name": "[parameters('customLocationId')]",
      "type": "CustomLocation"
    },
   "properties": {
      "clientAffinityEnabled": false,
      "name": "[parameters('name')]",
      "serverFarmId": "<hosting-plan-ID>",
      "siteConfig": {
         "appSettings": [
            {
               "name": "FUNCTIONS_EXTENSION_VERSION",
               "value": "~3"
            },
            {
               "name": "FUNCTIONS_WORKER_RUNTIME",
               "value": "dotnet"
            },
            {
               "name": "AzureWebJobsStorage",
               "value": "<storage-connection-string>"
            },
            {
               "name": "AzureFunctionsJobHost__extensionBundle__id",
               "value": "Microsoft.Azure.Functions.ExtensionBundle.Workflows"
            },
            {
               "name": "AzureFunctionsJobHost__extensionBundle__version",
               "value": "[1.*, 2.0.0)"
            },
            {
               "name": "APP_KIND",
               "value": "workflowapp"
            }
         ],
         "use32BitWorkerProcess": "[parameters('use32BitWorkerProcess')]",
         "linuxFxVersion": "Node|12"
      }
   }
}

Remarque

Par défaut, FUNCTIONS_WORKER_RUNTIME paramètre d’application pour votre application logique est dotnet. Auparavant, node était la valeur par défaut. Cependant, dotnet est désormais la valeur par défaut pour toutes les applications logiques déployées, nouvelles et existantes, activées par l’Arc, même pour les applications qui avaient une valeur différente. Cette modification ne devrait pas affecter le runtime de votre flux de travail, et tout devrait fonctionner de la même manière qu’auparavant. Pour plus d’informations, consultez le paramètre d’application FUNCTIONS_WORKER_RUNTIME.

Le paramètre d’application APP_KIND de votre application logique est défini sur workflowapp, mais dans certains scénarios, ce paramètre d’application est manquant, par exemple en raison de modèles Azure Resource Manager ou d’autres scénarios où le paramètre peut ne pas être inclus. Si certaines actions ne fonctionnent pas, telles que la Exécuter le code JavaScript ou si le flux de travail cesse de fonctionner, vérifiez que le paramètre d’application APP_KIND existe et est défini sur workflowapp. Pour plus d’informations, voir le paramètre APP_KIND de l’application.

Déploiement de conteneur

Si vous préférez utiliser des outils de conteneur et des processus de déploiement, vous pouvez conteneuriser vos applications logiques et les déployer sur Logic Apps avec Azure Arc. Pour ce scénario, effectuez les tâches de haut niveau suivantes lors de la configuration de votre infrastructure :

  • Configurez un registre Docker pour héberger vos images de conteneur.

  • Pour conteneuriser votre application logique, ajoutez le fichier Dockerfile suivant au dossier racine de votre projet d’application logique, puis suivez les étapes de création et de publication d’une image dans le registre Docker. Par exemple, consultez le Tutoriel : Créer et déployer des images conteneurs dans le cloud avec Azure Container Registry Tasks.

    Notes

    Si vous utilisez SQL en tant que fournisseur de stockage, veillez à utiliser une image Azure Functions version 3.3.1 ou ultérieure.

    FROM mcr.microsoft.com/azure-functions/node:3.3.1
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true \
FUNCTIONS_V2_COMPATIBILITY_MODE=true
COPY . /home/site/wwwroot
RUN cd /home/site/wwwroot

  • Informez le fournisseur de ressources que vous créez une application logique sur Kubernetes.

  • Dans votre modèle de déploiement, pointez sur le registre Docker et l’image de conteneur dans laquelle vous envisagez de déployer. Azure Logic Apps monolocataire utilise ces informations pour récupérer l’image de conteneur à partir de votre registre Docker.

  • Incluez un plan App Service avec votre déploiement. Pour plus d’informations, consultez Inclure un plan App Service avec le déploiement.

Dans votre modèle Azure Resource Manager (ARM), incluez les valeurs suivantes :

Élément Propriété JSON Description
Emplacement location Veillez à utiliser le même emplacement de ressources (région Azure) que votre emplacement personnalisé et votre environnement Kubernetes. Les emplacements de ressources doivent tous être identiques pour votre application logique, votre emplacement personnalisé et votre environnement Kubernetes.

Remarque : cette valeur n’est pas la même que le nom de votre emplacement personnalisé.
Genre d’application kind Le type d’application que vous déployez afin que la plateforme Azure puisse identifier votre application. Pour Azure Logic Apps, ces informations ressemblent à l’exemple suivant : kubernetes,functionapp,workflowapp,container
Emplacement étendu extendedLocation Cet objet nécessite le "name" de votre emplacement personnalisé pour votre environnement Kubernetes et "type" doit être défini sur "CustomLocation".
Nom du conteneur linuxFxVersion Nom de votre conteneur, mis en forme comme suit : DOCKER\|<container-name>
ID de ressource du plan d’hébergement serverFarmId L’ID de ressource du plan App Service associé, mis en forme comme suit :

"/subscriptions/{subscriptionID}/resourceGroups/{groupName}/providers/Microsoft.Web/serverfarms/{appServicePlanName}"
Chaîne de connexion de stockage AzureWebJobsStorage La chaîne de connexion de votre compte de stockage

Important : Quand vous effectuez un déploiement sur un conteneur Docker, vous devez fournir la chaîne de connexion de votre compte de stockage dans votre modèle ARM. Pour les scénarios ou environnements de production, veillez à protéger et à sécuriser ces secrets et informations sensibles, par exemple en utilisant un coffre de clés.

Pour référencer votre registre Docker et votre image de conteneur, incluez ces valeurs dans votre modèle :

Élément Propriété JSON Description
URL du serveur de registre Docker DOCKER_REGISTRY_SERVER_URL URL du serveur de registre Docker
Serveur de registre Docker DOCKER_REGISTRY_SERVER_USERNAME Nom d’utilisateur pour accéder au serveur de registre Docker
Mot de passe du serveur de registre Docker DOCKER_REGISTRY_SERVER_PASSWORD Mot de passe pour accéder au serveur de registre Docker

Modèle ARM

L’exemple suivant décrit un exemple de définition de ressource Logic Apps avec Azure Arc que vous pouvez utiliser dans votre modèle ARM. Pour plus d’informations, consultez la documentation Microsoft.Web/sites template format (modèle ARM).

{
   "type": "Microsoft.Web/sites",
   "apiVersion": "2020-12-01",
   "name": "[parameters('name')]",
   "location": "[parameters('location')]",
   "kind": " kubernetes,functionapp,workflowapp,container",
   "extendedLocation": {
      "name": "[parameters('customLocationId')]",
      "type": "CustomLocation"
    },
   "properties": {
      "name": "[parameters('name')]",
      "clientAffinityEnabled": false,
      "serverFarmId": "<hosting-plan-ID>",
      "siteConfig": {
         "appSettings": [
            {
               "name": "FUNCTIONS_EXTENSION_VERSION",
               "value": "~3"
            },
            {
               "name": "FUNCTIONS_WORKER_RUNTIME",
               "value": "dotnet"
            },
            {
               "name": "AzureWebJobsStorage",
               "value": "<storage-connection-string>"
            },
            {
               "name": "AzureFunctionsJobHost__extensionBundle__id",
               "value": "Microsoft.Azure.Functions.ExtensionBundle.Workflows"
            },
            {
               "name": "AzureFunctionsJobHost__extensionBundle__version",
               "value": "[1.*, 2.0.0)"
            },
            {
               "name": "APP_KIND",
               "value": "workflowapp"
            }, 
            {
               "name": "DOCKER_REGISTRY_SERVER_URL",
               "value": "<docker-registry-server-URL>"
            },
            { 
               "name": "DOCKER_REGISTRY_SERVER_USERNAME",
               "value": "<docker-registry-server-username>"
            },
            {
               "name": "DOCKER_REGISTRY_SERVER_PASSWORD",
               "value": "<docker-registry-server-password>"
            }
         ],
         "use32BitWorkerProcess": "[parameters('use32BitWorkerProcess')]",
         "linuxFxVersion": "DOCKER|<container-name>"
      }
   }
}

Remarque

Auparavant, la valeur par défaut du paramètre FUNCTIONS_WORKER_RUNTIME était node. Désormais, dotnet est la valeur par défaut pour toutes les applications logiques standard déployées, nouvelles et existantes, même pour les applications qui avaient une valeur différente. Cette modification ne devrait pas affecter le runtime de votre flux de travail, et tout devrait fonctionner de la même manière qu’auparavant. Pour plus d’informations, consultez le paramètre d’application FUNCTIONS_WORKER_RUNTIME.

Inclure un plan App Service avec le déploiement

Que vous disposiez d’un déploiement standard ou de conteneur, vous devez inclure un plan App Service avec votre déploiement. Bien que ce plan devienne moins pertinent dans un environnement Kubernetes, les déploiements standard et de conteneur requièrent toujours un plan App Service.

Bien que les autres options de création gèrent habituellement la mise en service de la ressource Azure pour ce plan, si vos déploiements utilisent des modèles d’« infrastructure en tant que code », vous devez créer explicitement la ressource Azure pour le plan. La ressource du plan d’hébergement ne change pas, uniquement les informations sku.

Dans votre modèle Azure Resource Manager (ARM), incluez les valeurs suivantes :

Élément Propriété JSON Description
Emplacement location Veillez à utiliser le même emplacement de ressources (région Azure) que votre emplacement personnalisé et votre environnement Kubernetes. Les emplacements de ressources doivent tous être identiques pour votre application logique, votre emplacement personnalisé et votre environnement Kubernetes.

Remarque : cette valeur n’est pas la même que le nom de votre emplacement personnalisé.
Type kind Type de plan app service déployé qui doit être kubernetes,linux
Emplacement étendu extendedLocation Cet objet nécessite le "name" de votre emplacement personnalisé pour votre environnement Kubernetes et "type" doit être défini sur "CustomLocation".
Nom du plan d’hébergement name Le nom du plan App Service
Niveau de plan sku: tier Le niveau de plan App Service, qui est K1
Nom du plan sku: name Nom du plan App Service, qui est Kubernetes

Modèle ARM

L’exemple suivant décrit une définition de ressource de plan App Service que vous pouvez utiliser avec le déploiement de votre application. Pour plus d’informations, consultez la documentation Microsoft.Web/serverfarms template format (modèle ARM).

{
   "type": "Microsoft.Web/serverfarms",
   "apiVersion": "2020-12-01",
   "location": "<location>",
   "name": "<hosting-plan-name>",
   "kind": "kubernetes,linux",
   "extendedLocation": {
      "name": "[parameters('customLocationId')]",
      "type": "CustomLocation"
   },
   "sku": {
      "tier": "Kubernetes",
      "name": "K1", 
      "capacity": 1
   },
   "properties": {
      "kubeEnvironmentProfile": {
         "id": "[parameters('kubeEnvironmentId')]"
      }
   }
}

Modifier le comportement de mise à l’échelle par défaut

Logic Apps avec Azure Arc gère automatiquement la mise à l’échelle de vos applications logiques en fonction du nombre de travaux dans la file d’attente de stockage du back-end. Toutefois, vous pouvez modifier le comportement de mise à l’échelle par défaut.

Dans une application logique, la définition de workflow spécifie la séquence d’actions à exécuter. Chaque fois qu’une exécution de workflow est déclenchée, le runtime Azure Logic Apps crée un travail pour chaque type d’action dans la définition de workflow. Le runtime organise ensuite ces travaux dans un séquenceur de travaux. Ce séquenceur orchestre l’exécution des tâches pour la définition de workflow, mais le moteur d’orchestration de travail Azure Logic Apps sous-jacent exécute chaque travail.

Pour les workflows avec état, le moteur d’orchestration de travail utilise des messages de file d’attente de stockage pour planifier des travaux dans les séquenceurs de travaux. En arrière-plan, les répartiteurs de tâches (ou instances de travail de répartiteur) surveillent ces files d’attente de travaux. Le moteur d’orchestration utilise un nombre minimal et maximal d’instances de travail par défaut pour surveiller les files d’attente de travaux. Pour les workflows sans état, le moteur d’orchestration conserve complètement les états d’action en mémoire.

Pour modifier le comportement de mise à l’échelle par défaut, vous spécifiez des nombres minimum et maximum d’instances de travail qui analysent les files d’attente de travaux.

Conditions préalables à la modification de la mise à l’échelle

Sur votre cluster Kubernetes avec Azure Arc, l’extension de bundle App Service que vous avez précédemment créée doit avoir la propriété keda.enabled définie sur true. Pour plus d’informations, consultez les prérequis de haut niveau.

Modifier le seuil de mise à l’échelle

Dans Logic Apps avec Azure Arc, la longueur de la file d’attente de travaux déclenche un événement de mise à l’échelle et définit un seuil pour la fréquence des mises à l’échelle de votre application logique. Vous pouvez modifier la longueur de la file d’attente, avec la valeur par défaut définie sur 20 travaux. Pour une mise à l’échelle moins fréquente, augmentez la longueur de la file d’attente. Pour une mise à l’échelle plus fréquente, diminuez la longueur de la file d’attente. Ce processus peut nécessiter des expérimentations de votre part.

Pour modifier la longueur de la file d’attente, dans le fichier host.json au niveau de la racine du projet d’application logique, définissez la propriété Runtime.ScaleMonitor.KEDA.TargetQueueLength, par exemple :

"extensions": {
   "workflow": {
      "settings": {
         "Runtime.ScaleMonitor.KEDA.TargetQueueLength": "10"
      }
   }
}

Modifier le débit maximal

Sur une ressource d’application logique existante, vous pouvez modifier le nombre maximal d’instances de travail, dont la valeur par défaut est 2. Cette valeur détermine la limite supérieure du nombre d’instances de worker pouvant surveiller les files d’attente de travaux.

Pour modifier cette valeur maximale, utilisez Azure CLI (création d’application logique uniquement) et le portail Azure.

Azure CLI

Pour créer une application logique, exécutez la commande az logicapp create avec les paramètres suivants :

az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation 
   [--plan MyHostingPlan] [--min-worker-count 1] [--max-worker-count 4]

Pour configurer le nombre maximal d’instances, utilisez le paramètre --settings :

az logicapp config appsettings set --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription
   --settings "K8SE_APP_MAX_INSTANCE_COUNT=10"

Portail Azure

Dans les paramètres de votre application logique monolocataire, ajoutez ou modifiez la valeur du paramètre K8SE_APP_MAX_INSTANCE_COUNT en procédant comme suit :

  1. Dans le portail Azure, recherchez et ouvrez votre application logique monolocataire.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Configuration.

  3. Dans le volet Configuration, sous Paramètres de l’application, ajoutez un nouveau paramètre d’application ou modifiez la valeur existante, si elle est déjà ajoutée.

    1. Sélectionnez Nouveau paramètre d’application, puis ajoutez le paramètre K8SE_APP_MAX_INSTANCE_COUNT avec la valeur maximale que vous souhaitez.

    2. Modifiez la valeur existante pour le paramètre K8SE_APP_MAX_INSTANCE_COUNT.

  4. Lorsque vous avez terminé, enregistrez vos modifications.

Modifier le débit minimal

Sur une ressource d’application logique existante, vous pouvez modifier le nombre minimal d’instances de travail, dont la valeur par défaut est 1. Cette valeur détermine la limite inférieure du nombre d’instances de worker pouvant surveiller les files d’attente de travaux. Pour une haute disponibilité ou des performances élevées, augmentez cette valeur.

Pour modifier cette valeur minimale, utilisez Azure CLI ou le portail Azure.

Azure CLI

Pour une ressource d’application logique existante, exécutez la commande az logicapp scale avec les paramètres suivants :

az logicapp scale --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --instance-count 5

Pour créer une application logique, exécutez la commande az logicapp create avec les paramètres suivants :

az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation 
   [--plan MyHostingPlan] [--min-worker-count 2] [--max-worker-count 4]

Portail Azure

Dans les paramètres de votre application logique monolocataire, modifiez la valeur de la propriété Scale out en procédant comme suit :

  1. Dans le portail Azure, recherchez et ouvrez votre application logique monolocataire.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Scale out.

  3. Dans le volet Scale out, faites glisser le curseur Nombre minimal d’instances vers la valeur de votre choix.

  4. Lorsque vous avez terminé, enregistrez vos modifications.

Résoudre les problèmes

Pour obtenir plus d’informations sur les applications logiques déployées, essayez les options suivantes :

Accéder aux paramètres et à la configuration de l’application

Pour accéder aux paramètres de votre application, exécutez la commande az logicapp config appsettings avec les paramètres suivants :

az logicapp config appsettings list --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Pour configurer un paramètre d’application, exécutez la commande az logicapp config appsettings set avec les paramètres suivants. Veillez à utiliser le paramètre --settings avec le nom et la valeur de votre paramètre.

az logicapp config appsettings set --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --settings "MySetting=1"

Pour supprimer un paramètre d’application, exécutez la commande az logicapp config appsettings delete avec les paramètres suivants. Veillez à utiliser le paramètre --setting-names avec le nom du paramètre que vous souhaitez supprimer.

az logicapp config appsettings delete --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription
   --setting-names MySetting

Afficher les propriétés de l’application logique

Pour afficher les informations et les propriétés de votre application, exécutez la commande az logicapp show avec les paramètres suivants :

az logicapp show --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription

Surveiller l’activité d’un workflow

Pour afficher l’activité d’un workflow dans votre application logique, procédez comme suit :

  1. Dans le portail Azure, recherchez et ouvrez votre application logique déployée.

  2. Dans le menu de l’application logique, sélectionnez Workflows, puis votre workflow.

  3. Dans le menu du workflow, sélectionnez Superviser.

Collecter les journaux d’activité

Pour obtenir des données journalisées sur votre application logique, activez Application Insights sur votre application logique si ce n’est pas déjà le cas.

Étapes suivantes