データの種類でアーキテクチャを決める？

　コンテナはオーバヘッドが少なくVM/GCEに比べ軽量高速、スケールアップ/ダウンに優れている

GCS
　IAPを使うと画像アクセスにも認証が使えそう＞LBのバックエンドではIAPが使えない
　　GCEにGCSマウントするとGCEのIAPとしてイケる、gcsfuseのOSSでLinux上のドライブになる
　　　CensOS6.8にgcsfuseをインストールしてGCSをマウント - Qiita
　　　GCS Fuseを使ってみる - Qiita
　リテンションで保護期間を設定したり、ライフサイクルで削除時期を設定したり
　世代管理ができたり

■制約が重要そうでまとめて記載したい

default VPCネットワークを削除（セキュリティが緩いため）

vpcネットワーク作成 サブネットIPレンジ 10.27.0.0/16-192.168.27.0/24 等で

　private google accessはオンでいいのか?on

　FWはひとまずなしで、だが大体ポートは22,80,443,8080?

別途firewallで下記を設定（ちなみにリクエスト側を許可すればよく、レスポンス側は自動）

bangboo-fw-allow-iap-ssh IAPからのSSHを許可 35.235.240.0/20 tcp:22

　レンジはマニュアル https://cloud.google.com/iap/docs/using-tcp-forwarding#create-firewall-rule

bangboo-fw-allow-lb GFE(Google Front End)からのHTTPを許可 35.191.0.0/16,130.211.0.0/22 tcp:qll

　レンジはマニュアル https://cloud.google.com/load-balancing/docs/health-checks#fw-rule

Cloud NAT(Router)を設定

https://cloud-ace.jp/column/detail260/

https://www.topgate.co.jp/google-cloud-network-security

　インスタンステンプレートのメタデータ

　　起動スクリプトをファイル化できる

　　　キーstartup-script or shutdown-script、値にパス

　　　キーstartup-script-url or shutdown-script-url、値にGCSのURL
　　OSLoginをIAPにしてVM上の独自ID管理PW管理不要に
　　　便利機能「OS Login」を使ってIAMでインスタンスへのSSH接続制限をする | apps-gcp.com
　　　キーenable-oslogin、値にTRUE、IAMで権限（compute OSLogin/IAP tunnel/gce系）、IAP API有効
　　　　権限もIAMで管理されるのでLINUX上の755等も不要なようだ（computeinstanceAdmin.v1を付けとく）

　　MIGとLBと同じヘルスチェックを使うことは非推奨

　　　LBはより短い低い閾値にせよ

　IAPを見るとLBを設定するとFWはLBに対するものだけになるので不要との指示がある

　　fw-bangboo-http-ingress-allow　0.0.0.0/0（削除）

　　下記はインスタンス作成時の許可設定分で不要

　　　default-allow-internal　69.11.0.0/9（削除）　default-allow-http　0.0.0.0/0（削除）
　　　これも不要？default-allow-http 0.0.0.0/0 tcp:443（削除）default-allow-icmp 0.0.0.0/0（削除）
　　　default-allow-rdp 0.0.0.0/0 tcp:3389（削除）default-allow-ssh 0.0.0.0/0 tcp:22（削除）
　IAP(ssh/tcp)を見るとFWで開けてくれの指定があるが開けるとhttpsに穴ができると出るし止め
　　fw-bangboo-lb-iap-tcp-allow  Source IP range:072.72.2.0/20 tcp:all（sshターミナルを使う時だけFW開ける、通常priority9000）

CloudSQL

　APIライブラリからCloud SQL API、Cloud SQL Admin APIを有効に

　平文通信→暗号化CloudSQL proxyバイナリをVMインスコ、ディレクトリ切る

　　proxyとアプリ設定を合わせる、proxyサービス起動

　　↑Readyになってからコマンドが返るのに何分か掛かる
　　もう一つSSHを開くと下記コマンドが通る
　　mysql -u root -p -S /cloudsqlproxy/bangboo-sql:asia-northeast1:mysql-01
FW/ArmorでIngress全止め or VMインスタンス停止、LB停止

■GCE MIGローリング更新
■インスタンススケジュール

sute16　asia-northeast1-b　2021/7/24(91日で33000yen-10/20位まで)
sute3　asia-northeast1-b　2022/2/20(91日で34500yen-5/20位まで)

Instance groupはどう止める？＞LB削除＞LBのバックエンド削除＞Instance group削除
　LBはinstance groupがいる、IAPはGCEの場合はLBにSSL証明書要る（ドメインもGlobalIPも要る）
　　DNSのAレコードを登録しLB設定すれば証明書入る
　　　毎回検証終了時につぶして、立てるのが面倒そうだな→FWでdeny allしとく
　【初心者】GCP Identity-Aware Proxy (IAP), Access Context Managerを使ってみる (WEBサーバへのアクセス制限) - Qiita
　Oauth同意画面のサポートメールはログインしているユーザのものか、そいつがオーナになっているGoogle workspaceのメールグループを設定することができる（gcpのロールとしてwnerかoauthconfig.editorも要る）

protoPayload.request.policy.bindings.role="organizations/123456/roles/unco"

protoPayload.methodName="SetlamPolicy"

--操作者

--protoPayload.authenticationInfo.principalEmail="kuso@dayo.com"

/// BQテーブル、ビュー作成
protoPayload.methodName="google.cloud.bigquery.v2.TableServiceInsertTable"

resource.labels.instance_id="12234567898"

severity=WARNING

例えばGKE使用しているアセット情報（GKE cluster）

gcloud asset search-all-resources \

--scope=organizations/組織の数字ID \

--asset-types=container.googleapis.com/Cluster

■GCPディスク容量
コンソールからディスクに入り編集で容量追加

　公開イメージのブートは自動変更される

　カスタムイメージや非ブートディスクは手動変更が必要

　手動方法は下記参照

/// BANGBOO BLOG /// - Linux cmd

■ZOZOの新米Google cloud管理者
新米Google Cloud管理者の奮闘記のその後 〜Organizationの秩序を維持する試み〜 - ZOZO TECH BLOG

GCPを活用するスキルを問われる「Associate Cloud Engineer」

インフラストラクチャの知識を問われる「Professional Cloud Architect」

データと機械学習の知識を問われる「Professional Data Engineer」

　マシーンラーニング：教師ありをベースにパターンを線形として認識し相似のパターンを見つける

　ディープラーニング：人間が把握できる次元のデータ構造ではない多次元でパターンを見つける
　　線形検索みたいなもんか

無料枠

GCE:プリエンプティブル以外の1つの以下のe2-micro VMインスタンスと30GB/月の標準永続ディスク

　オレゴン: us-west1

　アイオワ: us-central1

　サウスカロライナ: us-east1
GCS: 5GB/月のRegional Storage（米国リージョンのみ）

　月額のプロダクトを日割レポートで見ると2月の日割りは高く見え、3月は安く見える

　為替の影響は月初から適応されるので円安だと高いよ

GCP ハンズオンセミナー Google_Cloud_GCPHandson_infra1122.pdf (cloudplatformonline.com)

　GKE, Cloud SQL, Dataflow等

■IAM(Identity and Access Management)　
https://cloud.google.com/iam/docs/overview?hl=ja

https://cloud.google.com/iam?hl=ja
IAMベストプラクティス　https://cloud.google.com/iam/docs/using-iam-securely
操作方法　https://cloud.google.com/iam/docs/how-to?hl=ja
ロール　https://cloud.google.com/iam/docs/understanding-roles?hl=ja

https://www.isoroot.jp/blog/1244/

https://medium.com/google-cloud-jp/gcp-iam-beginner-b2e1ef7ad9c2

/// BANGBOO BLOG /// - GCP ログ調査 Logging/Bigquery information schema

■GCS
■GCP Cloud asset inventory

公式

https://www.terraform.io/docs/index.html
GCP用リファレンス

https://registry.terraform.io/providers/hashicorp/google/latest/docs

お便強

https://qiita.com/minamijoyo/items/1f57c62bed781ab8f4d7

https://qiita.com/donko_/items/6289bb31fecfce2cda79

https://www.apps-gcp.com/infra-automation-01/

https://colsis.jp/blog/gcpterraform/

moduleは構成に合わないようなリファクタリングが必要になった時にterraform state mv が必要になってとたんにつらい、moduleを細分化しすぎるとvariable と output が大量に必要になって書きづらい、moduleは再利用できる複数のリソースの単位（プログラミング言語でいうところの関数みたいなもの）で作るのがしっくり

環境情報は外部ファイルが基本

prd/stg/dev環境はprd.tfvars, stg.tfvars, dev.tfvarsを用意

.tfvars　各環境の設定

aws_access_key    = "XXXXXXXXXXXXXXXXXXXX"

aws_secret_key    = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

aws_region        = "eu-west-1"

main.tf

terraform {

  required_version = "= 0.12.26"

}

provider "aws" {

  version    = "2.66.0"

  access_key = var.aws_access_key

  secret_key = var.aws_secret_key

  region     = var.aws_region

}

var.tf　空の受け皿

variable aws_access_key {}

variable aws_secret_key {}

variable aws_region {}

Terraform で変数を使う - Qiita

credentials等の秘匿したい変数を外部のファイルやコマンドライン引数から読み込む

variable "credentials_file" {}　＠var.tf　変数を定義し空にしておく

credentials = file(var.credentials_file)　＠main.tf　ファイルを読むがファイル名は変数

terraform plan -var 'project=' -var 'credentials_file=.json'　＠cmd　プロジェクトとクレデンをコマンド時に指定
他にもvars.tfvars設定ファイル(行頭variableが不要)、TF_VAR_環境変数による指定

Terraformのベストなプラクティスってなんだろうか | フューチャー技術ブログ (future-architect.github.io)
Workspace派、module派、ディレクトリ分離派

HCLの変数は基本2種類のlocalとvariable

variableはグローバル変数、ファイル外やコマンドラインから使える

変数

　variable(input var)はcmd実行時に変数を上書きできるが、localsはできない

　outputはapply時にterminalで値が確認できる、moduleから値を取得する

google_bigquery_connection | Resources | hashicorp/google | Terraform Registry
ドット繋ぎで値を扱える

    for_each = toset(["foo", "bar", "bar"])　でbar, foo

    name = each.key

}

for_each/eachのループ
locals {
    sg = {

        foo = "FOO"
        bar = "BAR"
    }

}
resource "xxx" "aaa" {
    for_each = local.sg
    name = each.key
    description = each.value
}

　　provider "google" {

　　  project = "bangboo-kuso"

　　}

　　terraform {

　　  backend "gcs" {

　　    bucket = "bangboo-kuso-terraform"

　　  }

　　}

　プロジェクトレベルownerのサービスアカウントを持っておく

　セットアップする際にtfsateのbackend保存場所のbucket部分をコメントアウト

　bucketを作るterraformを実施しbucketを作成しつつlocalにtfstateファイルを作成

　再度terraformをするとtfstateファイルがbucketにコピーされる

　bucket部分のコメントアウトを外すと次回tfからはバケットにtfstate更新する
　　このときローカルtfstateの内容をバケットに写すか聞かれるが写す
　　（写さないと差分しかバケットに行かないのでimport等が必要になる）

　リソースタイプや個別パラメータは公式ドキュメントを参照しながら定義

　https://registry.terraform.io/providers/hashicorp/google/latest/docs

リファレンスでoptionalとなっていてもtfファイルでは必要な場合もある

　tfstateファイルからは必要ないとして自動的に削除されるが

スプシをBQでみれるFederatedQueryはテーブルだけ定義しimportしstate show調査

　urlをTFファイルに記載する

シャーディング（日付別）テーブルは定義できないのでは

　生成するクエリの方をTF化したい
Authorized viewはモジュールがあるがconflictがあり全消えする場合がありTF化にまだ向かない

　TFのorg_iamページのArgument referenceのrole項目を見ると

　　Note that custom roles must be of the format organizations/{{org_id}}/roles/{{role_id}}

　TFのorg_iam_custom_roleページのAttributes  referenceのrole項目を見ると

　　id - an identifier for the resource with the format organizations/{{org_id}}/roles/{{role_id}}
　で下記と分かる、使用側と被使用側のTFマニュアルを両方確認する

resource "google_organization_iam_custom_role" "my-custom-role" {

  role_id     = "myCustomRole"

  org_id      = "123456789"

  title       = "My Custom Role"

  description = "A description"

  permissions = ["iam.roles.list", "iam.roles.create", "iam.roles.delete"]

}

resource "google_organization_iam_member" "my-organization" {

  org_id  = "123456789"

  role    = google_organization_iam_custom_role.my-custom-role.id
  #あるいは通常"roles/bigquery.dataEditor"のようにいれるがorganizations/0123456789/roles/chinkoといれる

  member  = "user:jane@example.com"

}
↑
resourceの2番目リソース名を定義しますが任意の名前を指定します
　ここが同じ項目はユニーク制限がない場合は追加としてまとめられます
　通常はユニークにしterraformで管理するリソース名(yourResourceName)を宣言します
　　※1番目のリソースタイプ内でユニークにするのが基本（全体でもユニークの方が分かり易い）

■TFのcount
数を指定してその個数のリソースを作る。なのだが

　enable_lien = true　モジュール側/変数側でこう設定し

　count = var.enable_lien ? 1 : 0　リソース側で3項演算子を使えばIFのように使える
　　※for loopのようなインクリのcount"+="でなく"="の1発実行なので3項演算子でIFになる

gcloud auth login --enable-gdrive-access

gcloud auth application-default login --scopes="https://www.googleapis.com/auth/drive","https://www.googleapis.com/auth/cloud-platform"

排他処理でロックが残る：

他の作業者がいなければ、terraform apply -lock=false で一時的に無視をして続行
エラーIDに対して terraform force-unlock id_num963103164

Terraform と gcloud CLI を使用した完璧な Google Cloud インフラストラクチャの構築 | Google Cloud Blog
gcloud beta resource-config bulk-export --help
gcloud beta resource-config bulk-export --project=kuso12345 --resource-format=terraform --path=/path/to/dir/
　対応を見ると数が少ないgcloud beta resource-config list-resource-types --format=json --project=kuso12345

terraformer import google list --projects=xxxx-123　で対象のリソース確認

terraformer import google --resources=instances,forwardingRules --regions=us-west1 --projects=xxxx-123　とか

https://www.apps-gcp.com/terraformit-gcp/

https://qiita.com/uu4k/items/48d3ecfefe57dba1d7e1

■Terraform applyで意図しない権限削除で障害が発生する
Terraform x GCP で、IAM権限を全削除してしまった - Qiita
google_bigquery_dataset_iam_member：roleとmemberを1対1でresourceを作りまくる、Non-authoritative
　※_iam_policyや_bindingはまとめ易そうだが権限消しそう


Terraform で GCP のサービスアカウントを管理する - Eng (なりたい) (hatenablog.com)
Terraform で GCP IAM 設定どれ使うのがいいのか - pokutuna (scrapbox.io)
google_project_iam | Resources | hashicorp/google | Terraform Registry
Authoritative: TFに明示していないものをApply時に削除しますという意、TFの権威
Non-authoritative: TFは権威を示さず、TFに明示していないものは現状維持ですという意

■勝手に公開
terraform vpc auto_create_subnetworks = falseにせなサブネットを公開して作りよる

■Applyの依存関係はdepends_on(プロジェクト作成の前に権限を付与しようとしてエラー等の順序)
[Terraform]Module間の値の受け渡しについて | DevelopersIO (classmethod.jp)
　これより先にあれをTFしてくれという記述

■データセット
google_bigquery_dataset | Resources | hashicorp/google | Terraform Registry
スキーマ取得: bq show --schema --format=prettyjson bangboo-prj:test-dataset.tbl001
ビューはコンソール＞BQ＞該当ビュー＞detailからコピー

■組織ポリシー
google_organization_policy | Resources | hashicorp/google | Terraform Registry
制約について  |  Resource Manager のドキュメント  |  Google Cloud

■parallelismで早くなるかもしれない
あなたのterraform planを手軽に高速化する（かもしれない）魔法の言葉 - Qiita

■テスト
TF Apply後には検証をしっかりしたい、最低Apply後にPlanを再実行したい、テストスクリプト的にチェックしたい
適応されていないことや、TF定義とtfstateと実設定の差分が想定と違うことがある感じがするからだ
moduleを含めて条件的な書き方だと、適応の順序の関係で適応が抜け2回以上TF applyしないといけなかったり

■TFファイルを分割し部分的に別環境へTFファイルを移行したい
tf stateファイルを新環境用にコピー
TFファイルを分割：現行の部分的に削除したTFファイル、と新環境用のTFファイルを準備
tf stateから不要部分を削除
　terrafrom state rm {{asset}}
terrafrom planで差分がないことを確認
新環境用にコピーしたtf stateファイルを編集し準備
　下の terraform state push xxx.tfstate で変更された状態をtf stateファイルに書き戻すことができる？
　このコマンドを実行する前に必要に応じて terraform state pull で最新の状態を取得？

　ダメなら terraform state rm で不要分を削る

新環境用にtfファイルを準備
新環境で下記を実行
　terraform init
　terraform state push xxx.tfstate
　terraform planで差分がないことを確認

　これにクレデンシャルファイルのパスを渡すとサービスアカウントでgcloudコマンド打てるはず