Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – Part 10

This is the tenth part of Building Microservice Applications with Azure Container Apps and Dapr. The topics we’ll cover are:

• Tutorial for building Microservice Applications with Azure Container Apps and Dapr – Part 1
• Deploy backend API Microservice to Azure Container Apps – Part 2
• Communication between Microservices in Azure Container Apps – Part 3
• Dapr Integration with Azure Container Apps – Part 4
• Azure Container Apps State Store With Dapr State Management API – Part 5
• Azure Container Apps Async Communication with Dapr Pub/Sub API – Part 6
• Azure Container Apps with Dapr Bindings Building Block – Part 7
• Azure Container Apps Monitoring and Observability with Application Insights – Part 8
• Continuous Deployment for Azure Container Apps using GitHub Actions – Part 9
• Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – (This Post)
• Azure Container Apps Auto Scaling with KEDA – Part 11
• Azure Container Apps Volume Mounts using Azure Files – Part 12
• Integrate Health probes in Azure Container Apps – Part 13

Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps

In the previous post we’ve used GitHub Actions to continuously build and deploy the 3 Azure Container Apps after any code commits to a specific branch, on this post we will be working on defining the proper process to automate the infrastructure provisioning by creating the scripts/templates to provision the resources, this process is known as IaC (Infrastructure as Code).

Once we have this in place, IaC deployments will benefit us in key ways such as:

1. Increase confidence in the deployments, ensure consistency, reduce human error in resource provisioning, and ensure consistent deployments.
2. Avoid configuration drifts, IaC is an idempotent operation, which means it provides the same result each time it’s run.
3. Provision of new environments, during the lifecycle of the application you might need to run penetration testing or load testing for a short period of time in a totally isolated environment, with IaC in place it will be a matter of executing the scripts to recreate an identical environment to the production one.
4. When you provision resources from the Azure Portal many processes are abstracted, in our case think of when creating an Azure Container Apps Environment from the portal, behind the sense it will create a log analytics workspace and associate with the environment. With IaC it can help provide a better understanding of how Azure works and how to troubleshoot issues that might arise.

ARM Templates in Azure

ARM templates are files that define the infrastructure and configuration for your deployment, the template uses declarative syntax, which lets you state what you intend to deploy without having to write the sequence of programming commands to create it.

Within Azure there are 2 ways to create IaC, we can use the JSON ARM templates or Bicep (domain-specific language). From my personal experience, I’ve used JSON ARM templates in real-world scenarios which tend to be complex to manage and maintain especially when the project grows and the number of components and dependencies increases.

For Bicep, this is my first time to use it, so far I found it easier to work with and you can be more productive compared to ARM templates, it is worth mentioning that Bicep code will be compiled into ARM templates eventually, this process called “Transpilation”.

If you want to learn more about Bicep, I highly recommend checking Microsft learn website Fundamentals of Bicep and the post Getting started with Azure Bicep by Tobias Zimmergren

The source code for this tutorial is available on GitHub. You can check the demo application too.

Creating the Infrastructure as Code using Bicep

Lets’ get started by defining the Bicep modules needed to create the Infstatrcure code, what we want to achieve by the end of this post is to have a new resource group containing all the resources and configuration (connection strings, secrets, env variables, dapr components, etc..) we used to build our solution, we should have a new resource group which contains the below resources.

Step 1: Add the needed extension to VS Code Or Visual Studio

If you are using VS Code, you need to install an extension named “Bicep“, and if you are using Visual Studio, PG team announced the release of Bicep extension for Visual Studio version 17.3 and higher, you can get it from here. Both extensions will simplify building Bicep files as they will offer IntelliSense, Validation, listing all available resource types, etc..

Step 2: Define an Azure Log Analytics Workspace

Add a new folder named “deploy” on the root project directory then add a new file named “logAnalyticsWorkspace.bicep”, use the content below:

This module takes 2 input parameters “logAnalyticsWorkspaceName” and “location”, the location defaults to the container resource group location. Bicep has a function named resourceGroup() which you can get the location from, yet you can override this default value if you provided the location when calling this module.

The output of this module is 2 parameters, first one is “workspaceResourceId” and the second one is “logAnalyticsWorkspaceCustomerId” both outputs are needed as input for the Azure Container Apps Environment and Application Insights resource which we will provision next.

Important note: You can see that I left a commented code on how to return the secret/shared key using outputs, this was the initial way I followed but it turned out it is not secure as those outputs will be available on the deployment level (when viewing the Resource Group Deployment section) in Azure Portal in plain text, so anyone has access to the resource group will see those keys and secrets.
I will be using a different approach to return the secrets from modules. Keep reading to see how. You can read more about the 2 possible approaches on the official documentation.
In my personal opinion, I wished there is a “@Secure” param we can put on the output parameters to keep things modular. There is a GitHub issue opened and hopefully, PG will add it.

Step 3: Define an Azure Application Insights resource

Add a new file named “appInsights.bicep” under the folder “deploy” and use the content below:

This module accepts 3 parameters, the “location”, and “workspaceResourceId “, and “appInsightsName”, we are associating the log analytics workspace with this Application Insights resource by setting the property “WorkspaceResourceId”

Step 4: Define an Azure Container Apps Environment resource

Add a new file named “acaEnvironment.bicep” under the folder “deploy” and use the content below:

This module accepts 5 input parameters, mainly those to associate the log analytics workspace with the Environment and set the Application Insights Key for dapr distributed calls tracing and telemetry. This module outputs the Container App Environment Id as an output parameter which will be used when defining the 3 Azure Container Apps. More about the “@secure” attribute below.

Step 5: Define Azure CosmosDB resources

We will start defining the supporting resources needed for our solution, we will start defining the module needed to provision Azure Cosmos Account, Database, and Container, to do so, add a new file named “cosmosdb.bicep” and use the content below:

On this file, we are creating Azure Cosmos Account, Database, and a Collection, I’m defaulting the names of Database and Collection to use the same names we’ve previously used in the tutorial, but we are going to send a different Cosmos Account. For full details on Cosmos DB Bicep module parameters, you can check it here.

Step 6: Define Azure Service Bus resource

Add a new file named “serviceBus.bicep” under the folder “deploy” and use the content below:

This module will be needed to provision the Azure Service Bus and a Topic named “tasksavedtopic” by default. The connection string of the service bus will be returned in a different way, not like the commented code.

Step 7: Define Azure Storage Account resource

Add a new file named “storageAccount.bicep” under the folder “deploy” and use the content below:

This module will be needed to provision an Azure Storage Account and a queue named “external-tasks-queue”.

Step 8: Define Azure Container Apps module

Now we will create a reusable Bicep module which will be used to define the 3 Azure Container Apps in our solution, so add a new file named “containerApp.bicep” and use the content below:

The Azure Container Apps module is reusable and almost accepts input parameters for all Azure Container Apps properties, we will be using it to provision the 3 container apps. The output parameter of this module is the fully qualified domain name (FQDN) of the container app if the “enableIngress” property is set to true.

Notice how conditional boolean parameters such as “useProbes”, or “enableIngress” control how the template will be provisioned differently based on those values.

The property “envList” is an array that accepts a dictionary of environment variables, we will see how we are sending those values next.

The property “secListObj” is an object with a “@secure” attribute his attribute can be applied on string and object parameters that might contain secret values, when it is used Azure won’t make the parameter values available in the deployment logs nor on the terminal if you are using Azure CLI.

Step 9: Define the Main module for the solution

Lastly, we need to define the Main Bicep module which will link all other modules together, this will be the file that is referenced from AZ CLI command or GitHub action when creating the entire resources, to do so add a new file named “main.bicep”, I will not list the file content here as it is more than 500 lines but I will go over it step by step, you can always get the file from GitHub repo. The file “main.bicep” can be accessed from the previous link.

What we have added to the file is the following:

• We have defined many parameters to make the deployment flexible, yet we default most of them, this means that there is no need to provide values for the defaulted ones. The only mandatory parameters are “containerRegistryPassword ” and “sendGridApiKey“.
• We used the attribute “@secure” on the properties “containerRegistryPassword” and “sendGridApiKey” as those are secrets and should not be logged or visible when typing them in Azure CLI.
• We are calling the modules defined earlier “cosmosdb.bicep”, “serviceBus.bicep”, “storageAccount.bicep”, “logAnalyticsWorkspace.bicep”, and then “appInsights.bicep” by bundling them in 1 single module named “primaryResources.bicep”.
• We want to get the secrets, keys, and connection strings from the resources without using the output parameter, so we are going to use the existing keyword to obtain a strongly typed reference to the pre-created resource. Then use the listKeys() function to obtain the key or connection string.
  For example, let’s take a look at how we are getting a reference for the Application Insights Resource by providing its name as an input, then using the resource named “appInsightsResource” to get the InstrumentationKey by calling “appInsightsResource.properties.InstrumentationKey“.
• Looking at how we are creating the Azure Container App “Backend API App” using the module “containerApp.bicep” we notice the following:
  • We are setting the array “dependsOn” to help the Bicep interpreter to understand the dependencies between components, this is not needed if we are not using the “existing” keyword.
  • We are passing various mandatory parameters for Azure Container Apps, we are getting the value of “environmentId” from the output parameter defined in ACA Environment.
  • We are passing the needed information to access the ACR to pull the right image for each ACA. We will pass the registry password from Azure CLI.
  • We are passing the property “secListObj” by adding secrets to a dictionary named “secArray”, we did this because @secure attribute is only applicable on strings and objects, so this is a workaround to do this by creating an object which wraps an array. Thanks Alex for the hint.
• Looking at one of the Dapr components, for example, “stateStoreDaprComponent” you will notice the following:
  • Setting the component name while prefixing it with ACA environment name “${environmentName}/statestore” (Parent/Child) relation in Bicep.
  • Setting “secrets”, “metadata” and “scopes” dictionaries of this component in a consistent way among all other Dapr components.

Step 10: Calling the main.bicep file from Azure CLI and deploy the Infrastructure

Now we are ready to start the actual deployment by calling az deployment group create to do so, open the PowerShell console and use the content below, don’t forget to replace the “containerRegistryPassword” and SendGrid API key with your values. You need to create an empty resource group before. I’m using a resource group named “tasks-bicep-rg”:

Azure CLI will take the Bicep module, and start creating the deployment in the resource group “tasks-bicep-rg”

Step 11: Verify the final results

If the deployment succeeded; you should see all the resources created under the resource group, as well you can navigate to the “Deployments” tab to verify the ARM templates deployed, it should look like the below image:

That’s it for now, Bicep is a quite powerful DSL language to manage your Infrastructure, I highly recommend checking the reference below to get more familiar with Bicep and IaC.

References:

• Fundamentals of Bicep
• How to deploy Azure Container Apps with Bicep by Thorsten Hans

The source code for this tutorial is available on GitHub. You can check the demo application too.

Follow me on Twitter @tjoudeh