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

Appeler des fonctions Cloud Run ou Cloud Run

Appeler ou appeler un service Google Cloud tel que des fonctions Cloud Run ou Cloud Run à partir de Workflows se fait via une connexion HTTP requête. 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 Autoriser un workflow à accéder aux ressources Google Cloud

Quand appeler un service

Comment savoir quand créer des étapes au format YAML ou JSON à l'aide de Workflows ? ou quand créer un service, par exemple un service Cloud Run ou une fonction Cloud Run, pour qu'elle s'en charge ?

Utiliser Workflows pour appeler des services à partir du workflow lui-même et gérer les résultats et exécuter des tâches simples comme un appel HTTP. Les workflows peuvent appeler des services, analyser des réponses et construire pour d'autres services connectés. Appeler un service vous permet d'éviter complications d'appels supplémentaires, de dépendances supplémentaires, et de services services d'appel.

Créer des services pour effectuer des tâches trop complexes pour Workflows (par exemple, implémenter une logique métier réutilisable, effectuer des calculs complexes ou les transformations non compatibles avec les expressions Workflows et ses bibliothèque standard. Un cas compliqué est généralement plus facile à implémenter dans le code, au lieu d'utiliser YAML ou JSON et la syntaxe 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, 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 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 qu'elle accepte provenant d'une fonction ou d'un service d'appel spécifique, vous devez ajouter compte de service de l'appelant en tant que compte principal sur la fonction de réception le demandeur de fonctions Cloud Run (roles/cloudfunctions.invoker) rôle de ressource. 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 au service Cloud Run sous-jacent. Si votre workflow appelle un de la fonction Cloud Run (2e génération), il n'est pas nécessaire d'accorder compte de service de l'appelant, 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 de 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, 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 le type de contenu application/json, la réponse JSON stockée dans un est automatiquement convertie en 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 tâches Cloud Run n'écoutent pas pour traiter les requêtes HTTP. Pour exécuter des jobs Cloud Run à partir d'un workflow, utilisez la Connecteur de l'API Admin Cloud Run.

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 d'exécution d'un job Cloud Run traite les données stockées dans un bucket Cloud Storage, ce qui vous permet à l'aide de clés de chiffrement gérées par le client (CMEK), Exécuter une tâche Cloud Run qui traite les données d'événement dans Cloud Storage