Résoudre les échecs de déploiement courants dans Azure Container Apps

Cet article vous aide à identifier et à résoudre les scénarios d’échec de déploiement qui nécessitent le plus fréquemment une escalade de prise en charge dans Azure Container Apps. Chaque scénario comprend des symptômes, des étapes de diagnostic du portail et de l’interface CLI et des résolutions.

Recherchez votre symptôme dans la table de référence rapide et suivez le lien vers le scénario correspondant.

Informations de référence rapides sur les symptômes

Où chercher : surfaces de diagnostic

Utilisez les surfaces de diagnostic suivantes pour examiner les échecs de déploiement.

Échecs de téléchargement d’images

Les échecs d’extraction d’images sont l’une des causes les plus courantes des erreurs de déploiement. Ils se produisent généralement avant qu’Azure Container Apps ne puisse créer une révision utilisable.

Symptoms

• Aucune révision n’a été créée.
• provisioningState a la valeur Failed.
• Le message d’erreur mentionne ImagePullBackOff, UNAUTHORIZEDou manifest unknown.

Où rechercher : diagnostics d’extraction d’images

# Check app-level provisioning state and error
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
  --query "{provisioning:properties.provisioningState, error:properties.provisioningError, latestRevision:properties.latestRevisionName}" -o json

# List revisions (expect empty or failed)
az containerapp revision list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
  --query "[].{name:name, health:properties.healthState, provisioning:properties.provisioningState}" -o table

Causes et résolutions courantes

Plantage du conteneur et échecs de démarrage

Utilisez cette section lorsqu’une révision est créée, mais que la charge de travail ne parvient pas à démarrer ou à rester en cours d’exécution.

Symptoms

• La révision est créée, mais healthState est Unhealthy.
• runningState a la valeur Failed.
• Les journaux de la console peuvent être vides (le conteneur s’arrête avant d’écrire une sortie).

Où rechercher : incidents et diagnostics de démarrage

# Inspect revision detail
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> \
  --query "{health:properties.healthState, running:properties.runningState, details:properties.runningStateDetails, error:properties.provisioningError}" -o json

# Pull console logs (if any output was written)
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --tail 100

# Pull system logs for platform-level events
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50

Causes et résolutions courantes

Problèmes d’accès aux secrets

Utilisez cette section pour résoudre les valeurs secrètes manquantes ou vides qui interrompent la configuration de l’application au moment de l’exécution.

Symptoms

• Le conteneur démarre mais l’application échoue, car une valeur de configuration attendue est vide ou manquante.
• Les variables d’environnement qui référencent des secrets n’ont aucune valeur.

Où rechercher : diagnostics des références secrètes

# List secrets defined on the app
az containerapp secret list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o table

# Show the revision template to verify env var references
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> \
  --query "properties.template.containers[].env" -o json

Causes et résolutions courantes

Échecs des références Key Vault

Utilisez cette section lorsque les secrets adossés à Key Vault ne peuvent pas être résolus lors du déploiement ou lorsque l’application est en cours d’exécution.

Symptoms

• Le déploiement échoue ou la valeur secrète n’est pas disponible.
• Les journaux système font référence à des erreurs d’accès à Key Vault.
• provisioningError mentionne un échec d’authentification ou d’autorisation avec Key Vault.

Où chercher : diagnostics d’accès à Key Vault

# List secrets and check for Key Vault reference status
az containerapp secret list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o json

# Verify managed identity is assigned
az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME>

Causes et résolutions courantes

Configuration incorrecte de l’identité managée

Utilisez cette section lorsque l’authentification pour Azure services échoue même si votre application est configurée pour utiliser l’identité managée.

Symptoms

• Le code d’application reçoit 401 (non autorisé) ou 403 (Interdit) lors de l’appel de services Azure.
• Échec de l’acquisition de jetons d’identité gérée.

Où rechercher : diagnostics d’identité et d’autorisation

# Verify identity configuration
az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME>

# Check role assignments for the identity's principal ID
az role assignment list --assignee <PRINCIPAL_ID> --all -o table

Causes et résolutions courantes

Problèmes de synchronisation lors de l’initialisation

Utilisez cette section lorsque les conteneurs init bloquent le démarrage ou échouent avant que le conteneur principal puisse commencer à traiter le trafic.

Symptoms

• L’application n’atteint jamais un état de fonctionnement.
• Les conteneurs Init apparaissent bloqués ou échouent.
• Les journaux système affichent le conteneur init en cours d’exécution, mais jamais terminé.

Où chercher : diagnostics du conteneur d’initialisation

# Check revision running state
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> \
  --query "{running:properties.runningState, details:properties.runningStateDetails}" -o json

# Check init container logs
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --container <INIT_CONTAINER_NAME> --tail 100

# System logs for platform events
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50

Causes et résolutions courantes

Échecs de sonde de santé

Utilisez cette section lorsque les révisions sont déployées avec succès, mais sont marquées comme non saines ou détériorées par les vérifications de sonde.

Symptoms

• La révision est provisionnée, mais l’état d’exécution est Degraded.
• Les journaux système affichent les événements Unhealthy avec les détails de l’échec de la sonde.
• L’application fonctionne localement, mais ne passe pas les vérifications d’état dans ACA.

Où chercher : diagnostics d'intégrité de la sonde

# Check the revision's probe configuration
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> \
  --query "properties.template.containers[].probes" -o json

# System logs for probe failure events
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50

Causes et résolutions courantes

Valeurs de sonde par défaut

Lorsque vous activez l’entrée et que vous ne configurez pas les sondes, ACA applique ces valeurs par défaut :

Problèmes d’entrée et de routage du trafic

Utilisez cette section lorsque l’application est en cours d’exécution, mais que les requêtes échouent, car les paramètres de trafic d’entrée ou de révision sont incorrects.

Symptoms

• L’application est en cours d’exécution et intègre, mais les requêtes HTTP retournent des erreurs (404, 502) ou aucune réponse.
• L’application fonctionne via az containerapp exec, mais pas via l’URL publique.

Où chercher : trafic entrant et diagnostics du trafic

# Check ingress configuration and traffic split
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
  --query "{ingress:properties.configuration.ingress, latestReady:properties.latestReadyRevisionName}" -o json

# Verify the FQDN
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --query "properties.configuration.ingress.fqdn" -o tsv

Causes et résolutions courantes

Authentification du registre de conteneurs

Utilisez cette section lorsque les extractions d’images échouent, car l’application ne peut pas s’authentifier auprès de votre registre de conteneurs.

Symptoms

• Le déploiement échoue avec UNAUTHORIZED: authentication required.
• Cette erreur masque souvent d’autres problèmes (comme une balise d’image incorrecte) car le Registre rejette la demande avant de pouvoir vérifier la balise.

Où rechercher : diagnostics d’authentification du Registre

# Check configured registries
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
  --query "properties.configuration.registries" -o json

# Verify ACR credentials work
az acr login --name <AZURE_CONTAINER_REGISTRY_NAME>
docker pull <AZURE_CONTAINER_REGISTRY_NAME>.azurecr.io/<REPOSITORY_NAME>:<TAG>

Causes et résolutions courantes

Résumé du flux de travail de diagnostic

Utilisez cette séquence lorsque vous ne savez pas ce qui a échoué :

1. Exécutez az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o json. Vérifiez provisioningState, provisioningErroret latestRevisionName.

2. Exécutez az containerapp revision list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o table. Si la liste est vide, l’échec est un problème de validation d’image ou de validation de modèle (échecs d’extraction d’images et authentification de Registre de conteneurs). Si une révision existe, passez à l’étape 3.

3. Exécutez az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> -o json. Vérifier healthState, runningState, runningStateDetails, et provisioningError.

4. Exécutez az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50 pour afficher les événements au niveau de la plateforme, tels que les échecs de sonde, les erreurs d’identité et les problèmes de synchronisation des secrets.

5. Exécutez az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --tail 100 pour afficher l’application stdout/stderr, notamment les traces de pile, les erreurs de configuration et les échecs de connexion.

6. Exécutez az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> pour vérifier la configuration de l’identité si des erreurs liées à l’authentification sont apparues dans les étapes précédentes.

Utilisez « Diagnostiquer et résoudre les problèmes » dans le portail

Requêtes Log Analytics pour une analyse plus approfondie

Si la sortie de la CLI et les diagnostics du portail ne suffisent pas, interrogez directement les journaux sous-jacents dans Log Analytics. Les deux requêtes suivantes couvrent les points de départ les plus courants pour les échecs au niveau de la plateforme et les erreurs HTTP de niveau entrée.

Rechercher des échecs au niveau du système

ContainerAppSystemLogs_CL
| where RevisionName_s == "<REV>"
| where Log_s contains "BackOff" or Log_s contains "Failed" or Log_s contains "Error"
  or Reason_s == "Unhealthy"
| project TimeGenerated, Reason_s, Log_s
| order by TimeGenerated desc
| take 50

Cette requête affiche des erreurs d’extraction d’images, des échecs de sonde, des erreurs d’approvisionnement et d’autres événements de plateforme.

Rechercher des erreurs HTTP (nécessite que les journaux HTTP soient activés)

La couche d’entrée génère des journaux HTTP, et vous choisissez de les activer. Activez ces journaux via les paramètres de diagnostic d’Azure Monitor sur l’environnement managé Container Apps. Une fois que vous les avez activés, la ContainerAppHTTPLogs table apparaît dans Log Analytics. L’affichage du tableau peut prendre plusieurs minutes.

ContainerAppHTTPLogs
| where TimeGenerated > ago(1h)
| where StatusCode >= 400
| project TimeGenerated, ContainerAppName, RevisionName, Method, Path,
  StatusCode, ResponseCodeDetails, RequestDuration, RequestId
| order by TimeGenerated desc
| take 100

Cette requête filtre les journaux HTTP de la couche d’entrée pour afficher uniquement les demandes ayant échoué (code d’état 400 ou supérieur) à partir de la dernière heure. Il retourne l’horodatage, l’application et le nom de révision, la méthode HTTP et le chemin, le code d’état d’erreur, un ResponseCodeDetails champ qui indique si l’erreur provient de votre conteneur (via_upstream) ou de la plateforme (, route_not_found),connection_timeout la durée de la requête et un ID de requête unique que vous pouvez utiliser pour mettre en corrélation les journaux d’application.

Pour en savoir plus, notamment sur l’analyse des requêtes lentes, le taux d’erreur par révision, le traçage d’une requête unique et les principaux points de terminaison en échec, consultez Surveiller les journaux dans Azure Container Apps avec Log Analytics.

Contenu connexe

• Dépanner une application conteneurisée
• Gérer les secrets dans Azure Container Apps
• Identités managées dans Azure Container Apps
• Sondes de santé dans Azure Container Apps
• Entrées dans Azure Container Apps
• Surveiller les journaux dans Azure Container Apps avec Log Analytics