TerraformでCloud Functions, Cloud Storage, サービスアカウントをつくった
Terraform と GCP に同時入門していくにあたって、この前 AWS でつくったリソースと、だいたい同じものをつくってみることにしました (Deployment Manager は、いまのところ利用予定なしのためスキップ)
実装
GitHub に置いてあります。
AWS
- S3にCSVがアップロードされたら、LambdaがダウンロードしてParquetに変換して、S3にアップロードする
- この処理をSAMでデプロイする
- IAM RoleはSAMがよしなにしてくれる
GCP
- GCSにCSVがアップロードされたら、Cloud Functions がダウンロードしてParquetに変換して、GCSにアップロードする
- この処理をTerraformでデプロイする
- サービスアカウントの作り方がちょっとくせあり
resource "google_service_account" "sa" { account_id = "pq-converter" display_name = "pq-converter" } resource "google_project_iam_member" "cloud_storage_admin" { role = "roles/storage.objectAdmin" member = "serviceAccount:${google_service_account.sa.email}" } resource "google_cloudfunctions_function_iam_member" "member" { project = google_cloudfunctions_function.pq-converter.project region = google_cloudfunctions_function.pq-converter.region cloud_function = google_cloudfunctions_function.pq-converter.name role = "roles/cloudfunctions.invoker" member = "serviceAccount:${google_service_account.sa.email}" }
- Cloud Functions の実装はあとできれいにしよう
感想
Terraform
(これまでのところ)書きやすくて読みやすい
- 公式ドキュメントをみれば書き方はだいたい分かる
- よくもわるくもAPI準拠、勝手に[やってくれる|やられてしまう]というのがない
- わからないことはだいたいサービス側の内容
- これで複数のサービスを管理できるのはつよい
ロールバックされないのがつらい
- 既存環境を壊してしまいそう()
- CloudFormation の強みはここだな、と思った
Cloud Functions
用途が思っていたより限定的だと感じた
- REST API と KVS をつなぐとか、GAEをたてるまでもないようなシンプルな処理
- ETL目的で並列ぶん回しするのは、Dataflow とか Cloud Composer をつかってね!というメッセージを受信した
依存ライブラリは Function ごとに指定する
- Lambda Layer 便利だよね、ということ
Cloud Storage Trigger はバケットレベルで指定する
- 公式ドキュメント
- prefix/suffix の指定ができない。つまり、今回の条件である ”CSVがアップロードされたら” は、厳密に言うと達成できていない
- 今回のように、加工後に同じバケットに保存、という処理をすると、Functionが2回起動する。
おわりに
Terraformの便利さと、GCPの高潔さを少し感じ取れたように思います。 次は Cloud Run を試していくぞ!