ハンズオンラボ — PCA Google Cloud Professional Cloud Architect

概要

前提条件

ステップ

1. 1.プロバイダ、プロジェクトサービス、命名

   Compute、GKE、Cloud SQL、Service Networking（Cloud SQLプライベートIP用）、およびCloud StorageのAPIを有効にします。

   コピー

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       google = { source = "hashicorp/google", version = "~> 6.0" }
     }
   }
   
   provider "google" {
     project = "your-project-id" # REPLACE
     region  = "us-central1"
   }
   
   locals {
     labels = {
       project    = "certlabpro-pca"
       managed_by = "terraform"
     }
   }
   
   resource "google_project_service" "compute" {
     service            = "compute.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "container" {
     service            = "container.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "sqladmin" {
     service            = "sqladmin.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "servicenetworking" {
     service            = "servicenetworking.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "storage" {
     service            = "storage.googleapis.com"
     disable_on_destroy = false
   }

2. 2.アウトバウンド専用エグレスのためのVPC + Cloud NATを構築する

   プロビジョニング対象:

   • VPC
   • Cloud NAT

   PCAが推奨するパターン：プライベートVM/Podは外部IPを持たないものの、外部の依存関係（pip / docker / API呼び出し）に到達する必要があります。その解決策がCloud NATです。Cloud NATは、プライベートリソースにアウトバウンド専用のエグレスを提供するマネージドリージョンNATサービスです。

   ここでは、GKE用の2つのセカンダリレンジ（Pod + サービス）を持つ/20サブネットを切り出し、Cloud Routerをプロビジョニングし、それにCloud NATをアタッチします。

   コピー

   resource "google_compute_network" "main" {
     name                    = "certlabpro-pca-vpc"
     auto_create_subnetworks = false
   
     depends_on = [google_project_service.compute]
   }
   
   resource "google_compute_subnetwork" "main" {
     name                     = "certlabpro-pca-subnet"
     ip_cidr_range            = "10.10.0.0/20"
     region                   = "us-central1"
     network                  = google_compute_network.main.id
     private_ip_google_access = true
   
     secondary_ip_range {
       range_name    = "pods"
       ip_cidr_range = "10.20.0.0/14"
     }
   
     secondary_ip_range {
       range_name    = "services"
       ip_cidr_range = "10.24.0.0/20"
     }
   }
   
   resource "google_compute_router" "nat_router" {
     name    = "certlabpro-pca-router"
     region  = "us-central1"
     network = google_compute_network.main.id
   }
   
   resource "google_compute_router_nat" "nat" {
     name                               = "certlabpro-pca-nat"
     router                             = google_compute_router.nat_router.name
     region                             = "us-central1"
     nat_ip_allocate_option             = "AUTO_ONLY"
     source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
   
     log_config {
       enable = true
       filter = "ERRORS_ONLY"
     }
   }

3. 3.VPC上にGKE Autopilotクラスターをプロビジョニングする

   プロビジョニング対象:

   • Google Kubernetes Engine

   GKE AutopilotはPCAが推奨するGKEモードです。Googleがノードプールを管理し、PodのvCPU/メモリの使用量に応じて課金されます。自分でノードプールのサイズを決定し課金されるGKE Standardと比較してください。PCA試験ではこのAutopilot対Standardのトレードオフが、繰り返し登場するマネージド対コントロールの形として出題されます。

   ここでは、VPCネイティブ（エイリアスIP — Podはステップ2のセカンダリレンジからIPを取得し、NATからは取得しません）、プライベートクラスター（ノードIPはプライベートであり、コントロールプレーンもプライベートエンドポイントを取得します）、およびWorkload Identity（PodからGCP-API認証へのPCA推奨パターン — ノードレベルのサービスアカウント認証情報は不要）を有効にします。

   コピー

   resource "google_container_cluster" "main" {
     name     = "certlabpro-pca-cluster"
     location = "us-central1" # regional Autopilot
   
     enable_autopilot = true
   
     network    = google_compute_network.main.id
     subnetwork = google_compute_subnetwork.main.id
   
     ip_allocation_policy {
       cluster_secondary_range_name  = "pods"
       services_secondary_range_name = "services"
     }
   
     private_cluster_config {
       enable_private_nodes    = true
       enable_private_endpoint = false # public control plane for kubectl access
       master_ipv4_cidr_block  = "172.16.0.0/28"
     }
   
     deletion_protection = false # lab-only
   
     depends_on = [google_project_service.container]
   }

4. 4.プライベートIPのみでCloud SQL Postgresを立ち上げる

   プロビジョニング対象:

   • Cloud SQL

   PCAが推奨するデータベース接続性：VPCピアリングによるプライベートIP — Cloud SQLはGoogle管理のVPC内にプロビジョニングされ、それがあなたのVPCとピアリングされ、インスタンスはプライベートIPを取得し、Podはプライベートネットワーク経由でそれに到達します。パブリックIPを持つCloud SQLは、PCA試験で問われるアンチパターンです。

   構成は次のとおりです。(1) Service Networkingが使用するあなたのVPCから/16を割り当てる、(2) servicenetworking.googleapis.comとVPCをピアリングする、(3) ipv4_enabled = falseとピアリングされたネットワーク参照を使用してCloud SQLインスタンスをプロビジョニングする。

   コピー

   resource "google_compute_global_address" "private_ip_alloc" {
     name          = "certlabpro-pca-sql-peer"
     purpose       = "VPC_PEERING"
     address_type  = "INTERNAL"
     prefix_length = 16
     network       = google_compute_network.main.id
   }
   
   resource "google_service_networking_connection" "sql_peering" {
     network                 = google_compute_network.main.id
     service                 = "servicenetworking.googleapis.com"
     reserved_peering_ranges = [google_compute_global_address.private_ip_alloc.name]
   
     depends_on = [google_project_service.servicenetworking]
   }
   
   resource "google_sql_database_instance" "main" {
     name             = "certlabpro-pca-pg"
     database_version = "POSTGRES_15"
     region           = "us-central1"
   
     settings {
       tier              = "db-perf-optimized-N-2"
       availability_type = "ZONAL" # lab-only; production = REGIONAL
   
       ip_configuration {
         ipv4_enabled    = false
         private_network = google_compute_network.main.id
       }
   
       backup_configuration {
         enabled                        = true
         point_in_time_recovery_enabled = true
       }
     }
   
     deletion_protection = false # lab-only
   
     depends_on = [
       google_service_networking_connection.sql_peering,
       google_project_service.sqladmin,
     ]
   }

5. 5.アセット用のCloud Storageアプリバケットを配置する

   プロビジョニング対象:

   • Cloud Storage

   PCAリファレンスアーキテクチャには、必ず何かのためのCloud Storageバケットが含まれます — アップロード、エクスポート、ML特徴データ、静的ウェブアセットなど。ここでは、ユニフォームバケットレベルアクセスを有効にし、30日後にデータをニアラインに移動するライフサイクルを設定したバケットを追加します。

   5つのブロック（VPC + NAT、Autopilot GKE、プライベートIP付きCloud SQL、GCSバケット）が揃い、PCAリファレンスアーキテクチャの形が完成します。ワークロードはGKE上で実行され、プライベートネットワーク経由でPostgresと通信し、成果物をGCSに書き込み、Cloud NAT経由で外部に出ます。

   コピー

   resource "random_id" "suffix" {
     byte_length = 4
   }
   
   resource "google_storage_bucket" "app" {
     name                        = "certlabpro-pca-app-${random_id.suffix.hex}"
     location                    = "US"
     uniform_bucket_level_access = true
     force_destroy               = true # lab-only
   
     lifecycle_rule {
       condition {
         age = 30
       }
       action {
         type          = "SetStorageClass"
         storage_class = "NEARLINE"
       }
     }
   
     labels = local.labels
   
     depends_on = [google_project_service.storage]
   }

クリーンアップ