Insight

Run a Logic App in a container

This article serves as a proof of concept to test the Logic App (Standard) “run anywhere” Microsoft statement.
Here we describe the necessary steps to make a Logic App (Standard) run in a containerized way, avoiding extra costs of having the App service running even when the workflow is not being called. By the end of this article, you will be able to also containerize your workflows, not only run and test them locally but also publish them to the cloud and see them running on Microsoft serverless container services (Azure Container Instances and/or Azure Container Apps).

Pre-Requisites

Tools required to download and install locally (dev)

Project

Local Run and Testing

  1. Start a Stateful logic app (standard) project with VS Code.
  2. Build a logic app flow in VS Code:
    1. Designer is available for ease of development. The designer might still contain some bugs, so never discard the code view.
    2. Try to use Build-in Connectors as much as possible (good practice) and because Managed Identity still does not work with apps running on containers.
    3. Create workflows with single-tenant Azure Logic Apps (Standard) in Visual Studio Code – Azure Logic Apps | Microsoft Learn
    4. For this example, I’m using a Logic App Flow that uses a Service Bus Trigger but also uses other connections, namely, to Blob Storage and Azure SQL Server:
  1. Save your project and convert it to a NuGet project (.NET)
    1. Right-Click on any of the empty space of the project files and select “Convert to NuGet-based Logic App project“.
    2. This will generate .NET specific files and libraries and will also add a .csproj file to your project.

(This is a IRREVERSIBLE change, so use it carefully if you really want to convert your project.)

  1. Next, we will add a “Dockerfile” to the project, this file contains instructions to build your container image.
    1. Example for this project:
  1. Some notes on the above “Dockerfile“:
    • Filename must be exactly as spelled above, building the image will throw and error if it is not.
    • Base of the image using Node.js
    • Update environment variable “AzureWebJobsStorage” with storage account connection string.
    • For every different connector used in your application that needs a connection string, these have to be added as an ENV variables (i.e. service bus, blob storage & SQL server).
    • ENV variables cannot have spaces on their values or connection strings, these can be escaped by encapsulating the value between double quotes (“).
    • WEBSITE_SITE_NAME is the name by which entries are created in Storage Account by the Logic App while caching its state.
    • If we want to run based on .NET functions runtime, use “FROM mcr.microsoft.com/azure-functions/dotnet:3.4.2“.
  1. At this stage we are ready to start building and testing our project; we will start by building and publishing our .NET project.
    1. Open your Terminal in Visual Studio Code and type these 2 commands (one at a time):
  1. Once the last step is finished, we will (on the same terminal) create our container image with the following command: ”docker build -tag <containerName> <pathToStoreContainer>“
  1. With this you can run your container containing your built image, just typing this command in your terminal window.
  1. If everything is gone as planned your app is now running locally and waiting for something to trigger the workflow, in this case a message on a topic of the service bus.
  1. You can also navigate to: http://localhost:8080 and check that your app is healthy and running:
  1. As a side note, the created image and running container can be checked also in the Docker Desktop application.
  1. Once the workflow is triggered you can see all steps running in the terminal log.

Cloud Run and Testing

After you have your project finished and tested locally you can now deploy it to the cloud services:

(Docker Desktop should be running for all these steps)

  1. First, we need to create an Azure Container Registry in order to deploy our locally created docker image. This registry will serve has an application image repository.
    1. Quickstart – Create registry in portal – Azure Container Registry | Microsoft Learn
  1. Back on our VS Code project Terminal we need to login into our Azure environment (if you are not logged in), and login to our recently created Azure Container registry.
  1. Also in the VS code terminal, we are going to update the name of our container image to match the Azure container registry just created:
  1. We will now deploy our local image to Azure Container registry, push it to the cloud with this command in the terminal:
  1. After the push you can delete it locally if you wish with this terminal command (don’t worry, won’t remove from the registry, just locally)
  1. Another curiosity, if the image is deleted locally and we try to run it locally, docker first checks if the image is present locally, if not, he gets it from the registry online.
  1. If another colleague developer wants to work locally with an image he can also do so by pulling it from the docker server or from azure container services.

Azure Container Instances (OLD)

  • Better for 1 or multiple containers that do not need too much communication between each other.
    • Applications that are just a single container, Azure Container Instances is a great fit.
  • This is great for running certain processes that are not a web application or background worker.
  • Not scalable to 0 instances, so a cost is always associated, always running.
  1. Create an Azure Container Instance on azure portal based on your container registry image previously deployed.
  1. Once it is deployed, you Logic app should up and running:
  1. You can now Test it and check the logs of your Logic App run within the container Log:

Azure Container Apps (NEW)

  • Underneath is Kubernetes, we can call it a “Kubernetes to Go”.
  • Use it when you do not need all that Kubernetes has to offer and all the maintenance attached with it.
  • When we need to have multiple containers communicating within an environment (frontend/backend/database) this is the better solution.
  • Great with CI/CD integration, direct connection to GitHub.
  • Less Maintenance and higher scalability since it uses Kubernetes event-driven auto scale (rules to be set).

Limitations

  • Managed identities is currently not yet supported to connect to other resources (databases, queues, …)
  • Linux Based images only.
  • (Specific for Logic app or function) Logs needs to be built in the app, currently there is no REST api to retrieve the logs or a way to see the logic app run.
  1. Enabling Admin user and password in the container registry; this will allow the container app to be created using an image that is stored on the registry:
  1. Create an Azure Container app using the previously pushed image.
    1. Quickstart: Deploy an existing container image in the Azure portal | Microsoft Learn
  1. Test your application running in the cloud, do what needs to be done to trigger it 🙂 – ENJOY!
    1. Logs can be checked to see if your application is running as it should
    2. Write and view application logs in Azure Container Apps | Microsoft Learn

Interesting/Referenced articles

– By Tiago Costa

Other .insights

.insight

Azure APIM Synthetic GraphQL formats dates

Read more
.insight

Claim-check pattern with APIM, Service Bus, Storage account and Logic apps

Read more
.insight

Azure API Management  – stv1 platform retirement

Read more