Our application is now verified using blue-green deployment as part of challenge 3. We are now ready for production and will only have the latest revision of our application deployed. In addition we will deploy new configuration with scaling configured. We will also add a simple dashboard for monitoring the messages flow.
Review scaling rules added to HTTP API (httpapi) and Queue Reader (queuereader) Container Apps by examining existing Bicep template v4
]
scale: {
minReplicas: 0
maxReplicas: 5
rules: [
{
name: 'myqueuerule'
...
scale: {
minReplicas: 1
maxReplicas: 10
rules: [
{
name: 'httpscalingrule'
We are configuring the Queue Reader app to scale from 0 to 5 replicas and HTTP API to scale from 1 to 10 replicas. Also note the additional Container Apps dashboardapp and dashboardapi that are part of this template. They are used for observability and will visualize current order count in the queue and number of orders in our store.
One additional time, we'll now deploy the new configuration with scaling configured. We will also add a simple dashboard for monitoring the messages flow.
Bash
# Deploy Bicep template.
az deployment group create \
-g $resourceGroup \
--template-file v4_template.bicep \
--parameters @v4_parametersbicep.json \
--parameters \
ContainerApps_Environment_Name=$containerAppEnv \
LogAnalytics_Workspace_Name=$logAnalytics \
AppInsights_Name=$appInsights \
Location=$location
PowerShell
New-AzResourceGroupDeployment -ResourceGroupName $resourceGroup -Name 'v4_deployment' -TemplateFile .\v4_template.bicep -TemplateParameterFile .\v4_parametersbicep.json -Location $location -ContainerApps_Environment_Name $containerAppEnv -LogAnalytics_Workspace_Name $logAnalytics -AppInsights_Name $appInsights
Let's check the number of orders in the queue
Bash
curl $dataURL
PowerShell
Invoke-RestMethod $dataUrl
As before, we can check the application log files in Log Analytics to see what messages are being received
ContainerAppConsoleLogs_CL
| where ContainerAppName_s has "queuereader" and ContainerName_s has "queuereader"
| where Log_s has "Message"
| project TimeGenerated, Log_s
| order by TimeGenerated desc
Now let's see scaling in action. To do this, we will generate a large amount of messages which should cause the applications to scale up to cope with the demand.
While the scaling script is running, you can also have this operations dashboard open to visually see the messages flowing through queue into the store. Get the dashboard URL and open in a browser.
Bash
dashboardURL=https://dashboardapp.$(az containerapp env show -g $resourceGroup -n $containerAppEnv --query 'properties.defaultDomain' -o tsv)
PowerShell
$dashboardURL="https://dashboardapp.$((Get-AzContainerAppManagedEnv -ResourceGroupName $resourceGroup -EnvName $containerAppEnv).DefaultDomain)/"
To demonstrate this, a script that uses the tmux
command is provided in the scripts folder of this repository. Run the following commands:
cd scripts
./appwatch.sh $resourceGroup $dataURL
Note
When running the dev container locally it is a risk that the appwatch script has wrong line-endings. Run the following command to fix the issue.
sed -i -e 's/\r$//' appwatch.sh
This will split your terminal into four separate views.
- On the left, you will see the output from the hey command. It's going to send 10,000 requests to the application, so there will be a short delay, around 20 to 30 seconds, whilst the requests are sent. Once the hey command finishes, it should report its results.
- On the right at the top, you will see a list of the container app versions (revisions) that we've deployed. One of these will be the latest version that we just deployed. As hey sends more and more messages, you should notice that one of these revisions of the app starts to increase its replica count
- Also on the right, in the middle, you should see the current count of messages in the queue. This will increase to 10,000 and then slowly decrease as the app works it way through the queue.
Once hey has finished generating messages, the number of instances of the HTTP API application should start to scale up and eventually max out at 10 replicas. After the number of messages in the queue reduces to zero, you should see the number of replicas scale down and return to 1.
Note
It might take some time before the replica count decrease is reflected in the console. You can also navigate to the Revisions and replicas blade of the container apps in Azure Portal to review the running status of each replica.
Tip
To exit from tmux when you're finished, type CTRL-b
, then :
and then the command kill-session
That concludes the deployment of the application. In upcoming challenges we will look at improving the DevOps and security capabilities of our solution. Next up is CI/CD deployment as part of Challenge 5
- Challenge 1: Setup the environment
- Challenge 2: Deploy Container Apps Environment and troubleshoot Container Apps
- Challenge 3: Split traffic for controlled rollout
- Challenge 4: Scale Container Apps
- Challenge 5: Configure CI/CD for Container Apps
- Challenge 6: Protect Container App with API Management
- Challenge 7: Enable Container App authentication