Deploy RabbitMQ Producer and Consumer applications to Azure Container Apps

We will perform following steps to deploy the RabbitMQ Producer and Consumer applications to Azure Container Apps:

• Create Azure Container Apps environment
• Create a Dapr Pubsub component for RabbitMQ
• Create TechTalks Producer Azure Container App
• Create TechTalks Consumer Azure Container App

Automate the deployment process using a Powershell script

In order to make things easier, I have created a small powershell script to run all the commands related to setting up of the Azure Container Apps. You can find the script named setup-tech-talks-container-app.ps1 in the powershell directory.

This script takes following parameters:

• subscriptionName: The name of the subscription, defaults to Microsoft Azure Sponsorship
• resourceGroupName : The name of the resource group, defaults to azure-container-app-rg
• resourceGroupLocation : The location of the resource group, defaults to eastus
• environmentName : Name of the environment, default value is aci-dev-env

You can override the default values. We can run the whole script with default parameters by running the following command:

.\setup-tech-talks-container-app.ps1

If you wish to override of the default values, pass the name of the parameter and value as shown below:

.\setup-tech-talks-container-app.ps1 -resourceGroupName "my-resource-group" -resourceGroupLocation "westus"

Here we are overriding the resourceGroupName with the value my-resource-group and resourceGroupLocation with westus parameters.

Below is the description of each of the steps performed by the Powershell script.

---

Create Azure Container Apps environment

First thing we need is to create an environment for the Azure Container Apps. The script run the following command to create an environment:

az containerapp env create `
    --name $environmentName `
    --resource-group $resourceGroupName `
    --location $resourceGroupLocation

This will create an environment for the Azure Container Apps. The environment acts as a namespace for the Azure Container Apps. You can create multiple environments for different environments like dev, test, prod etc. For simplicity we will be using a single environment.

Verify Azure Container Apps environment using CLI

We can verify the environment using the following command:

az containerapp env list --output table

This will list all the environments for the subscription. You should see the environment created in the previous step. We are using the --output table parameter to get the output in a tabular format.

Verify Azure Container Apps environment using Azure Portal

We can verify the environment using the Azure Portal. Navigate to the Resource Group related to the container app in the Azure Portal and you should see the environment created.

---

Create a Dapr component for RabbitMQ

We need to create a Dapr component for RabbitMQ. This component will be used by the microservices to connect to the RabbitMQ cluster. The script runs the following command to create the component with the name rabbitmq-pubsub :

az containerapp env dapr-component set `
    --name $environmentName `
    --resource-group $resourceGroupName `
    --dapr-component-name rabbitmq-pubsub `
    --yaml ../config/Dapr-components/rabbitmq-dapr.yaml

All the metadata related to the RabbitMQ cluster is stored in the rabbitmq-dapr.yaml file. You can find the file here. The file contains the following metadata:

• host: The hostname of the RabbitMQ cluster
• durable: Whether the queue is durable or not
• deleteWhenUnused: Whether the queue should be deleted when not used
• autoAck: Whether the message should be auto acknowledged or not
• prefetchCount: The number of messages to prefetch
• reconnectWait: The time to wait before reconnecting to the RabbitMQ cluster
• concurrencyMode: The concurrency mode for the consumer
• exchangeKind: The kind of the exchange

One important thing to note here is the prefetchCount value. This value is set to 50 which means that the consumer will receive 50 message at a time. This is done to demonstrate the behavior of the Azure Container Apps. If the value is set to 0 or null, the consumer will receive all the messages at once. This is not what we want to demonstrate in this tech talk. You can adjust this value as per your requirement. You can find more information about the RabbitMQ Dapr component RabbitQM PubSub docs

Verify Dapr component using CLI

We can verify the Dapr component using the following command:

az containerapp env dapr-component list `
    --name $environmentName `
    --resource-group $resourceGroupName `
    --output table

This will list all the Dapr components for the environment. You should see the Dapr component created in the previous step. We are using the --output table parameter to get the output in a tabular format.

Verify Dapr component using Azure Portal

We can verify the Dapr component using the Azure Portal. Navigate to the Resource Group related to the container app in the Azure Portal and go to the details of the Azure Container Apps environment. In the left pane we can find the Dapr components under the settings section. You should see the Dapr component created in the previous step.Clicking on the name rabbitmq-pubsub will show the details of the Dapr component which we specified in the metadata using the rabbitmq-dapr.yaml file.

---

Create RabbitMQ Producer Azure Container App

Next we create an Azure Container App for the RabbitMQ Producer. The script runs the following command to create the Azure Container App:

az containerapp create `
    --environment $environmentName `
    --resource-group $resourceGroupName `
    --name techtalks-producer `
    --image ngacrregistry.azurecr.io/techtalksproducer:azurecontainerapp `
    --registry-server ngacrregistry.azurecr.io `
    --target-port 80 `
    --ingress 'external' `
    --enable-dapr `
    --dapr-app-id rabbitmq-producer `
    --dapr-app-port 80 `
    --min-replicas 1 `
    --max-replicas 3

Most of the parameters are self-explanatory. The --enable-dapr parameter enables Dapr for the Azure Container App. The --dapr-app-id parameter is the Dapr application id. The --dapr-app-port parameter is the port on which the Dapr sidecar will listen for requests. The --min-replicas and --max-replicas parameters are used to specify the minimum and maximum number of replicas for the Azure Container App.

We do not expect the RabbitMQ Producer to receive a lot of requests. So we are using a minimum of 1 replica and a maximum of 3 replicas. This will ensure that we have at least 1 replica running at all times and we can scale up to 3 replicas if needed.

Verify RabbitMQ Producer Azure Container App using CLI

We can verify the RabbitMQ Producer Azure Container App has been created successfully using the following command:

az containerapp list -g azure-container-app-rg --output table

Note that at the time of taking the screenshot, both the RabbitMQ Producer and Consumer Azure Container Apps were deployed. The RabbitMQ Producer Azure Container App is the one with the name techtalks-producer.

Verify RabbitMQ Producer Azure Container App using Azure Portal

We can verify the RabbitMQ Producer Azure Container App has been created successfully using the Azure Portal. Navigate to the Resource Group related to the container app in the Azure Portal and you should see the RabbitMQ Producer Azure Container App created. Clicking on the name techtalks-producer will show the details of the Azure Container App.

---

Create RabbitMQ Consumer Azure Container App

Next we create an Azure Container App for the RabbitMQ Consumer. The script runs the following command to create the Azure Container App:

az containerapp create `
    --environment $environmentName `
    --resource-group $resourceGroupName `
    --name techtalks-consumer `
    --image ngacrregistry.azurecr.io/techtalksconsumer:azurecontainerapp `
    --registry-server ngacrregistry.azurecr.io `
    --target-port 80 `
    --ingress 'internal' `
    --enable-dapr `
    --dapr-app-id rabbitmq-consumer `
    --dapr-app-port 80 `
    --min-replicas 1

Here also the parameters are self-explanatory. The only major difference is that we are using internal ingress for the consumer. This means that the consumer will be accessible only from within the cluster. We are also not setting the --max-replicas parameter. This means that the consumer will not scale up.

We do not want the consumer to scale up using the default scaling mechanism used by the Azure Container Apps. We want to demonstrate the behavior of autoscaling using Kubernetes-based Event Driven Autoscaling (KEDA). We will see how to configure KEDA autoscaler in the later section.

Verify RabbitMQ Consumer Azure Container App using CLI

The steps to verify the RabbitMQ Consumer Azure Container App are the same as the RabbitMQ Producer Azure Container App. In fact we can use the same command to verify the RabbitMQ Consumer Azure Container App which we saw in the output of the earlier command when we tried to verify the RabbitMQ Producer Azure Container App.

Verify RabbitMQ Consumer Azure Container App using Azure Portal

The steps to verify the RabbitMQ Consumer Azure Container App are the same as the RabbitMQ Producer Azure Container App. Instead of clicking on the name techtalks-producer, we need to click on the name techtalks-consumer.