GCP

結論 Terraform がリソース間の依存を張るのは、式が別のリソースや module の output を参照したときと、depends_on を書いたときだけ。同じ値を文字列や root の変数で渡しても依存はできず、親と子は並行に作られる 依存が無くても、親が既にある環境では通る。落ちるのはまっさらな環境への初回 apply だけで、Firestore の Field が 404 になったり、API の有効化より先にリソースの作成が走ったりする depends_on = [module.x] は x の全リソースを待つ。x の中に自分の出力を使うリソースがあると、依存が一周して cycle (循環参照) になり、Error: Cycle で落ちる。x の output を書けば、その output が参照するリソースだけを待つ 設定を持つ provider ブロックを中に書いた module には、depends_on (と count / for_each) を付けられない。provider は root へ上げる module の depends_on は、依存先に未適用の変更がある plan で、module 内の data source の読み込みを apply 時まで遅らせる。その値を ForceNew の属性に渡すと、何も変わっていなくても replace が出る 以下のコードと出力は Terraform v1.15.8 で確かめた。使ったのは terraform init -backend=false と terraform validate だけで、plan / apply は打っていない。 GCP の API を呼ぶ節と data source の節は、作業ログの記録をもとに書いた。 ...

疑問 GCP ErrorReporting でのエラー通知の挙動についてわかっていなかったので、メモ まとめ ErrorReporting に出力され、通知設定先（Email/Slack）に内容が飛ぶ 同じエラーはグループ化され、既存のエラーグループに属する場合は通知されない 原則として「新しいタイプのエラー」や「一度解決済みとマークされたエラーが再発したとき」にのみ通知 解決済みとすれば再度通知される エラーが原因で発生する通知は、1時間に最大5回まで送信可能

はじめに クラウド環境でのデータベース管理において、セキュリティは日々進化する脅威への対応が求められる重要課題です。特に、以下の課題が顕在化しています： 従来の認証情報（パスワード）の漏洩リスク 認証情報のローテーション管理の煩雑さ アプリケーション展開時の認証情報受け渡しの安全性確保 これらの課題に対し、IAM認証を活用することで、より強固でかつ運用負荷の少ないセキュリティ体制を実現できます。IAM認証のメリットは以下の通りです： 一時的な認証トークンの利用による漏洩リスクの低減 クラウドプロバイダーの統合認証基盤との連携による管理の一元化 きめ細かなアクセス制御とアクセスログの監査対応 本ガイドでは、Cloud FunctionsからCloudSQL(PostgreSQL)へIAM認証で接続する実践的な手順を解説します。この設定により、セキュアかつスケーラブルなデータベースアクセス環境を構築できます。 Cloud Function から CloudSQL(PostgreSQL) へ IAM 認証で接続するために必要な手順 Cloud Function 用 Service Account に必要な権限を付与 PGUSER の作成（IAM認証用） データベースへの権限付与 Cloud Function の実装 Service Account での Cloud Function のデプロイ 具体的な設定手順 1. Cloud Function 用 Service Account に必要な権限を付与 以下の権限が必要: Cloud SQL インスタンス ユーザー Cloud SQL クライアント 今回はコンソールから設定したが、以下のコマンドで設定も可能: gcloud projects add-iam-policy-binding example-project \ --member="serviceAccount:example-function@example-project.iam.gserviceaccount.com" \ --role="roles/cloudsql.instanceUser" gcloud projects add-iam-policy-binding example-project \ --member="serviceAccount:example-function@example-project.iam.gserviceaccount.com" \ --role="roles/cloudsql.client" 2. PGUSER の作成 IAM認証用のユーザーを作成する。 gcloud sql users create example-function@example-project.iam \ --instance=example-project-fdc \ --type=cloud_iam_service_account PostgreSQLの場合、以下の点に注意が必要: ユーザー名から .gserviceaccount.com を除いた形で作成 タイプは cloud_iam_service_account を指定 MySQL の場合は @project-id.iam.gserviceaccount.com を除いた形で作成する模様 Refs: GoogleCloudPlatform/cloud-sql-nodejs-connector: A JavaScript library for connecting securely to your Cloud SQL instances Postgres: For an IAM user account, this is the user’s email address. For a service account, it is the service account’s email without the .gserviceaccount.com domain suffix. MySQL: For an IAM user account, this is the user’s email address, without the @ or domain name. For example, for test-user@gmail.com , set the user field to test-user. For a service account, this is the service account’s email address without the @project-id.iam.gserviceaccount.com suffix. ...

BigQueryテーブルへのパーティション追加 概要 既存の非パーティションテーブルを直接パーティションテーブルに変更することはできない 新しいパーティションテーブルを作成し、データをコピーする方法で実現可能 手順 新しいパーティションテーブルの作成とデータのコピー CREATE TABLE `project_id.dataset_id.new_partitioned_table` PARTITION BY DATE(timestamp_column) AS SELECT * FROM `project_id.dataset_id.original_table`; 元のテーブルの削除と新テーブルの名前変更 DROP TABLE `project_id.dataset_id.original_table`; ALTER TABLE `project_id.dataset_id.new_partitioned_table` RENAME TO `project_id.dataset_id.original_table`; 注意点 大量データの場合、時間とリソースを要する パーティションキーの列は適切なデータ型である必要がある テーブル設計に影響を与えるため、慎重な計画が必要 メリット クエリパフォーマンスの向上 コスト削減の可能性 その他 時系列パーティショニング以外に、整数範囲パーティショニングも利用可能 整数範囲パーティショニングを使用する場合は、CREATE TABLE文を適宜調整する

terrarorm init で バケットがなければ作成する バケット名は ${project_id}-${app}-tfstate とする project_id, app は Makefile で指定 terraform コマンドをラップした Makefile app := sample project_id := project-a export init_tfstate_gs: @init_gs_tfstate_if_needed init: init_tfstate_gs @echo "==> Initializing terraform..." @make _tf cmd=init init_if_needed: @if [[ ! -e envs/$(stage)/.terraform ]]; then \ make init; \ fi login: @make _tf cmd=login init_upgrade: @make _tf cmd=init opt="-upgrade=true" init_migrate_state: @make _tf cmd=init opt="-migrate-state" plan: init_if_needed @make _tf cmd=plan apply: init_if_needed @make _tf cmd=apply apply-auto-approve: @make _tf cmd=apply opt=-auto-approve apply-refresh: @make _tf cmd=apply opt=-refresh-only destroy: @make _tf cmd=destroy refresh: @make _tf cmd=refresh show: @make _tf cmd=show output: @make _tf cmd=output opt=-json console: @make _tf cmd=console validate: @make _tf cmd=validate _check_env: @test -e envs/$(stage) || (echo 'No such stage:envs/$(stage) exist.' && exit 1) _tf: _check_env @cd envs/$(stage) && \ terraform $(tf_opt) $(cmd) $(opt) バケット作成スクリプト init_gs_tfstate_if_needed #!/usr/bin/env -S bash -e app=${app:-""} && readonly app region=${region:-"us-central1"} && readonly region main() { if [[ -z ${app} ]]; then echo "==> app is required." exit 1 fi local project_id bucket_tfstate project_id=$(gcloud config get-value project) if [[ -z ${project_id} ]]; then echo "==> project_id is required." exit 1 fi bucket_tfstate="${project_id}-${app}-tfstate" if gsutil ls | grep "gs://${bucket_tfstate}" &>/dev/null; then echo "==> Already tfstate ${bucket_tfstate} exist." return fi echo "==> Creating tfstate ${bucket_tfstate}..." gsutil mb -l "${region}" "gs://${bucket_tfstate}" gsutil versioning set on "gs://${bucket_tfstate}" echo "==> Bucket created!" } main "$@" terraform backend を GCS backet に設定する terraform { backend "gcs" { bucket = "project-a-sample-tfstate" prefix = "terraform/state" } }