O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Invocar funções do Cloud Run ou o Cloud Run

A chamada ou invocação de um serviço do Google Cloud , como o Cloud Run functions ou o Cloud Run, no Workflows é feita por uma solicitação HTTP. Os métodos de solicitação HTTP mais comuns têm um atalho de chamada (como http.get e http.post), mas é possível fazer qualquer tipo de solicitação HTTP definindo o campo call como http.request e especificando o tipo de solicitação usando o campo method. Para mais informações, consulte Fazer uma solicitação HTTP.

Para enviar solicitações autenticadas:

O fluxo de trabalho precisa estar associado a uma conta de serviço que tenha recebido um ou mais papéis do Identity and Access Management (IAM) com as permissões necessárias.
É necessário adicionar as informações de autenticação à definição do fluxo de trabalho explicitamente. Por padrão, as solicitações HTTP não contêm tokens de identidade ou de acesso por motivos de segurança.

Para mais informações, consulte Conceder permissão a um fluxo de trabalho para acessar recursos do Google Cloud .

Quando chamar um serviço

Como saber quando criar etapas em YAML ou JSON usando a sintaxe do Workflows ou quando criar um serviço, como um serviço do Cloud Run ou uma função do Cloud Run, para fazer o trabalho?

Use o Workflows para chamar serviços do próprio fluxo de trabalho e processar os resultados, além de executar tarefas simples, como fazer uma chamada HTTP. O Workflows pode invocar serviços, analisar respostas e criar entradas para outros serviços conectados. Chamar um serviço permite evitar as complicações de invocações extras, dependências adicionais e serviços que chamam serviços.

Crie serviços para realizar qualquer trabalho que seja muito complexo para o Workflows. Por exemplo, implementar lógica de negócios reutilizável, computações complexas ou transformações que não são compatíveis com as expressões do Workflows e a biblioteca padrão. Um caso complicado geralmente é mais fácil de implementar no código, em vez de usar YAML ou JSON e a sintaxe do Workflows.

Tempo limite de solicitação e limites de payload

Ao chamar um serviço do Cloud Run ou uma função do Cloud Run por HTTP, lembre-se de que as solicitações HTTP síncronas (http.get, http.post, http.request) no Workflows têm um tempo limite padrão de 5 minutos (300 segundos), um tempo limite máximo de 30 minutos (1.800 segundos) e um tamanho máximo de resposta de 2 MB (sujeito ao limite de memória variável de 512 KB se armazenado em variáveis).

Embora os serviços do Cloud Run e o Cloud Run functions (2ª geração) aceitem tempos limite de solicitação de até 60 minutos, qualquer etapa síncrona http.* no Workflows expira com um TimeoutError após o tempo limite configurado (até 30 minutos). Para cargas de trabalho que levam mais de 30 minutos ou retornam payloads grandes, use jobs do Cloud Run ou endpoints de callback. Para uma comparação de limites e padrões recomendados, consulte Alinhar tempos limite e tamanhos de payload entre serviços.

Invocar serviços que são restritos à entrada interna

Workflows podem invocar funções do Cloud Run ou serviços do Cloud Run no mesmo projeto do Google Cloud ou perímetro do VPC Service Controls que têm entrada restrita ao tráfego interno. Com essa configuração, seus serviços não podem ser acessados pela Internet, mas podem ser acessados pelo Workflows.

Para aplicar essas restrições, ajuste as configurações de entrada do serviço ou da função. O serviço do Cloud Run precisa ser acessado no URL run.app, e não em um domínio personalizado. Para mais informações, consulte Restringir a entrada de rede (para o Cloud Run e o Cloud Run functions de 2ª geração) e Definir as configurações de rede (1ª geração) (para o Cloud Run functions de 1ª geração). Nenhuma outra mudança é necessária no seu fluxo de trabalho.

Usar uma conta de serviço com as permissões necessárias

Ao fazer solicitações para outros serviços do Google Cloud , seu fluxo de trabalho precisa estar associado a uma conta de serviço que tenha as permissões corretas para acessar os recursos solicitados. Para saber qual conta de serviço está associada a um fluxo de trabalho, consulte Verificar a conta de serviço associada a um fluxo de trabalho.

Ao configurar uma conta de serviço, você associa a identidade solicitante ao recurso ao qual quer conceder acesso, tornando-a um principal do recurso, e atribui o papel apropriado a ela. O papel define quais permissões a identidade tem no contexto do recurso.

Por exemplo, para configurar uma função do Cloud Run de recebimento (1ª geração) para aceitar solicitações de uma função ou serviço de chamada específico, é necessário adicionar a conta de serviço do autor da chamada como principal na função de recebimento e conceder a esse principal o papel de invocador do Cloud Functions (roles/cloudfunctions.invoker). Da mesma forma, para configurar uma conta de serviço para serviços ou funções do Cloud Run (2ª geração), conceda a essa conta de serviço o papel de invocador do Cloud Run (roles/run.invoker). Para saber mais, consulte Controle de acesso com o IAM ou a Visão geral da autenticação do Cloud Run.

Invocar funções do Cloud Run

No Cloud Run functions, as permissões de invocação estão disponíveis ao gerenciar o serviço subjacente do Cloud Run. Se o fluxo de trabalho estiver invocando um serviço do Cloud Run functions, não será necessário conceder à conta de serviço do autor da chamada o papel do IAM de Invocador do Cloud Functions (roles/cloudfunctions.invoker). Em vez disso, é necessário conceder o papel do IAM de Invocador do Cloud Run (roles/run.invoker).

Para mais informações, consulte Comparar o Cloud Run functions.

Adicionar informações de autenticação ao fluxo de trabalho

Ao fazer solicitações para o Cloud Run functions ou o Cloud Run, use o OIDC para autenticação.

Para fazer uma solicitação HTTP usando o OIDC, adicione uma seção auth à seção args da definição do fluxo de trabalho, depois de especificar o URL. Neste exemplo, uma solicitação é enviada para invocar uma função do 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"
            }
          }
        }
      }
    ]

O parâmetro opcional audience especifica o público-alvo do OIDC (OIDC_AUDIENCE) para o token. Por padrão, ele é definido com o mesmo valor de url. No entanto, se url incluir outros segmentos de caminho além do URL raiz do serviço ou da função, defina audience como o URL raiz (por exemplo, https://us-central1-project.cloudfunctions.net/functionA).

Especificar o tipo de mídia para os dados de resposta

Se o cabeçalho Content-Type da resposta especificar um tipo de mídia application/json, a resposta JSON armazenada em uma variável será convertida automaticamente em um mapa que pode ser acessado.

Se necessário, modifique a API que está sendo chamada para especificar um tipo de mídia application/json para o cabeçalho de resposta Content-Type. Caso contrário, use as funções json.decode e text.encode para converter o corpo da resposta em um mapa. Exemplo:

json.decode(text.encode(RESPONSE_FROM_API))

Para mais informações, consulte Acessar dados de resposta HTTP salvos em uma variável.

Executar jobs do Cloud Run

Ao contrário dos serviços do Cloud Run, os jobs do Cloud Run não detectam nem atendem a solicitações HTTP. Para executar jobs do Cloud Run com um fluxo de trabalho, use o conector da API Cloud Run Admin. Se um job levar mais de 30 minutos para ser concluído, configure o tempo limite da tarefa do job (10 minutos por padrão, configurável até 168 horas ou 7 dias) e connector_params.timeout na chamada do conector (que tem como padrão 1.800 segundos e pode ser configurado para até 31.536.000 segundos ou 1 ano).

Para ver um exemplo completo de execução de um job do Cloud Run que processa dados transmitidos como variáveis de ambiente para o job, consulte Executar um job do Cloud Run usando Workflows.

Para ver um exemplo completo de execução de um job do Cloud Run que processa dados armazenados em um bucket do Cloud Storage, permitindo a criptografia dos dados usando chaves de criptografia gerenciadas pelo cliente (CMEK), consulte Executar um job do Cloud Run que processe dados de eventos no Cloud Storage.