Leveraging Azure Container Apps Labels for Environment-based Routing and Feature Testing

Introduction

In modern cloud applications, managing different environments (such as development, staging, and production) is crucial for ensuring smooth deployment and testing workflows.

Azure Container Apps offers a powerful feature through labels and traffic splitting that can help developers easily manage multiple versions of an app, route traffic based on different environments, and enable controlled feature testing without disrupting live users.

In this blog, we'll walk through a practical scenario where we deploy an experimental feature in a staging revision, test it with internal developers, and then switch the feature to production once it’s validated. We'll use Azure Container Apps labels and traffic splitting to achieve this seamless deployment process.

Note: labels is a feature that can be leveraged with multi-revision mode.

Overview

• Staging Revision: We will deploy the experimental feature in the staging revision and set the FEATURE_FLAG=true. This will allow internal developers to test the feature, while external traffic will still be routed to the production revision.
• Production Revision: The production revision will have the feature disabled FEATURE_FLAG=false to ensure stability for users. Initially, 100% of the traffic will be routed to the production revision.
• Testing Phase: During testing, internal users or developers will access the staging revision using a label based URL based on the label staging, while external users will access the main app URL and land on the production revision.
• Switching to Production: After testing is completed, the staging and production revisions will be swapped using the revision labels and traffic split feature so that the feature goes live in production without any downtime.

Step-by-Step guide to set up Label-based Routing and Feature-Testing:

1. Create the Application Code:

Create a Node.js application that includes a feature (FEATURE_FLAG) that we want to test in the staging environment. The feature will be controlled  through code, the value of FEATURE_FLAG will be configured as true in staging and false in production. Refer to the snippet below:

//add this to your app.js

const featureFlag = process.env.FEATURE_FLAG || 'true';

app.get('/', (req, res) => {
  if (featureFlag === 'true') {
    res.send('Feature is enabled!');
  } else {
    res.send('Feature is disabled.');
  }
});

Create a Dockerfile to Containerize the Application and push the images to ACR with v1 and v2 tags for production and staging respectively. For sample code please refer to ashh0710/Node-feature_flag

2. Deploy the Application to Azure Container Apps:

Now, let’s deploy the app to Azure Container Apps, first creating the staging environment, followed by production.

Deploy Production Revision

We deploy the production revision with the feature disabled (FEATURE_FLAG=false), ensuring that the app in production remains stable:

az containerapp create \
  --name my-container-app-prod \
  --resource-group <your-resource-group> \
  --image <your-acr-name>.azurecr.io/my-container-app:v1 \
  --cpu 0.5 --memory 1Gi \
  --target-port 8080 \
  --ingress 'external' \
  --revision-suffix version1

Deploy Staging Revision

We deploy the staging revision with the experimental feature enabled (FEATURE_FLAG=true):

az containerapp create \
  --name my-container-app-staging \
  --resource-group <your-resource-group> \
  --image <your-acr-name>.azurecr.io/my-container-app:v2 \
  --cpu 0.5 --memory 1Gi \
  --target-port 8080 \
  --ingress 'external' \
  --revision-suffix version2

 

3. Apply Labels to Distinguish Between Revisions

Labels are used to mark the different environments (staging and production) for easy identification and routing.

Revision details for production:

Revision details for staging:

Apply Label for Production:

az containerapp revision label \
  --name my-container-app-prod \
  --resource-group <your-resource-group> \
  --revision prod \
  --label environment=production

Apply Label for Staging:

az containerapp revision label \
  --name my-container-app-staging \
  --resource-group <your-resource-group> \
  --revision staging \
  --label environment=staging

4. Traffic Routing to Production and Testing in Staging:

At this point, 100% of the traffic is routed to the production revision while staging remains used for internal testing. When users visit the main app URL (my-container-app-prod.azurecontainerapps.io), they see the stable production version with FEATURE_FLAG=false.

az containerapp ingress traffic set \
--name my-container-app-prod  \
--resource-group<your-resource-group> \
--label-weight production=100 staging=0

Now, users accessing the main app URL will land on the production label revision with 100% traffic weight by default (my-container-app-prod.azurecontainerapps.io). Meanwhile, internal developers or testers can access the staging revision using the label based staging URL (my-container-app-staging.azurecontainerapps.io),where the feature is enabled (FEATURE_FLAG=true).

 

Browsing the main app url:

Browsing the production label url:

Browsing the staging label url:

 

5. Switch Traffic between staging and production after testing

Once the experimental feature is fully tested in staging, and you're ready to move it to production, you can easily switch the traffic and labels.

Swap Labels Between Staging and Production

Finally, swap the labels between the staging and production revisions so that staging becomes production:

az containerapp revision label swap \
--name my-containerapp \
--resource-group MyResourceGroup \
--source production \
--target staging

 

Revision details for production after swapping:

 

Revision details for staging after swapping:

This will effectively swap the staging and production environments.

6. Final Traffic Routing to Production

Once the revisions have been swapped, you can set the traffic to 100% production again, ensuring that all users are now accessing the updated production version of the app with the experimental feature enabled.

 

az containerapp ingress traffic set \
--name my-container-app-prod  \
--resource-group<your-resource-group> \
--label-weight production=100 staging=0

Browsing the main app url:

Browsing the production label url:

 

Browsing the staging label url:

Why Label-Based URLs Are Preferred Over Revision URLs

• Label-based URLs in Azure Container Apps simplify traffic routing by using meaningful labels like production or staging, making it easier to manage different environments. Unlike revision URLs, which require manual management of unique URLs for each revision, label-based routing offers better scalability and flexibility, especially for feature testing and controlled rollouts.
• By leveraging Azure Container Apps labels and traffic splitting, you can efficiently manage and route traffic between staging and production environments without disrupting live users, isolated testing, and smooth transitions of tested features to production. The use of label-based URLs ensures clear separation between internal testing and external user access, making it easier to validate changes and safely roll them out.
• In CI/CD workflows, label-based URLs streamline automation by dynamically routing traffic based on environment labels. This reduces the need for manual URL updates, making deployments smoother and less error-prone.

In summary, label-based URLs are easier to manage, and ideal for CI/CD pipelines, offering better control over traffic, feature testing, and production deployments.