Container Apps for microservices in Azure - Step-by-Step Execution

Process Flow - Container Apps for microservices

Create Container App Environment

↓

Deploy Microservice Container 1

→Deploy Microservice Container 2

↓

Configure Ingress & Routing

↓

Scale Microservices Automatically

↓

Monitor & Update Containers

This flow shows creating an environment, deploying multiple microservice containers, setting up routing, scaling automatically, and monitoring.

Execution Sample

Azure

az containerapp env create --name myEnv --resource-group myRG
az containerapp create --name service1 --resource-group myRG --environment myEnv --image myimage1
az containerapp create --name service2 --resource-group myRG --environment myEnv --image myimage2
az containerapp ingress enable --name service1 --resource-group myRG --environment myEnv --target-port 80
az containerapp scale set --name service1 --resource-group myRG --environment myEnv --min-replicas 1 --max-replicas 3

This code creates an environment, deploys two microservices as container apps, enables ingress on one, and sets scaling rules.

Process Table

Step	Action	Resource State	Result
1	Create Container App Environment 'myEnv'	Environment 'myEnv' created	Ready to deploy container apps
2	Deploy Container App 'service1' with image 'myimage1'	service1 deployed in 'myEnv'	Microservice 1 running
3	Deploy Container App 'service2' with image 'myimage2'	service2 deployed in 'myEnv'	Microservice 2 running
4	Enable ingress on 'service1' port 80	Ingress enabled for service1	service1 accessible via HTTP
5	Set scaling for 'service1' min=1 max=3	Scaling rules applied	service1 scales automatically between 1 and 3 replicas
6	Monitor container apps	Metrics collected	Health and performance visible
7	Update container image for 'service2'	service2 updated	New version running without downtime
8	Scale 'service1' replicas based on load	Replicas adjusted	Handles traffic spikes smoothly
9	Delete environment 'myEnv'	All container apps removed	Resources cleaned up

💡 Execution stops after environment deletion and cleanup

Status Tracker

Resource	Initial	After Step 2	After Step 3	After Step 4	After Step 5	After Step 7	Final
Environment 'myEnv'	Not created	Created	Created	Created	Created	Created	Deleted
Container App 'service1'	Not deployed	Deployed	Deployed	Ingress enabled	Scaling set	Scaling set	Deleted
Container App 'service2'	Not deployed	Not deployed	Deployed	Deployed	Deployed	Updated	Deleted
Replicas for 'service1'	0	1 (default)	1	1	1-3 (auto scale)	1-3	0

Key Moments - 3 Insights

Why do we create a Container App Environment before deploying microservices?

The environment acts like a shared space where all container apps run and communicate. Without it, container apps cannot be deployed or managed together, as shown in step 1 of the execution_table.

How does enabling ingress affect a container app?

Enabling ingress opens a network port so the app can receive external traffic. In step 4, ingress is enabled on service1, making it accessible via HTTP.

What happens when scaling rules are set for a container app?

Scaling rules let the app automatically add or remove replicas based on load. Step 5 shows setting min and max replicas, allowing the app to handle traffic changes smoothly.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What change happens to 'service1'?

A Ingress is enabled making it accessible externally

B The container image is updated

C Scaling rules are removed

D The environment is deleted

💡 Hint

Check the 'Action' and 'Result' columns at step 4 in the execution_table

According to variable_tracker, what is the state of 'service2' after step 7?

A Not deployed

B Deployed and updated

C Deleted

D Ingress enabled

💡 Hint

Look at the 'Container App service2' row under 'After Step 7' in variable_tracker

At which step does the environment get deleted?

A Step 5

B Step 7

C Step 9

D Step 3

💡 Hint

Check the last step in the execution_table and variable_tracker for environment state

Concept Snapshot

Container Apps for microservices:
- Create a Container App Environment first
- Deploy each microservice as a container app in the environment
- Enable ingress to allow external access
- Set scaling rules for automatic replica management
- Monitor and update containers without downtime
- Delete environment to clean up all resources

Full Transcript

This visual execution shows how to use Azure Container Apps to run microservices. First, you create a Container App Environment, which is a shared space for your apps. Then you deploy each microservice as a container app inside this environment. You enable ingress on apps to allow external traffic. Scaling rules help apps adjust replicas automatically based on load. You can monitor app health and update container images without downtime. Finally, deleting the environment removes all container apps and cleans up resources.

Practice

1. What is the main benefit of using Azure Container Apps for microservices?

easy

A. They let you run small parts of an app separately and scale them easily.

B. They require you to manage all the servers manually.

C. They combine all app parts into one big container.

D. They only work for apps without any updates.

Solution

1. Step 1: Understand microservices in Azure Container Apps

   Azure Container Apps allow running small, separate parts of an app independently.

2. Step 2: Identify the benefit of scaling and updating

   This setup lets you scale and update parts without affecting the whole app, and Azure manages the servers.

3. Final Answer:

   They let you run small parts of an app separately and scale them easily. -> Option A

4. Quick Check:

   Microservices = separate, scalable parts [OK]

Hint: Microservices run small parts separately for easy scaling [OK]

Common Mistakes:

• Thinking you must manage servers yourself
• Believing all parts run in one container
• Assuming no updates are possible

2. Which of the following is the correct way to define a container app in Azure CLI?

easy

A. az container create --name myapp --resource-group mygroup --image myimage:latest

B. az containerapp deploy --name myapp --resource-group mygroup --image myimage:latest

C. az appcontainer create --name myapp --resource-group mygroup --image myimage:latest

D. az containerapp create --name myapp --resource-group mygroup --image myimage:latest

Solution

1. Step 1: Identify the correct Azure CLI command for Container Apps

   The correct command to create a container app is az containerapp create.

2. Step 2: Check the command syntax

   The command includes the app name, resource group, and image, matching az containerapp create --name myapp --resource-group mygroup --image myimage:latest exactly.

3. Final Answer:

   az containerapp create --name myapp --resource-group mygroup --image myimage:latest -> Option D

4. Quick Check:

   Container Apps use 'az containerapp create' [OK]

Hint: Use 'az containerapp create' to define container apps [OK]

Common Mistakes:

• Using 'az container create' which is for regular containers
• Typing 'appcontainer' instead of 'containerapp'
• Using 'deploy' instead of 'create' command

3. Given this Azure CLI command:

az containerapp create --name orderservice --resource-group shoprg --image shop/orders:1.0 --cpu 0.5 --memory 1.0

What resource limits are set for this container app?

medium

A. 0.5 CPU cores and 1.0 GB memory

B. 1 CPU core and 0.5 GB memory

C. 0.5 CPU cores and 0.5 GB memory

D. 1 CPU core and 1.0 GB memory

Solution

1. Step 1: Read the CPU and memory flags in the command

   The command sets --cpu 0.5 and --memory 1.0.

2. Step 2: Interpret the values

   CPU is 0.5 cores, memory is 1.0 GB as per the flags.

3. Final Answer:

   0.5 CPU cores and 1.0 GB memory -> Option A

4. Quick Check:

   CPU=0.5, Memory=1.0 GB [OK]

Hint: Match --cpu and --memory values exactly [OK]

Common Mistakes:

• Swapping CPU and memory values
• Assuming units are in MB instead of GB
• Ignoring the flags and guessing defaults

4. You tried to deploy a container app with this command:

az containerapp create --name paymentapp --resource-group payrg --image pay/image:latest --cpu two --memory 1.5

What is the likely problem?

medium

A. The memory value 1.5 is too low; it must be at least 2 GB.

B. The CPU value 'two' is invalid; it should be a number like 2 or 0.5.

C. The image tag 'latest' is not allowed in Azure Container Apps.

D. The resource group name 'payrg' is invalid.

Solution

1. Step 1: Check the CPU parameter format

   The CPU value must be a number (like 0.5 or 2), not a word.

2. Step 2: Identify the error in the command

   Using 'two' instead of a numeric value causes a syntax error.

3. Final Answer:

   The CPU value 'two' is invalid; it should be a number like 2 or 0.5. -> Option B

4. Quick Check:

   CPU must be numeric [OK]

Hint: CPU must be a number, not a word [OK]

Common Mistakes:

• Using words instead of numbers for CPU
• Assuming 'latest' tag is invalid
• Thinking resource group name is the problem

5. You want to deploy a microservice architecture using Azure Container Apps with three services: frontend, backend, and database. You want each to scale independently and update without downtime. Which approach is best?

hard

A. Deploy only the frontend as a container app and run backend and database on VMs.

B. Combine all services into one container app to simplify management.

C. Deploy each service as a separate container app with its own scaling rules.

D. Use Azure Container Instances for all services instead of Container Apps.

Solution

1. Step 1: Understand microservice deployment goals

   Each service should scale independently and update without downtime.

2. Step 2: Evaluate deployment options

   Deploying each service as a separate container app allows independent scaling and updates.

3. Step 3: Rule out other options

   Combining services loses independent scaling; mixing VMs adds complexity; Container Instances lack built-in scaling features.

4. Final Answer:

   Deploy each service as a separate container app with its own scaling rules. -> Option C

5. Quick Check:

   Separate apps = independent scaling and updates [OK]

Hint: Separate container apps for each microservice [OK]

Common Mistakes:

• Combining all services in one container app
• Mixing container apps with VMs unnecessarily
• Using Container Instances which lack scaling