Cloud Run 関数または Cloud Run を呼び出す

Workflows からの Cloud Run 関数や Cloud Run などの Google Cloud サービスの呼び出しは、HTTP リクエストを介して行われます。最も一般的な HTTP リクエスト メソッドには、呼び出しショートカット(http.get、http.post など)がありますが、call フィールドを http.request に設定し、method フィールドでリクエストのタイプを指定することであらゆるタイプの HTTP リクエストを作成できます。詳細については、HTTP リクエストを行うをご覧ください。

認証済みリクエストを送信するには、次のようにする必要があります。

  • ワークフローは、必要な権限を持つ 1 つ以上の Identity and Access Management(IAM)ロールが付与されているサービス アカウントに関連付ける必要があります。

  • 認証情報は、明示的にワークフロー定義に追加する必要があります。デフォルトでは、セキュリティ上の理由から、HTTP リクエストには ID やアクセス トークンが含まれていません。

詳細については、 Google Cloud リソースにアクセスする権限をワークフローに付与するをご覧ください。

サービスを呼び出すタイミング

Workflows 構文を使用して YAML または JSON でステップを作成するタイミングや、Cloud Run サービスや Cloud Run 関数などのサービスを作成して作業を行うタイミングを認識するにはどうすればよいですか。

Workflows を使用して、ワークフロー自体からサービスを呼び出し、結果を処理して、HTTP 呼び出しなどの単純なタスクを実行します。Workflows は、サービスを呼び出して、レスポンスを解析し、他の接続されたサービスに対する入力を構築できます。サービスを呼び出すことで、追加の呼び出し、追加の依存関係、サービスを呼び出すサービスによる複雑性を回避できます。

ワークフローでは複雑すぎる作業を行うサービスを作成します。たとえば、ワークフロー式とその標準ライブラリでサポートされていない、再利用可能なビジネス ロジック、複雑な計算、変換の実装が挙げられます。複雑なケースは通常、YAML や JSON、Workflows 構文を使用するよりもコード内で実装する方が簡単です。

リクエストのタイムアウトとペイロードの上限

HTTP 経由で Cloud Run サービスまたは Cloud Run 関数を呼び出す場合、Workflows の同期 HTTP リクエスト(http.get、http.post、http.request)はデフォルトで 5 分(300 秒)のタイムアウトになり、最大 30 分(1,800 秒)のタイムアウトをサポートし、最大 2 MB のレスポンス サイズを許可します(変数に保存されている場合は 512 KB の変数メモリ制限が適用されます)。

Cloud Run サービスと Cloud Run functions(第 2 世代)は最大 60 分のリクエスト タイムアウトをサポートしていますが、Workflows の同期 http.* ステップは、構成されたタイムアウト(最大 30 分)後に TimeoutError でタイムアウトします。30 分以上実行されるワークロードや、大きなペイロードを返すワークロードの場合は、Cloud Run ジョブまたはコールバック エンドポイントを使用します。上限と推奨パターンの比較については、サービス間でタイムアウトとペイロード サイズを調整するをご覧ください。

内部 Ingress に限定されたサービスを呼び出す

Workflows では、上り(内向き)が内部トラフィックに制限されている同じ Google Cloud プロジェクトまたは VPC Service Controls 境界内の Cloud Run functions または Cloud Run サービスを呼び出すことができます。この構成では、インターネットからサービスにアクセスできませんが、Workflows からはサービスにアクセスできます。

これらの制限を適用するには、サービスまたは関数の上り(内向き)設定を調整する必要があります。Cloud Run サービスには、カスタム ドメインではなく、run.app URL でアクセスする必要があります。詳細については、ネットワーク上り(内向き)を制限する(Cloud Run と Cloud Run functions 第 2 世代の場合)とネットワーク設定を構成する(第 1 世代)(Cloud Run functions 第 1 世代の場合)をご覧ください。ワークフローに対するその他の変更は必要ありません。

必要な権限を持つサービス アカウントを使用する

他の Google Cloud サービスに対してリクエストを行う場合は、ワークフローに、リクエストされたリソースへのアクセスに必要な権限を持つサービス アカウントが関連付けられている必要があります。既存のワークフローに関連付けられているサービス アカウントについては、ワークフローに関連付けられたサービス アカウントの確認をご覧ください。

サービス アカウントを設定するときに、リクエスト対象の ID とアクセス権を付与するリソースを関連付けます。リクエスト元 ID は、そのリソースのプリンシパルとし、適切なロールを指定します。このロールでは、リソースのコンテキストで ID が持つ権限を定義します。

たとえば、受信側の Cloud Run 関数(第 1 世代)が特定の呼び出し側関数またはサービスからのリクエストを受け入れるように構成するには、呼び出し元のサービス アカウントを受信側の関数のプリンシパルとして追加し、そのプリンシパルに Cloud Functions の起動元(roles/cloudfunctions.invoker)ロールを付与する必要があります。同様に、Cloud Run サービスまたは Cloud Run functions(第 2 世代)のサービス アカウントを設定するには、そのサービス アカウントに Cloud Run 起動元(roles/run.invoker)ロールを付与します。詳細については、IAM を使用したアクセス制御または Cloud Run の認証の概要をご覧ください。

Cloud Run functions の関数を呼び出す

Cloud Run functions では、基盤となる Cloud Run サービスを管理することで呼び出し権限を使用できます。ワークフローが Cloud Run functions サービスを呼び出している場合、呼び出し元のサービス アカウントに Cloud Functions 起動元(roles/cloudfunctions.invoker)IAM ロールを付与する必要はありません。代わりに、Cloud Run 起動元(roles/run.invoker)IAM ロールを付与する必要があります。

詳細については、Cloud Run functions を比較するをご覧ください。

ワークフローに認証情報を追加する

Cloud Run functions や Cloud Run にリクエストを送信するときは、OIDC を使用して認証します。

OIDC を使用して HTTP リクエストを行うには、URL を指定した後に、ワークフローの定義の args セクションに auth セクションを追加します。この例では、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 パラメータは、トークンの OIDC オーディエンス(OIDC_AUDIENCE)を指定します。デフォルトでは、url と同じ値に設定されています。ただし、url にサービスまたは関数のルート URL 以外のパス セグメントが含まれている場合は、audience をルート URL(例: https://us-central1-project.cloudfunctions.net/functionA)に設定します。

レスポンス データのメディアタイプを指定する

レスポンスの Content-Type ヘッダーで application/json メディアタイプが指定されている場合、変数に保存される JSON レスポンスは、アクセス可能なマップに自動的に変換されます。

必要に応じて、呼び出される API を変更し、Content-Type レスポンス ヘッダーの application/json メディアタイプを指定します。それ以外の場合は、json.decode 関数と text.encode 関数を使用して、レスポンスの本文をマップに変換できます。次に例を示します。

json.decode(text.encode(RESPONSE_FROM_API))

詳細については、変数に保存された HTTP レスポンス データにアクセスするをご覧ください。

Cloud Run ジョブを実行する

Cloud Run サービスとは異なり、Cloud Run ジョブは HTTP リクエストをリッスンまたは処理しません。ワークフローから Cloud Run ジョブを実行するには、Cloud Run Admin API コネクタを使用します。ジョブの完了に 30 分以上かかる場合は、ジョブのタスク タイムアウト(デフォルトは 10 分、最大 168 時間(7 日)まで構成可能)と、コネクタ呼び出しの connector_params.timeout(デフォルトは 1,800 秒、最大 31,536,000 秒(1 年)まで設定可能)の両方を構成します。

ジョブに環境変数として渡されたデータを処理する Cloud Run ジョブを実行するエンドツーエンドの例については、Workflows を使用して Cloud Run ジョブを実行するをご覧ください。

Cloud Storage バケットに保存されているデータを処理する Cloud Run ジョブを実行し、顧客管理の暗号鍵(CMEK)を使用してデータを暗号化できるようにするエンドツーエンドの例については、Cloud Storage 内のイベントデータを処理する Cloud Run ジョブを実行するをご覧ください。

次のステップ