Résoudre les problèmes liés aux fonctions Cloud Run (1re génération)

Remarque : Ce contenu ne s'applique qu'aux fonctions Cloud Run (1re génération) (anciennement Cloud Functions (1re génération).)

Pour obtenir la version de ce document correspondant à Cloud Run Functions, consultez Résoudre les problèmes liés aux fonctions Cloud Run.

Ce document explique comment résoudre les problèmes liés aux messages d'erreur et à l'utilisation de Cloud Run Functions (1re génération).

Déploiement

Cette section répertorie les problèmes que vous pouvez rencontrer lors du déploiement et fournit des suggestions pour les résoudre. La plupart des problèmes que vous pouvez rencontrer lors du déploiement sont liés aux rôles et autorisations ou à une configuration incorrecte.

Le compte de service de déploiement ne dispose pas des autorisations Pub/Sub nécessaires lors du déploiement d'une fonction basée sur des événements

Le service Cloud Functions utilise le compte de service de l'agent de service Cloud Functions ([e-mail]) pour effectuer des tâches d'administration. Le rôle cloudfunctions.serviceAgent Cloud Functions est attribué par défaut à ce compte de service. Pour déployer des fonctions basées sur des événements, le service Cloud Functions doit accéder à Pub/Sub pour configurer les sujets et les abonnements. Si le rôle attribué au compte de service change et que les autorisations appropriées ne sont pas mises à jour, le service Cloud Functions ne peut pas accéder à Pub/Sub et le déploiement échoue.

Message d'erreur

Console

Failed to configure trigger PubSub projects/PROJECT_ID/topics/FUNCTION_NAME

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=13, message=Failed to configure trigger PubSub projects/PROJECT_ID/topics/FUNCTION_NAME

Solution

Vous pouvez réinitialiser votre compte de service pour rétablir le rôle cloudfunctions.serviceAgent par défaut.

Le compte de service d'exécution par défaut n'existe pas

Lorsqu'un compte de service géré par l'utilisateur n'est pas spécifié, les fonctions Cloud Run (1re génération) utilisent par défaut le compte de service App Engine. Les déploiements échouent si vous supprimez le compte par défaut sans spécifier de compte de service géré par l'utilisateur.

Message d'erreur

gcloud

ERROR: (gcloud.functions.deploy) ResponseError: status=[400], code=[Ok], message=[Default service account '[e-mail]' doesn't exist. Please recreate this account or specify a different account. Please visit https://cloud.google.com/functions/docs/troubleshooting for in-depth troubleshooting documentation.]

Solution

Pour résoudre ce problème, appliquez l'une des solutions suivantes:

• Spécifiez un compte de service d'exécution géré par l'utilisateur lorsque vous déployez votre fonction.

• Recréez le compte de service par défaut [e-mail] pour votre projet.

• Annulez la suppression du compte de service par défaut.

L'utilisateur ne dispose pas des autorisations nécessaires sur le compte de service d'exécution lors du déploiement d'une fonction

Chaque fonction est associée à un compte de service qui sert d'identité lorsque la fonction accède à d'autres ressources. Ce compte de service d'exécution peut être le compte de service par défaut ou un compte de service géré par l'utilisateur. Pour que Cloud Functions utilise un compte de service d'exécution, l'utilisateur à l'origine du déploiement doit disposer de l'autorisation iam.serviceAccounts.actAs sur ce compte de service. Cette autorisation est automatiquement accordée à un utilisateur qui crée un compte de service d'exécution autre que celui par défaut. Pour que d'autres "déployeurs" puissent en disposer, elle doit leur être accordée par un utilisateur disposant des autorisations appropriées.

Un utilisateur qui dispose du rôle de lecteur de projet, de développeur de fonction Cloud ou d'administrateur de fonction Cloud doit également disposer de l'autorisation iam.serviceAccounts.actAs sur le compte de service d'exécution.

Message d'erreur

Console

You must have the iam.serviceAccounts.actAs permission on the selected service account. To obtain this permission, you can grant a role that includes it like the Service Account User role, on the project.

gcloud

L'erreur suivante se produit pour le compte de service par défaut:

ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Ok], message=[Caller USER is missing permission 'iam.serviceaccounts.actAs' on service account [e-mail]. Grant the role 'roles/iam.serviceAccountUser' to the caller on the service account [e-mail]. You can do that by running 'gcloud iam service-accounts add-iam-policy-binding
[e-mail] --member MEMBER --role roles/iam.serviceAccountUser' where MEMBER has a prefix like 'user:' or 'serviceAccount:'.

L'erreur suivante se produit pour le compte de service non par défaut:

ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Ok], message=[Caller USER is missing permission 'iam.serviceaccounts.actAs' on service account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com. Grant the role 'roles/iam.serviceAccountUser' to the caller on the service account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com. You can do that by running 'gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com --member MEMBER --role roles/iam.serviceAccountUser' where MEMBER has a prefix like 'user:' or 'serviceAccount:'.

Remarque :[e-mail] est le compte de service d'exécution par défaut pour les fonctions Cloud Run(1re génération). Il est remplacé par le compte de service SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com géré par l'utilisateur dans le message d'erreur lorsque vous utilisez un compte de service autre que celui par défaut.

Solution

Attribuez à l'utilisateur le rôle roles/iam.serviceAccountUser sur le compte de service par défaut ou géré par l'utilisateur. Ce rôle inclut l'autorisation iam.serviceAccounts.actAs.

Le compte de service de l'agent de service Cloud Run Functions ne dispose pas des autorisations nécessaires sur le bucket du projet lors du déploiement d'une fonction

Les fonctions Cloud Run ne peuvent être déclenchées par des événements qu'à partir de buckets Cloud Storage situés dans le même projet Google Cloud. En outre, le compte de service de l'agent de service Cloud Functions ([e-mail]) doit disposer du rôle cloudfunctions.serviceAgent sur votre projet.

Message d'erreur

Console

Deployment failure: Insufficient permissions to (re)configure a trigger
(permission denied for bucket BUCKET_ID). Please, give owner permissions
to the editor role of the bucket and try again.

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=7, message=Insufficient
permissions to (re)configure a trigger (permission denied for bucket BUCKET_ID).
Please, give owner permissions to the editor role of the bucket and try again.

Solution

Pour résoudre cette erreur, réinitialisez le compte de service Service Agent pour rétablir le rôle par défaut.

Un utilisateur doté du rôle d'éditeur de projet ne peut pas rendre une fonction disponible publiquement

Le rôle "Éditeur de projet" dispose d'autorisations étendues pour gérer les ressources d'un projet, mais ne permet pas de rendre les fonctions Cloud Run publiques. Vous devez accorder l'autorisation cloudfunctions.functions.setIamPolicy à l'utilisateur ou au service qui déploie la fonction.

Message d'erreur

gcloud

 ERROR: (gcloud.functions.add-iam-policy-binding) ResponseError: status=[403], code=[Forbidden], message=[Permission 'cloudfunctions.functions.setIamPolicy' denied on resource 'projects/PROJECT_ID/locations/LOCATION/functions/FUNCTION_NAME (or resource may not exist).]

Solution

Pour résoudre cette erreur, appliquez l'une des solutions suivantes:

• Attribuer au "déployeur" le rôle de propriétaire du projet ou celui d'administrateur Cloud Functions, qui contiennent tous deux l'autorisation cloudfunctions.functions.setIamPolicy

• Accorder manuellement l'autorisation en créant un rôle personnalisé

• Vérifiez si le partage restreint de domaine est appliqué au projet.

Échec du déploiement de la fonction lors de l'utilisation de la règle d'administration Restriction d'emplacement des ressources

Si votre organisation utilise une règle Restriction d'emplacement des ressources, elle limitera le déploiement de fonctions dans les régions restreintes par la règle. Dans la console Google Cloud, la région soumise à des restrictions ne sera pas disponible dans le menu déroulant des régions lorsque vous déploierez une fonction.

Message d'erreur

gcloud

  ERROR: (gcloud.functions.deploy) ResponseError: status=[400], code=[Ok], message=[The request has violated one or more Org Policies. Please refer to the respective violations for more information. violations {
    type: "constraints/gcp.resourceLocations"
    subject: "orgpolicy:projects/PROJECT_ID"
    description: "Constraint constraints/gcp.resourceLocations violated for projects/PROJECT_ID attempting GenerateUploadUrlActionV1 with location set to RESTRICTED_LOCATION. See https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints for more information."
  }

Solution

Ajoutez ou supprimez des emplacements des listes allowed_values ou denied_values de la contrainte d'emplacement de ressources pour réussir le déploiement.

Échec du déploiement de la fonction lors de l'exécution du champ d'application global de la fonction

Cette erreur indique qu'un problème est lié au code. Le pipeline de déploiement a fini de déployer la fonction, mais a échoué à la dernière étape en envoyant une vérification d'état à la fonction. Cette vérification d'état est destinée à exécuter le champ d'application global d'une fonction, ce qui peut générer une exception, un plantage ou un dépassement de délai. Le champ d'application global est l'endroit où vous chargez généralement les bibliothèques et initialisez les clients.

Message d'erreur

Console

Deployment failure: Function failed on loading user code. This is likely due to a bug in the user code.

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=3, message=Function
failed on loading user code. This is likely due to a bug in the user code.

Dans les journaux Cloud Logging :

  "Function failed on loading user code. This is likely due to a bug in the user code."

Solution

Pour résoudre ce problème, appliquez l'une des solutions suivantes:

• Pour afficher un message d'erreur plus détaillé, consultez les journaux des builds de votre fonction, ainsi que les journaux d'exécution de la fonction.

• Si vous ne comprenez pas pourquoi votre fonction n'a pas réussi à exécuter son champ d'application global, envisagez de déplacer temporairement le code dans l'appel de la requête, en utilisant l'initialisation différée des variables globales. Cela vous permet d'ajouter des entrées de journal supplémentaires à vos bibliothèques clientes, qui pourraient expirer lors de leur instanciation (surtout si elles appellent d'autres services), ou pour éviter tout plantage/toute génération d'exceptions.

• Augmentez le délai avant expiration de la fonction.

• Le code source doit contenir une fonction de point d'entrée qui a été correctement spécifiée dans le déploiement, via la console ou gcloud.

Un utilisateur disposant du rôle de lecteur ne peut pas déployer une fonction

Les utilisateurs disposant du rôle de lecteur de projet ou de lecteur Cloud Functions ne bénéficient que d'un accès en lecture seule aux fonctions et aux détails des fonctions, et ne peuvent pas déployer de nouvelles fonctions. La fonctionnalité Créer une fonction est grisée dans la console Google Cloud, avec l'erreur suivante:

Message d'erreur

gcloud

ERROR: (gcloud.functions.deploy) PERMISSION_DENIED: Permission
'cloudfunctions.functions.sourceCodeSet' denied on resource
'projects/PROJECT_ID/locations/LOCATION` (or resource may not exist)

Solution

Attribuez à l'utilisateur le rôle Développeur Cloud Functions.

Autorisations manquantes pour le compte de service de compilation

Message d'erreur

Dans l'erreur de déploiement de la fonction ou dans les journaux de compilation, l'une des erreurs suivantes peut s'afficher :

The service account running this build does not have permission to write logs.
To fix this, grant the Logs Writer (roles/logging.logWriter) role to the service
account.

Step #0 - "fetch": failed to Fetch: failed to download archive gs://gcf-sources-PROJECT_NUMBER-LOCATION/FUNCTION_NAME/version-VERSION_NUMBER/function-source.zip: Access to bucket gcf-sources-PROJECT_NUMBER-LOCATION denied. You must grant Storage Object Viewer permission to [e-mail].

Step #2 - "build": ERROR: failed to create image cache: accessing cache image "LOCATION-docker.pkg.dev/PROJECT/gcf-artifacts/FUNCTION_NAME/cache:latest": connect to repo store "LOCATION-docker.pkg.dev/PROJECT/gcf-artifacts/FUNCTION_NAME/cache:latest": GET https://LOCATION-docker.pkg.dev/v2/token?scope=repository%3APROJECT%2Fgcf-artifacts%2FFUNCTION_NAME%2Fcache%3Apull&service=: DENIED: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/PROJECT/locations/LOCATION/repositories/gcf-artifacts" (or it may not exist)

Could not build the function due to a missing permission on the build service account. If  you didn't revoke that permission explicitly, this could be caused by a change in the organization policies.

Solution

Le compte de service de compilation doit être autorisé à lire le bucket source, et à lire et écrire dans le dépôt de déploiement d'artefacts. Cette erreur peut se produire en raison d'un changement du comportement par défaut de Cloud Build concernant l'utilisation des comptes de service, détaillé dans la section Modification du compte de service Cloud Build.

Pour résoudre ce problème, appliquez l'une des solutions suivantes :

• Créez un compte de service de compilation personnalisé pour les déploiements de fonctions.
• Ajoutez le rôle de compte de service Cloud Build (roles/cloudbuild.builds.builder) au compte de service Compute par défaut.
• Consultez les conseils de Cloud Build concernant les modifications apportées au compte de service par défaut et désactivez ces modifications.

Compte de service de compilation désactivé

Message d'erreur

Could not build the function due to disabled service account used by Cloud Build. Please make sure that the service account is active.

Solution

Le compte de service de compilation doit être activé pour pouvoir déployer une fonction. Cette erreur peut se produire en raison d'un changement du comportement par défaut de Cloud Build concernant l'utilisation des comptes de service, détaillé dans la section Modification du compte de service Cloud Build.

Pour résoudre ce problème, appliquez l'une des solutions suivantes :

• Créez un compte de service de compilation personnalisé pour les déploiements de fonctions.
• Activez le compte de service Compute par défaut.
• Consultez les conseils de Cloud Build concernant les modifications apportées au compte de service par défaut et désactivez ces modifications.

Diffusion

Cette section répertorie les problèmes que vous pouvez rencontrer et fournit des suggestions pour les résoudre.

Erreur d'autorisation de diffusion due à la fonction nécessitant une authentification

Les fonctions HTTP sans l'option Autoriser les appels non authentifiés activée limitent l'accès aux utilisateurs finaux et aux comptes de service qui ne disposent pas des autorisations appropriées.

La consultation de l'URL des fonctions Cloud Run dans un navigateur n'ajoute pas automatiquement un en-tête d'authentification.

Message d'erreur

Code de réponse d'erreur HTTP : 403 Forbidden

Corps de la réponse d'erreur HTTP:

Error: Forbidden Your client does not have permission
to get URL /FUNCTION_NAME from this server.

Solution

Pour résoudre cette erreur, appliquez l'une des solutions suivantes:

• Attribuez à l'utilisateur le rôle Demandeur de fonctions Cloud Run.

• Redéployez votre fonction pour autoriser les appels non authentifiés si votre organisation le permet. Cela peut être utile à des fins de test.

Erreur d'autorisation de diffusion due à la configuration de allow internal traffic only

Les paramètres d'entrée limitent les appels d'une fonction HTTP par des ressources extérieures à votre projet Google Cloud ou au périmètre de service VPC Service Controls. Lorsque vous configurez le paramètre Autoriser le trafic interne uniquement pour le trafic réseau entrant, ce message d'erreur indique que seules les requêtes provenant des réseaux VPC du même projet ou du même périmètre VPC Service Controls sont autorisées.

Remarque : La consultation de l'URL Cloud Run Functions dans un navigateur n'ajoute pas automatiquement un en-tête d'authentification.

Message d'erreur

Code de réponse d'erreur HTTP: 404 NOT FOUND

Corps de la réponse d'erreur HTTP:

404 Page not found

Solution

Pour résoudre cette erreur, appliquez l'une des solutions suivantes:

• Vous assurer que la requête provient bien de votre projet Google Cloud ou de votre périmètre de service VPC Service Controls

• Modifier les paramètres d'entrée pour autoriser tout le trafic pour la fonction

• Le code source des fonctions Cloud Run peut générer une erreur 404 en raison d'une URL ou de méthodes HTTP incorrectes, ou d'erreurs logiques.

L'appel de fonction ne contient pas d'identifiants d'authentification valides

Les fonctions configurées avec un accès restreint nécessitent un jeton d'ID. L'appel de fonction échoue si vous utilisez des jetons d'accès ou des jetons d'actualisation.

Message d'erreur

Code de réponse d'erreur HTTP : 401 (Non autorisé)

Corps de la réponse d'erreur HTTP:

Your client does not have permission to the requested URL </FUNCTION_NAME>

Solution

Pour résoudre cette erreur, appliquez l'une des solutions suivantes:

• Assurez-vous que vos requêtes incluent un en-tête Authorization: Bearer ID_TOKEN et qu'il s'agit d'un jeton d'ID, et non d'un jeton d'accès ou d'actualisation. Si vous générez ce jeton manuellement avec la clé privée d'un compte de service, vous devez remplacer le jeton JWT autosigné par un jeton d'identité signé par Google. Pour en savoir plus, consultez la page Authentification pour l'appel.

• Appelez votre fonction HTTP à l'aide des identifiants d'authentification dans votre en-tête de requête. Par exemple, vous pouvez obtenir un jeton d'identité à l'aide de gcloud comme suit:

  curl  -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
    https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME

  Pour en savoir plus, consultez la page Authentification pour l'appel .

La fonction s'arrête en cours d'exécution ou continue de s'exécuter une fois votre code terminé

Certains environnements d'exécution Cloud Run Functions permettent aux utilisateurs d'exécuter des tâches asynchrones. Si votre fonction crée des tâches de ce type, elle doit également attendre explicitement que ces tâches se terminent. À défaut, votre fonction peut cesser de s'exécuter au mauvais moment.

Comportement de l'erreur

Votre fonction présente l'un des comportements suivants :

• Votre fonction s'arrête pendant l'exécution des tâches asynchrones, mais avant la fin du délai avant expiration spécifié.
• Votre fonction ne s'arrête pas une fois ces tâches terminées et continue de s'exécuter jusqu'à la fin du délai d'expiration.

Solution

Si votre fonction s'arrête prématurément, vous devez vous assurer que toutes les tâches asynchrones de votre fonction sont terminées avant que votre fonction n'effectue l'une des actions suivantes:

• Renvoi d'une valeur
• Résolution ou refus d'un objet Promise renvoyé (fonctions Node.js uniquement)
• Générer des exceptions et des erreurs non interceptées
• Envoi d'une réponse HTTP
• Appel d'une fonction de rappel

Si votre fonction ne s'arrête pas une fois toutes les tâches asynchrones terminées, vous devez vérifier qu'elle signale correctement Cloud Run Functions une fois l'opération terminée. Veillez en particulier à effectuer l'une des opérations répertoriées dans la liste précédente dès que votre fonction a terminé ses tâches asynchrones.

Erreur d'environnement d'exécution lors de l'accès aux ressources protégées par VPC Service Controls

Par défaut, Cloud Run Functions utilise des adresses IP publiques pour envoyer des requêtes sortantes à d'autres services. Les fonctions qui ne se trouvent pas dans le périmètre VPC Service Controls peuvent recevoir des réponses HTTP 403 lorsqu'elles tentent d'accéder aux services Google Cloud protégés par VPC Service Controls, en raison de refus du périmètre de service.

Message d'erreur

Dans les journaux des ressources auditées, une entrée de ce type se présente comme suit :

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {
    "principalEmail": "CLOUD_FUNCTION_RUNTIME_SERVICE_ACCOUNT",
  ...
  "metadata": {
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
    "securityPolicyInfo": {
      "organizationId": "ORGANIZATION_ID",
      "servicePerimeterName": "accessPolicies/NUMBER/servicePerimeters/SERVICE_PERIMETER_NAME"
  ...

Solution

Pour résoudre cette erreur, appliquez l'une des solutions suivantes:

• La fonction doit acheminer l'intégralité du trafic sortant vers le réseau VPC. Pour en savoir plus, consultez la section Déployer des fonctions conformes aux règles de VPC Service Controls.

• Vous pouvez aussi accorder au compte de service d'exécution de la fonction l'accès au périmètre. Pour ce faire, vous pouvez utiliser au choix l'une des méthodes suivantes : créer un niveau d'accès et ajouter le niveau d'accès au périmètre de service, ou créer une règle d'entrée sur le périmètre. Pour en savoir plus, consultez Utiliser VPC Service Controls avec des fonctions situées en dehors d'un périmètre.

Évolutivité

Cette section répertorie les problèmes de scalabilité et fournit des suggestions pour les résoudre.

Erreurs Cloud Logging liées à l'abandon de requêtes en file d'attente

Les conditions suivantes peuvent être associées à des échecs de scaling.

• Une augmentation soudaine et importante du trafic
• Temps de démarrage à froid long
• Un long temps de traitement des requêtes.
• Un taux d'erreur de la fonction élevé
• Vous avez atteint la limite maximale d'instances.
• Des facteurs temporaires attribuables au service Cloud Run Functions

Dans chacun de ces cas, Cloud Run Functions peut ne pas évoluer assez rapidement pour gérer le trafic.

Message d'erreur

 The request was aborted because there was no available instance.

Les fonctions Cloud Run proposent les niveaux de gravité suivants:

* `severity=WARNING` ( Response code: 429 ) Cloud Run functions cannot scale due
  to the [`max-instances`](/functions/docs/configuring/max-instances) limit you set
  during configuration.
* `severity=ERROR` ( Response code: 500 ) Cloud Run functions intrinsically
  cannot manage the rate of traffic.

Solution

• Pour les fonctions basées sur un déclencheur HTTP, implémentez un intervalle exponentiel entre les tentatives et que les nouvelles tentatives pour les requêtes ne soient pas supprimées. Si vous déclenchez Cloud Run Functions à partir de Workflows, vous pouvez utiliser pour ce faire la syntaxe try/retry.
• Pour les fonctions en arrière-plan ou basées sur des événements, Cloud Run Functions est compatible avec la distribution de type "au moins une fois". Même si vous n'activez pas explicitement les nouvelles tentatives, l'événement est automatiquement redistribué et l'exécution de la fonction est relancée. Pour en savoir plus, consultez la section Activer les nouvelles tentatives d'exécution des fonctions basées sur des événements.
• Lorsque le problème est lié à une période d'augmentation temporaire du nombre d'erreurs attribuables uniquement à Cloud Run Functions, ou si vous avez besoin d'aide pour résoudre votre problème, veuillez contacter l'équipe Cloud Customer Care.

Journalisation

La section suivante décrit les problèmes de journalisation et explique comment les résoudre.

Les entrées de journal n'ont pas de niveaux de gravité des journaux, ou ceux-ci sont incorrects.

Par défaut, Cloud Run Functions inclut la journalisation de l'environnement d'exécution. Les journaux écrits dans stdout ou stderr s'affichent automatiquement dans la console Google Cloud. Par défaut, ces entrées de journal ne contiennent que des messages de chaîne.

Solution

Pour inclure les niveaux de gravité dans les journaux, vous devez plutôt envoyer une entrée de journal structurée.

Remarque :Depuis septembre 2020, chaque environnement d'exécution publié utilise le comportement du niveau de gravité des journaux par défaut, défini par la bibliothèque de l'environnement d'exécution elle-même. Par exemple, Python 3.8 définit le niveau de gravité des journaux par défaut sur WARNING ou un niveau supérieur. Si vous souhaitez capturer des événements correspondant au niveau de gravité DEBUG ou INFO à l'aide de Python 3.8, vous devez également définir de manière automatisée votre niveau de journalisation pour inclure ces niveaux.

Gérer ou consigner les exceptions différemment en cas de plantage

Vous souhaiterez peut-être personnaliser la manière dont vous gérez et consignez les informations sur les plantages.

Solution

Encapsulez votre fonction dans un bloc try pour personnaliser la gestion des exceptions et les traces de la pile de journalisation.

L'ajout d'un bloc try peut entraîner un effet secondaire inattendu dans les fonctions basées sur des événements avec la configuration retry on failure. La répétition d'événements ayant échoué peut elle-même échouer.

Exemple

import logging
import traceback
def try_catch_log(wrapped_func):
  def wrapper(*args, **kwargs):
    try:
      response = wrapped_func(*args, **kwargs)
    except Exception:
      # Replace new lines with spaces so as to prevent several entries which
      # would trigger several errors.
      error_message = traceback.format_exc().replace('\n', '  ')
      logging.error(error_message)
      return 'Error';
    return response;
  return wrapper;

#Example hello world function

@try_catch_log
def python_hello_world(request):
  request_args = request.args

  if request_args and 'name' in request_args:
    1 + 's'
  return 'Hello World!'

Journaux trop volumineux dans Node.js 10 et versions ultérieures, Python 3.8, Go 1.13 et Java 11

La taille maximale d'une entrée de journal standard dans ces environnements d'exécution est de 105 Kio.

Solution

Envoyez des entrées de journal qui ne dépassent pas cette limite

Journaux manquants alors que les fonctions Cloud Run renvoient des erreurs

Cloud Run Functions diffuse les journaux de Cloud Run Functions vers un bucket par défaut. Lorsque vous créez un projet, Cloud Run Functions crée et active le bucket par défaut. Si le bucket par défaut est désactivé ou si les journaux de la fonction Cloud Run se trouvent dans le filtre d'exclusion, les journaux n'apparaissent pas dans l'Explorateur de journaux.

Solution

Activez les journaux par défaut et assurez-vous qu'aucun filtre d'exclusion n'est défini.

Remarque : L'activation de Cloud Logging peut entraîner des frais.

Les journaux de Cloud Run Functions n'apparaissent pas dans l'Explorateur de journaux

Certaines bibliothèques clientes Cloud Logging utilisent un processus asynchrone pour écrire des entrées de journal. Si une fonction plante ou s'arrête, il est possible que certaines entrées de journal n'aient pas encore été écrites et qu'elles apparaissent ultérieurement. Il est également possible que certains journaux soient perdus et ne soient pas visibles dans l'explorateur de journaux.

Solution

Utilisez l'interface de bibliothèque cliente pour vider les entrées de journal mises en mémoire tampon avant de quitter la fonction ou utilisez la bibliothèque pour écrire des entrées de journal de manière synchrone. Vous pouvez également écrire des journaux de manière synchrone directement dans stdout ou stderr.

Les journaux des fonctions Cloud Run n'apparaissent pas avec le récepteur du routeur de journaux

Les récepteurs du routeur de journaux acheminent les entrées de journal vers différentes destinations.

Les paramètres incluent les filtres d'exclusion, qui définissent les entrées qui peuvent simplement être supprimées.

Solution

Supprimez le filtre d'exclusion défini pour resource.type="cloud_functions".

Connexions à la base de données

De nombreuses erreurs de base de données sont associées au dépassement des limites de connexion ou à l'expiration du délai. Si un avertissement Cloud SQL s'affiche dans vos journaux (par exemple, Context deadline exceeded), vous devrez peut-être ajuster votre configuration de connexion. Pour en savoir plus, consultez les bonnes pratiques Cloud SQL.

Mise en réseau

Cette section répertorie les problèmes de réseau et fournit des suggestions pour les résoudre.

Connectivité réseau

Si toutes les requêtes sortantes d'une fonction Cloud Run échouent même après la configuration des paramètres de sortie, vous pouvez exécuter le module Tests de connectivité pour identifier les problèmes de connectivité réseau sous-jacents. Pour plus d'informations, consultez la page Créer et exécuter des tests de connectivité.

Le connecteur d'accès au VPC sans serveur n'est pas prêt ou n'existe pas.

Si un connecteur d'accès au VPC sans serveur échoue, il risque de ne pas utiliser un masque de sous-réseau /28 dédié au connecteur, comme requis.

Message d'erreur

VPC connector projects/xxxxx/locations/REGION/connectors/xxxx
is not ready yet or does not exist.

Lorsque les fonctions Cloud Run sont déployées avec un connecteur dont l'état est incorrect en raison d'une autorisation manquante sur le compte de service de l'agent de service des API Google [e-mail], l'erreur suivante s'affiche :

Message d'erreur

Failed to prepare VPC connector. Please try again later.

Solution

Listez vos sous-réseaux pour vérifier si votre connecteur utilise un masque de sous-réseau /28. Si votre connecteur n'utilise pas le masque de sous-réseau /28, recréez ou créez un connecteur.

Pour résoudre ce problème, appliquez l'une des solutions suivantes:

• Si vous recréez le connecteur, vous n'avez pas besoin de redéployer les autres fonctions. Vous risquez de subir une interruption du réseau lors de la recréation du connecteur.

• Si vous créez un autre connecteur, redéployez vos fonctions pour qu'elles utilisent le nouveau connecteur, puis supprimez le connecteur d'origine. Cette méthode évite toute interruption du réseau.

• Assurez-vous que Cloud Run Functions et le connecteur associé sont déployés dans la même région.

• Pour la configuration du VPC partagé :

  • Assurez-vous que les autorisations des comptes de service [e-mail] et [e-mail] utilisés par le connecteur VPC pour provisionner des ressources dans le projet ne sont pas manquantes. Ces comptes de service doivent disposer du rôle roles/compute.networkUser dans le projet hôte de la configuration VPC partagé lorsque le connecteur se trouve dans le projet de service. Sinon, roles/compute.networkAdmin est obligatoire.

  • Si le connecteur est créé dans le projet hôte, assurez-vous que le rôle Serverless VPC Access User est accordé à Cloud Run functions Service Agent dans votre projet hôte.

  • Si l'état du connecteur indique l'erreur Connector is in a bad state, manual deletion recommended et que l'agent de service des API Google ne dispose pas des autorisations requises pour provisionner des ressources de calcul dans le projet du connecteur, accordez roles/compute.admin au compte de service [e-mail]. Dans certains cas, vous devrez peut-être recréer le connecteur après avoir mis à jour les autorisations.

Le trafic SMTP vers des adresses IP de destination externes via le port TCP 25 est bloqué

Pour plus de sécurité, Google Cloud bloque les connexions au port de destination TCP 25 lors de l'envoi d'e-mails à partir de fonctions Cloud Run.

Solution

Pour débloquer ces connexions, choisissez l'une des options suivantes :

• Connectez-vous à votre serveur SMTP sur un autre port, tel que le port 587 ou 465.

• Utiliser un service de messagerie tiers

Autre

Cette section décrit les problèmes supplémentaires qui ne correspondent à aucune autre catégorie et propose des solutions pour chacun d'eux.

Erreur VPC Service Controls sur la méthode google.storage.buckets.testIamPermissions dans Cloud Audit Logs

Lorsque vous ouvrez la page Informations sur la fonction dans la console Google Cloud, les fonctions Cloud Run vérifient si vous pouvez modifier le dépôt de stockage de l'image du conteneur et y accéder publiquement. Pour vérifier, les fonctions Cloud Run envoient une requête au bucket Container Registry à l'aide de la méthode google.storage.buckets.testIamPermissions avec le format suivant : [REGION].artifacts.[PROJECT_ID].appspot.com. La seule différence entre les vérifications est que l'une s'exécute avec authentification pour vérifier les autorisations des utilisateurs de modifier le bucket, tandis que l'autre s'exécute sans authentification pour vérifier si le bucket est accessible au public.

Si le périmètre VPC Service Controls limite l'API storage.googleapis.com, la console Google Cloud affiche une erreur sur la méthode google.storage.buckets.testIamPermissions dans Cloud Audit Logs.

Message d'erreur

Pour la vérification de l'accès public sans informations d'authentification, les journaux d'audit de la règle de refus de VPC SC affichent une entrée semblable à celle-ci:

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {},
  "requestMetadata": {
    "callerIp": "END_USER_IP"
  },
  "serviceName": "storage.googleapis.com",
  "methodName": "google.storage.buckets.testIamPermissions",
  "resourceName": "projects/PROJECT_NUMBER",
  "metadata": {
    "ingressViolations": [
      {
        "servicePerimeter": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
        "targetResource": "projects/PROJECT_NUMBER"
      }
    ],
    "resourceNames": [
      "projects/_/buckets/REGION.artifacts.PROJECT_ID.appspot.com"
    ],
    "securityPolicyInfo": {
      "servicePerimeterName": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
      "organizationId": "ORG_ID"
    },
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
  ...

Pour la vérification de l'accès public avec des informations d'authentification, les journaux d'audit de la règle de refus VPC SC affichent une entrée permettant à l'utilisateur de modifier les paramètres du bucket, comme dans l'exemple suivant:

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {
    "principalEmail": "END_USER_EMAIL"
  },
  "requestMetadata": {
    "callerIp": "END_USER_IP",
    "requestAttributes": {},
    "destinationAttributes": {}
  },
  "serviceName": "storage.googleapis.com",
  "methodName": "google.storage.buckets.testIamPermissions",
  "resourceName": "projects/PROJECT_NUMBER",
  "metadata": {
    "ingressViolations": [
      {
        "servicePerimeter": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
        "targetResource": "projects/PROJECT_NUMBER"
      }
    ],
    "resourceNames": [
      "projects/_/buckets/REGION.artifacts.PROJECT_ID.appspot.com"
    ],
    "securityPolicyInfo": {
      "servicePerimeterName": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
      "organizationId": "ORG_ID"
    },
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
  ...

Solution

Si le bucket Container Registry n'est pas accessible au public, vous pouvez ignorer les erreurs VPC Service Controls.

Vous pouvez également ajouter une règle d'entrée VPC Service Controls pour autoriser la méthode google.storage.buckets.testIamPermissions, comme illustré dans l'exemple suivant:

ingress_from {
  sources {
    access_level: "*"
  }
  identity_type: ANY_IDENTITY
}
ingress_to {
  operations {
    service_name: "storage.googleapis.com"
    method_selectors {
      method: "google.storage.buckets.testIamPermissions"
    }
  }
  resources: "projects/PROJECT_NUMBER"
}

Dans la mesure du possible, vous pouvez affiner davantage la règle d'entrée en définissant le niveau d'accès avec les adresses IP des utilisateurs.