Azure Container Apps : valider le trafic des révisions avant rollback

Un déploiement Azure Container Apps peut échouer sans que la révision soit techniquement morte. La nouvelle image démarre, les probes passent, une partie du trafic arrive dessus, mais les erreurs augmentent seulement pour certains chemins, certains clients ou certains appels sortants. Le réflexe immédiat est souvent de rollbacker toute la révision. Parfois c’est juste. Parfois le problème vient du poids de trafic, d’un label mal pointé, d’une dépendance non prête ou d’une route qui envoie encore des utilisateurs vers l’ancienne hypothèse.

Le cas d’usage est une application Container Apps en mode révisions multiples, avec un déploiement progressif ou un basculement bleu/vert. Après promotion, les alertes montrent une dégradation, mais l’équipe ne sait pas encore si elle doit réduire le trafic, corriger la configuration, revenir à la révision précédente ou garder la révision candidate isolée pour analyse.

Le but du runbook est de prendre une décision observable : conserver, réduire, basculer ou rollbacker.

Nommer la révision qui sert vraiment

Commence par capturer l’état de routage avant toute action. Il faut distinguer la révision active, le poids de trafic, le label public ou interne, et l’image de conteneur réellement exposée.

Service à qualifier
Container App: api-orders-prod
Environnement: cae-prod
Révision précédente: api-orders-prod--r42
Révision candidate: api-orders-prod--r43
Mode: révisions multiples
Changement: nouvelle image et nouvelle variable de configuration
Stratégie: 20 pourcent candidate, 80 pourcent stable

Questions avant rollback
Quel pourcentage de trafic touche vraiment la candidate ?
Un label pointe-t-il vers une révision différente du poids attendu ?
Les erreurs suivent-elles la révision, le chemin, le client ou la dépendance ?
Les probes sont-elles suffisantes pour valider le parcours utilisateur ?
Peut-on réduire le trafic sans supprimer la preuve ?

Cette étape évite de confondre rollback et diagnostic. Si l’on supprime immédiatement la révision candidate, on retire aussi les traces qui permettaient de comprendre pourquoi elle dégradait le service.

Lire révisions, poids et labels

Capture l’état Container Apps depuis Azure CLI. Le point important n’est pas seulement de savoir quelle révision est active, mais de savoir comment le trafic y arrive.

RG="rg-prod"
APP="api-orders-prod"

az containerapp show --resource-group "$RG" --name "$APP" --query "{mode:properties.configuration.activeRevisionsMode,ingress:properties.configuration.ingress.traffic,latestRevision:properties.latestRevisionName}" --output json

az containerapp revision list --resource-group "$RG" --name "$APP" --query "[].{name:name,active:properties.active,created:properties.createdTime,image:properties.template.containers[0].image,replicas:properties.replicas,trafficWeight:properties.trafficWeight}" --output table

Si le service utilise des labels, vérifie aussi que le label de test, de canary ou de production pointe vers la bonne révision. Un label oublié peut maintenir un chemin de validation sur une ancienne révision, ou exposer une candidate à un client qui ne devait pas la recevoir.

Corréler les erreurs par révision

La dégradation doit être lue par révision. Une moyenne globale peut masquer une candidate qui échoue à 20 pourcent de trafic ou une stable qui subit une dépendance partagée.

let Window = 2h;
ContainerAppConsoleLogs_CL
| where TimeGenerated > ago(Window)
| where ContainerAppName_s == "api-orders-prod"
| summarize errors=countif(Log_s has_any ("ERROR", "Exception", "timeout")), rows=count() by RevisionName_s, bin(TimeGenerated, 5m)
| order by TimeGenerated asc, RevisionName_s asc

Complète avec les logs système pour détecter redémarrages, problèmes de scale, échec de pull image ou contraintes de ressources.

let Window = 2h;
ContainerAppSystemLogs_CL
| where TimeGenerated > ago(Window)
| where ContainerAppName_s == "api-orders-prod"
| summarize events=count(), messages=make_set(Log_s, 5) by RevisionName_s, Reason_s, bin(TimeGenerated, 10m)
| order by TimeGenerated asc

Si les erreurs sont partagées par toutes les révisions, le rollback applicatif risque de ne rien corriger. Cherche alors une dépendance, un secret, une identité, une route sortante, un service amont ou une saturation commune.

Vérifier probes et chemin utilisateur

Une révision peut être saine du point de vue de la plateforme et mauvaise du point de vue utilisateur. Les probes valident souvent un endpoint court. Elles ne prouvent pas que l’authentification, l’appel base de données, la file de messages ou le routage interne fonctionnent.

Validation minimale
Probe plateforme: révision active et replicas prêts
Smoke test: endpoint utilisateur avec vrai hostname
Corrélation: request id présent dans logs applicatifs
Dépendances: appels sortants, identité et erreurs 401/403/5xx
Trafic: poids attendu observé dans les logs
Rollback: révision stable encore active et cible possible

Bloquer la promotion si
La candidate répond seulement à la probe technique
Les logs ne distinguent pas les révisions
Le label de validation ne pointe pas vers la candidate
Une dépendance critique échoue uniquement sur la candidate
Le rollback supprimerait la seule preuve disponible

Le smoke test doit passer par le même chemin que les utilisateurs : domaine, TLS, éventuel Front Door ou Application Gateway, authentification, dépendance principale et trace de corrélation.

Décider réduction, bascule ou rollback

La décision doit être proportionnée. Tout incident après déploiement ne justifie pas le même geste.

decision:
keep_and_watch:
  when:
    - no_revision_specific_error
    - latency_and_error_budget_within_limit
    - traces_distinguish_candidate_and_stable
  actions:
    - keep_current_traffic_weight
    - extend_observation_window
    - keep_previous_revision_active

reduce_candidate_traffic:
  when:
    - candidate_errors_are_real_but_bounded
    - stable_revision_remains_healthy
    - evidence_is_needed_before_full_rollback
  actions:
    - lower_candidate_weight
    - keep_label_for_targeted_tests
    - capture_logs_before_next_change

shift_back_to_stable:
  when:
    - user_impact_confirmed_on_candidate
    - stable_revision_has_no_same_failure
    - rollback_path_is_known
  actions:
    - set_stable_revision_to_100_percent
    - keep_candidate_active_without_public_traffic
    - validate_user_path_and_error_drop

deactivate_candidate:
  when:
    - candidate_causes_restarts_or_resource_pressure
    - no_more_evidence_is_required
    - stable_revision_is_validated
  actions:
    - deactivate_candidate_revision
    - open_fix_task_with_evidence
    - document_return_condition

La nuance importante est entre “ramener le trafic” et “désactiver la révision”. Ramener le trafic protège les utilisateurs. Garder la candidate active, sans trafic public, préserve souvent la capacité de diagnostic.

Appliquer un rollback contrôlé

Si le rollback est décidé, applique un changement minimal et réversible. Le premier geste peut être de remettre la révision stable à 100 pourcent, pas de supprimer la candidate.

RG="rg-prod"
APP="api-orders-prod"
STABLE="api-orders-prod--r42"
CANDIDATE="api-orders-prod--r43"

az containerapp ingress traffic set --resource-group "$RG" --name "$APP" --revision-weight "$STABLE=100" "$CANDIDATE=0"

az containerapp show --resource-group "$RG" --name "$APP" --query "properties.configuration.ingress.traffic" --output json

Puis valide avec les mêmes signaux que ceux qui ont justifié le rollback : taux d’erreurs, latence, logs par révision, traces de dépendances, et retour utilisateur si le symptôme était externe.

Garder une preuve exploitable

Avant de fermer l’incident, conserve un paquet de preuves court.

Preuves à conserver
État du trafic avant changement
Révisions actives et images exposées
Heure de première dégradation
Logs applicatifs par révision
Logs système Container Apps
Smoke test avant et après rollback
Décision: réduire, basculer ou désactiver
Condition de retour de la candidate

La condition de retour est essentielle. Elle peut être : nouvelle image, variable corrigée, dépendance validée, test de charge repassé, ou observation canary avec un poids plus faible.

Conclusion

Un incident Azure Container Apps après déploiement ne doit pas être traité comme un simple bouton rollback. En mode révisions multiples, le trafic, les labels, les probes et les logs racontent souvent une histoire plus précise que l’état “active” de la révision.

Le bon réflexe consiste à mesurer quelle révision sert vraiment les utilisateurs, isoler les erreurs par révision, valider le chemin utilisateur, puis choisir entre observation, réduction de trafic, bascule vers la stable ou désactivation. La décision finale doit protéger la production sans effacer les preuves dont l’équipe aura besoin pour corriger proprement la candidate.