Gcp

Slack APIはUXのため著名な3秒レスポンスルールを設けています。初期設定のようなものではなく、自ら伸ばすことはできません。（厳しい） https://api.slack.com/interactivity/slash-commands If you need to respond outside of the 3 second window provided by the request responses above, you still have plenty of options for keeping the workflow alive. Slack Appsを開発したことのある人にとって最初は少し戸惑うでしょうか。（筆者はそうでした。） 最近はCloud Functionsとslack boltで社内の承認アプリを開発していて、試行錯誤した経験を共有したいと思います。 経緯 実装する予定のアプリの最初のステップとして、ショートカットでCloud Functionsを発火させてmodalを開きます。slack boltのドキュメントを読んで、以下の実装をおこないました。 https://slack.dev/bolt-python/concepts （一部のコード） @app.shortcut("/hogehoge") def open_application_modal(ack, body: dict, client: WebClient): ack() result = process() client.views_open( trigger_id=body["trigger_id"], view={ "type": "modal", # View identifier "callback_id": "application_form_view", "title": {"type": "plain_text", "text": "APP Title"}, "submit": {"type": "plain_text", "text": "Submit"}, "blocks": create_blocks(result), }, ) # ....

GCPのFaaS(Functions-as-a-Service)Cloud Functionsは最近第二世代がリリースされ、（まだbeta期間中ですが）インフラ周りがけっこう強化されました。Cloud StorageとBigQueryにある大規模データを処理するために、HTTPトリガーのアップタイムが60分までに、イベントトリガーも10分まで伸びました。 https://cloud.google.com/functions/docs/2nd-gen/overview 筆者はこの数週間ちょうどCloud Functionsを利用して承認システムを開発しています。Cloud Functions 2nd Genにおけるsecret keyの管理について少し困っていたので、調べたものを共有します。 何が問題か secret keyなどを明文でCloud Functionsの環境変数に保存するは流石に危ないので、他の方法が必要です。 we recommend that you review the best practices for secret management. Note that there is no Cloud Functions-specific integration with Cloud KMS. Cloud Functions公式ドキュメントによると、secret keyを管理するベストプラクティスはSecret Managementを利用することです。また、Cloud Functions特有のCloud KMSは存在しません。 https://cloud.google.com/functions/docs/configuring/env-var#managing_secrets 1st genの場合はデプロイする際に-set-secretsというオプションでSecret Management上保存しているキーを追加すれば良いですが、2nd genで同じようなことをやると、-set-secretsはまだ実装されていない（2022年5月）ので、怒られます。 ERROR: (gcloud.beta.functions.deploy) --set-secrets is not yet supported in Cloud Functions V2. Cloud KMSを使う Secret Managementはまだ存在しない時代（と言っても3年前）に書かれた記事を読んで、参考になりました。 考え方としては、 Cloud KMSで認証情報(文字列)を暗号化する 暗号化した認証情報をCloud Functionsの環境変数に登録する Cloud Functionsの関数内で暗号化された環境変数を復号化する https://www.apps-gcp.com/kms-with-functions/...

最近よくデータ基盤構築の仕事をしているため、TerraformでGCPをいじったりしています。今回はCloud Storageのバケット名を変更する際に罠にはまりやすいところを紹介します。もちろん、Cloud Storageだけでなく、他のサービスやAWSなどにも活用できそうな箇所があるではないかと思います。 環境 Terraform v1.1.2 on darwin_arm64 provider registry.terraform.io/hashicorp/google v4.15.0 他の環境は正しく動作するかは未検証です。 経緯 下記のバケットを作って検証環境に反映した後、PRを出しました。 resource "google_storage_bucket" "my_bucket" { name = "my-bucket" storage_class = var.gcs_storage_class.coldline project = var.project_id location = var.gcs_location force_destroy = false uniform_bucket_level_access = true retention_policy { is_locked = true retention_period = 30 } lifecycle_rule { condition { age = 30 } action { type = "Delete" } } } チームメンバーのレビュー受けて、バケット名はmy-bucketよりmy-bucket-hogeの方が良いと言われたので、my-bucketをmy-bucket-hoge変更しterraform applyしたらエラーになりました。もちろんのことですが、最初はforce_destroy = falseに設定していて、バケット内オブジェクトが入っているので、強制変更はできません。 force_destroy - (Optional, Default: false) When deleting a bucket, this boolean option will delete all contained objects....