L'appel d'un service Google Cloud tel que Cloud Run Functions ou Cloud Run à partir de Workflows s'effectue 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 n'importe quel type 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 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é ni 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 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 Run) pour effectuer le travail à la place ?
Utilisez Workflows pour appeler des services à partir du workflow lui-même, gérer les résultats et exécuter des tâches simples, comme effectuer un appel HTTP. Workflows peut appeler des services, analyser des réponses et créer des entrées pour d'autres services connectés. L'appel d'un service vous permet d'éviter les complications liées aux appels supplémentaires, aux dépendances supplémentaires et aux services qui appellent des services.
Créez des services pour effectuer des tâches trop complexes pour Workflows, par exemple pour implémenter 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 dans le code, plutôt qu'en utilisant YAML ou JSON et la syntaxe Workflows.
Délai avant expiration de la requête et limites de charge utile
Lorsque vous appelez un service Cloud Run ou une fonction Cloud Run via HTTP, n'oubliez pas que les requêtes HTTP synchrones (http.get, http.post, http.request) dans Workflows expirent par défaut au bout de cinq minutes (300 secondes), acceptent un délai avant expiration maximal de 30 minutes (1 800 secondes) et autorisent une taille de réponse maximale de 2 Mo (sous réserve de la limite de mémoire variable de 512 Ko si elles sont stockées dans des variables).
Bien que les services Cloud Run et les fonctions Cloud Run (2e génération) acceptent des délais avant expiration des requêtes allant jusqu'à 60 minutes, toute étape http.* synchrone dans Workflows expire avec une erreur TimeoutError après le délai avant expiration configuré (jusqu'à 30 minutes). Pour les charges de travail qui s'exécutent pendant plus de 30 minutes ou qui renvoient des charges utiles volumineuses, utilisez des jobs Cloud Run ou des points de terminaison de rappel. Pour comparer les limites et les modèles recommandés, consultez Aligner les délais avant expiration et les tailles de charge utile entre les services.
Appeler des services limités à l'entrée interne
Workflows peut appeler des fonctions Cloud Run ou des services Cloud Run dans le même projet Google Cloud ou périmètre VPC Service Controls dont l'entrée est limitée au trafic interne. Avec cette configuration, vos services sont inaccessibles depuis Internet, mais sont accessibles depuis Workflows.
Pour appliquer ces restrictions, vous devez ajuster les paramètres d'entrée de votre service ou de votre 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 Restreindre l'entrée réseau (pour Cloud Run et Cloud Run Functions 2e génération) et Configurer les paramètres réseau (1re génération) (pour Cloud Run Functions 1re génération). 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 Vérifier le compte de service associé à un workflow.
Lorsque vous configurez un compte de service, vous associez l'identité à l'origine de la requête à la ressource à laquelle vous souhaitez lui donner accès (vous faites de l'identité à l'origine de la requête un compte principal de la ressource), puis vous lui 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 (1re génération) de réception afin qu'elle accepte les requêtes d'une fonction ou d'un service 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 lui attribuer le rôle Demandeur Cloud Functions (roles/cloudfunctions.invoker). De même, pour configurer un compte de service pour les services Cloud Run ou Cloud Run Functions (2e génération), vous devez lui attribuer le rôle de demandeur Cloud Run (roles/run.invoker). Pour en savoir plus, consultez Contrôle des accès avec IAM ou la présentation de l'authentification Cloud Run.
Appeler Cloud Run Functions
Dans Cloud Run Functions, les autorisations d'appel sont disponibles en gérant le service Cloud Run sous-jacent. Si votre workflow appelle un service Cloud Run Functions, vous n'avez pas besoin d'accorder au compte de service de l'appelant le rôle IAM Demandeur Cloud Functions (roles/cloudfunctions.invoker). À la place, vous devez attribuer le rôle IAM Demandeur Cloud Run (roles/run.invoker).
Pour en savoir plus, consultez Comparer les fonctions Cloud Run.
Ajoutez des informations d'authentification à votre workflow
Lorsque vous envoyez des requêtes à Cloud Run Functions 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" } } } } ]
audience spécifie l'audience OIDC (OIDC_AUDIENCE) du jeton. Par défaut, elle est définie sur la même valeur que url. Toutefois, si url inclut des segments de chemin d'accès supplémentaires au-delà de l'URL racine du service ou de la fonction, définissez audience sur l'URL racine (par exemple, https://us-central1-project.cloudfunctions.net/functionA).
Spécifiez le type de média 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 mappage accessible.
Si nécessaire, modifiez l'API appelée pour 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 mappage. Exemple :
json.decode(text.encode(RESPONSE_FROM_API))
Pour en savoir plus, consultez 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 jobs Cloud Run n'écoutent pas les requêtes HTTP et ne les diffusent pas. Pour exécuter des jobs Cloud Run à partir d'un workflow, utilisez le connecteur de l'API Cloud Run Admin.
Si l'exécution d'un job prend plus de 30 minutes, configurez à la fois le délai avant expiration de la tâche du job (10 minutes par défaut, configurable jusqu'à 168 heures ou 7 jours) et connector_params.timeout dans l'appel du connecteur (qui est défini par défaut sur 1 800 secondes et peut être configuré jusqu'à 31 536 000 secondes, soit 1 an).
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.