Dépannage

Cette page présente des stratégies de dépannage et des solutions à certains problèmes courants.

Lors du déploiement d'une nouvelle révision, si vous voyez le message d'erreur "Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable." (Impossible de démarrer le conteneur. Impossible de démarrer puis d'écouter sur le port défini par la variable d'environnement PORT), suivez ces étapes pour résoudre le problème.

Votre conteneur s'exécute-t-il localement ?

Lorsque vous dépannez Cloud Run, la première étape consiste toujours à vérifier que vous pouvez exécuter votre image de conteneur localement. Si l'image de conteneur ne s'exécute pas localement, le problème ne provient pas de Cloud Run. Vous devez d'abord diagnostiquer et résoudre le problème localement.

Votre conteneur écoute-t-il les requêtes sur le port prévu ?

Oublier d'écouter les requêtes entrantes ou les écouter sur le mauvais port est une erreur fréquente.

Comme précisé dans le contrat d'exécution du conteneur, votre conteneur doit écouter les requêtes entrantes sur le port défini par Cloud Run et indiqué dans la variable d'environnement PORT.

Si votre conteneur n'écoute pas sur le port prévu, la vérification de l'état de la révision échouera, la révision sera en état d'erreur et le trafic ne sera pas acheminé vers le conteneur.

Votre conteneur écoute-t-il sur toutes les interfaces réseau ?

L'échec du démarrage des services Cloud Run est souvent causé par le processus serveur à l'intérieur du conteneur qui est configuré pour écouter sur l'adresse localhost (127.0.0.1). Il s'agit de l'interface réseau de bouclage, qui n'est pas accessible de l'extérieur du conteneur. Par conséquent, la vérification de l'état de Cloud Run ne peut pas être effectuée, ce qui entraîne l'échec du déploiement du service.

Pour résoudre ce problème, configurez votre application pour démarrer le serveur HTTP afin qu'il écoute sur toutes les interfaces réseau, généralement référencées sous l'adresse 0.0.0.0.

Les journaux affichent-ils des erreurs ?

Utilisez Cloud Logging pour rechercher les erreurs d'application dans les journaux stdout ou stderr, comme décrit sur la page Journaliser et afficher des journaux de Cloud Run. Vous pouvez également rechercher les plantages capturés dans Error Reporting, comme décrit sur la page Error Reporting de Cloud Run. Consultez également le tutoriel de dépannage.

Vous devrez probablement mettre à jour votre code ou vos paramètres de révision pour corriger ces erreurs ou ces plantages.

Vos instances de conteneur dépassent-elles la mémoire disponible ?

Vos instances de conteneur peuvent entraîner un dépassement de la mémoire disponible. Pour le déterminer, recherchez ce type d'erreurs dans les journaux varlog/system. Si les instances dépassent la mémoire disponible, envisagez d'augmenter la limite de mémoire.

Notez que, dans l'environnement d'exécution des instances de conteneur Cloud Run, les fichiers écrits dans le système de fichiers local sont comptabilisés dans la mémoire disponible. Sont également inclus les fichiers journaux qui ne sont pas écrits dans les journaux /var/log/* ou /dev/log.

403 Error: Forbidden lors de l'ouverture ou de l'appel de l'URL du service

Si vous recevez un message d'erreur 403 "Error: Forbidden" lors de l'accès à votre service Cloud Run, cela signifie que votre client n'est pas autorisé à appeler ce service. L'une des actions suivantes vous permet de résoudre le problème :

Erreur SIGNATURE_REMOVED_BY_GOOGLE lors de l'utilisation du jeton d'ID

Cette erreur peut être observée lors du développement et du test dans les cas suivants :

  1. L'utilisateur se connecte avec les comptes utilisateur à l'aide de la ligne de commande gcloud ou de Cloud Shell.
  2. L'utilisateur génère un jeton d'ID via la ligne de commande gcloud.
  3. L'utilisateur essaie ensuite d'utiliser le jeton d'ID pour appeler un service Cloud Run non public.

Cela est volontaire. La signature du jeton est supprimée pour des raisons de sécurité, afin d'empêcher tout service Cloud Run non public de relire les jetons d'ID générés de la manière décrite ci-dessus. À la place, pour appeler un service privé avec un nouveau jeton d'ID, consultez la section Tester l'authentification dans votre service.

Le code d'erreur 203 pour les requêtes de longue durée s'affiche-t-il ?

Si votre service traite des requêtes de longue durée et que vous avez augmenté le délai avant expiration des requêtes, il est possible que leur traitement s'achève plus tôt que prévu et génère le code d'erreur 203. Le paramètre du délai avant expiration des requêtes de votre infrastructure de langage est sans doute en cause et vous devez également le mettre à jour. Par exemple, les développeurs en Node.js doivent mettre à jour la propriété server.timeout.

Des erreurs 503 apparaissent-elles lors de charges élevées ?

L'équilibreur de charge Cloud Run s'efforce de répartir les requêtes entrantes en fonction du nombre d'instances de conteneur nécessaires. Toutefois, si celles-ci utilisent beaucoup de ressources processeur pour traiter les requêtes, elles ne peuvent pas les traiter toutes et certaines requêtes sont renvoyées avec un code d'erreur 503.

Pour y remédier, essayez de réduire la simultanéité. Pour en savoir plus, consultez la page Définir la simultanéité.

Des erreurs 429 s'affichent-elles ?

Si le service a atteint son nombre maximal d'instances de conteneur, les requêtes sont renvoyées avec un code d'erreur 429. Essayez d'augmenter cette limite en augmentant les paramètres de nombre maximal d'instances ou, si vous avez besoin de plus de 1 000 instances, demandez une augmentation du quota.

Vos requêtes sont-elles abandonnées, car aucune instance n'est disponible ?

Vous pouvez obtenir l'erreur suivante si l'infrastructure Cloud Run n'a pas évolué assez rapidement pour faire face au pic de trafic :

The request was aborted because there was no available instance

La cause de ce problème peut être l'une des suivantes :

Êtes-vous dans l'impossibilité de déployer ou d'appeler d'autres API Google Cloud ?

Vérifiez que l'agent de service Cloud Run n'a pas été supprimé et qu'il dispose du rôle IAM "Agent de service Cloud Run". Son adresse e-mail se termine par @serverless-robot-prod.iam.gserviceaccount.com.

Erreur : La fonctionnalité n'est pas compatible dans l'étape de lancement déclarée

Si vous appelez directement l'API Cloud Run Admin et utilisez une fonctionnalité bêta sans spécifier d'annotation de l'étape de lancement, l'erreur suivante peut s'afficher :

The feature is not supported in the declared launch stage

Les utilisateurs directs de l'API Cloud Run Admin doivent annoter la ressource avec une annotation run.googleapis.com/launch-stage en tant que BETA dans la requête si une fonctionnalité bêta est utilisée.

L'exemple suivant ajoute une annotation de l'étape de lancement à une requête de service :

kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA

Votre problème est-il causé par une limite dans le bac à sable de conteneur ?

Si votre conteneur s'exécute localement mais échoue dans Cloud Run, le bac à sable de conteneur Cloud Run en est peut-être responsable.

Dans la section Cloud Logging de la console GCP (et non dans l'onglet "Journaux" de la section Cloud Run), vous pouvez rechercher "Bac à sable de conteneur" avec une gravité définie sur "DEBUG" dans les journaux varlog/system ou utiliser la requête de journal :

resource.type="cloud_run_revision"
logName="projects/PROJECT_ID/logs/run.googleapis.com%2Fvarlog%2Fsystem"

varlogs

Exemple :

Container Sandbox: Unsupported syscall setsockopt(0x3,0x1,0x6,0xc0000753d0,0x4,0x0)

Si vous pensez que ces limites peuvent être responsables de l'échec de votre conteneur, contactez l'assistance et ajoutez le message du journal à la demande d'assistance. L'assistance Google Cloud peut vous demander de tracer les appels système effectués par votre service pour diagnostiquer les appels système de niveau inférieur qui ne sont pas affichés dans les journaux Cloud Logging.