La chiamata o l'invocazione di un servizio Google Cloud come Cloud Run Functions o Cloud Run da Workflows viene eseguita tramite una richiesta HTTP. I metodi di richiesta HTTP più comuni hanno una scorciatoia di chiamata (ad esempio http.get e http.post), ma puoi effettuare qualsiasi tipo di richiesta HTTP impostando il campo call su http.request e specificando il tipo di richiesta utilizzando il campo method. Per saperne di più, consulta Effettua una richiesta HTTP.
Per inviare richieste autenticate:
Il workflow deve essere associato a un account di servizio a cui sono stati concessi uno o più ruoli Identity and Access Management (IAM) contenenti le autorizzazioni richieste.
Devi aggiungere esplicitamente le informazioni di autenticazione alla definizione del workflow. Per impostazione predefinita, le richieste HTTP non contengono token di identità o di accesso per motivi di sicurezza.
Per saperne di più, consulta Concedi l'autorizzazione dei workflow per l'accesso alle risorse Google Cloud .
Quando chiamare un servizio
Come fai a sapere quando creare passaggi in YAML o JSON utilizzando la sintassi di Workflows o quando creare un servizio, ad esempio un servizio Cloud Run o una funzione Cloud Run, per eseguire il lavoro?
Utilizza Workflows per chiamare i servizi dal workflow stesso e gestire i risultati, nonché per eseguire attività semplici come effettuare una chiamata HTTP. Workflows possono richiamare servizi, analizzare risposte e creare input per altri servizi connessi. La chiamata di un servizio ti consente di evitare le complicazioni di chiamate aggiuntive, dipendenze aggiuntive e servizi che chiamano servizi.
Crea servizi per eseguire qualsiasi lavoro troppo complesso per Workflows, ad esempio l'implementazione di logica di business riutilizzabile, calcoli complessi o trasformazioni non supportate dalle espressioni di Workflows e dalla relativa libreria standard. In genere, un caso complicato è più facile da implementare nel codice, anziché utilizzare YAML o JSON e la sintassi di Workflows.
Timeout della richiesta e limiti del payload
Quando chiami un servizio Cloud Run o una funzione Cloud Run tramite HTTP, ricorda che le richieste HTTP sincrone (http.get, http.post, http.request) in Workflows hanno un timeout predefinito di 5 minuti (300 secondi), supportano un timeout massimo di 30 minuti (1800 secondi) e consentono una dimensione massima della risposta di 2 MB (soggetta al limite di memoria delle variabili di 512 kB se archiviata in variabili).
Sebbene i servizi Cloud Run e Cloud Run Functions (2ª generazione.) supportino timeout delle richieste fino a 60 minuti, qualsiasi passaggio sincrono di http.* in Workflows scade con un TimeoutError dopo il timeout configurato (fino a 30 minuti). Per i workload in esecuzione per più di 30 minuti o che restituiscono payload di grandi dimensioni, utilizza i job Cloud Run o gli endpoint di callback. Per un confronto dei limiti e dei pattern consigliati, consulta Allinea i timeout e le dimensioni dei payload tra i servizi.
Richiama i servizi limitati al traffico in entrata interno
Workflows può richiamare Cloud Run Functions o servizi Cloud Run nello stesso progetto Google Cloud o perimetro dei Controlli di servizio VPC con traffico in entrata limitato al traffico interno. Con questa configurazione, i tuoi servizi non sono raggiungibili da internet, ma possono essere raggiunti da Workflows.
Per applicare queste limitazioni, devi modificare le impostazioni del traffico in entrata del servizio o della funzione. Tieni presente che il servizio Cloud Run deve essere raggiunto tramite il relativo URL run.app e non tramite un dominio personalizzato. Per saperne di più, consulta Limita il traffico di rete in entrata (per Cloud Run e Cloud Run Functions 2ª generazione.) e Configura le impostazioni della rete (1ª generazione.) (per Cloud Run Functions 1ª generazione.). Non sono necessarie altre modifiche al tuo workflow.
Utilizza un account di servizio con le autorizzazioni richieste
Quando effettua richieste ad altri servizi Google Cloud , il workflow deve essere associato a un account di servizio con le autorizzazioni corrette per accedere alle risorse richieste. Per scoprire quale account di servizio è associato a un workflow esistente, consulta Verifica il service account associato a un workflow.
Quando configuri un account di servizio, associ l'identità richiedente alla risorsa a cui vuoi concedere l'accesso, rendendo l'identità richiedente un principal della risorsa, quindi le assegni il ruolo appropriato. Il ruolo definisce le autorizzazioni di cui dispone l'identità nel contesto della risorsa.
Ad esempio, per configurare una funzione Cloud Run (1ª gen.) ricevente in modo che accetti richieste da una funzione o un servizio chiamante specifico, devi aggiungere il account di servizio del chiamante come entità nella funzione ricevente e concedere a questa entità il ruolo Invoker di Cloud Functions (roles/cloudfunctions.invoker). Analogamente, per configurare un account di servizio per i servizi Cloud Run o Cloud Run Functions (2ª generazione.), concedi a quel account di servizio il ruolo Cloud Run Invoker (roles/run.invoker). Per saperne di più, consulta Controllo dell'accesso con IAM o la panoramica dell'autenticazione di Cloud Run.
Richiama Cloud Run Functions
In Cloud Run Functions, le autorizzazioni di chiamata sono disponibili gestendo il servizio Cloud Run sottostante. Se il tuo workflow richiama un servizio Cloud Run Functions, non è necessario concedere al account di servizio del chiamante il ruolo IAM Cloud Functions Invoker (roles/cloudfunctions.invoker). Devi invece concedere il ruolo IAM Cloud Run Invoker (roles/run.invoker).
Per saperne di più, consulta Confronta le versioni di Cloud Run Functions.
Aggiungi informazioni di autenticazione al workflow
Quando effettui richieste a Cloud Run Functions o Cloud Run, utilizza OIDC per l'autenticazione.
Per effettuare una richiesta HTTP utilizzando OIDC, aggiungi una sezione auth alla sezione args della definizione del workflow, dopo aver specificato l'URL. In questo esempio, viene inviata una richiesta per richiamare una funzione 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 specifica il pubblico OIDC (OIDC_AUDIENCE) per il token. Per impostazione predefinita, è impostato sullo stesso valore di url; tuttavia, se url include segmenti di percorso aggiuntivi oltre all'URL di base del servizio o della funzione, imposta audience sull'URL di base (ad esempio, https://us-central1-project.cloudfunctions.net/functionA).
Specifica il tipo di media per i dati della risposta
Se l'intestazione Content-Type della risposta specifica un tipo di media application/json, la risposta JSON archiviata in una variabile viene convertita automaticamente in una mappa a cui è possibile accedere.
Se necessario, modifica l'API chiamata per specificare un tipo di media application/json per l'intestazione della risposta Content-Type. In caso contrario, puoi utilizzare le funzioni json.decode e text.encode per convertire il corpo della risposta in una mappa. Ad esempio:
json.decode(text.encode(RESPONSE_FROM_API))
Per saperne di più, consulta Accedi ai dati della risposta HTTP salvati in una variabile.
Esegui job Cloud Run
A differenza dei servizi Cloud Run, i job Cloud Run non ascoltano né gestiscono le richieste HTTP. Per eseguire i job Cloud Run da un workflow, utilizza il connettore API Cloud Run Admin.
Se un job richiede più di 30 minuti per essere completato, configura sia il timeout dell'attività del job (10 minuti per impostazione predefinita, configurabile fino a 168 ore o 7 giorni) sia connector_params.timeout nella chiamata del connettore (che per impostazione predefinita è di 1800 secondi e può essere impostato fino a 31.536.000 secondi o 1 anno).
Per un esempio end-to-end di esecuzione di un job Cloud Run che elabora i dati passati come variabili di ambiente al job, consulta Esegui un job Cloud Run utilizzando Workflows.
Per un esempio end-to-end di esecuzione di un job Cloud Run che elabora i dati archiviati in un bucket Cloud Storage, consentendoti di criptare i dati utilizzando chiavi di crittografia gestite dal cliente (CMEK), consulta Esegui un job Cloud Run che elabora i dati sugli eventi in Cloud Storage.