/// BANGBOO BLOG ///
■21/5/21 12:00AM
GCP part2
■サービスアカウントの種類
サービスエージェントとは何か - G-gen Tech Blog
サービス アカウントのタイプ  |  IAM のドキュメント  |  Google Cloud
１）ユーザー管理サービス アカウント例　service-account-name@project-id.iam.gserviceaccount.com　プロジェクト名がサブドメインについている２）デフォルトのサービス アカウント例　project-number-compute@developer.gserviceaccount.com３）Google マネージド サービス アカウント　３－１）サービス固有のサービス エージェント例　　service-PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com　３－２）Google API サービス エージェント例　　project-number@cloudservices.gserviceaccount.com 　３－３）Google 管理のサービス アカウントのロール マネージャー例　　service-agent-manager@system.gserviceaccount.com
１は所有プロジェクト名で判断できる、それ以外はdeveloperやgcp-やcloudservicesやsystem
３－１、３－２はSAだがサービスエージェントとも言われるService agents  |  IAM Documentation  |  Google Cloud

■Artifact registryArtifact registryt APIの有効化kusoリポジトリ作成 format=docker, mode=standard, region=asia-northeast1
権限を設定（詳しくはマニュアル要確認）
標準リポジトリへの移行  |  Artifact Registry のドキュメント  |  Google Cloud
　artifact registry admin
　storage.admin
ROUTEボタンのリダイレクトなら付与Cloud buildのサービスアカウントに付与（cloud build > setting）
操作をしようとするとエラーがでるなら下記のように付与
gcloud projects add-iam-policy-binding prj-xxx -member='serviceAccount:service-123456@gcp-sa-artifactregistry.iam.gservice.com' --role='roles/storage.objectViewer'

※事前にgcloud auth loginが必要gcloud config configurations activate gcp-profilegcloud auth logingcloud auth configure-docker asia-northeast1-docker.pkg.devgcloud builds submit --tag asia-northeast1-docker.pkg.dev/chimpo-prj/kuso/image001
gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGEリポジトリ単位で権限管理ができる、リージョン選択できレイテンシー有利、CRコストはGCS計上だがAR計上で分かりやすい、新機能はARに実装されるリポジトリ名はハイフンOKだがアンスコNG、CRはイメージ名にアプリ名称を付ける感じであったがARはリポジトリ名にアプリ名称/イメージ名に版名を付ける感じに付与名が増えた
■ARホスト名(マルチリージョン)us-docker.pkg.deveurope-docker.pkg.devasia-docker.pkg.dev■ARホスト名(リージョナル)asia-northeast1-docker.pkg.dev
等々
Container registry は下記であったgcloud builds submit --tag gcr.io/PROJECT-ID/IMAGECRで使用しているgcr.ioは元々米国のホスト、asia.gcr.io等が派生した
■CRホスト名(マルチリージョン)gcr.ious.gcr.ioeu.gcr.ioasia.gcr.io

※CRからARの移行でROUTEボタンで有効にすれば、CRへのコマンドはARに転送、コンテナもARにsubmitできる※ARにコンテナを最初に置いておきたい場合は gcraneコマンドでコピーできる

■GCPディスク容量
コンソールからディスクに入り編集で容量追加永続ディスクのサイズを増やす  |  Compute Engine ドキュメント  |  Google Cloud　公開イメージのブートは自動変更される　カスタムイメージや非ブートディスクは手動変更が必要　手動方法は下記参照/// BANGBOO BLOG /// - Linux cmd

■GCPでsudo apt-get updateができないときGoogle Cloud PackagesのGPGでエラー。2018/04/02 #googlecloud - Qiitawget https://packages.cloud.google.com/apt/doc/apt-key.gpgapt-key add apt-key.gpg

■GCEでの通信（GCEのサービスアカウントとホスト上のOSLoginユーザの違い）
Google APIはSAで行く（SAに各権限を付けておく）ただgcloud compute start-iap-tunel はSAで行くが　サービスアカウントユーザロールで実行者とSAを紐づけて行く？
　（サービスアカウントに操作するユーザのserviceAccountUserの権限が必要）その他のhttpsアクセスやls等コマンドはホスト上の実行者で行く
■IAPトンネルで内部IPでも外部に出る設定
#権限
ユーザ利用のGCEのSAのIAPトンネル権限を踏み台IAPにつける
SAに利用ユーザに対するserviceAccountUserの権限を付ける#GCEインスタンスにSSHをし下記を実行#自分に通信するプロキシexport http_proxy=http://localhost:3128export https_proxy=http://localhost:3128#それを転送するgcloud compute start-iap-tunnel --zone asia-northeast1-a gce-host-proxy001 3128 --local-host-port=localhost:3128 --project=bangboo-kuso-proxy &#外部通信git clone xxx#止める(止めないと同じホストに繋ぎに行く）
lsof -i 3128
ps ax | grep 3128
ps ax | iapps　からの　kill -kill <iap ps>　でできそうにないgcloud auth revoke　からの gcloud auth login の再ログイン？export -n http_proxyexport -n http_proxy
■踏み台経由して他のインスタンスに接続#踏み台に接続gcloud compute ssh step-fumidai001 --project=bangboo-unco --zone=asia-notrheast2-a --tunnel-through-iap#リストを出し該当ホストを見つけるgcloud compute instances list#踏み台から他のへ接続instance=bangboo-kamigcloud compute ssh $instance --internal-ip --zone=asia-northeast2-a

#もしGKEなら接続前にstep-fumidai001でクレデンシャルが必要だったり、、、gcloud container clusters get-credentials main -zone asia-northeast2-a --project bangboo-k8s

■curlで認証を受けながらのURLアクセス●gcloud auth loginしていると、、curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://宛先
●SAキーをアップロードなら、、export GOOGLE_APPLICATION_CREDENTIALS="/home/aho/sa-key.json"　この環境変数はgcloudライブラリ/SDK等が認証情報として参照するようになっているaccess_token=$(gcloud auth application-default print-access-token)curl -H "Authorization: Bearer $access_token" https://kuso.com/api/endpoint

■キー３種サービスアカウントキー
APIキー
credentials（Oauth clientIDを作成しキー生成）
■Workload identity federation使うサービスがIdPを持ってWIF対応していればSAキー無く使用できる(GCPのSAは要る)●GCP<-AWS,Github,EKS等OpenID connect/SAML2.0事前設定）GCP SAを作成し権限付与　GCPにWIプールを作成　GCP WIプールで該当IdPを認証、外部アカウントを紐づける1)UserがIdPにリクエスト2)IdPがUserを割り当てたIDトークン(JWT)発行3)IdPがIDトークンをGCPに検証　組織を限定するGCP設定　リポジトリを限定するGCP設定4)GCPがWIF一時トークンを発行しUserがGCPリソースを使用Workload Identity Federationを図で理解する - Carpe Diem (hatenablog.com)

●GCP<-GKEクラスタは他の方法もある
●●GKEのSA設定（WIF以外）1)ノードに紐付いたサービスアカウントを使用する
　GKEクラスタ作成時にIAM SAを指定かGCEデフォSAが設定されるのでこれでGCP使用　GKEノードのワークロード全てで同一のSAが使用されPod毎に権限を分けられない　GKE のワークロードから GCP サービスへ 安全 にアクセスする 〜 Workload Identity 入門 〜 (zenn.dev)　　GKEの中身はGCEなのでGCEインスタンスのSAを見る？GCEが無いかも　　GKEがAutopilotならWIFが有効でノードSAがGoogleAPI用には使えない？2)SAのキーを Kubernetes SecretリソースとしてGKEクラスタに登録
　IAM SA キーの有効期限が長く、手動でログローテーションが必要な点が懸念　エクスポートした IAM SA の流出リスクがある　　GCP SAとキーを作成しキーをマニフェストに設定
●●GKEのためのWIF利用（推奨）GKE node SA @project.iam.serviceaccount.com を pool name - namespace の WIプールでGOP SA の pool-namespace@project.iam.serviceaccount.contに紐づける
　コマンドやマニフェストで詳しくはLink先で
　ブールを有効化するとノードSAが使えなくなるので注意GKE クラスタ内のワークロードから Google Cloud APIs にアクセスする（Workload Identity） - G-gen Tech Blog
■GCEでOSConfigAgent のエラー(apt updateが失敗する、リポジトリが変わった）sudo apt-allow-releaseinfo-change updateを複数回実行することで新しいリポジトリが追加される
■SAでGoogleドライブにアクセスOUを使う解決策。Trusted RuleによりGCP サービスアカウントからGoogle Driveへのアク セスを許可する方法です。サービスアカウントのグループがアクセス可能なOUを作りOU内 で専用共有ドライブを作成する。
■IAM>PAM
一時付与の権限申請ができる

■スクリプトによる権限付与IAM を使用してリソースへのアクセスを制御する  |  BigQuery  |  Google CloudGrant文、BQ、Python　等の方法がある
■ZOZOの新米Google cloud管理者
新米Google Cloud管理者の奮闘記のその後 〜Organizationの秩序を維持する試み〜 - ZOZO TECH BLOG

■データ
次世代データ基盤：データレイクハウスを Google Cloud で実現する (zenn.dev)
↓
■BigQuery CDC(Change data capture)upsert/delをBQ storage write APIを利用してリアルタイム反映ができるすでにDatastream for BQの裏で利用されており、PostgreSQL/MySQL/Oracle等データ同期可変更データ キャプチャを使用してテーブル更新をストリーミングする  |  BigQuery  |  Google Cloud
Pub/Sub の BigQuery Change Data Capture 機能について (zenn.dev)

■Binary authorizationGKEやRunに信頼できるコンテナイメージのみをデプロイするための管理ポリシーや承認者を設定してOKのもののみ許可するコンテナ脆弱性スキャン強弱の設定等
■reCaptchav1はゆがんだ文字を入力するもの、v2は画像を選択し私はロボットではありませんとチェック、v3はWeb行動履歴等をスコア化して自動的に判定を行う操作不要のもの（GCPコンソールで結果分析もできる）
■BQ DuetAIBQ studio内にnotebookがありpythonが使える（現在プレビューMLモデルを作成し使用できるクエリで#コメントを書くとSQLを生成したり解説してくれたりする

■Google cloud developer チートシート
Google Cloud Developer Cheat Sheet (googlecloudcheatsheet.withgoogle.com)
システム構成図を書けばTerraformを書いてくれる

■NotebookLM
ASCII.jp：情報整理の決定版「NotebookLM」が最高すぎる。こういうのがほしかったのよ！！ (1/7)
自分専用AIを作る　グーグル「NotebookLM」を家電取説・辞書・時刻表で使う - Impress Watch
今さらながらGoogleの「NotebookLM」を触ったら、インターネットサーフィンが普通にそのまま"仕事"になった話 (zenn.dev)


Comment (0)

■21/5/20 9:00PM
GCP
■GCP(Google Cloud Platform)https://console.developers.google.com/GCPを活用するスキルを問われる「Associate Cloud Engineer」インフラストラクチャの知識を問われる「Professional Cloud Architect」データと機械学習の知識を問われる「Professional Data Engineer」　マシーンラーニング：教師ありをベースにパターンを線形として認識し相似のパターンを見つける　ディープラーニング：人間が把握できる次元のデータ構造ではない多次元でパターンを見つける
　　線形検索みたいなもんか

■GCP
https://techblog.gmo-ap.jp/category/gcp/
https://tech.zeals.co.jp/entry/2019/01/08/094054
https://techblog.gmo-ap.jp/category/tensorflow/

情報源
Solution Design Pattern (gc-solution-design-pattern.jp)
google-cloud-jp – Medium
サポートを付けるとGoogleに聞き放題になったりする　サポートのケースは組織レベルでみると全プロジェクトのケースが見れる

3か月間300 ドル分だけ無料
https://console.cloud.google.com
無料枠Google Cloud の無料プログラムGCE:プリエンプティブル以外の1つの以下のe2-micro VMインスタンスと30GB/月の標準永続ディスク　オレゴン: us-west1　アイオワ: us-central1　サウスカロライナ: us-east1
GCS: 5GB/月のRegional Storage（米国リージョンのみ）
無料だとBigQueryのDML(insert)ができないらしい
予算とアラートを1円で設定（通知チャネルにSMSとメール設定）
　月額のプロダクトを日割レポートで見ると2月の日割りは高く見え、3月は安く見える　為替の影響は月初から適応されるので円安だと高いよ

辞めるときはプロジェクトをシャットダウン＆請求先アカウントの閉鎖
１）プロジェクトの閉鎖
Google Cloud Console ＞ IAMと管理 ＞ 設定 ＞ シャットダウン
２）請求先アカウントの閉鎖（原因不明だが下記画面が出るときと出ないときがった）
Google Cloud Console ＞ お支払い ＞ (左ナビ)アカウント管理 ＞ 請求先アカウントの閉鎖
※お支払い＞マイプロジェクト＞アクション＞無効や請求先変更ができる

セキュリティは使用GoogleアカウントのSMSによる２段階認証、信用するデバイスの設定があるようだ

GCP ハンズオンセミナー Google_Cloud_GCPHandson_infra1122.pdf (cloudplatformonline.com)　GKE, Cloud SQL, Dataflow等
【GCP入門編・第3回】難しくない！ Google Compute Engine (GCE) でのインスタンス起動方法！ | 株式会社トップゲート (topgate.co.jp)
【GCP入門編・第12回】 BigQuery を使って気軽にビッグデータの解析を行ってみよう！ | 株式会社トップゲート (topgate.co.jp)
【GCP入門編・第25回】 Cloud SQL for MySQL で Master-Slave 構成を組もう！ | 株式会社トップゲート (topgate.co.jp)
【GCP入門編・第29回】Cloud Load Balancing で Web アプリケーションにロードバランサーを設定する | 株式会社トップゲート (topgate.co.jp)
【初心者】GCP Identity-Aware Proxy (IAP), Access Context Managerを使ってみる (WEBサーバへのアクセス制限) - Qiita

■IAM(Identity and Access Management)　
https://cloud.google.com/iam/docs/overview?hl=jahttps://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=jahttps://www.isoroot.jp/blog/1244/https://medium.com/google-cloud-jp/gcp-iam-beginner-b2e1ef7ad9c2

//IAMの機能（RBAC認可：role based access control）機械学習を使ったスマート アクセス制御の最適化デバイスのセキュリティ、IP アドレス、リソースタイプ、日時などの属性に基づいて、リソースに対するきめ細かいアクセス制御ポリシー権限の認可、解除、委任に関するすべての監査証跡の履歴ユーザーとグループのプロビジョニングや管理、シングル サインオンの設定、2 要素認証プロセス（2FA）
//IAMポリシー
IDをGroup（●●部）にアサイン　Members(Group等)にRoles（●●役）をアサイン　　MembersとはグループやドメインやID(Googleユーザアカウント、サービスアカウント)　Roles（●●役）にPermissions（権限）を付与
ロールは作成ができ●●世話役みたいな感じか
permissionsは権限で「resourcemanager.projects.get」等でロールに紐づける
　個人や無料アカだと組織がない？→フォルダが作成できない？
　組織がないとグループが作成できない→グループがないとIDにRoleを付与するしか
フォルダは組織ツリー状でリソース管理、組織改編が多いならプロジェクトフォルダでも
　各フォルダに対してそれぞれメールグループを定型(folder-admin/dev/lead/member/parttime/etc)で持たせ　メールグループへのユーザ出し入れで権限の管理をするのが良さそう
IAMやServceAccountの一覧には出てこないが存在するIDがある、実際に権限を付与できるかで存在確認する(TFで作成の場合？)ポリシーはMSのGPOみたいものも組み込みで存在する
サービスアカウントはAPI用、人が使うことは基本想定されていない(impersonate等できるが
ユーザが削除になっても権限やリソースは残る？30日位はdeleted:になって消えるのでは
プリンシパルには@gmail.comのGoogleアカウントやWorkspace契約のある組織ドメインのGWSアカウント等があり、独自ドメインでもGWS契約がない場合は@gmailのように登録しGoogleアカウントにして使用するGCPはGWS gmailメールの変名に追従して権限も付与状態も変化がなく問題がない　しかしterraformは追従しないためtfファイルでメールを使っている場合は変更する外部ドメインのユーザの場合はメールグループ単位でのロール付与が効かず個別アカウントで付与する必要がある？あるいは組織ポリシーを開けっ放し？
APIを有効化せんと何もできないが、するロール roles/serviceusage.serviceUsageAdmin
メールグループの権限関係の確認方法
　仕組み：祖->親->子、上の権限は下も持つ　権限から確認する、所属から確認するの両面で確認　１）権限を持っている全ての子をリストアップ　２）所属しているメールグループの全ての親をリストアップ
//画面上部のプルダウンからプロジェクトを選択できない場合（BQのデータセットにのみ権限がある等）１）BQの左ペーンでデータセット名を検索し（すべてのプロジェクトを検索するため2回必要）スターを付けて代替とする２）データセットレベル権限でもURLパラメータ付きだと選択ができるhttp://console.cloud.googl.com/bigquery?project=bangboo-kuso-project３）IAMの画面で何かしらresourcemanager.projects.listを含むロール、つまりBQ data viewerでOKだがプロジェクトレベルの権限を付与しておく（権限付与後にログインしなおしが必要）※jobuserがないとBQコンソールでプルダウンできない訳ではない（jobuserなしでOK）※グループメールの深い階層で付与されていても影響はしない
//リソース
階層：Organization > Folders > Project > Resource(Google Cloud services)
割り当て：日や分に対してのデータ量の上限等を設定
必要以上に権限を付与しない組み込みロールが多い、改変してロールを作るか権限はサービス名.リソース.動詞という命名規則
プロジェクト名はGCPグローバルで名前空間を共有しており、企業名等でprefixするのがいい
プロジェクト毎にメールグループを設け、権限はメールグループの参加で管理したい
//リージョンとゾーン
リージョン：データセンターの存在場所、ゾーンをいくつか持つ
ゾーン：障害ドメイン区画（単一障害点を避ける形で環境設計したい）
Google Cloud SDKをインストールすればコマンドラインが使える
　BQは同一リージョンでないとJoinができない、ゾーンはマルチで良い
APAC: asia-east(台湾、香港)、asia-northeast(日本、韓国)、asia-south(インド)、asia-southeast(シンガポール、インドネシア)、australia-shoutheast(オーストラリア)NA: northamerica-northeast(モントリオール、トロント)、us-central(アイオワ等)、us-east(バージニア等)、us-west(ネバダ等)リージョンとゾーン  |  Compute Engine ドキュメント  |  Google Cloud

//サブネット、Shared VPC
Shared VPCホストプロジェクトに対しサービスプロジェクトを設定しプロジェクト間を共有
サブネットは通常リージョン内？レガシーだと完全に仮想で自由なサブネット？

//Cloud Shell
Google Cloud Shell の 10 の知っておくと便利な Tips | Google Cloud Blog
ファイルのアップロードやダウンロードが可、コードエディタもありブラウザで完結
Webアプリのプレビューも可
　f1-microのGCE一時インスタンスがプロジェクトをまたいだ永続ディスク5GBで起動されている
　gcludやdocker,bash,sh,vim,nano,pip,git,mysql等がプリインスコされている
　　5GBあるのでインスコもできる　sudo apt-get install gawk　Cloud Shell VM の Zoneを知る：curl metadata/computeMetadata/v1/instance/zone　Ctrl + b キーを押してから % キーを押すとtmux により ウィンドウが左と右のペインに分割Cloud shellのグローバルIPを取得できる　curl http://ifconfig.me/
リスト一覧を出すgcloud cmdgcloud projects list --filter='bangboo-' --format=json | grep -oP '(?<="name": ")[^"]*'　gcloud tasks list  |  Google Cloud CLI Documentation
どのgcloud cmdにも使えるワイルドフラグ--access-token-file, --account, --billing-project, --configuration, --flags-file, --flatten, --format, --help, --impersonate-service-account(人がcmdを打つ場合でも成りすませる、その人にprjレベルの権限が必要), --log-http(cmdでエラーがでるならコレを、詳細が出る), --project, --quiet, --trace-token, --user-output-enabled, --verbosity

各言語でのSDKを使ったプログラムを実行する際の認証を得るために使います
gcloud auth application-default loginローカルで以下のようなGCP系CLIを実行する際の認証を得るために使いますgcloud config configurations listgcloud config configurations create unko-profilegcloud config set account unko@dot.comgcloud config set project onara-project
gcloud config configurations activate unko-profilegcloud auth logingcloud でプロジェクトの切り替え設定 - Qiita
■GCE　Marketplaceを使えばアプリを数クリックでデプロイできる　永続ディスク…NWストレージ、SSD永続ディスクも選択できる　ローカルSSD…高性能、永続ではなく一時的
　非マネージドインスタンスグループ　インスタンスをIGに紐づけるだけ　ステートレスMIG　自動スケーリング（Webフロントエンド等）　　スケジュールでもスケーリングできる(cronや予測も)　ステートフルMIG　設定を保持可（DBやデータ保持必要なstatefulなアプリ等）
　　インスタンス名やIPやディスクやメタを維持する、部分的に外部化ステートレスにして自動化等も　ゾーンMIG＝シングルゾーン、リージョンMIG＝マルチゾーン(最大3ゾーン)
　プリエンプティブは24時間までだが20%課金だけで安い

インスタンスにサービスアカウントを改めて設定するとGoogleAPIはこれで実行される
　改めて設定しないとデフォルトSA
　操作自体はSSHで入るユーザで操作をする
　　設定はsudoして行うことが多く例えばcronはroot実行になっている
　　SSHで入ったユーザで設定するなら所有者/グループ/他のパーミッションを設定した上で

■マネージドクラウドDB各種
ホワイトペーパーPDF

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

■GCS
　http(s)で公開可（そもそも公開しているがAllUsersやAllAuthenticatedUsersや各ユーザに権限がついていないだけ）　Nearline…3カ月でアクセス等（全ファイルを1度閲覧）　Coldline…1.5年でアクセス等長期アーカイブ
　(standard以外は最低保存期間の縛りがあり早期削除でもお金が掛かる)　Multi-regional 99.95%、Regional 99.9%の可用性
　　BigqueryからGCSにエクスポートできるが1GBまで
料金  |  Cloud Storage  |  Google Cloud　　5GBまで無料、リージョンで値段が違う、保存/NW/取得/操作で課金　　nearlineの保存は半額で取得と併せstandardと同じ金額になるが操作費高い　　coldline/archive storageでも長期保存はせずできれば削除する、できないならポリシーでcold/archiveへ移動　　　　最低保存期間の縛り(90/365)があり早期削除でも請求、その期間は置いておく
　　autoclassだとニア→コールド→アーカイブといい感じにしてくれるが1000ファイルにつき0.0025追加料金
　　　※128kb以下は適応されずstdで追加料金もかからない
Autoclassが安全便利でファーストチョイス？単価から370kb程度以下で損する
　バケット作成時に設計をしておく（バケット編集でAutoClassが変更できるようになった）
　　ライフサイクルを決めて削除条件も決めておく
　　バケットを細かく分けた方がよいかも（バケット内でフォルダを作るとコマンドが遅く管理が面倒）
　　　ファイルサイズが大きいもの＝AutoClassが良いかも
　　　ファイルサイズが小さいもの＝OLMでライフサイクル設定（クラスと削除）　ログ保存用途ならColdline/Archive設定＋OLMでの削除設定
gsutil ls -lR gs://aaaa　バケット内の各ファイルのサイズと、最終行でオブジェクト数と合計サイズが分かる（オブジェクト数はフォルダも一つとカウントされる、フォルダはサイズが0）※GCSの注意点早期削除料金の発生がリスク
ストレージクラスはファイルごとに設定がある、バケットはデフォルト設定だけ、AutoClassはバケットオブジェクトライフサイクルマネージメントOLMでストレージクラスの変更すること
早期削除料金は削除、置換、移動、クラス移動でかかるが、OLMのクラス移動ではかからない
OLMの変更はファイル単位で変わりバケット設定をみてもクラスが分からない手動(gsutilやAPIという意味)で変更するとStd以外は早期削除料金で高額化の恐れ　ただしOLMは若返りの方向へのストレージクラス変更はできない
　gsutilやAPIでなら若返りストレージの変更ができるStd以外は保存と閲覧の使用としたい、なぜなら、置換はファイル編集が該当するためファイルサーバとできないから費用は保存費、オペレーション費、NW費、Std以外は取得費等からなり、費用は利用サイズの影響が大きく、通常は保存より利用の費用が高くなる早期削除料金はStd以外で削除されたり更新がかかればファイル単位でかかる早期削除料金は最低保存期間分がかかるがファイル作成日を元に計算されどのストレージであっても日数としてカウントされる
LoggingをBQに吐き出しておけば、利用者やバケット作成者が分かる　protopayload_auditlog.methodName = 'storage.bucket.create'　とかの条件

/// GCSの論理削除によるデータ保護削除や上書き等でも元に戻せる。ソフトデリート適応期間分の費用/オペA費用が掛かるがGoogle Cloud StorageのSoft Deleteで一度削除したファイルを復元してみる | DevelopersIO (classmethod.jp)Cloud Storage soft delete announcement | Google Cloudリストアには大量データの場合は数日かかる場合があり保持期間の延長の考慮が必要 (デフォ7daysでは不足するかも)
パケットの削除のやり直しはGoogleに問い合わせが必要早期削除は物理削除日を元に計算するので論理削除の期間後の日時が使用されるので、7days早めに削除してもいいかも
■GCP Cloud asset inventory　5週間分の履歴が保管される　CAI exportにより任意のタイムスタンプでBQあるいはGCSに履歴情報を吐き出す
　　コマンドやライブラリでダンプが可能　　gcloud asset exportコマンド、Pythonのライブラリ cloud.asset_v1でもBQにダンプできる
　　Cloud Asset Inventory を使用してGoogle Cloud上のアセットを分析する - NRIネットコムBlog (nri-net.com)
　　Cloud Asset Inventory クライアント ライブラリ  |  Cloud Asset Inventory のドキュメント  |  Google Cloud　gcloud CLIのgcould asset search-all-resourseコマンドにより設定
　　BQに吐き出し各種状況のチェックやポリシーのチェックに活用

権限の確認もコマンドでできる　gcloud asset analyze-iam-policy --organization=123456 --identity="user:fack@unko.com"
■Cloud logging
Cloud Audit Logging 活用のベスト プラクティス | Google Cloud BlogStackdriver Loggingのログを失う前にエクスポートしておく方法（前編） | apps-gcp.comStackdriver Loggingのログを失う前にエクスポートしておく方法（後編） | apps-gcp.comGoogle Cloudの監査ログを理解する&長期間保存方法 - NRIネットコム Design and Tech Blog (nri-net.com)
Cloud Loggingの利用方法 | apps-gcp.com
料金  |  オペレーション スイート  |  Google Cloud　毎月取込50GBまで無料、取込0.5$/GB+保存0.01$/GB、2種類ありAuditLogで有効無効化　　管理アクティビティログ　13ヵ月400日デフォ有効（_requiredログバケットは取込もデフォ期間保存も完全無料）　　データアクセスログ　デフォ無効（有効にしてもデフォ保存期間30日は無料、50GBを超える取込が有料）　　　※つまり50GBを超えた取込、あるいは保存期間を伸ばした分が有料
　BQ streaming insert0.05$/GB+BQ保存(10G無料)0.02/GB=0.07$/GBでBQ化し保存が得　　長期保存が必要なものだけエクスポート　　集約エクスポート　　ログ取集前にログシンク(取込費がかからない)
　　　サンプル1%等で絞る等Google Cloud のログ設定 Cloud Logging の概要と一部設定など - QiitaCloud Logging の基本的な使い方 - Qooskyクイックスタート: gcloud CLI を使用したログエントリの書き込みとクエリ  |  Cloud Logging  |  Google Cloud400日の_requiredに入らないものが30日の_defaultに入るLogルータのシンクでフィルタ、サンプリングしLogバケット/GCS/BQ/Pubsubに転送　requiredでなくdefaultに入る時にLogルータを設定しフィルタを掛ければ減る
　自動でSAが作られるので作成や権限付与は不要　　包含フィルタが空なら全ログ　　クエリsample(insertId, 0.10)で10%のサンプルLogバケットのdefault30日は変更できる
全ログをBigqueryに入れるには組織プロジェクトで転送を設定すればいいログ エクスプローラを使用したサンプルクエリ  |  Cloud Logging  |  Google Cloud
Logging のクエリ言語  |  Google Cloud
　/// BANGBOO BLOG /// - GCP ログ調査 Logging/Bigquery information schema クエリ：Loggingをクエリで見る、Logルータのシンクをフィルタ(サンプル)する
■Monitoring
ダッシュボードはサンプルから作ると楽
MQLで改変、クエリを実行するとエラーメッセが出るんでfetch gae_instance::appengine.googleapis.com/flex/cpu/utilization | { top1, max(val()); bottom 1, min(val()) } | UNIONGoogle Cloud metrics  |  Cloud Monitoring　MQLは使えなくなりPromQLに変わった

■APIキー
APIキーを発行することで、外部アプリから利用できるようになる。各種使えるが強力なためAPIを絞る等制限を入れた方がよい、アクセス元のIPアドレスやリファラーで縛る等も
API キーを使用して認証する  |  Google Cloud
【要確認】Google Maps Platform APIキーの取得方法と注意点 | ワードプレステーマTCD (tcd-theme.com)

■サービスアカウント
デフォルトでは上限100個
svacキーはPWと同じ、できるだけ発行せず慎重に管理、gitにUP厳禁svac名や役割を広くしない、強すぎる権限は付与せず最小限の権限でGCEデフォのsvacは使用しない(Editorを持つから)
　サービスアカウントはサービスを有効化したときに動作用に自動作成されたり、別途手動でも作れる
所属のプロジェクトが削除されると：　サービスアカウントは削除できなくなり、権限が残るため権限は個別削除が必要になる　サービスアカウントの権限が残るが、他のプロジェクトで使用できる　一定期間が経つとサービスアカウントの権限も自動削除される　＞プロジェクト削除前にサービスアカウントの無効にするのが望ましいIAMでsvacにロールを付与、IAM>svacでユーザにsvacに対する管理ロールを付与できる組織ポリシーでsvacキーの使用を特定のプロジェクトに制限した方が良いできればキーを作成せず他の方法を　workload identity(gke)、workload identity federation(serverless)　　SAMLみたいなものでGKE、OpenID、AWS、Azure、ActiveDirectory、GoogleCloudAPIは対応している　一発使用ならimpersonateで成り済ませば一連のgcloud cmdは実行できる(下記参照)SAキーの管理方法
　キーの削除、あるいはIAMコンディションにより権限側の変更、あるいはVPCサービスコントロールで制限位しかない
　有効期限の設定は無い、キーローテート機能もなくコマンドで自作するしか（削除と作成をするだけ）
　キーローテートを要求するため、キーは各々で発行してもらう
　　手前でキーを発行した方が、キー削除や追跡ができるがローテートの手間がある、手前だと権限付与も少なくできるが、、

svacキーはRSA鍵ペア、秘密鍵でJWT署名なしトークンを作成（JWT=json web token）　GCP内ではキーが自動rotateされている　外部の場合は手動や仕組みでローテーションしたい　開発環境ではクライアントライブラリとgoogle application credentials環境変数を使い隠匿するサービス アカウント キーを管理するためのベスト プラクティス  |  IAM のドキュメント  |  Google Cloud
Google Cloud SDKのインストールと認証の設定について - TASK NOTES (task-notes.com)
概要 / アジェンダ - Infra OnAir (cloudonair.withgoogle.com)
秘密鍵さえあれば成り済ませ追跡が困難で誰が利用したか等が分からないのでsvacキーは使いたくないsvacキーは10個作成できる
/// svacキー使用方法
サービスアカウントのキーを作成しローカルに保存SSHでGCEのVMに内容をコピペしてキーファイルを作成下記でSAとしてログインgcloud auth activate-service-account ketsu@un.com --key-file /home/ketsu/sakey.jsoncloud shell terminalでもファイルをアップロードできるのでup後下記でOKgcloud auth activate-service-account ketsu@un.com --key-file sakey.jsonログオン切替終わるとき rm sakey.json
shellセッションごとに環境変数でkeyを設定する方法も
認証のスタートガイド  |  Google Cloud

/// サービスアカウントキーを発行せずにサービスアカウント権限を使うサービスアカウントに直接成り代わって gcloud コマンドを実行する - Qiita
サービス アカウントの権限借用の管理  |  IAM のドキュメント  |  Google Cloud
gceにデフォルトsvacが設定されていれば誰で入ってもauthはsvac？パスはユーザだが任意のコマンドに--impersonate-service-account=ワイルドフラグを付けるだけIAM and Resource Manager API を有効化
サービスアカウントに使いたいロールを付与(roles/accesscontextmanager.policyAdminとか)自身にroles/iam.serviceAccountTokenCreatorを付与叩くgcloud info --impersonate-service-account=chinko-compute@developer.gserviceaccount.com　※tfだとproviderにimpersonate_service_accountを追加する形
設定するにはこれらしい　gcloud config set auth/impersonate_service_account chinko-compute@developer.gserviceaccount.comsvacを指定するならこれでもいいがKeyがいる　gcloud auth activate-service-account chinko-compute@developer.gserviceaccount.com --key-file=/himitsu/dame_key.json --project=bangboo-kusoログインユーザ確認で要確認　gcloud auth listgcloudコマンドのリファレンス　gcloud auth activate-service-account  |  Google Cloud CLI Documentation
■セック
Google workspace googleアカウント(特定の経路:IP以外は無効）
組織ポリシー(GCP)　Google Cloud 組織ポリシー - Qiita
　serviceuser.services deny compute.googleapis.com デフォルトcomputeなし　compute.skipDefaultNetworkCreation enforced=true デフォルトcompute nwなし　compute.vmExternalIpAccess inherit_from_parent=true　iam.allowedPolicyMemberDomains inherit_from_parent=true 対象組織 外部ユーザ禁止
　　→allusers/allauthuserも影響する(このためGCSもallusersが設定できず公開にはならない)　iam.allowedPolicyMemberDomains inherit_from_parent=false 対象prj 外部ユーザ許可　storage.uniformBucketLevelAccess enforced=true GCSアクセス制御を均一
　storage.publicAccessPrevention=true 公開しない(allusersも消える、逆にoffってもallusersも要る)　sql.restrictAutherizedNetwork enforced=true CloudSQLのネットワーク制限　compute.restrictLoadBalancerCreationForTypes allow=in:INTERNAL LBは内部だけ許可　compute.restrictLoadBalancerCreationForTypes allow=all=true 対象prj LB許可　compute.disableSerialortAccess enforced=true シリアルポートアクセスの制限　compute.disableSerialortAccess enforced=false 対象prj シリアルポートアクセスの許可BeyondCorp Enterprise(VPNレス、なお下の各要素はこの為だけということではない)┣ IAP┣ IAM┣ Access Context Manager(VPC Service Controls:IPとかメールドメインとか) ┗ Endpoint Verification(Chrome機能拡張)Cloud armor(WAF)、FW
危険な設定はアラートを出したい：security command center、cloud asset inventoryをBQに出し定期スキャン
BigQueryの高額クエリはアラートを出したい

セキュアなBigQueryの運用方法 - Speaker Deck
　IAM condition: 20時以降はアクセスできない等時間やリソースで権限制御　VPC-ServiceControls: VPC+FWで制限を掛けられなかったIPやIDで制限を掛ける(クレデンシャル漏洩防御)
　　LBのバックエンドをGCSにするとIAPが使えない時も
　　TF)perimeterで境界を設定してaccess leveで超えれるものを定義　　　危険で user explicit dry run spec = trueでテストしながら falseで本番化　　　statusが本番用、specがドライラン用で一旦statusを消してテスト　　　　restricted_services = storage.googleapis.com ならGCS　　　　resource　　　　access_levelgoogle_access_context_manager_service_perimeter | Resources | hashicorp/google | Terraform | Terraform Registry

VPCサービスコントロール＋Access context managerVPC SCで組織で有効にするプロジェクトを指定し、上り(内向き)のソース、ID、プロジェクト、サービスを指定、ACMで許可するアクセス元地域やデバイスを指定(beyond corpかも)VPC Service Controls の概要  |  Google Cloud
VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog
サービス境界とアクセスレベルで、特定のユーザーやサービスアカウントからしか BigQuery にアクセスできないようにしてみた | DevelopersIO (classmethod.jp)

GCPでセキュリティガードレールを作るための方法と推しテク - Speaker Deck
　サブネット作成の際はセキュリティの観点からフローログを15分で取る　監査ログを有効に　ContainerResistryの脆弱性スキャンを有効に　ログ：データアクセス/ポリシー拒否は30日、管理アクティビティは400日　　BQにバックアップしたい　SecurityCommandCenterで脆弱性を検知Cloud Audit Logging 活用のベスト プラクティス | Google Cloud Blog
　集約エクスポート シンクにより監査ログをBQに貯めたい
■タグとラベル
組織ポリシーはタグでconditionを指定した上で設定できるタグは権限管理のための機能タグは事前に組織レベルでタグを作成する、その後にリソースに対しタグ付けFWで使うのはネットワークタグで種類が違うと思われるラベルはリソース整理や課金整理のための機能タグとラベルの違いについて (Tags / Labels) - G-gen Tech Blog
■ネットワーク外部IP　External IP addressで取得、300円/月位、通常一つは自動で割り当てられるPoP(Point of presence)　世界70か所でGCPとエッジ(ネット)接続NWトポロジーで通信が可視化でき通信コストが分かるNetwork Topology – Network Intelligence – Google Cloud Platform　詳細開くのは片側だけにすると使用帯域が表示される

■課金
BillingのBilling ExportからBigQueryにダンプができる

■サービスイン、導入、廃止
どういうステップかよくわからんが
GA(Generally available)
サービスに関する重要なお知らせ：MSA(Mandatory service announcement)
Deprecated
Decommission

■他
///gcloudをプロキシで使う環境設定とかhttps://qiita.com/tora470/items/bc00bef8cba9f9acecc7
///Loadbalancer
　IAPはhttp LB/GCE/AppEngineに
　Internal LBにExternal IPは無理

ついでにIAP tunnel userの権限で踏み台が作れる＋OS Loginで認証強化
　OS LoginはIAPの認証機能でSSH上でGCEインスタンスにログインできる代物
　GCPがSSH keyとIAMをGCEに準備してくれる

ついでにリバースプロキシ（nginxとかで作る）
LBみたいなもんだがプロキシでキャッシュを返す
代理代表サーバとなりWEBサーバ界のFWみたいな役割もできる
///NoSQL
=not only sql、分散kvsだったりの非構造化データ、下記2つのみ提供　キーを指定してCRUD(追加、取得、更新、削除)　キーの範囲かキーの前方一致でのスキャン

///bigtable
高スループット低レイテンシー読み書き速く膨大なユーザや数千万件テラ以上でgmail、GA、マップ等々で使われている
///cloud functionsサーバレスでRESTみたいな形でURLでサーバアプリを実行、Node.js/PHP/Python等のコードが直接コンソールに掛ける
　ブラウザでcloud functionsにアクセスしたら下記が出た
Error: Forbidden Your client does not have permission to get URL/kuso-ketsu from this server
呼び出しの認証  |  Google Cloud Functions に関するドキュメントcurl https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME  -H "Authorization: bearer $(gcloud auth print-identity-token)"
↑curlでいいなら、コンソールで[未認証の呼び出しを許可する] 設定 + allusersでも可
///Pub/Sub
パプリッシャーからサブスクライバーにメッセージ転送、順序設定可、大量データを1件ずつとか
publisher -> topic : メッセージ -> push型 subscriberpublisher -> topic : メッセージ -> pull型 subscriber
-> cloud functions/runに連携したり、cloud schedulerから連携をしたり

BQ テーブルにデータをエクスポートする Dataflow ジョブGCS でデータをテキスト ファイルまたは Avro ファイルにエクスポートするための Dataflow ジョブ
///シリアルコンソール接続
SSH接続できない！そんな時のシリアルコンソール | apps-gcp.com
突然起動しなくなったWordPressサーバーをなんとか復旧した話 | (tipstock.net)

///gcloud cmd
gcloud organization list　GCP IDやGoogleWorkspace IDが分かる

///Recommender
API の使用 - 推奨事項  |  Recommender のドキュメント  |  Google Cloud

///Googleスプレッドシート+GAS＋BigQuery
GAS:マクロで記録してそれを使いまわす　GASでBQの制御は難しいかも、更新してもBQのデータが古いままだったりする（appscript.jsonに権限を追記しても）
　　シート経由せずにGASから直にファイルに書き出すとましかも（下記コード参照）　データを一時でも書込ならスプレッドシートの共有の編集権限とシート保護しない設定が必要と思われ（セキュリティがザルに）呼び名　connected sheetでBQのデータをスプシに抽出する　federated queryはBQに外部ソース（スプシ等）をインポートする
スプシの保護（シートはコピーできザルなのでセキュリティ対策でなくデータ保護）
シートを保護する、非表示にする、編集する - パソコン - ドキュメント エディタ ヘルプ (google.com)
スプシの閲覧共有だけでBQコネクテッドシートのプレビュー/抽出は可能だが、それをvlookup系で他のセルに移せない
組織でコネクテッド シートを使用する - Google Workspace 管理者 ヘルプ
↓他のブックにすればいいかも
編集共有した別ブックに入力データ（日付やメール）を持たせBQフェデレテッドクエリでBQに準備
閲覧共有した別ブックは参照用にBQコネクテッドシートがある形

■シートを経由しないBQを操作するGAS
const request = { query: "select * from asoko", useLegacySql: false};let rows = [['c1','c2']]const result = BigQuery.jobs.query(request, 'kuso-prj');for(let i=0; i < result.rows.length; i++){ let resultRow = result.rows[1]; let c1 = resultRow.f[0].v; let c2 = resultRow.f[1].v; let row = []; row.push(c1, c2); rows.push(row);}const spreadsheet = SpreadsheetApp.create("file", rows.length, 2);const range = spreadsheet.getRange("A:B");range.setValues(rows);Browser.msgBox("A file is created"+spreadsheet.getUrl(), Browser.Buttons.OK);
GASのGCPプロジェクトは通常はデフォルトがベスト
　GASはOauthのためだけにGCPのプロジェクトを使う
Google Cloud Platform Projects  |  Apps Script  |  Google Developersデフォルトプロジェクトから切り替えると戻せない、利点も少しだけ（サイト参照）appscript.jsonにoauthのスコープを追加しないと十分に機能しない
　GAS で OAuth のスコープが足りなくてやったこと (zenn.dev)
　GoogleAPIのOAuth2.0スコープ  |  Google Identity Platform  |  Google Developers
※エラーの場合
　BQの場合はBQコンソールでクエリ単体で実行しテスト
　loggingを見るともう少し情報がある
　コネクテッドシートならスプシの共有設定とBQの閲覧ロール等が要る、ビューならその先の小孫～最後までのロールまで要る
　　委任を有効にするとスプシ共有だけでBQロールが不要になるが、、
　　コネクテッド シートでアクセス権の委任を使用する - Google ドキュメント エディタ ヘルプ
　oauth自体でこけるとクッキー消去すれば待たずに再確認ができる？
Google Apps Script試行錯誤 Blog: デフォルトのGCPプロジェクトを標準のGCPプロジェクトに切り替えたい (pre-practice.net)
Google Apps ScriptのログをGoogle Cloud Platformで確認する方法 – hidetoshl.com

GASでAdminDirectoryを使う
　gas > サービス > AdminDirectory APIをOn
　gcp該当prj > APIダッシュボード > ライブラリ > Admin SDKを有効
　等でg workspaceのユーザ情報が取れるらしい
　　Google Apps Script試行錯誤 Blog: AdminDirectoryでUsers.listを取得したい (pre-practice.net)
　　GASでAdmin SDKを利用する（Directory編）その１ - Qiita
メールグループは任意にg workspace管理画面で削除が可能GCP上はDeleted groupとなり1か月程度で削除される（IAMの状態は見れるが使えない）
■アプリ
公開資料 - App Modernization OnAir 〜 モダンなアプリケーション開発とは 〜 (cloudonair.withgoogle.com)
cloud runの設定だけでCDCIできる（第10回

End
Comment (0)

■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" }変数ファイルを異なるバックエンド(フォルダ構成)で共有したいときはシンボリックリンクを貼る　ln -s ../common/shared_var.tf shared_var.tf

TerraformでGCPのリソースの作成と変数から値を読み込む - y-zumiの日記 (hatenablog.com)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_環境変数による指定
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_　実行ログに残らない鍵情報等workspaceは使わない、moduleを限定的に使う
設定をコード化>Gitレポジトリに置く>設定内容、作業履歴の明確化、チームでの運用性向上

■特性TFの影響を反映するのはterraform applyの時だけ、tfファイルとtfstateの差分を実際にリソース作成する
　tfファイルで変更した場合、TFはリソースの再作成を行うので一度消えることになる（大体は単位が権限だったりで影響がないだけでplanで要注意）
terraform planはtfとtfstateと実体の差なので、実体があってもtfstateになければwill be createdでplan時は表示されるterraform importはtfファイルからtfstateへ記載だけを行う(実体からも情報を取得し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でデプロイするリソースを特定できる(TFファイルだけでなくTFステートもターゲットになる)

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
}
mapをリストしたものをfor_eachTerraformのfor_eachにmapのlistを渡してループしたい - Qiitalocals {  images = [    { name = "foo", image = "alpine" },    { name = "bar", image = "debian" },  ]}resource "docker_container" "this" {  for_each = { for i in local.images : i.name => i } # こう書くのが正しい  name     = each.value.name  image    = each.value.image}

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することが必要
terraform importで対象プロジェクトを間違えるとハマる
　通常のterraform applyではproviderの情報を使用してプロジェクトを決めるが、importはハードコードするのでimportを間違えばなぜ変な変更がでるのかわからなくなる（プロジェクトが変なものはstateを調べ、terraform state rmするしか）
for_eachで書いた.tfをterraform importする | DevelopersIO (classmethod.jp)
　ユーザ指定は　user:aaa@xxx.com だったりメールグループなら group:aaa@xxx.com

■セットアップ　作業ディレクトリの作成(プロジェクトに対するローカルのフォルダ）　プロバイダを指定したtfファイルの作成(gcsにstateを置く設定が良い
　　provider "google" {　　  project = "bangboo-kuso"　　}　　terraform {　　  backend "gcs" {　　    bucket = "bangboo-kuso-terraform"　　  }　　}　terraform init　ローカルに対して初期化
　プロジェクトレベルownerのサービスアカウントを持っておく　セットアップする際にtfsateのbackend保存場所のbucket部分をコメントアウト　bucketを作るterraformを実施しbucketを作成しつつlocalにtfstateファイルを作成　再度terraformをするとtfstateファイルがbucketにコピーされる　bucket部分のコメントアウトを外すと次回tfからはバケットにtfstate更新する
　　このときローカルtfstateの内容をバケットに写すか聞かれるが写す
　　（写さないと差分しかバケットに行かないのでimport等が必要になる）

■既存リソースのTF化のおおよその作業　リソースタイプと名前を定義したtfファイルを作成する(任意のリソース名、基本ユニーク、纏められるものは重複してもいい)
　　resource "google_cloudfunctions_function" "fuckin" { ...　をtfファイルに記載
　　　tfResourceID(リソースIDというようタイプ：リソース種別)とyourResourceName (リソース名) だけで　リソースタイプや個別パラメータは公式ドキュメントを参照しながら定義　https://registry.terraform.io/providers/hashicorp/google/latest/docs
　　(簡単)tfファイル内で１行目以外は空で、terraform planをするとエラーで必要なものが分かるので、それを埋める
　　planが通ると自動的に値をサーバから拾ってくる（importすればtfstate.tfに入っている or コピーしてTFに入れる）
　　planでダメならterraform state show tfResourceID.yourResourceName でstateを見てtfファイルにパラメータを定義していく
　　　暫定に空でリソースをTFファイルに記載しterraform import、次にtfstateを調査する
　　　　terraform state list　tfstateファイルにあるアセットを一覧
　　　　terraform import google_bigquery_table.xxx project/dataset/table　インポート
　　　　terraform state show google_bigquery_table.xxx　tfstateの該当部を表示
　　　　terraform state rm  google_bigquery_table.xxx　インポート取り消し
　　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とか含まれないか

■個別
リファレンスでoptionalとなっていてもtfファイルでは必要な場合もある　tfstateファイルからは必要ないとして自動的に削除されるがスプシをBQでみれるFederatedQueryはテーブルだけ定義しimportしstate show調査　urlをTFファイルに記載するシャーディング（日付別）テーブルは定義できないのでは　生成するクエリの方をTF化したい
Authorized viewはモジュールがあるがconflictがあり全消えする場合がありTF化にまだ向かない

google_bigquery_dataset_iam_memberでもAuthorized viewをはがしてしまう。Authorized viewを使っている個所は google_bigquery_dataset_access あるいは google_bigquery_dataset の access フィールドを使う。google_bigquer_dataset_iam_policy と google_bigquery_iam_binding は Authoritative で権限追加でなく権限強制設定でコンソール付与分を引き剝がすので、使わない方が安全。なお、Authorized view と Routines はTerraform化できない事が分かっている（2022/4時点）ScheduledQuery は Terraform化できるが実行者の設定ができない（Terraform実行者がSQ実行者？誰？）

BQ関連ではデータセット定義、テーブル定義、ビュー定義、フェデレテッドクエリ定義、ScheduledQuery定義をTerraformで行いBQ権限定義、AuthorizedView定義、Routines定義は行わない
　BQ権限を定義するならデータセットレベルはgoogle_bigquery_dataset_access 
　　プロジェクトレベルはgoogle_project_iam_memberで実施すると別なので安全らしい？

■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
  #あるいは通常"roles/bigquery.dataEditor"のようにいれるがorganizations/0123456789/roles/chinkoといれる  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ファイルだけでなくTFステートもターゲットに含まれる
　これでTFファイルにコードがなくTFステートだけにあるものを指定して削除等もできる
■TFのcount
数を指定してその個数のリソースを作る。なのだが　enable_lien = true　モジュール側/変数側でこう設定し　count = var.enable_lien ? 1 : 0　リソース側で3項演算子を使えばIFのように使える
　　※for loopのようなインクリのcount"+="でなく"="の1発実行なので3項演算子でIFになる
■エラー
bigquery access denied：
gcloud auth login --enable-gdrive-accessgcloud auth application-default login --scopes="https://www.googleapis.com/auth/drive","https://www.googleapis.com/auth/cloud-platform"BigQueryでGoogleドライブデータへのクエリでエラーが出るときの対処 (zenn.dev)

排他処理でロックが残る：他の作業者がいなければ、terraform apply -lock=false で一時的に無視をして続行
エラーIDに対して terraform force-unlock id_num963103164Terraform で state のロックを解除する方法、ロックを手動で行う方法 | ゲンゾウ用ポストイット (genzouw.com)
TerraformでState Lockエラーが発生したら | DevelopersIO (classmethod.jp)


■terraformのバージョン管理.terraform.lock.hclファイルでGCP provider等のライブラリのバージョン管理をしている、pyenvのPipfile.lockみたいなHash差分が記載されている、terraform init等で生成されapply時の設定が担保される、通常tfファイルでproviderのバージョンを記載すればよいので不要と思われる
.terraform-versionファイルでterraform自体の要求バージョンを担保できるtfenvの.terraform-versionファイルにはバージョンベタ書きしなくてもOK | DevelopersIO (classmethod.jp)通常はtfenvを使えばよい、tfファイルでrequired_versionを記載すればよいので不要と思われる

■tfenvを使う場合tfenv install 1.0.0
tfenv listtfenv use 1.0.0
　terraform init　terraform workspace list　terraform workspace select ore_spacemain.tf作成し記載　terraform fmt　tfファイルのフォーマット（書式は適当で書けばいい）　　gcloud auth login　ローカル操作のための認証　　gcloud auth application-default login　SDKを実行のための認証　　　API&Servicesでクレデンシャルは取得できそう、key=xxxx既存のリソースを調査terrafrom import google_storage_bucket.pri-bucket project-abc123/asia-northeast1/pri-bucket　でimportとか　terraform refresh　tfstateの最新化、どのタイミングで使う？
■既存のリソースを調査
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　とか

既存リソース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はまとめ易そうだが権限消しそう

google_bigquery_dataset_iam_memberでもAuthorized viewをはがしてしまう。Authorized viewを使っている個所は google_bigquery_dataset_access あるいは google_bigquery_dataset の access フィールドを使う。
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にせなサブネットを公開して作りよる
Cloud sqlのtfファイルに記述がなくてもtf stateにはPWが出てしまう＞tf化したくない

■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
シェル変数を設定、確認cmdは printenvexport TF_CLI_ARGS_plan="--parallelism=50"export TF_CLI_ARGS_apply="$TF_CLI_ARGS_plan"
■テスト
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で差分がないことを確認

■GCP権限（メールの変名時）
GCPはGWS gmailメールの変名に追従して権限も付与状態も変化がないしかしterraformは追従しないためtfファイルで使っている場合は変更する
■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)

Navi: <  6 | 7 | 8 | 9  >
-Home
-Column [128]
-Europe [9]
-Gadget [77]
-Web [133]
-Bike [4]
@/// BANGBOO BLOG ///