Appeler des fonctions Cloud Run ou Cloud Run

Les appels d'un service Google Cloud tels que les fonctions Cloud Run ou Cloud Run à partir de Workflows sont effectués via une requête HTTP. Les méthodes de requête HTTP les plus courantes disposent d'un raccourci d'appel (tel que http.get et http.post), mais vous pouvez effectuer tous types de requête HTTP en définissant le champ call sur http.request et en spécifiant le type de requête à l'aide du champ method. Pour en savoir plus, consultez la page Envoyer une requête HTTP.

Pour envoyer des requêtes authentifiées, procédez comme suit:

  • Votre workflow doit être associé à un compte de service disposant d'un ou de plusieurs rôles IAM (Identity and Access Management) contenant les autorisations requises.

  • Vous devez explicitement ajouter des informations d'authentification à votre définition de workflow. Par défaut, les requêtes HTTP ne contiennent pas de jetons d'identité ou d'accès pour des raisons de sécurité.

Pour en savoir plus, consultez la section Accorder à un workflow l'accès aux ressources Google Cloud.

Quand appeler un service

Comment savoir quand créer des étapes en YAML ou en JSON à l'aide de la syntaxe des workflows ou quand créer un service (par exemple, un service Cloud Run ou une fonction Cloud Run) pour effectuer la tâche à la place ?

Utilisez des workflows pour appeler des services à partir du workflow lui-même et gérer les résultats, et pour exécuter des tâches simples comme effectuer un appel HTTP. Les workflows peuvent appeler des services, analyser des réponses et créer des entrées pour d'autres services connectés. Appeler un service vous permet d'éviter les complications liées aux invocations supplémentaires, aux dépendances supplémentaires et aux services appelant des services.

Créez des services pour effectuer toute tâche trop complexe pour Workflows, par exemple en implémentant une logique métier réutilisable, des calculs complexes ou des transformations non compatibles avec les expressions Workflows et sa bibliothèque standard. Un cas complexe est généralement plus facile à implémenter en code qu'en utilisant YAML ou JSON et la syntaxe des workflows.

Appeler des services limités à l'entrée interne

Les workflows peuvent appeler des fonctions ou des services Cloud Run dans le même projet Google Cloud dont l'entrée est limitée au trafic interne. Avec cette configuration, vos services sont inaccessibles depuis Internet, mais peuvent être accessibles à partir de Workflows.

Pour appliquer ces restrictions, vous devez ajuster les paramètres d'entrée de votre service ou fonction. Notez que le service Cloud Run doit être accessible via son URL run.app et non via un domaine personnalisé. Pour en savoir plus, consultez les sections Restreindre le trafic entrant (pour Cloud Run) et Configurer les paramètres réseau (pour les fonctions Cloud Run). Aucune autre modification n'est nécessaire dans votre workflow.

Créez un compte de service doté des autorisations requises.

Lorsque vous envoyez des requêtes à d'autres services Google Cloud, votre workflow doit être associé à un compte de service disposant des autorisations appropriées pour accéder aux ressources demandées. Pour savoir quel compte de service est associé à un workflow existant, consultez la page Vérifier le compte de service associé d'un workflow.

Lors de la configuration d'un compte de service, vous associez l'identité à l'origine de la requête à la ressource à laquelle vous souhaitez lui accorder l'accès. Vous choisissez comme identité principale de la ressource à l'origine de la requête, puis vous l'attribuez. le rôle approprié. Le rôle définit les autorisations dont dispose l'identité dans le contexte de la ressource.

Par exemple, pour configurer une fonction Cloud Run de réception afin d'accepter les requêtes d'un service ou d'une fonction d'appel spécifique, vous devez ajouter le compte de service de l'appelant en tant que compte principal sur la fonction de réception et accorder à ce compte principal le rôle de demandeur Cloud Run (roles/cloudfunctions.invoker). De même, pour configurer un compte de service pour Cloud Run, vous devez lui attribuer le rôle Demandeur Cloud Run (roles/run.invoker). Pour en savoir plus, consultez les informations sur l'authentification pour les fonctions Cloud Run ou la présentation de l'authentification Cloud Run.

Appeler des fonctions Cloud Run (2e génération)

Dans les fonctions Cloud Run (2e génération), les autorisations d'appel sont disponibles en gérant le service Cloud Run sous-jacent. Si votre workflow appelle un service de fonction Cloud Run (2e génération), vous n'avez pas besoin d'accorder au compte de service de l'appelant le rôle Demandeur de fonctions Cloud Run (roles/cloudfunctions.invoker). Vous devez plutôt attribuer le rôle Demandeur Cloud Run (roles/run.invoker).

Pour en savoir plus, consultez la page Comparaison des versions Cloud Run Functions.

Ajoutez des informations d'authentification à votre workflow

Lorsque vous envoyez des requêtes à des fonctions Cloud Run ou à Cloud Run, utilisez OIDC pour l'authentification.

Pour effectuer une requête HTTP à l'aide d'OIDC, ajoutez une section auth à la section args de la définition de votre workflow, après avoir spécifié l'URL. Dans cet exemple, une requête est envoyée pour appeler une fonction Cloud Run:

YAML

  - step_A:
      call: http.get
      args:
          url: https://us-central1-project.cloudfunctions.net/functionA
          query:
              firstNumber: 4
              secondNumber: 6
              operation: sum
          auth:
              type: OIDC
              audience: OIDC_AUDIENCE

JSON

    [
      {
        "step_A": {
          "call": "http.get",
          "args": {
            "url": "https://us-central1-project.cloudfunctions.net/functionA",
            "query": {
              "firstNumber": 4,
              "secondNumber": 6,
              "operation": "sum"
            },
            "auth": {
              "type": "OIDC",
              "audience": "OIDC_AUDIENCE"
            }
          }
        }
      }
    ]
Le paramètre audience peut être utilisé pour spécifier l'audience OIDC du jeton. Par défaut, cette valeur est définie sur la même valeur que url. Cependant, elle doit être définie sur l'URL racine de votre service. Par exemple : https://region-project.cloudfunctions.net/hello_world.

Spécifier le type de support pour les données de réponse

Si l'en-tête Content-Type de la réponse spécifie un type de média application/json, la réponse JSON stockée dans une variable est automatiquement convertie en une carte accessible.

Si nécessaire, modifiez l'API appelée pour spécifier un type de contenu application/json pour l'en-tête de réponse Content-Type. Sinon, vous pouvez utiliser les fonctions json.decode et text.encode pour convertir le corps de la réponse en mappage. Exemple :

json.decode(text.encode(RESPONSE_FROM_API))

Pour en savoir plus, consultez la section Accéder aux données de réponse HTTP enregistrées dans une variable.

Exécuter des tâches Cloud Run

Contrairement aux services Cloud Run, les jobs Cloud Run n'écoutent pas de requêtes HTTP, ni ne les diffusent. Pour exécuter des jobs Cloud Run à partir d'un workflow, utilisez le connecteur de l'API Cloud Run Admin.

Pour obtenir un exemple de bout en bout d'exécution d'un job Cloud Run qui traite les données transmises en tant que variables d'environnement au job, consultez la page Exécuter un job Cloud Run à l'aide de Workflows.

Pour obtenir un exemple de bout en bout de l'exécution d'un job Cloud Run qui traite les données stockées dans un bucket Cloud Storage vous permettant de chiffrer les données à l'aide de clés de chiffrement gérées par le client (CMEK), consultez la page Exécuter un job Cloud Run qui traite les données d'événement dans Cloud Storage.

Étape suivante