You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: learn-pr/wwl-data-ai/manage-containers-azure-container-apps/includes/1-introduction.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ This module focuses on the operational decisions and tools you use to keep Conta
8
8
9
9
After completing this module, you’ll be able to:
10
10
11
-
- Update container images and manage revisions safely during development and release cycles, including activation, deactivation, rollback, and cleanup.
11
+
- Update container images and manage revisions safely during development and release cycles, including activation, deactivation, rollback, and clean up.
12
12
- Perform app lifecycle operations, including start, stop, and restart, and diagnose failing revisions.
13
13
- Monitor logs and troubleshoot common revision and runtime issues.
14
14
- Configure liveness and readiness probes and troubleshoot probe failures.
Copy file name to clipboardExpand all lines: learn-pr/wwl-data-ai/manage-containers-azure-container-apps/includes/2-update-images-manage-revisions.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ For AI solutions, traceability matters because you often need to correlate opera
13
13
14
14
When you update the image for a container app, Container Apps creates a new revision with the updated template. You can then verify the revision’s health before you route traffic to it. This workflow helps you avoid sending production traffic to a revision that fails startup, fails probes, or crashes under load.
15
15
16
-
The following example updates the image reference. If you are using Azure Container Registry, your image name typically looks like `myregistry.azurecr.io/myapp@sha256:<digest>`.
16
+
The following example updates the image reference. If you're using Azure Container Registry, your image name typically looks like `myregistry.azurecr.io/myapp@sha256:<digest>`.
17
17
18
18
```azurecli
19
19
az containerapp update \
@@ -31,7 +31,7 @@ az containerapp show \
31
31
--query properties.template.containers
32
32
```
33
33
34
-
## Understand revision modes and what “active” means
34
+
## Understand revision modes and what "active" means
35
35
36
36
Revision mode determines how many revisions can be active at the same time. Single revision mode keeps only one active revision, which simplifies operations but limits advanced rollout strategies. Multiple revision mode enables canary rollouts and traffic splitting, which is useful when you want to validate a new model version with a small portion of traffic.
Copy file name to clipboardExpand all lines: learn-pr/wwl-data-ai/manage-containers-azure-container-apps/includes/3-app-lifecycle-management.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,13 +5,13 @@ Managing the container app lifecycle is a day-two skill that supports both cost
5
5
6
6
## Decide between stop, restart, and scaling to zero
7
7
8
-
Container Apps supports scaling to zero based on your scaling configuration, which can be appropriate for event-driven services or workloads with intermittent traffic. Stopping an app is different. Stopping is an explicit operational action, and it is useful when you want to guarantee the app does not start replicas while you are mitigating an incident.
8
+
Container Apps supports scaling to zero based on your scaling configuration, which can be appropriate for event-driven services or workloads with intermittent traffic. Stopping an app is different. Stopping is an explicit operational action, and it's useful when you want to guarantee the app doesn't start replicas while you're mitigating an incident.
9
9
10
10
Restart sits between those two actions. Restart is useful when configuration changes should take effect immediately, or when a process is stuck due to a deadlock or a transient dependency issue. For AI services that load large models at startup, restarting too aggressively can increase cold start frequency, so you should use restart with intent.
11
11
12
12
## Start and stop a container app
13
13
14
-
Starting and stopping are app-level actions. They affect the container app as a whole and therefore can be too broad if the problem is limited to one revision. When you are isolating a single bad release, revision deactivation is often the safer first step.
14
+
Starting and stopping are app-level actions. They affect the container app as a whole and therefore can be too broad if the problem is limited to one revision. When you're isolating a single bad release, revision deactivation is often the safer first step.
15
15
16
16
```azurecli
17
17
az containerapp stop \
@@ -27,7 +27,7 @@ az containerapp start \
27
27
28
28
## Restart an app to recover from a bad runtime state
29
29
30
-
Restarting forces replicas to restart and can clear transient failure states. Restart is not a substitute for understanding the root cause. You should pair restart with log inspection so you can determine whether the restart fixed the issue or simply delayed the next failure.
30
+
Restarting forces replicas to restart and can clear transient failure states. Restart isn't a substitute for understanding the root cause. You should pair restart with log inspection so you can determine whether the restart fixed the issue or delayed the next failure.
31
31
32
32
```azurecli
33
33
az containerapp restart \
@@ -44,7 +44,7 @@ Common failure patterns to validate:
44
44
-**Image pull failures:** The registry credentials are missing or invalid, or the image reference is incorrect.
45
45
-**Port mismatches:** The container listens on a different port than the Container Apps ingress configuration expects.
46
46
-**Missing configuration:** Environment variables or secrets that the app requires are missing or misnamed.
47
-
-**Probe failures:** Liveness or readiness probes target the wrong path or do not allow enough startup time for model loading.
47
+
-**Probe failures:** Liveness or readiness probes target the wrong path or don't allow enough startup time for model loading.
48
48
-**Resource pressure:** The container starts but is killed due to memory limits or becomes slow due to CPU throttling.
49
49
50
50
The following query is a useful starting point to compare revision status at a glance.
@@ -59,7 +59,7 @@ az containerapp revision list \
59
59
60
60
## Additional resources
61
61
62
-
Use these links to review how lifecycle actions fit into the broader Container Apps operational model. They are also useful when you build runbooks and want a single place to confirm current CLI syntax.
62
+
Use these links to review how lifecycle actions fit into the broader Container Apps operational model. They're also useful when you build runbooks and want a single place to confirm current CLI syntax.
Copy file name to clipboardExpand all lines: learn-pr/wwl-data-ai/manage-containers-azure-container-apps/includes/4-monitor-logs-troubleshoot.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ az containerapp logs show \
18
18
19
19
## Design logs that support AI troubleshooting
20
20
21
-
AI services often behave differently for different inputs, and that makes troubleshooting harder if logs do not capture enough context. You want enough detail to debug safely, but you also want to avoid logging sensitive content. A balanced approach is to log identifiers and metadata rather than raw documents or prompts.
21
+
AI services often behave differently for different inputs, and that makes troubleshooting harder if logs don't capture enough context. You want enough detail to debug safely, but you also want to avoid logging sensitive content. A balanced approach is to log identifiers and metadata rather than raw documents or prompts.
22
22
23
23
Recommended fields to include in application logs:
24
24
@@ -29,7 +29,7 @@ Recommended fields to include in application logs:
29
29
30
30
## Troubleshoot revision-specific failures
31
31
32
-
Revision failures often fall into a few categories: startup failures, probe failures, configuration errors, or runtime exceptions. Logs help you identify which category you are facing. For example, an app might exit immediately due to a missing environment variable, or it might start successfully but fail readiness probes due to a wrong path.
32
+
Revision failures often fall into a few categories: startup failures, probe failures, configuration errors, or runtime exceptions. Logs help you identify which category you're facing. For example, an app might exit immediately due to a missing environment variable, or it might start successfully but fail readiness probes due to a wrong path.
33
33
34
34
During an incident, use a workflow that narrows scope quickly:
Copy file name to clipboardExpand all lines: learn-pr/wwl-data-ai/manage-containers-azure-container-apps/includes/5-health-probes.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,13 +5,13 @@ Health probes protect your users during rollouts by preventing traffic from reac
5
5
6
6
## Understand readiness versus liveness
7
7
8
-
Readiness answers the question, “Can this replica receive traffic right now?” If readiness fails, the platform should avoid routing requests to that replica. Liveness answers the question, “Is this process healthy enough to keep running?” If liveness fails, the platform restarts the replica.
8
+
Readiness answers the question, "Can this replica receive traffic right now?" If readiness fails, the platform should avoid routing requests to that replica. Liveness answers the question, "Is this process healthy enough to keep running?" If liveness fails, the platform restarts the replica.
9
9
10
10
In an AI solution, you commonly treat readiness as a guard for model loading and dependency readiness. You treat liveness as a safety valve for deadlocks and runaway memory issues. You tune both probes so they match your real startup and steady-state behavior.
11
11
12
12
## Recognize common probe failure causes
13
13
14
-
Probe failures are frequently configuration issues rather than code issues. When a new revision fails probes, validate the simple causes first so you do not spend time chasing the wrong layer.
14
+
Probe failures are frequently configuration issues rather than code issues. When a new revision fails probes, validate the common causes first so you don't spend time chasing the wrong layer.
15
15
16
16
Common causes include:
17
17
@@ -52,7 +52,7 @@ properties:
52
52
53
53
## Troubleshoot probe failures during rollout
54
54
55
-
When probes fail, combine revision status and logs. Revision status tells you whether the platform considers the revision healthy, and logs tell you whether the application started successfully and which endpoint it exposed. You should also confirm that the probe endpoints do not depend on external systems that might be unavailable during an incident.
55
+
When probes fail, combine revision status and logs. Revision status tells you whether the platform considers the revision healthy, and logs tell you whether the application started successfully and which endpoint it exposed. You should also confirm that the probe endpoints don't depend on external systems that might be unavailable during an incident.
56
56
57
57
If an AI service loads a model at startup, tune `initialDelaySeconds` and `failureThreshold` to give the process enough time to reach a ready state. If you see liveness failures shortly after startup, liveness is likely too aggressive or the process is failing fast due to misconfiguration.
Copy file name to clipboardExpand all lines: learn-pr/wwl-data-ai/manage-containers-azure-container-apps/includes/6-optimize-container-settings.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,9 +23,9 @@ az containerapp update \
23
23
24
24
## Tune scaling for a synchronous API versus a background worker
25
25
26
-
Scaling strategies differ by workload. A synchronous API often needs stable readiness and predictable latency, so you may choose a minimum replica count to reduce cold starts. A background worker can often tolerate scale-to-zero if it is event-driven and can drain work safely when replicas scale down.
26
+
Scaling strategies differ by workload. A synchronous API often needs stable readiness and predictable latency, so you might choose a minimum replica count to reduce cold starts. A background worker can often tolerate scale-to-zero if it's event-driven and can drain work safely when replicas scale down.
27
27
28
-
When you adjust scaling, consider the implications for revision rollouts. A rollout that creates a new revision might start new replicas, and if your service has slow warmup, those new replicas can stay unready for longer. Align scaling configuration with probe configuration so rollouts do not appear to fail simply because warmup takes time.
28
+
When you adjust scaling, consider the implications for revision rollouts. A rollout that creates a new revision might start new replicas, and if your service has slow warmup, those new replicas can stay unready for longer. Align scaling configuration with probe configuration so rollouts don't appear to fail simply because warmup takes time.
Copy file name to clipboardExpand all lines: learn-pr/wwl-data-ai/manage-containers-azure-container-apps/includes/7-exercise-diagnose-fix-failing-deployment.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ To complete the exercise, you need:
18
18
19
19
- An Azure subscription with the permissions to deploy the necessary Azure services. If you don't already have one, you can [sign up for one](https://azure.microsoft.com/).
20
20
-[Visual Studio Code](https://code.visualstudio.com/) on one of the [supported platforms](https://code.visualstudio.com/docs/supporting/requirements#_platforms).
21
-
- The latest version of the [Azure CLI](https://learn.microsoft.com/cli/azure/install-azure-cli?view=azure-cli-latest).
21
+
- The latest version of the [Azure CLI](/cli/azure/install-azure-cli).
22
22
- Optional: [Python 3.12](https://www.python.org/downloads/) or greater.
0 commit comments