Skip to content

Latest commit

 

History

History
183 lines (135 loc) · 5.43 KB

solution3.md

File metadata and controls

183 lines (135 loc) · 5.43 KB
Raw

Challenge 3: Solution

Solution steps

We will perform a controlled rollout of the new version and split the incoming network traffic so that only 20% of requests will be sent to the new version of the application.

We'll deploy the first version of the application to Azure and invoke some APIs to test the application. We will then use Log Analytics to validate that traffic split is working.

Add traffic split to the HTTP API app by changing existing Bicep template

To implement the traffic split, in v3_template.bicep add the traffic section on your httpapi app and save the file.

  ingress: {
        external: true
        targetPort: 80
        traffic: [
          {
            revisionName: 'httpapi--${ContainerApps_HttpApi_CurrentRevisionName}'
            weight: 80
          }
          {
            latestRevision: true
            weight: 20
          }
        ]
      }

Effectively, we're asking for 80% of traffic to be sent to the current version (revision) of the application and 20% to be sent to the new version that's about to be deployed.

Deploy updated Bicep template

Once again, let's repeat the deployment command from earlier, now using version 2 of the HTTP API application and with traffic splitting configured

Bash 
# Deploy Bicep template.
az deployment group create \
  -g $resourceGroup \
  --template-file v3_template.bicep \
  --parameters @v3_parametersbicep.json \
  --parameters \
    ContainerApps_Environment_Name=$containerAppEnv \
    LogAnalytics_Workspace_Name=$logAnalytics \
    AppInsights_Name=$appInsights \
    Location=$location
PowerShell 
New-AzResourceGroupDeployment -ResourceGroupName $resourceGroup -Name 'v3_deployment' -TemplateFile .\v3_template.bicep -TemplateParameterFile .\v3_parametersbicep.json -Location $location -ContainerApps_Environment_Name $containerAppEnv -LogAnalytics_Workspace_Name $logAnalytics -AppInsights_Name $appInsights

Add orders via HTTP API

With the third iteration of our applications deployed, let's try and send another order.

Bash 
curl -X POST $dataURL?message=item3

And let's check the Store application again to see if the messages have been received

curl $storeURL | jq

[
   {
    "id": "b222d3fd-9776-4631-9f1d-5038055e1541",
    "message": "fa7c4a50-a711-48d5-8d7c-b9a9e9b9056e"
  },
  {
    "id": "807fd951-7213-4fd7-8a6f-df3a8e064ed9",
    "message": "f5a52f7a-67db-4ada-bdab-baa8189af700 -- item3"
  },
]
PowerShell 
Invoke-RestMethod  "$($dataURL)?message=item3" -Method Post

And let's check the Store application again to see if the messages have been received

Invoke-RestMethod $storeUrl
id                                   message
--                                   -------
a62d0fa5-26dd-449a-8c16-2e897c6ac4c1 9b4d6594-0c06-476f-81dd-1c9a7120d60b
a2be1546-7290-49df-9f1b-9dd567b7ce3b f5a52f7a-67db-4ada-bdab-baa8189af700--item3

Note

The traffic split is 80/20 (80% old api, 20 % new api), so you might need to send a few messages before it hits our new revision of httpapi and appends the provided string to the message.

That's looking better. We can still see the original message, but we can also now see our "item3" message with the date and time appended to it.

We configured traffic splitting, so let's see that in action. First we will need to send multiple messages to the application. We can use the load testing tool hey to do that.

Bash 
hey -m POST -n 25 -c 1 $dataURL?message=hello

# Verify orders in StoreApp
curl $storeURL | jq
PowerShell 
hey -m POST -n 25 -c 1 "$($dataURL)?message=hello"

# Verify orders in StoreApp
Invoke-RestMethod $storeURL

Verify that traffic is distributed between Container App revisions

Let's check the application logs for the Queue Reader application

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

Looking through those logs, you should see a mix of messages, with some containing "hello" and others still containing a GUID. It won't be exact, but roughly one out of every five messages should contain "hello".

So, is our app ready for primetime now? Let's change things so that the new app is now receiving all of the traffic, plus we'll also setup some scaling rules. This will allow the container apps to scale up when things are busy, and scale to zero when things are quiet.

That will be done as part of Challenge 4

The challenges