Appeler des fonctions Cloud Functions ou Cloud Run

Les appels d'un service Google Cloud tels que Cloud Functions 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 Accorder à un workflow l'autorisation d'accéder aux ressources Google Cloud.

Quand appeler un service

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

Utilisez Workflows pour appeler des services à partir du workflow lui-même et gérer les résultats, ainsi que pour exécuter des tâches simples telles qu'un appel HTTP. Les workflows peuvent appeler des services, analyser des réponses et construire des entrées pour d'autres services connectés. L'appel d'un service vous permet d'éviter les complications liées à des appels supplémentaires, à des dépendances supplémentaires et à des services appelant des services.

Créer des services permettant d'effectuer des tâches trop complexes pour Workflows (par exemple, implémenter une logique métier réutilisable, des calculs complexes ou des transformations non compatibles avec les expressions de Workflows et sa bibliothèque standard) Les cas complexes sont généralement plus faciles à implémenter dans le code que d'utiliser YAML ou JSON et la syntaxe Workflows.

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

Les workflows peuvent appeler des services Cloud Functions ou 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 sont 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 pages Restreindre l'entrée (pour Cloud Run) et Configurer les paramètres réseau (pour Cloud Functions). 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 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 Functions (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 Cloud Functions ou la présentation de l'authentification Cloud Run.

Appeler Cloud Functions (2nd gen)

Dans Cloud Functions (2nd gen), les autorisations d'appel sont disponibles via la gestion du service Cloud Run sous-jacent. Si votre workflow appelle un service Cloud Functions (2e génération), vous n'avez pas besoin d'attribuer le rôle Demandeur Cloud Functions (roles/cloudfunctions.invoker) au compte de service de l'appelant. À la place, vous devez attribuer le rôle Demandeur Cloud Run (roles/run.invoker).

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

Ajoutez des informations d'authentification à votre workflow

Lorsque vous envoyez des requêtes à Cloud Functions ou à Cloud Run, vous pouvez vous authentifier à l'aide d'OIDC.

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:

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 contenu 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 afin de spécifier un type de média 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 carte. 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 jobs Cloud Run

Contrairement aux services Cloud Run, les tâches Cloud Run n'écoutent pas et ne diffusent pas de requêtes HTTP. Pour exécuter des tâches 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 complet d'exécution d'une tâche Cloud Run qui traite les données stockées dans un bucket Cloud Storage, ce qui vous permet de les chiffrer à l'aide de clés de chiffrement gérées par le client (CMEK), consultez la page Exécuter une tâche Cloud Run qui traite les données d'événement dans Cloud Storage.