ハンズオンラボ — PCNE Google Cloud Professional Cloud Network Engineer

概要

前提条件

ステップ

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

   Compute、DNS、およびLogging 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-pcne"
       managed_by = "terraform"
     }
   }
   
   resource "google_project_service" "compute" {
     service            = "compute.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "dns" {
     service            = "dns.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "logging" {
     service            = "logging.googleapis.com"
     disable_on_destroy = false
   }

2. 2.Shared VPCホストプロジェクトモードを有効にし、リージョンサブネットを構成する

   プロビジョニング対象:

   • VPC
   • Shared VPC

   Shared VPCは、PCNEで標準的なマルチプロジェクトネットワーキングパターンです。1つのホストプロジェクトがVPCを所有し、複数のサービスプロジェクトがアタッチメントを介してそれを利用します。サービスプロジェクト内のワークロードは、ホストプロジェクトがワークロード層のリソースを所有することなく、ホストVPCのサブネットからIPを取得します。PCNE試験では、このホストとサービスの分離が、負荷分散スケーリングパターンとして問われます。

   現在のプロジェクトでホストプロジェクトモード（google_compute_shared_vpc_host_project）を有効にし、次にPrivate Google Accessが有効（外部IPを持たないVMが*.googleapis.comに到達できるようにする）でVPCフローログがオンになっている/20サブネットを構成します。

   コピー

   data "google_project" "current" {}
   
   resource "google_compute_shared_vpc_host_project" "host" {
     project = data.google_project.current.project_id
   
     depends_on = [google_project_service.compute]
   }
   
   resource "google_compute_network" "main" {
     name                    = "certlabpro-pcne-vpc"
     auto_create_subnetworks = false
     routing_mode            = "REGIONAL"
   
     depends_on = [google_project_service.compute]
   }
   
   resource "google_compute_subnetwork" "main" {
     name                     = "certlabpro-pcne-subnet"
     ip_cidr_range            = "10.10.0.0/20"
     region                   = "us-central1"
     network                  = google_compute_network.main.id
     private_ip_google_access = true
   
     log_config {
       aggregation_interval = "INTERVAL_5_SEC"
       flow_sampling        = 0.5
       metadata             = "INCLUDE_ALL_METADATA"
     }
   }

3. 3.アウトバウンド専用のCloud Router + Cloud NATを追加する

   プロビジョニング対象:

   • Cloud NAT
   • Cloud Router

   Cloud NATは、サブネットにVMごとの外部IPなしでアウトバウンドインターネットアクセスを提供します。これはPCNEで標準的なプライベート・バイ・デフォルトの送出パターンです。その構成は、Cloud RouterがBGPコントロールプレーンプリミティブ（NAT、VPN、Interconnectで使用）であり、Cloud NATがそれにアタッチしてデータプレーンを提供します。

   AUTO_ONLY NAT IP割り当て（Googleがアドレスを選択します。本番環境のデプロイでは、アップストリームのファイアウォール許可リストのために特定の予約済みIPに固定します）でNATを有効にします。ロギングはエラー時のみに設定します。フルログモードは大量のCloud Loggingボリュームを生成します。

   コピー

   resource "google_compute_router" "nat_router" {
     name    = "certlabpro-pcne-router"
     region  = "us-central1"
     network = google_compute_network.main.id
   }
   
   resource "google_compute_router_nat" "nat" {
     name                               = "certlabpro-pcne-nat"
     router                             = google_compute_router.nat_router.name
     region                             = "us-central1"
     nat_ip_allocate_option             = "AUTO_ONLY"
     source_subnetwork_ip_ranges_to_nat = "LIST_OF_SUBNETWORKS"
   
     subnetwork {
       name                    = google_compute_subnetwork.main.id
       source_ip_ranges_to_nat = ["ALL_IP_RANGES"]
     }
   
     log_config {
       enable = true
       filter = "ERRORS_ONLY"
     }
   }

4. 4.2つのファイアウォールルール（内部 + IAP SSH）を追加する

   プロビジョニング対象:

   • VPC

   PCNEが推奨するファイアウォールの構成：イングレスはデフォルトで拒否（GCPのデフォルト）、必要なもののみを許可します。内部からのすべて許可（サブネット内のVM間の任意のTCP / UDP / ICMP）と、IAP SSH許可（GoogleのIAPゲートウェイ範囲からのTCP/22。これにより、パブリックIPを持たないVMでもgcloud compute ssh --tunnel-through-iap経由でSSHアクセス可能になります）を追加します。

   これはACEラボと同じ2つのルールパターンですが、PCNEでは組織/フォルダスコープでのファイアウォールポリシー（プロジェクトレベルのルールと組み合わせる階層型ファイアウォール。ここでは範囲外です）でさらに深く掘り下げます。

   コピー

   resource "google_compute_firewall" "allow_internal" {
     name      = "certlabpro-pcne-allow-internal"
     network   = google_compute_network.main.name
     direction = "INGRESS"
   
     source_ranges = ["10.10.0.0/20"]
   
     allow {
       protocol = "tcp"
     }
     allow {
       protocol = "udp"
     }
     allow {
       protocol = "icmp"
     }
   }
   
   resource "google_compute_firewall" "allow_iap_ssh" {
     name      = "certlabpro-pcne-allow-iap-ssh"
     network   = google_compute_network.main.name
     direction = "INGRESS"
   
     source_ranges = ["35.235.240.0/20"]
   
     allow {
       protocol = "tcp"
       ports    = ["22"]
     }
   }

5. 5.内部名前解決のためのCloud DNSプライベートゾーンを作成する

   プロビジョニング対象:

   • Cloud DNS

   PCNEで標準的なパターン：VPCにアタッチされたCloud DNSのプライベートゾーンを介して内部ホスト名が解決されます。VPC内のVMはこのゾーンのレコードを参照できますが、外部のVMはできません。ユースケース：VMのプライベートIPに解決される、サービス用の安定した人間が読めるホスト名（api.internal.acme.com、db.internal.acme.com）です。

   ゾーンinternal.acme.comと1つの例のAレコードを作成します。本番環境のデプロイでは、ハイブリッド設定のためにCloud DNS DNS転送（オンプレミスのDNSクエリはクラウドゾーンに転送され、インバウンドサーバーポリシーを介して逆方向も可能）と組み合わせることがよくあります。5つのブロック（プロバイダー+API、Shared VPC + サブネット + フローログ、Cloud NAT、ファイアウォール、Cloud DNSプライベートゾーン）が配置されたことで、PCNE基盤が完成します。

   コピー

   resource "google_dns_managed_zone" "internal" {
     name        = "certlabpro-pcne-internal"
     dns_name    = "internal.acme.com."
     description = "PCNE lab private DNS zone"
     visibility  = "private"
   
     private_visibility_config {
       networks {
         network_url = google_compute_network.main.id
       }
     }
   
     labels = local.labels
   
     depends_on = [google_project_service.dns]
   }
   
   resource "google_dns_record_set" "api_example" {
     managed_zone = google_dns_managed_zone.internal.name
     name         = "api.${google_dns_managed_zone.internal.dns_name}"
     type         = "A"
     ttl          = 300
     rrdatas      = ["10.10.0.10"]
   }

クリーンアップ