Cette page a été traduite par l'API Cloud Translation.

Résoudre les problèmes de diffusion dans App Engine

Cette page décrit les erreurs d'initialisation et de diffusion d'application courantes dans App Engine, ainsi que les méthodes permettant de les résoudre.

Erreur d'autorisation lors de la création d'une application avec le compte de service par défaut

Lorsque vous créez une application après avoir activé l'API App Engine pour la première fois, elle peut échouer avec les erreurs suivantes:

CLI gcloud

An internal error occurred while calling service consumer manager for service account.
Creating  App Engine application in projectPROJECT and REGION....failed. DEBUG: (gcloud.app.create) Error Response: [13] an internal error has occurred

Journaux des requêtes

Service account creation is not allowed on this project.

Console

Error while initialising App Engine.

Cette erreur peut se produire en raison de l'application de la contrainte de règle d'administration constraints/iam.disableServiceAccountCreation lors de la création de votre application. Cette règle empêche le provisionnement du compte de service App Engine par défaut PROJECT_ID@appspot.gserviceaccount.com.

Pour résoudre ce problème, vous devez supprimer temporairement la contrainte de règle d'administration constraints/iam.disableServiceAccountCreation pour permettre la création et le déploiement du compte de service App Engine par défaut. Le compte de service par défaut est nécessaire pour la création de l'application et ne peut pas être ignoré. Cela est également applicable lorsque vous utilisez un compte de service par version. Le compte de service App Engine par défaut peut être supprimé ou remplacé par un compte de service que vous créez une fois le déploiement réussi.

Si vous utilisez un compte de service que vous avez créé, consultez Présentation des recommandations de rôle pour comprendre comment appliquer des autorisations restreintes, par exemple pour attribuer un rôle de créateur de jetons au compte de service créé pour l'agent de service.

L'application n'affiche pas les dernières modifications de code

Si votre application ne diffuse pas les dernières modifications de code après le déploiement, vous pouvez utiliser le système de fichiers racine du conteneur pour vérifier le contenu. Les étapes de dépannage suivantes montrent comment récupérer l'image du conteneur et exporter le système de fichiers racine pour une analyse plus approfondie:

Utilisez Cloud Logging pour obtenir l'URL de l'image du conteneur, avec le filtre GAE_FULL_APP_CONTAINER. Une fois le filtre appliqué, Cloud Logging affiche l'URL de l'image du conteneur, avec votre nom de domaine complet (FQDN). Exemple : GAE_FULL_APP_CONTAINER: FQDN/PROJECT_ID/appengine/SERVICE_NAME.VERSION_ID@sha256:SHA256_DIGEST.
Exécutez la commande suivante pour exporter l'URL de l'image du conteneur:
```
export IMAGE_URL='FQDN/PROJECT_ID/appengine/SERVICE_NAME.VERSION_ID@sha256:SHA256_DIGEST'
```
Remplacez :
- FQDN par le nom de domaine complet de l'URL de l'image du conteneur.
- PROJECT_ID par l'ID de votre Google Cloud projet.
- SERVICE_NAME par le nom de votre service.
- VERSION_ID par l'ID de version du service.
- SHA256_DIGEST avec la valeur SHA256.

Créez un conteneur avec l'URL de l'image du conteneur:

docker pull ${IMAGE_URL}
export CONTAINER_ID=$(docker create ${IMAGE_URL})
docker ps -a # the list should contain the newly created container with status `Created`

Exportez le système de fichiers racine (rootfs) de l'image du conteneur:

 docker export ${CONTAINER_ID} -o gae_app.tar
 mkdir gae_app
 mv -v gae_app.tar gae_app/
 cd gae_app/
 tar -xf gae_app.tar
 ls -la # inspect the container FS

Si vous n'avez pas besoin du fichier TAR, exécutez la commande suivante:

  mkdir gae_app
  cd gae_app/
  docker export ${CONTAINER_ID} | tar -xC <dest>
  ls -la # inspect the container FS

Analysez le contenu du système de fichiers racine pour vérifier si les dernières modifications de code sont présentes.

Exécutez la commande suivante pour nettoyer l'image:

docker container rm ${CONTAINER_ID}
docker image rm ${IMAGE_URL}
unset IMAGE_URL CONTAINER_ID

Nginx ne parvient pas à se connecter ou à contacter le conteneur d'application

L'erreur suivante ne se produit que dans l'environnement flexible App Engine et renvoie généralement des erreurs 502 immédiatement après l'erreur:

recv() failed (104: Connection reset by peer) while reading response header from upstream

Cette erreur indique que le proxy inverse nginx (side-car nginx) ne parvient pas à atteindre le conteneur d'application. Dans les journaux, vous pouvez comparer le délai de fermeture de l'erreur 502 dans le journal nginx avec le délai du journal nginx.error. Une erreur nginx.error suivie immédiatement d'une erreur 502 nginx est probablement la cause de l'erreur nginx 502.

Cette erreur se produit souvent lorsque le délai d'expiration de la connexion keepalive de l'application est inférieur au délai d'expiration keepalive de nginx. Comme nginx dans l'environnement flexible App Engine possède un keepalive_timeout de 650 secondes, les applications doivent maintenir les connexions actives pendant au moins cette durée. Par défaut, les applications Node.js possède un keepAliveTimeout de 5 000 millisecondes. Dans ce cas, vous pouvez définir server.keepAliveTimeout sur 700 000 millisecondes.

Pour résoudre le problème, consultez les journaux écrits par le code exécuté dans le conteneur de votre application en vous connectant à l'instance de VM et ajoutez, si nécessaire, d'autres journaux pour en identifier la cause.

Mémoire insuffisante

L'erreur de manque de mémoire suivante se produit dans l'environnement flexible App Engine et renvoie généralement des erreurs 502:

kernel: [  133.706951] Out of memory: Kill process 4490 (java) score 878 or sacrifice child
kernel: [  133.714468] Killed process 4306 (java) total-vm:5332376kB, anon-rss:2712108kB, file-rss:0kB

Cette erreur indique qu'App Engine a arrêté l'application.

Cette erreur se produit lorsque l'instance dispose d'une mémoire insuffisante. Par défaut, l'environnement flexible App Engine dispose de 1 Go de mémoire, avec seulement 600 Mo pour le conteneur d'applications.

Pour résoudre le problème, recherchez une entrée de mémoire insuffisante dans les journaux, mettez à jour la configuration memory_gb dans votre fichier app.yaml, puis redéployez-le.

Connexions ouvertes insuffisantes pour gérer les requêtes entrantes

Les applications peuvent rencontrer une erreur 502 si le nombre maximal de connexions en attente est égal ou supérieur à 75 % du nombre de connexions actives.

Pour résoudre le problème, consultez les Métriques Cloud Monitoring pour le nombre maximal de connexions actives et en attente, puis diminuez le nombre de connexions en attente pour vous assurer que le nombre maximal de connexions en attente est inférieur ou égal à 75 % du nombre de connexions actives.