Cloud Workflowsとは
Google Cloudのワークフローサービスです。
ワークフローとは、複数のタスクを順番に実行していく流れを意味しています。
例えば、下図のようにA/B/C1/C2/Dの5つのタスクがあるとします。
Aが終わったらB、Bが終わったらC1とC2、C1とC2が終わったらDというような順序関係を制御してくれるのがワークフローサービスです。
ちなみに、Google CloudのCloud WorkflowsはAWSにおけるStep Functions相当のサービスです。
子ワークフロー呼び出しとは
Cloud Workflowsでは、あるワークフローから別のワークフローを起動できます。
ここでは、呼び出す側のワークフローを親、呼び出される側のワークフローを子と呼びます。
複数のワークフロー間で共通する部分を子ワークフローとして切り出すことで、保守性を向上させられるのではないかと思い、実際に動かしてみました。
親から子は同期呼び出しなのかを検証する
子ワークフローのデプロイ
コンソールから子ワークフローをデプロイします。
この時、子ワークフロー用のサービスアカウントも作成します。
まずは10秒待ってからHello worldという文字列を返すようにします。
デプロイ後、実行を押して動かしてみます。
入力パラメータを指定できますが、デプロイした子ワークフローはパラメータを使っていないので空のまま実行します。
実行すると以下のようにwaitで10秒待機されている様子がわかります。
10秒経過後、completeステップも完了して出力がHello worldになりました。
親ワークフローのデプロイ
子ワークフローを呼び出すワークフローを作成します。
この時、親ワークフロー用のサービスアカウントを作成します。
callでWorkflow Executions APIコネクタを利用してchild-workflowを呼び出します。
デプロイし、実行してみます。
403エラーになりました。サービスアカウントparent-workflowにワークフローを起動する権限割り当てを行っていないためです。
このparent-workflowのサービスアカウントにワークフロー起動元のロールを追加します。
再度parent-workflowを起動すると以下のように起動に成功しました。
execute_child_workflowステップが10秒超かかっているので、子ワークフローの完了を待っているように見えます。
親ワークフローからは子ワークフローの実行状況は見えませんが、子ワークフローのページからは実行履歴を参照できます。
子ワークフローのページでは以下のようにparent-workflowから実行された2回目の実行ログが残っていました。
本当に同期処理かを確かめるためにchild-workflowの出力をparent-workflowの出力にそのまま流して結果を確認してみます。
以下のようにparent-workflowの定義を変更します。
再度、parent-workflowを実行すると出力がchild-workflowと同じくHello worldになりました。
以上から、親ワークフローから子ワークフローの呼び出しは同期的に行っていることがわかりました。
ワークフローの共通化を試してみる(承認が必要なジョブ実行のフローを共通化)
親ワークフローから子ワークフローにはパラメータを指定した実行ができます。
そこで、以下のようにすることで承認が必要な任意のステップを組み込みやすくなるのではないかと考えました。
- 子ワークフロー
- ワークフローの先頭でコールバックの待機をする
- コールバック後、パラメータで渡されたCloudRun Jobsを実行する
- 親ワークフロー
- 承認を得られたら実行したいCloudRun Jobsの名称をパラメータとして、子ワークフローを実行する
上記を実際に試してみます。
簡易なCloudRun Jobsを用意する
Artifact RegistryのDockerリポジトリを作成し、Job executed!と標準出力に表示するDockerイメージを格納します。
cloud shellで以下のDockerfileをビルドし、Dockerリポジトリにプッシュします。
FROM ubuntu:24.04
CMD [ "echo", "Job executed!" ]
DockerイメージのビルドとArtifact Registryへのプッシュは本題からそれるため割愛します。
方法を知りたい方は以下のページをご参照ください。
イメージをプッシュ後は、以下のようにArtifact Registryのページからイメージを確認できます。
作成したイメージを実行するCloudRun Jobsをデプロイします。
ここでは、sample-jobという名称にします。
Artifact Registryからイメージをプルするため、CloudRun JobsのサービスアカウントにArtifact Registry読み取りロールを割り当てます。
作成したジョブを実行するとCloudRun JobsのログにJob executed!と表示されていることがわかります。
パラメータで指定されたCloudRun Jobsを実行するよう子ワークフローを修正する
子ワークフローのサービスアカウントにCloud Run 閲覧者ロールとCloud Run 起動元ロールを追加します。
CloudRun Jobsを起動するだけなら、Cloud Run 起動元ロールだけで良いのですが、Workflowsでは実行結果の読み取りも行うため、起動と読み取りが可能なロールを割り当てています。
paramsでパラメータをargsという変数に割り当て、initステップでargsのjob_nameをワークフロー内の変数job_nameに代入します。
その後、run_jobステップにて、job_nameのCloudRun Jobsを実行します。
修正した子ワークフローを実行してみます。
先ほどデプロイしたCloudRun Jobs sample-jobを入力とします。
すると以下のように子ワークフローの実行が成功します。
これで、子ワークフローで実行するCloudRun Jobsを親ワークフローで指定できることがわかりました。
実行したいCloudRun Jobsを指定して子ワークフローを起動するよう親ワークフローを修正する
親ワークフローから子ワークフローを呼び出す個所でargumentを指定し、job_name: sample-jobを追加します。
子ワークフローのwaitをスリープからコールバック待ちに変更する
子ワークフローのwaitステップを削除し、代わりにcreate_callbackステップとawait_callbackステップを追加します。
create_callbackステップのevents.create_callback_endpointでコールバック用のURLを作成します。
await_callbackステップのevents.await_callbackはargs.callbackで指定したコールバック用のURLにアクセスがあるまで待機します。
親ワークフローを実行して動作を試してみると、親ワークフローは子ワークフロー実行のステップで停止します。
子ワークフロー側を見てみるとawait_callbackステップで停止していることがわかります。
create_callbackステップのログを見るとコールバック用のURLを確認できます。
cloud shellから以下のコマンドでコールバック用のURLにアクセスします。
コールバック用URLにリクエストするにはワークフロー起動元ロールが必要です。
権限を持つユーザーでgcloud auth application-default loginしている前提で、以下のコマンドを実行しています。
curl -X POST \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
"(コールバック用URL)"
すると、await_callbackが完了し、子ワークフローが動き出しました。
そして、子ワークフローの完了に伴い、親ワークフローも完了します。
これで、任意のジョブを承認したら実行するワークフローを子ワークフローとして共通化し、複数の親ワークフローから利用可能になりました。
本記事の例ではコールバック用URLをログから取得していますが、承認用の画面を用意し、メール等で承認用画面のURL送信するなどセキュリティ対策と利便性を良くできそうです。
まとめ
本記事では、Cloud Workflowsの子ワークフロー呼び出しを使ってみました。
子ワークフローは受け取ったパラメータに基づいたワークフローを実行できるため、汎用性の高い共通ワークフローを構築できます。
共通ワークフローをデプロイしておくことで、それを利用する複数の親ワークフローはシンプルな構成を保つことができ、保守性向上に寄与しそうに思いました。