Laboratório prático — PCA Google Cloud Professional Cloud Architect

Visão geral

Pré-requisitos

Passos

1. 1.Provedor, serviços de projeto, nomenclatura

   Habilite as APIs Compute, GKE, Cloud SQL, Service Networking (para IP privado do Cloud SQL) e Cloud Storage.

   Copiar

   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.Construa a VPC + Cloud NAT para egresso apenas de saída

   Provisiona:

   • VPC
   • Cloud NAT

   Padrão recomendado pela PCA: VMs / pods privados não têm IPs externos, mas ainda precisam alcançar dependências externas (chamadas pip / docker / API). A resposta é Cloud NAT — um serviço NAT regional gerenciado que oferece egresso apenas de saída para recursos privados.

   Nós alocamos uma sub-rede /20 com dois intervalos secundários para GKE (pods + serviços), provisionamos um Cloud Router e anexamos um Cloud NAT a ele.

   Copiar

   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.Provisione um cluster GKE Autopilot na VPC

   Provisiona:

   • Google Kubernetes Engine

   GKE Autopilot é o modo GKE recomendado pela PCA — o Google gerencia o pool de nós, você paga por vCPU/memória do pod consumida. Compare com o GKE Standard, onde você dimensiona e paga pelo pool de nós. O exame PCA testa esta troca Autopilot vs. Standard como a forma recorrente de gerenciado vs. controle.

   Nós habilitamos VPC-nativa (IPs de alias — os pods obtêm IPs do intervalo secundário na Etapa 2, não do NAT), cluster privado (os IPs dos nós são privados; o plano de controle também obtém um endpoint privado) e Workload Identity (o padrão recomendado pela PCA para autenticação de pod → GCP-API — sem credenciais de conta de serviço em nível de nó).

   Copiar

   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.Implante Cloud SQL Postgres apenas com IP privado

   Provisiona:

   • Cloud SQL

   Conectividade de banco de dados recomendada pela PCA: IP privado via emparelhamento de VPC — o Cloud SQL é provisionado dentro de uma VPC gerenciada pelo Google que se emparelha com a sua, a instância obtém um IP privado e os pods a alcançam por meio de rede privada. O Cloud SQL com IP público é o antipadrão testado no exame PCA.

   A forma: (1) alocar um /16 da sua VPC para uso do Service Networking, (2) emparelhar a VPC com servicenetworking.googleapis.com, (3) provisionar a instância do Cloud SQL com ipv4_enabled = false + a referência da rede emparelhada.

   Copiar

   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.Crie um bucket de aplicativo do Cloud Storage para ativos

   Provisiona:

   • Cloud Storage

   As arquiteturas de referência da PCA sempre incluem um bucket do Cloud Storage para algo — uploads, exportações, dados de recursos de ML, ativos da web estáticos. Adicionamos um aqui, com acesso uniforme em nível de bucket, ciclo de vida movendo dados para o Nearline após 30 dias.

   Com cinco blocos implementados (VPC + NAT, GKE Autopilot, Cloud SQL com IP privado, bucket GCS), a forma de referência da PCA está completa: as cargas de trabalho são executadas no GKE, se comunicam com o Postgres por meio de rede privada, gravam artefatos no GCS, saem pelo Cloud NAT.

   Copiar

   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]
   }

Limpeza