TerraformでGoogle Cloud Run Jobsを使った定期実行ジョブを作成する
この記事はPharmaXアドベントカレンダー2023の23日目の記事です。
こんにちは、PharmaX エンジニアの尾崎(@FooOzaki)です。
本記事ではGoogle Cloud Run Jobsを使った定期実行ジョブをTerraformで作成する方法を簡単にご紹介していこうと思います。
はじめに
Cloud Run JobsはGoogle Cloudのコンテナベースのサーバーレスサービス Cloud Runのバッチ処理を行うための機能です。
公式ドキュメントにも非常に丁寧な説明があるため本記事と併せてお読みいただくとより理解が深まるかと思います。
PharmaXでは元々バックエンドサーバをCloud Runで運用していたこともあり、Cloud Run JobsもGAになって以降本番導入し、運用しています。
Google Cloud Run Jobsが登場するまでは、Cloud Runの実行環境でタスク・スクリプトをトリガー実行するためにはHTTPリクエストの受け口を用意する必要がありました。
PharmaXでも定期実行ジョブは、Cloud Runにタスク実行用のエンドポイントを準備した上で、Cloud SchedulerからHTTPリクエストを飛ばして実行していました。
自身で専用のエンドポイントの準備が必要で、タスク実行専用のCloud Run立ち上げ等にも考慮事項があり定期実行ジョブの実装のしにくさは課題に感じていたのですが、これらの悩みがCloud Run Jobsにより解決されました。
Cloud Run Jobsは既にコンテナイメージベースのアプリケーションがあれば簡単に立ち上げ可能です。さらにCloud Runの実行環境が既にあるのであれば同様の設定が流用できるので、いくつかの固有パラメータ設定のみでリソース作成可能です。
本記事ではTerraformを利用した立ち上げ方法をご紹介しますので、ご参考になれば幸いです。
本記事の前提
- GCPプロジェクト、Terraformの実行環境は既にあること
- Artifact Registoryに実行環境のコンテナイメージが存在すること
実行環境
- terraform 1.5.3
- hashicorp/google(Terraformのgcpプラグイン) 4.81.0
Cloud Run jobsをTerraformで構築する
まず、タスクの実行環境となるCloud Run Jobsの準備です。
google_cloud_run_v2_job
のResourcesでCloud Run Jobsは構築可能です。
実際にお試しいただくときはこちらを確認いただきながら設定を適宜追加いただければと思います。
以下はCloud Firestoreのバックアップタスクを実行するサンプルです。(環境固有のものは最低限変数化していますが、設定値もイメージがつきやすいようにそのまま記載しています)
resource "google_cloud_run_v2_job" "this" {
provider = google-beta
name = "firestore_backup"
location = "asia-northeast1"
template {
template {
timeout = "1800s"
service_account = var.service_account_name
containers {
image = var.image
command = ["gcloud", "firestore", "export"]
args = ["gs://temp-firestore-backup"]
}
resources {
limits = {
cpu = "1000m"
memory = "1Gi"
}
}
vpc_access {
connector = google_vpc_access_connector.this.id
egress = "ALL_TRAFFIC"
}
}
}
}
前述の通りタスク実行可能なコンテナイメージはArtifact Registoryに事前に用意は必要となりますが、変数 var.image
で記載している箇所にArtifact RegistoryのイメージURLを指定いただければOKです。
また、VPC等も必要に応じて設定いただければと思います。
アプリケーションタスクであればSecret Managerや環境変数の設定等も設定が必要なケースも多いかと思いますが、Cloud Runを既に使用している場合は同様の設定で動作可能かと思います。
サービスアカウントに付与するIAMロールについても触れておくとCloud Run Jobsの実行だけであれば roles/run.invoker
の権限で実行可能です。
あとはタスクに応じて必要な関連サービスロールを付与いただければと思います。
Cloud Run Jobsを定期実行する
タスク実行タイミングをスケジューリングする必要がなければCloud Run Jobs単体で動かせます。
前章のCloud Run Jobsのterraform applyが成功していればGUIからも手動で実行は可能な状態となっているはずです。
動作確認はした上で定期実行を設定いただくのが良いかと思います。
以下はスケジューリングのサンプルですが、google_cloud_scheduler_jobのResourcesで設定可能です。
resource "google_cloud_scheduler_job" "this" {
name = "firestore_backup_scheduler"
schedule = "0 3 * * *"
time_zone = "Asia/Tokyo"
retry_config {
max_backoff_duration = "3600s"
max_doublings = 5
max_retry_duration = "0s"
min_backoff_duration = "5s"
retry_count = 0
}
http_target {
http_method = "POST"
uri = "https://${google_cloud_run_v2_job.this.location}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${var.project}/jobs/${google_cloud_run_v2_job.this.name}:run"
oauth_token {
service_account_email = var.service_account_email
}
}
}
執筆時点のCloud RunのGUIでは「トリガー」タブでも確認できますが、実体としてはCloud Schedulerとなり、TerraformリソースもCloud Schedulerとなります。
targetとしてCloud Run Jobsを指定するとこのように「トリガー」タブから見えるようになるようです。(リソースはCloud Schedulerからも確認できます。)
Cloud Run Jobs トリガー
schedule = "0 3 * * *"
のようにcron形式で実行タイミングを定義可能です。
retry_configにて実行失敗時の動作を定義可能です。
http_targetでCloud Run JobsのURIを指定すれば定期的にCloud Run Jobsのタスク実行が可能となります。
最後に
個人的にはCloud Run Jobsの登場によってGoogle Cloud上でのタスク実行選択肢がかなり広がった印象です。
コンテナイメージベースなので好きな言語で好きなアプリケーションで実行できます。
Cloud Run Jobsはジョブの実行時以外はコンテナが起動しないため、コスト面でも非常に利用しやすいサービスかと思います。
今回ご紹介した内容はシングルタスクの定期実行でしたが、タスクを同時実行させたい場合は並列処理も実行可能ですし、Workflowsと組み合わせるとワークフローを組むこともできます。
Cloud Run周りは新しいアップデートも頻繁にあり、Google Cloudも力を入れているとのことですので今後のアップデートも楽しみです。
以上、Cloud Run Jobsを使った定期実行ジョブの簡単な作成方法でした。
PharmaXエンジニアチームのテックブログです。エンジニアメンバーが、PharmaXの事業を通じて得た技術的な知見や、チームマネジメントについての知見を共有します。 PharmaXエンジニアチームやメンバーの雰囲気が分かるような記事は、note(note.com/pharmax)もご覧ください。
Discussion