Introduction
Employers value engineers who can release changes safely, without putting every user at risk.
The scenario: At Fabrikam Inc., the container app is deployed and the pipeline works. Now the team wants to ship a new version without sending all traffic to it at once. They need a v2 revision that receives 25 percent of requests while the existing version keeps the other 75 percent, with clear labels so each version can be tested directly.
In this final Part 5, I switch the container app to multiple revision mode, create the v2 revision, label the revisions "current" and "updated", and split traffic 75/25. I then verify the setup on the Revisions and replicas page.
Note: Here, I left the current version as Label-1, I didn't rename it.
The following Azure resources must be available in your Resource group named RG1:
- A Container registry instance that contains one image.
- A Virtual network with subnets.
- A Service Bus Namespace
- A Managed Identity
- A Private endpoint
- A Container App
- A Container Apps Environment
You've been asked to configure traffic splitting for your Container Apps to meet the following requirements:
- You need to create a new revision of the container app that uses a suffix of v2.
- You must ensure that 25 percent of requests to your app are directed to the v2 revision.
- You must label the revisions "current" and "updated" and ensure that requests to the "updated" revision are directed to the v2 revision.
You complete the following tasks during this exercise:
1.Set revision management to multiple.
2.Create a new revision with a v2 suffix.
3.Configure labels on the revisions.
4.Configure a traffic percentage on the revisions.
5.Verify the configuration.
Note: I used port 4050 in place of 5000 because my port 5000 was occupied.
Set revision management to multiple
1.In the Azure portal, open your container app resource.
2.On the left side menu, under Application, select Revisions and replicas.
3.At the top of the Revisions and replicas page, select Deployment mode.
4.To switch from single to multi-revision mode, select Apply.
5.On the Ingress page, specify the following information:
Ingress traffic: select Accepting traffic from anywhere.
Ingress type: select HTTP.
Client certificate mode: ensure that Ignore is selected.
Transport: ensure that Auto is selected.
Insecure connections: ensure that Allowed is NOT checked.
Target port: enter 5000
IP Security Restrictions Mode: ensure that Allow all traffic is selected.
6.At the bottom of the Ingress page, select Save, and then wait for the update to complete.
The Deployment Mode will be set to Multiple after the update.
7.On the left-side menu, under Revisions, select Revisions and replicas.
Select create new revision
Configure a traffic percentage and labels on the revisions
1.Ensure that you have the Revisions and replicas page open.
2.For the v2 revision, under Traffic, enter 25 as the percentage.
3.For the other revision, under Traffic, enter 75 as the percentage.
6.For the v2 revision, under Label, enter updated
7.For the other revision, enter current or leave as-is.
8.At the top of the page, select Save.
Check your work
1.Ensure that you have your Container App open in the Azure portal.
2.On the left-side menu, under Application, select Revisions and replicas.
3.Verify that your revisions are configured as follows:
Summary
Cloud and DevOps practitioner who completed a five-part, hands-on series on deploying containerized applications with Azure Container Apps.
Part 5 covers safe release management with revisions and traffic splitting:
Switched the container app from single to multiple revision mode
Created a new v2 revision of the container app
Configured HTTP ingress, accepting traffic from anywhere on target port 5000
Labeled the revisions "current" and "updated", with "updated" mapped to v2
Split traffic 75% to the existing revision and 25% to v2, and verified the configuration on the Revisions and replicas page
Skills practiced:
Azure Container Apps, revision management, traffic splitting, ingress configuration, progressive delivery
Across the full series: Azure resource setup, Azure Container Registry security with managed identity and private endpoints, container app deployment with Service Bus connectivity and HTTP autoscaling, CI/CD with Azure Pipelines and a self-hosted agent, and revision-based releases.
Top comments (2)
This completes my five-part series on Azure Container Apps. Over the series I set up the Azure foundation, secured Azure Container Registry with a managed identity and a private endpoint, deployed the app with Service Bus connectivity and HTTP autoscaling, automated deployments with Azure Pipelines, and finished with revision-based traffic splitting. Thank you to everyone who followed along. I'm always open to feedback and to connecting with other cloud and DevOps professionals.
In this part I split traffic 75/25 between the current revision and a new v2(updated) revision, with labels so each can be tested directly. This pattern limits the impact of a bad release. For teams already using Azure Container Apps, how do you decide when to move from a partial split to full traffic: a fixed time window, error-rate thresholds, or manual approval? I'd value your perspective.