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 構文を使用するよりもコード内で実装する方が簡単です。
内部 Ingress に限定されたサービスを呼び出す
Workflows では、上り(内向き)が内部トラフィックに制限されている同じ Google Cloud プロジェクト内の Cloud Run 関数や Cloud Run サービスを呼び出すことができます。この構成では、インターネットからサービスにアクセスできませんが、ワークフローからはサービスにアクセスできます。
これらの制限を適用するには、サービスまたは関数の上り(内向き)設定を調整する必要があります。Cloud Run サービスには、カスタム ドメインではなく、run.app
URL でアクセスする必要があります。詳細については、上り(内向き)の制限(Cloud Run の場合)とネットワーク設定の構成(Cloud Run 関数の場合)をご覧ください。ワークフローに対するその他の変更は必要ありません。
必要な権限を持つサービス アカウントを使用する
他の Google Cloud サービス対してリクエストを行う場合は、リクエストされたリソースにアクセスするのに適切な権限を持つサービス アカウントにワークフローを関連付ける必要があります。既存のワークフローに関連付けられているサービス アカウントについては、ワークフローに関連付けられたサービス アカウントの確認をご覧ください。
サービス アカウントを設定するときに、リクエスト対象の ID をアクセス権を付与するリソースと関連付けます。リクエスト元 ID は、そのリソースのプリンシパルとし、適切なロールを指定します。このロールでは、リソースのコンテキストで ID が持つ権限を定義します。
たとえば、受信側の Cloud Run 関数が特定の呼び出し側関数またはサービスからのリクエストを受け入れるように構成するには、呼び出し元のサービス アカウントを受信側の関数のプリンシパルとして追加し、そのプリンシパルに Cloud Run 関数の起動元(roles/cloudfunctions.invoker
)ロールを付与する必要があります。同様に、Cloud Run のサービス アカウントを設定するには、そのサービス アカウントに Cloud Run 起動元(roles/run.invoker
)ロールを付与します。詳細については、Cloud Run 関数の認証情報または Cloud Run の認証の概要をご覧ください。
Cloud Run 関数(第 2 世代)を呼び出す
Cloud Run 関数(第 2 世代)では、基盤となる Cloud Run サービスを管理することで呼び出し権限を使用できます。ワークフローで Cloud Run 関数(第 2 世代)サービスを呼び出す場合、呼び出し元のサービス アカウントに Cloud Run 関数の起動元(roles/cloudfunctions.invoker
)ロールを付与する必要はありません。代わりに、Cloud Run の起動元(roles/run.invoker
)ロールを付与する必要があります。
詳細については、Cloud Run 関数のバージョンの比較をご覧ください。
ワークフローに認証情報を追加する
Cloud Run 関数や 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 オーディエンスを指定できます。デフォルトでは、url
と同じ値に設定されています。ただし、サービスのルート URL に設定する必要があります。例: https://region-project.cloudfunctions.net/hello_world
。
レスポンス データのメディアタイプを指定する
レスポンスの 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 コネクタを使用します。
ジョブに環境変数として渡されたデータを処理する Cloud Run ジョブを実行するエンドツーエンドの例については、Workflows を使用して Cloud Run ジョブを実行するをご覧ください。
Cloud Storage バケットに保存されているデータを処理する Cloud Run ジョブを実行し、顧客管理の暗号鍵(CMEK)を使用してデータを暗号化できるようにするエンドツーエンドの例については、Cloud Storage 内のイベントデータを処理する Cloud Run ジョブを実行するをご覧ください。
次のステップ
- 機能の HTTP エンドポイントを作成する
- Cloud Run でホストされているサービスをトリガーする
- Cloud Run と Cloud Functions で Workflows を使用するチュートリアル