/// BANGBOO BLOG ///
■21/5/2 10:14PM
Terrafirma
公式https://www.terraform.io/docs/index.html
導入https://www.terraform.io/guides/core-workflow.html推奨方法https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part1.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part2.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.1.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.2.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.3.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.4.html
チュートリアルhttps://learn.hashicorp.com/collections/terraform/gcp-get-startedHCLhttps://www.terraform.io/docs/language/index.htmlCLI aka cmd(アルファベットリストから使う)https://www.terraform.io/docs/cli/auth/index.htmlGCP用リファレンスhttps://registry.terraform.io/providers/hashicorp/google/latest/docs

お便強https://qiita.com/minamijoyo/items/1f57c62bed781ab8f4d7https://qiita.com/donko_/items/6289bb31fecfce2cda79https://www.apps-gcp.com/infra-automation-01/TerraformでGCP環境を構築してみる | GMOアドパートナーズグループ TECH BLOG byGMO (gmo-ap.jp)https://colsis.jp/blog/gcpterraform/
Infra as codeとしてインフラの構築や設定をコード化できる特にクラウドだと構築の自動化や構成管理等でのレバレッジが強力
■段階
Terraformとは?基本知識とTerraformのメリット4つを紹介 | テックマガジン from FEnetインフラ
必要なリソースをTerraform化>workspaceの活用>main.tfの共通部分をmodule化

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

Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる - Qiitaリソースの差分を無視するlifecycleブロックを使うresource "aws_autoscaling_group" "app_1" {  name = "app-asg-1"  lifecycle {    ignore_changes = ["load_balancers"]    create_before_destroy = true//新しいのを作ってから古いのを削除  }}外部ファイルを文字列として読み込むresource "aws_iam_role" "ec2_role" {  name = "ec2-role"  assume_role_policy = "${file("./ec2_assume_role_policy.json")}"}1つのディレクトリで複数のStateを扱うWorkspaceという機能もあるのですが、個人的には普通にディレクトリを分けて管理する方が楽production/stagingが完全に同じリソース構成で、設定のパラメータの差分がちょっとだけあるという理想的な世界ではWorkspaceでも運用できるかもしれませんが、現実的にはstagingだけリリース前の検証用の一時的なリソースが立ってたりとか、完全に同じ構成にならないことも多いので、モジュールの読み込みの有無や一部の環境だけ存在するリソースなどの差分を吸収できる場所があったほうが都合がよい
Terraform職人再入門2020 - Qiita
モジュールが公式から提供されている
Browse Modules | Terraform Registry

Terraform の terraform.tfvars とは | 30歳未経験からのITエンジニア (se-from30.com)
環境情報は外部ファイルが基本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
実行時に-var-fileで値ファイルを指定して環境などを切り替えると良いかもしれない terrafrom plan -var-file=dev.tfvars terrafrom plan -var-file=prod.tfvars
変数ファイル指定がないときは変数でdefaultに入れておく、descriptionで変数の説明もかける variable "foo" {   type = "string"   default = "default-var"   description = "Sample Variable" }
TerraformでGCPのリソースの作成と変数から値を読み込む - y-zumiの日記 (hatenablog.com)credentials等の秘匿したい変数を外部のファイルやコマンドライン引数から読み込むvariable "credentials_file" {} @var.tf 変数を定義し空にしておくcredentials = file(var.credentials_file) @main.tf ファイルを読むがファイル名は変数terraform plan -var 'project=<PROJECT_ID>' -var 'credentials_file=<NAME>.json' @cmd プロジェクトとクレデンをコマンド時に指定
他にもvars.tfvars設定ファイル(行頭variableが不要)、TF_VAR_環境変数による指定
Input Variables - Configuration Language - Terraform by HashiCorp-var-fileで変数ファイルを明示してcmd、ファイル名は.tfvars/.tfvars.json-varで変数を明示してcmd順序があり後の読込でオーバーライド

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


HCLの変数は基本2種類のlocalとvariablevariableはグローバル変数、ファイル外やコマンドラインから使える
その他の変数参照方法としては(上から優先に適応) コマンド引数 一時的に使用 変数ファイル terraform.tfvars git管理等で外部ファイルで? 環境変数 TF_VAR_<NAME> 実行ログに残らない鍵情報等workspaceは使わない、moduleを限定的に使う
設定をコード化>Gitレポジトリに置く>設定内容、作業履歴の明確化、チームでの運用性向上

■特性TFの影響を反映するのはterraform applyの時だけ、tfファイルとtfstateの差分を実際にリソース作成する
 tfファイルで変更した場合、TFはリソースの再作成を行うので一度消えることになる(大体は単位が権限だったりで影響がないだけでplanで要注意)terraform importはtfファイルからtfstateへ記載だけを行う カレントdirの全.tfファイルor.tf.jsonを評価するのでtfファイルの名は何でもいい
各リソースに対してTF化するかは選択ができるが、TFする場合はそのリソースに必要な全記載をTFファイルに行うterraform import tfResourceID.yourResourceName gcpIdentifier のコマンド terrafrom import google_bigquery_dataset.tf-1 bangboo-prj/test-dataset tfResourceID(リソースIDというようタイプ:リソース種別)はTF指定のもの、yourResourceName (リソース名)は任意のもの 構成ファイル.tfはローカルのものが使われる、importするとtfstateに反映 GCP identifierはTF公式サイトの各サービスの一番下import項目を見ると指定内容が分かるのでGCPを見て拾ってくる terraform state list TF化されているリソースを見る terrarorm apply時にもtfstateは更新される(オプション-refresh=falseで無効可)  またapply時に-target=xxxでデプロイするリソースを特定できる

Syntax - Configuration Language - Terraform by HashiCorp コメントは#が基本、//や/**/も使える
Terraform v0.12で変わるHCLの記述について - Qiita localsや変数、リストやマップ等
Terraform職人再入門2020 - Qiita yamldecodeやjsonencode等
Terraformの基本 - Foreverly (hatenablog.com)
変数 variable(input var)はcmd実行時に変数を上書きできるが、localsはできない outputはapply時にterminalで値が確認できる、moduleから値を取得する

google_bigquery_connection | Resources | hashicorp/google | Terraform Registry
ドット繋ぎで値を扱えるresource "google_sql_database_instance" "instance" {    provider         = google-beta    name             = "my-database-instance"}resource "google_sql_database" "db" {    instance = google_sql_database_instance.instance.name    name     = "db"}

ToSetは値設定をするが順不同で重複を省く
resource "xxx" "aaa" {    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
}
terraform importはリソース単位、更新はできず削除してから追加 terraform state rm google_bigquery_dataset.tf-1
 実設定とimportの内容が違う場合は実設定の情報でtfstate化されるようだ(importは項目を入れ込む感じ?)
  なので実環境に変更を加えるにはterrafrom apply、tfstate化もされtfファイル/tfstate/実設定の3者で同じになる
 apply時にtfstateと実設定が違う場合、例えば既存設定がある場合は重複エラーになりapplyできず、importしtfstateと実設定を同じにしてから、tfファイルの内容をapplyすることが必要

for_eachで書いた.tfをterraform importする | DevelopersIO (classmethod.jp)
 ユーザ指定は user:aaa@xxx.com だったりメールグループなら group:aaa@xxx.com

■既存リソースのTF化のおおよその作業 作業ディレクトリの作成(プロジェクトに対するローカルのフォルダ) プロバイダを指定したtfファイルの作成(gcsにstateを置く設定が良い
  provider "google" {    project = "bangboo-kuso"  }  terraform {    backend "gcs" {      bucket = "bangboo-kuso-terraform"    }  } terraform init ローカルに対して初期化 リソースタイプと名前を定義したtfファイルを作成する(任意のリソース名、基本ユニーク、纏められるものは重複してもいい)
  resource "google_cloudfunctions_function" "fuckin" { ... をtfファイルに記載
   tfResourceID(リソースIDというようタイプ:リソース種別)とyourResourceName (リソース名) だけで リソースタイプや個別パラメータは公式ドキュメントを参照しながら定義 https://registry.terraform.io/providers/hashicorp/google/latest/docs
  (簡単)tfファイル内で1行目以外は空で、terraform planをするとエラーで必要なものが分かるので、それを埋める
  planが通ると自動的に値をサーバから拾ってくる(importすればtfstate.tfに入っている or コピーしてTFに入れる)
  ※terraform state show tfResourceID.yourResourceName でstateを見てtfファイルにパラメータを定義していく方法もある  TF定義は複数の方法がある、最終GCP公式のRestAPIで確認するしか terraform importする(公式ドキュメントの一番下にimportコマンドの指定がある) terraform planして差分がなくなるまでtfファイルを修正する  import(tfstate)の修正は一度stateから削除する terraform state rm google_bigquery_dataset.tf-1  (既存リソースがあってもあくまでtfファイルとtfstateの差分なのでinitした状態でplanしてもup-to-dateと表示されるだけ)
 tfstateファイルにおかしなものが無いか確認、keyとか含まれないか

■TF公式ドキュメント
google_organization_iam_custom_role | Resources | hashicorp/google | Terraform Registry
google_organization_iam | Resources | hashicorp/google | Terraform Registry
カスタムロールを設定して、組織レベルのIAMでそれを使いたい
 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  member  = "user:jane@example.com"}

resourceの2番目リソース名を定義しますが任意の名前を指定します
 ここが同じ項目はユニーク制限がない場合は追加としてまとめられます
 通常はユニークにしterraformで管理するリソース名(yourResourceName)を宣言します
  ※1番目のリソースタイプ内でユニークにするのが基本(全体でもユニークの方が分かり易い)
TFファイルに定義をしたい →定義したいリソースのArgument referenceの項目を設定TFファイルに定義した内容を変数で使いたい →使いたいリソースのAttributes referenceを見る
terraform importしたい →インポしたいリソースのページ一番下のimportコマンドの指定を見る

■他に一般的なTF(既存がimportされると以下で変更をapplyして運用) terraform -v 稼働確認
 terraform fmt ファイルの記述フォーマットを整える terraform validate ファイルの検証 terraform plan アクションを計画
 terraform apply 最後に変更を適応 terraform show ステータスを確認、一覧 terraform destroy で簡単にインフラの吐き、initができないとき必要そう

■特定のリソースだけ適応したい terraform plan -target="tfResourceID.yourResourceName"
 terraform apply -target="tfResourceID.yourResourceName"

■TFのcount
数を指定してその個数のリソースを作る。なのだが enable_lien = true モジュール側/変数側でこう設定し count = var.enable_lien ? 1 : 0 リソース側で3項演算子を使えばIFのように使える
  ※for loopのようなインクリのcount"+="でなく"="の1発実行なので3項演算子でIFになる
■tfenvを使う場合cd my-repoget clone https://bitbucket/bangboo-prj.gitcd bangboo-prjtfenv use 0.14.7 terraform workspace list terraform workspace select default デフォルト  terraform workspace new prod prodという名で作成ならmain.tf作成し記載 terraform fmt tfファイルのフォーマット(書式は適当で書けばいい)  gcloud auth list 認証確認  gcloud auth application-default login クレデンシャルが必要なら   API&Servicesでクレデンシャルは取得できそう、key=xxxxterraform initテラフォーマで既存のリソースを調査するにはterraformer import google list --projects=xxxx-123 で対象のリソース確認terraformer import google --resources=instances,forwardingRules --regions=us-west1 --projects=xxxx-123 とかterrafrom import google_storage_bucket.pri-bucket project-abc123/asia-northeast1/pri-bucket でimportとか terraform refresh tfstateの最新化、どのタイミングで使う?
既存リソースimport
https://www.apps-gcp.com/terraformit-gcp/https://qiita.com/uu4k/items/48d3ecfefe57dba1d7e1

■Terraform applyで意図しない権限削除で障害が発生する
Terraform x GCP で、IAM権限を全削除してしまった - Qiita
resource "google_project_iam_policy" "unko" {  project = "my-project"  role = "roles/noguso"  members = [    "serviceAccount:${google_service_account.baka.email}"  ]}google_project_iam_policy:書き換えるので他は無くなる(他を消したいときに使う)google_project_iam_binding:付与、Authritativeだが他は現状維持?
google_project_iam_member:付与、Non-authoritativeで安全、まとめ難いか
 ※_iam_policyと_iam_bindingとt_iam_memberは一緒に使えない ※_iam_bindingと_iam_memberは一緒に使える
google_bigquery_dataset_iam_binding:(承認済みビューの権限はなくなる>google_bigquery_dataset_accessを使え)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しないといけなかったり

■gcloud cmdhttps://www.devsamurai.com/ja/gcp-terraform-101/ gcloud projects list 権限あるプロジェクトを表示 gcloud config set project [prjID] ワーキングプロジェクトの設定 gcloud services enable iam.googleapis.com サービスの有効化 gcloud iam service-accounts create terraform-serviceaccount \  --display-name "Account for Terraform" サービスアカウント作成 gcloud projects add-iam-policy-binding [PROJECT_ID]  --member serviceAccount:terraform-serviceaccount@[PROJECT_ID].iam.gserviceaccount.com --role roles/editor 権限付与 gcloud iam service-accounts keys create path_to_save/account.json  --iam-account terraform-serviceaccount@[PROJECT_ID].iam.gserviceaccount.com クレデン発行 export GOOGLE_CLOUD_KEYFILE_JSON=path_to/account.json クレデン設定
↑サービスアカウントで認証 環境変数にファイルパスを渡す
 gcloud auth application-default login だと個人
 これにクレデンシャルファイルのパスを渡すとサービスアカウントでgcloudコマンド打てるはず
Terraformで複数リージョンをまたいだリソース制御する (mosuke.tech)
Terraform workspaceを利用して環境毎のリソース名の変更を行う (mosuke.tech)


End
Comment (0)

■21/3/9 11:39PM
Treachery
[Click for image]
:||

2021/4/25に気づいた、ハニーちゃんおめでとうとありがとう、エピソードは今度どこかで
Comment (0)

■21/3/6 1:43PM
ZERO
[Click for image]
値段と糖質とプリン体と度数、モノによっては明らかに太る感じがしない、ゆって0じゃ無い安酒でも糖質15g位らしいので良いのがなければいつものでいいかも。それより現像ができない!!→LR再インスコ→LRよりSony謹製の方が色が良かった→元画像が暗すぎが理由→LRでノイズを追加調整(元画像に注意、14mmf1.8の使い道がなく勿体ない)
極ZERO: 138/0/0/5 ちょい高、不味い、5%で軽いが酔えなくはない、太る感じ×Asahi Off: 118/0/0/3-4 酔えない、ノンアルの亜種かフルーティで旨い〇のどごしZERO: 118/0/0/4 フルーティで旨い、軽いが酔えなくはない〇贅沢ZERO: 118/0/x/6 プリン有 6%で嬉しいが雑味がすごくある気が▲バーリアル糖質50%off緑: 85/5-10/?/4 かるくない、そもそもZEROでないが旨い◯+氷結ZEROレモン: 108/0/0/5  レモンが強く旨い、飲みやすい◎鏡月焼酎ハイ: 98/0/0/7 スッキリ高アルコール度で満足感、ドライが好きかも◯+いいちんこ下町のハイボール: 168/0/0/7 高ぇ、重い感じがする▲
パーフェクトサントリービール: 168/0/x/5.5 高ぇ、旨い〇 →氷結Zeroレモン>鏡月ドライのコンボが強い
イオン麻婆豆腐辛口(肉付)vs丸美屋辛口(花椒なし):丸は味穏やか、Aは塩と肉多い →Aeonのとろみ入れるの減らす、甘口は邪魔甘さで、中辛が一番いいイオン四川式(肉無)vs丸美屋大辛(花椒付):Aは高いし辛い、お口は甘め好きda
 冷食が新しくなった、Palmボックスは忘れて何度か買ったが小さい

「カルト」はすぐ隣に: オウムに引き寄せられた若者たち (岩波ジュニア新書) | 紹子, 江川 |本 | 通販 | Amazon
霊的体験は飲み物にLSDを入れていたとなっている、まぁ殆どコレで教祖になれる


Comment (0)

Navi: <  1 | 2 | 3 | 4  >
-Home
-Column [122]
-Europe [9]
-Gadget [73]
-Web [111]
-Bike [3]

@/// BANGBOO BLOG ///