Create and deploy single-tenant based logic app workflows with Azure Arc-enabled Logic Apps (Preview)

With Azure Arc-enabled Logic Apps, you can create and deploy single-tenant based logic app workflows to a Kubernetes infrastructure that you operate and manage. Your logic apps run in a custom location that is mapped to an Azure Arc-enabled Kubernetes cluster where you installed and enabled the Azure App Service platform extensions bundle.

For example, this cluster can be Azure Kubernetes Service, bare-metal Kubernetes, or another setup. The extensions bundle enables you to run platform services such as Azure Logic Apps, Azure App Service, and Azure Functions on your Kubernetes cluster.

For more information, review the following documentation:

• What is Azure Arc-enabled Logic Apps?
• Single-tenant versus multitenant in Azure Logic Apps
• Azure Arc overview
• Azure Kubernetes Service overview
• What is Azure Arc-enabled Kubernetes?
• Custom locations on Azure Arc-enabled Kubernetes
• App Service, Functions, and Logic Apps on Azure Arc (Preview)
• Set up an Azure Arc-enabled Kubernetes cluster to run App Service, Functions, and Logic Apps (Preview)

This section describes the common prerequisites across all the approaches and tools that you can use to create and deploy your logic app workflows. Tool-specific prerequisites appear along with their corresponding steps.

• An Azure account with an active subscription. If you don't have an Azure subscription, create a free account.

• A Kubernetes environment with an Azure Arc-enabled Kubernetes cluster and custom location where you can host and run Azure Logic Apps, Azure App Service, and Azure Functions.

  Important

  Make sure that you use the same resource location for your Kubernetes environment, custom location, and logic app.

  When you create the App Service bundle extension on your Kubernetes cluster, you can change the default scaling behavior for running your logic app workflows. When you create the extension by using the Azure CLI command, az k8s-extension create, make sure to include the configuration setting, keda.enabled=true:

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

  For more information, review the following documentation:

  • App Service, Functions, and Logic Apps on Azure Arc (Preview)
  • Cluster extensions on Azure Arc-enabled Kubernetes
  • Set up an Azure Arc-enabled Kubernetes cluster to run App Service, Functions, and Logic Apps (Preview)
  • Change the default scaling behavior

• Your own Microsoft Entra identity

  If your workflows need to use any Azure-hosted connections, such as Office 365 Outlook or Azure Storage, your logic app must use a Microsoft Entra identity for authentication. Azure Arc-enabled Logic Apps can run on any infrastructure but requires an identity that has permissions to use Azure-hosted connections. To set up this identity, create an app registration in Microsoft Entra ID that your logic app uses as the required identity.

  Note

  Managed identity support is currently unavailable for Azure Arc-enabled Logic Apps.

  To create a Microsoft Entra app registration using the Azure CLI, follow these steps:

  1. Create an app registration by using the az ad sp create command.

  2. To review all the details, run the az ad sp show command.

  3. From the output of both commands, find and save the client ID, object ID, tenant ID, and client secret values, which you need to keep for later use.

  To create a Microsoft Entra app registration using the Azure portal, follow these steps:

  1. Create a new Microsoft Entra app registration by using the Azure portal.

  2. After creation finishes, find the new app registration in the portal.

  3. On the registration menu, select Overview, and save the client ID, tenant ID, and client secret values.

  4. To find the object ID, next to the Managed application in local directory field, select the name for your app registration. From the properties view, copy the object ID.

Based on whether you want to use Azure CLI or Visual Studio Code, select the matching tab to review the specific prerequisites and steps.

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

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

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

az logicapp create --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --storage-account MyStorageAccount --custom-location MyCustomLocation

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

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

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

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

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

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

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

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

Currently, Azure Arc-enabled Kubernetes clusters don't support using a logic app managed identity to authenticate managed API connections. You create these Azure-hosted and managed connections when you use managed connectors in your workflows.

Instead, you have to create your own app registration in Microsoft Entra ID. You can then use this app registration as an identity for logic apps deployed and running in Azure Arc-enabled Logic Apps. For more information, review the top-level prerequisites.

From your app registration, you need the client ID, object ID, tenant ID, and client secret. If you use Visual Studio Code to deploy, you have a built-in experience for setting up your logic app with a Microsoft Entra identity. For more information, review Create and deploy logic app workflows - Visual Studio Code.

However, if you use Visual Studio Code for development, but you use Azure CLI or automated pipelines to deploy, follow these steps.

1. In your logic app project's connections.json file, find the authentication object for the managed connection. Replace this object's contents with your app registration information, which you previously generated in the top-level prerequisites:

   "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. In your logic app project's local.settings.json file, add your client ID, object ID, tenant ID, and client secret. After deployment, these settings become your logic app settings.

   {
      "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>"
      }
   }
   

In single-tenant Azure Logic Apps, each logic app has an identity that is granted permissions by access policies to use Azure-hosted and managed connections. You can set up these access policies by using the Azure portal or infrastructure deployments.

In your Azure Resource Manager template (ARM template), include the following resource definition for each managed API connection and provide the following information:

{
   "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>"
         }
      }
   }
}

For more information, review the Microsoft.Web/connections/accesspolicies (ARM template) documentation.

For this task, use your previously saved client ID as the application ID.

1. In the Azure portal, find and open your logic app. On your logic app menu, under Workflows, select Connections, which lists all the connections in the workflows for your logic app resource.

2. Under API Connections, select a connection, which is office365 in this example.

3. On the connection's menu, under Settings, select Access policies > Add.

4. In the Add access policy pane, in the search box, find and select your previously saved client ID.

5. When you finish, select Add.

6. Repeat these steps for each Azure-hosted connection in your logic app.

To build and deploy your Azure Arc-enabled logic apps, you can use the same pipelines and processes as for single-tenant based logic apps. To automate infrastructure deployments using pipelines for DevOps, make the following changes at the infrastructure level for both noncontainer and container deployments.

If you use zip deploy for logic app deployment, you don't need to set up a Docker registry for hosting container images. Although logic apps on Kubernetes technically run on containers, Azure Arc-enabled Logic Apps manages these containers for you. For this scenario, complete the following tasks when you set up your infrastructure:

• Notify the resource provider that you're creating a logic app on Kubernetes.
• Include an App Service plan with your deployment. For more information, review Include App Service plan with deployment.

In your Azure Resource Manager template (ARM template) include the following values:

The following example describes a sample Azure Arc-enabled Logic Apps resource definition that you can use in your ARM template. For more information, review the Microsoft.Web/sites template format (JSON) documentation.

{
   "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"
      }
   }
}

If you prefer to use container tools and deployment processes, you can containerize your logic apps and deploy them to Azure Arc-enabled Logic Apps. For this scenario, complete the following high-level tasks when you set up your infrastructure:

• Set up a Docker registry for hosting your container images.

• To containerize your logic app, add the following Dockerfile to your logic app project's root folder, and follow the steps for building and publishing an image to your Docker registry, for example, review Tutorial: Build and deploy container images in the cloud with Azure Container Registry Tasks.

  Note

  If you use SQL as your storage provider, make sure that you use an Azure Functions image version 3.3.1 or later.

  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
  

• Notify the resource provider that you're creating a logic app on Kubernetes.

• In your deployment template, point to the Docker registry and container image where you plan to deploy. Single-tenant Azure Logic Apps uses this information to get the container image from your Docker registry.

• Include an App Service plan with your deployment. For more information, review Include App Service plan with deployment.

In your Azure Resource Manager template (ARM template), include the following values:

To reference your Docker registry and container image, include these values in your template:

The following example describes a sample Azure Arc-enabled Logic Apps resource definition that you can use in your ARM template. For more information, review the Microsoft.Web/sites template format (ARM template) documentation.

{
   "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>"
      }
   }
}

Whether you have a standard or container deployment, you have to include an App Service plan with your deployment. Although this plan becomes less relevant with a Kubernetes environment, both the standard and container deployments still require an App Service plan.

While other create options usually handle provisioning the Azure resource for this plan, if your deployments use "infrastructure-as-code" templates, you have to explicitly create the Azure resource for the plan. The hosting plan resource doesn't change, only the sku information.

In your Azure Resource Manager template (ARM template), include the following values:

The following example describes a sample App Service plan resource definition that you can use with your app deployment. For more information, review the Microsoft.Web/serverfarms template format (ARM template) documentation.

{
   "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')]"
      }
   }
}

Azure Arc-enabled Logic Apps automatically manages the scaling for your logic apps based on the number of jobs in the backend storage queue. However, you can change the default scaling behavior.

In a logic app, the workflow definition specifies the sequence of actions to run. Whenever a workflow run is triggered, the Azure Logic Apps runtime creates a job for each action type in the workflow definition. The runtime then organizes these jobs into a job sequencer. This sequencer orchestrates running the jobs for the workflow definition, but the underlying Azure Logic Apps job orchestration engine runs each job.

For stateful workflows, the job orchestration engine uses storage queue messages to schedule jobs in the job sequencers. Behind the scenes, job dispatchers (or dispatcher worker instances) monitor these job queues. The orchestration engine uses a default minimum and maximum number of worker instances to monitor the job queues. For stateless workflows, the orchestration engine completely keeps action states in memory.

To change the default scaling behavior, you specify different minimum and maximum numbers of worker instances that monitor the job queues.

On your Azure Arc-enabled Kubernetes cluster, your previously created App Service bundle extension must have the keda.enabled property set to true. For more information, review the top-level prerequisites.

In Azure Arc-enabled Logic Apps, the length of the job queue triggers a scale event and sets a threshold for how often scaling happens for your logic app. You can change the queue length, which has the default value set to 20 jobs. To scale less often, increase the queue length. To scale more often, decrease the queue length. This process might require some trial and error.

To change the queue length, in your logic app project's root-level host.json file, set the Runtime.ScaleMonitor.KEDA.TargetQueueLength property, for example:

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

On an existing logic app resource, you can change the maximum number of worker instances, which has the default value set to 2. This value controls the upper limit on how many worker instances can monitor the job queues.

To change this maximum, use the Azure CLI (logic app create only) and Azure portal.

To create a new logic app, run the command, az logicapp create, with the following parameters:

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]

To configure your maximum instance count, use the --settings parameter:

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

In your single-tenant based logic app settings, add or edit the K8SE_APP_MAX_INSTANCE_COUNT setting value by following these steps:

1. In the Azure portal, find and open your single-tenant based logic app.

2. On the logic app menu, under Settings, select Configuration.

3. In the Configuration pane, under Application settings, either add a new application setting or edit the existing value, if already added.

   1. Select New application setting, and add the K8SE_APP_MAX_INSTANCE_COUNT setting with the maximum value you want.

   2. Edit the existing value for the K8SE_APP_MAX_INSTANCE_COUNT setting.

4. When you finish, save your changes.

On an existing logic app resource, you can change the minimum number of worker instances, which has the default value set to 1. This value controls the lower limit on how many worker instances can monitor the job queues. For high availability or performance, increase this value.

To change this minimum, use the Azure CLI or the Azure portal.

For an existing logic app resource, run the command, az logicapp scale, with the following parameters:

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

To create a new logic app, run the command, az logicapp create, with the following parameters:

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]

In your single-tenant based logic app settings, change the Scale out property value by following these steps:

1. In the Azure portal, find and open your single-tenant based logic app.

2. On the logic app menu, under Settings, select Scale out.

3. On the Scale out pane, drag the minimum instances slider to the value that you want.

4. When you finish, save your changes.

To get more information about your deployed logic apps, try the following options:

To access your app settings, run the command, az logicapp config appsettings, with the following parameters:

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

To configure an app setting, run the command, az logicapp config appsettings set, with the following parameters. Make sure to use the --settings parameter with your setting's name and value.

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

To delete an app setting, run the command, az logicapp config appsettings delete, with the following parameters. Make sure to use the --setting-names parameter with the name of the setting you want to delete.

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

To view your app information and properties, run the command, az logicapp show, with the following parameters:

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

To view the activity for a workflow in your logic app, follow these steps:

1. In the Azure portal, find and open your deployed logic app.

2. On the logic app menu, select Workflows, and then select your workflow.

3. On the workflow menu, select Monitor.

To get logged data about your logic app, enable Application Insights on your logic app if not already enabled.

• About Azure Arc-enabled Logic Apps