🛠 Associate Cloud Engineer

1. クラウド環境のセットアップ

リソース階層（組織・フォルダ・プロジェクト）

リソースは組織 → フォルダ → プロジェクト → リソースの木の形で管理し、上で決めた権限やルールは下へ自動で引き継がれます。

組織：example.com
フォルダ：開発部
プロジェクト：app-dev
VM
プロジェクト：app-prod
バケット
フォルダ：営業部
プロジェクト：crm
Cloud SQL
組織で Viewer を付与
→
すべてのフォルダ・プロジェクトで閲覧できる下位に継承される
プロジェクトで取り消したい
→
できない子で親の許可は打ち消せない（止めるなら拒否ポリシー）
会社の組織図と同じです。「全社員はこの部屋に入れる」と本社で決めたら、どの部署の社員も入れます。部署の判断だけでは取り消せません。

Google Cloud のリソースは 組織 (Organization) → フォルダ → プロジェクト → リソース の階層で管理されます。IAM ポリシーと組織ポリシーは下位に継承されます（親で付与した権限は子でも有効。子で親の許可を取り消すことはできない）。

要素ポイント
組織Cloud Identity / Google Workspace のドメインに紐づく最上位ノード。全社ポリシーの適用点
フォルダ部門・環境（dev/prod）ごとにプロジェクトをまとめ、IAM・組織ポリシーを一括適用
プロジェクトリソース・API 有効化・課金・IAM の基本単位。プロジェクト名は変更可、プロジェクト IDは一意で変更不可、プロジェクト番号は自動採番

プロジェクトの3つの識別子

プロジェクト名例：My App
あとから変更できる
プロジェクト ID例：my-proj-123
全体で一意・変更できない
プロジェクト番号例：123456789012
自動で採番される
gcloud の --project などで指定するのは、ふつうプロジェクト ID
削除したプロジェクトは約30日間は復元（undelete）可能。
gcloud projects create my-proj-123 --folder=FOLDER_ID
gcloud config set project my-proj-123
gcloud services enable compute.googleapis.com

課金（Cloud Billing）

お金は請求先アカウントが払い、プロジェクトはそこにリンクして使います。予算アラートは知らせるだけで、課金は止めません。

請求先アカウント支払い方法（カードや請求書）を持つ
→
プロジェクト A
→
プロジェクト B
→
プロジェクト C
1つの請求先アカウントに複数のプロジェクトをリンクできる（1つのプロジェクトのリンク先は1つ）。リンクがないと有料リソースは使えない
  • 請求先アカウントを作成し、プロジェクトにリンクする。リンクされていないプロジェクトでは有料リソースを使えない。
  • 主なロール：Billing Account Administrator（管理）、Billing Account User（プロジェクトのリンク）、Billing Account Viewer（閲覧）。
  • 予算とアラート：しきい値（50%・90%・100% など）でメール通知。予算は課金を止めない（止めるには Pub/Sub 通知 + Cloud Functions 等で自動化）。
  • BigQuery への課金データエクスポートで詳細な費用分析ができる。ラベルでコスト配賦。

予算アラートと、課金を自動で止めるしくみ

0〜50%
50〜90%
〜100%
50%・90%・100% の線を超えるたびにメールが届くだけ。100% を超えてもリソースは動き続け、課金も続く
予算アラートしきい値を超えた
→
Pub/Sub通知を受け取る
→
Cloud Run functionsプログラムで処理
→
課金を無効化プロジェクトとの
リンクを外す
「上限を超えたら自動で止めたい」なら、この仕組みを自分で作る必要がある
予算アラートは「家計簿アプリの使いすぎ通知」。お知らせは来ますが、カードが止まるわけではありません。

gcloud CLI・Cloud Shell・構成

構成（configuration）は「アカウント・プロジェクト・リージョン」の組み合わせを名前を付けて保存したもの。activate で一発で切り替えられます。

構成：dev

account：me@example.com

project：app-dev

region：asia-northeast1

構成：prod

account：me@example.com

project：app-prod

region：asia-northeast1

gcloud config configurations activate prod で、以後のコマンドの既定値がまとめて切り替わる
ゲームのセーブスロットのようなもの。「開発用」「本番用」を保存しておけば、毎回設定し直さなくて済みます。
  • Cloud Shell：ブラウザ上の無料シェル。gcloud / kubectl 等がプリインストール、$HOME は永続（5GB）。
  • gcloud 構成 (configuration)：アカウント・プロジェクト・リージョン等のセットを複数保持して切り替え。
gcloud init                                   # 初期設定
gcloud auth login                             # ユーザー認証
gcloud config configurations create dev       # 構成を作成
gcloud config configurations activate dev     # 切り替え
gcloud config set compute/region asia-northeast1
gcloud config set compute/zone asia-northeast1-a
gcloud config list
gcloud components update

どの値が使われる？

① コマンドのフラグ--project --zone
＞
② 有効な構成gcloud config set の値
フラグを付ければ、そのコマンドだけ構成の値を上書きできる
コマンド単位で上書きするなら --project / --zone フラグ。gcloud auth application-default login はローカルのアプリ用 ADC 認証。

ユーザー・グループとサービスアカウント

権限を持つのは2種類。人はユーザー（グループにまとめて付与）、プログラムはサービスアカウントです。

人alice、bob、carol
→
グループ devs@example.comこのグループにロールを付与
プログラムVM 上のアプリ、バッチ
→
サービスアカウントVM にアタッチして使う
人の入れ替わりはグループのメンバー変更だけで済み、IAM ポリシーを書き換えなくてよい
サービスアカウントは「ロボット社員の社員証」。人ではなくプログラムに配る社員証で、必要な部屋（ロール）にだけ入れるようにします。
  • ユーザー管理は Cloud Identity / Google Workspace。権限は個人ではなくグループに付与するのがベストプラクティス。
  • サービスアカウント (SA)：アプリ・VM 用の ID。ユーザー管理 SA を作成し、必要最小限のロールを付与。VM には SA をアタッチする（キーファイルのダウンロードは極力避ける）。
gcloud iam service-accounts create my-sa --display-name="My SA"
gcloud projects add-iam-policy-binding PROJECT \
  --member="serviceAccount:my-sa@PROJECT.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"
次の領域 →