Google Cloud Reseller: Build a standard network architecture on GCP with batch automation in 10 minutes with Terraform tools
In the operation and maintenance circle of public cloud, there is a wise saying that is regarded as the standard:"
If you repeatedly click the same button more than three times in the console, you should code it.
”
Many friends who have just come into contact with Google Cloud (GCP) often log on to the console with ease when facing a brand-new commercial project and start clicking the mouse with human flesh: build a custom VPC, divide Subnet (subnet) into three different regions, configure a bunch of network tag firewalls, and finally configure an internal NAT gateway to enable virtual machines to access the Internet safely.
This set of processes will take at least half an hour. Even more painful is when a company has to work in a test environment, an advance release environment, a production environment, or even a new overseas region.
Perfect replica
When you have an identical network, you can only sweat and pray that you don't misread an IP mask while reading the document. As long as the hand shook a wrong place, followed by a long mistake and row fish pit.
In the DevOps ecology of modern large factories, there is an ultimate kill to completely end this primitive workshop-style operation and maintenance, called
Terraform
.
Its core logic is summed up in four words:
Infrastructure as Code (IaC,Infrastructure as Code)
. You don't need to click any mouse, just write down your network blueprint in a text file, and Terraform will "print" a set of standard network architecture for you accurately and batch like a printer on GCP around the world within 10 minutes.
Today we refuse to preach any concept and refuse to talk nonsense. Directly take the production specifications of the multinational structure of large factories as the standard, and take you with your Terraform to build high-rise buildings within 10 minutes.
Stage 1: Deep Dismantling, IaC's "God Perspective World Model"
Before you start writing the first line of code, you have to build Terraform underlying physical world model in your head, or you'll definitely be left behind.
.tf
The file is dizzy.
The interaction between Terraform and GCP is essentially a declaration-> execution closed-loop process:
Drawing layer (Configuration Files, .tf): A drawing of the network architecture that you write in HCL, an easy-to-read declarative configuration language. You just need to declare "I want a network called prod-vpc", regardless of how Google's bottom layer dispatches through the API.
Connector (Provider):Terraform the official GCP translator. It is responsible for translating the drawings you write into RESTful API instructions that Google Cloud can understand.
Real World Feedback (State File, terraform.tfsta
te): This is Terraform's "memory ledger". It will record the real resources and IP addresses currently in the cloud in a JSON file. It is the underlying core of the Terraform that can be "incrementally modified and never overlapped.
The second stage: the eve of the actual combat-to open up a local ammunition depot
Please make sure that the Terraform CLI has been downloaded and installed on your local computer and has been configured
Google Cloud CLI
command line tool.
Create a new empty directory on the local computer, named
gcp-network-automation
. In this directory, we will establish three core documents that conform to the large factory architecture specifications.
The big factory code forbids stuffing everything into one file.
, we must modularly decouple it:
providers.tf: Used to align the secret code with Google Cloud and declare where we want to use the resources.
variables.tf: Variable Console. All regions, project IDs and IP network segments are uniformly changed here to realize reuse of a set of codes everywhere.
main.tf: Core network blueprint.
The third stage: the actual combat exercise-hand-to-hand code batch construction network.
Next, take your hands off the mouse and prepare to start this 10-minute Internet Express campaign in your IDE (such as VS Code).
1. Write a connector
providers.tf
This document is responsible for welding the Terraform firmly to your GCP project.
terraform {
required_version = ">= 1.5.0"
required_providers {
google = {
source = "hashicorp/google"
version = "~> 5.0"# Lock large versions to prevent syntax incompatibility caused by future official upgrades
}
}
}
provider "google "{
project = var.project_id
region = var.main_region
}
2. Write Variable Desk
variables.tf
To extract all the parameters that may be changed, you only need to change one line in this document to send new regions in the future, and you do not need to move the core blueprint.
variable "project_id "{
type &n
bsp; = string
description = "Your GCP project ID"
default = "my-automation-project-2026"# Replace with your own real project ID
}
variable "main_region "{
type = string
description = "Primary Business Deployment Region"
default = "asia-east1"# Taiwan region with low domestic visit latency
}
variable "backup_region "{
type = string
description = "DR region"
default = "asia-northeast1"# Tokyo region, high availability for cross-border double work
}
3. Write the core network blueprint
main.tf
This is the hardest part. We're going to batch build in one breath here:
1 custom VPC, 2 cross-border subnets, 1 fully isolated intranet security firewall, and a Cloud NAT gateway that allows intranet machines to download patches without confidentiality
.
Terraform
#1. Build a Big Back in Batch: Custom VPC Network
resource "google_compute_network" "custom_vpc "{
name = "prod-standard-vpc"
auto_create_subnetworks = false# large factory-level security specification: resolutely close the automatic atomic network and must manually divide and control IP domains
routing_mode = "GLOBAL"# Enable global routing to enable intranet interoperability across multinational subnets
}
#2. Divide Position 1: Taiwan Main Service Subnet (Front End and Application)
resource "google_compute_subnetwork" "subnet_asia_east "{
name = "subnet-asia-east-prod"
ip_cidr_range = "10.0.1.0/24"# Divide 254 Available Intranet IP
region = var.main_region
network = google_compute_network.custom_vpc.id
private_ip_google_access = true# Inject Soul: Allow intranet machines to safely connect to Google's official API without public IP
}
#3. Division 2: Tokyo Remote Disaster Recovery Subnetwork (Core Database and Backup)
resource "google_compute_subnetwork" "subnet_asia_northeast "{
name = "subnet-asia-tokyo-backup"
ip_cidr_range = "10.0.2.0/24"
region = var.backup_region
network = google_compute_network.custom_vpc.id
private_ip_google_access = true
}
#4. Welding safety gate: establish internal network security firewall
resource "google_compute_firewall" "allow_internal "{
name = "allow-internal-mesh-traffic"
network = google_compute_network.custom_vpc.name
allow {
protocol = "tcp"
}
allow {
protocol = "udp"
}
allow {
protocol = "icmp"
}
source_ranges = ["10.0.0.0/16"]# Only knock on each other's doors within our own large network segment will be released, completely blocking all detection on the public network.
description = "Only allow backbone interconnection between VPC intranet members"
}
#5. Pipeline Construction: Configure Cloud Router
resource "google_compute_router" "nat_router "{
name = "prod-nat-router"
region = var.main_region
network = google_compute_network.custom_vpc.id
}
#6. Configure a fully managed Cloud NAT gateway
resource "google_compute_router_nat" "nat_gateway "{
name = "prod-cloud-nat"
router = google_compute_router.nat_router.name
region = var.main_region
nat_ip_allocate_option = "AUTO_ONLY"# Google Automatic Assign High Anti External Static IP
source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}
The fourth stage: the moment to witness the miracle-cloud "snap" one-button pipeline trigger
The code is finished. Next, we enter the terminal and perform the Terraform "clearance trilogy".
Step 1: Force Gathering (Initialization)
Type in the terminal project root directory:
Bash
terraform init
At this time, the Terraform will automatically go to the official mirror station to download the Provider plug-in dedicated to GCP to the local, so that the local computer has the ability to control Google Cloud.
Step 2: Sand table deduction (preview plan)
This is the IaC's most invincible step. before actually going to the clouds to make ground, first come to an absolutely safe military exercise:
Bash
terraform plan
Looking at the report output by the terminal, it will use a full-screen green plus sign (
) to tell you clearly:
"If you press OK, I will create 6 new network products for you in the background, 0 modifications and 0 destruction."
Step 3: Heavy Fire Full Open (One Button Roars on Cloud)
After confirming that the drawing is perfect, issue the final death order:
Bash
terraform apply -auto-approve
The progress bar on the screen began to scroll wildly. Terraform use extremely dense concurrency frequency in the background, and make calls to the API of Google's global backbone network at the same time.
Usually only need
15 to 30 seconds
Terminal finally.
Will show a line of gold tips:
Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
.
At this point you log in
GCP Console
Looking at the network market, a perfect industrial-grade network with multi-active subnets, NAT gateways and isolation firewalls has already stood firm on the public network. The whole process does not waste a drop of spittle, and all the dishes fall in less than 1 minute.
The fifth stage: the history of avoiding the pit and tears of large-scale IaC development at the enterprise level.
This automation scheme is extremely refreshing to use. But in a truly enterprise-class, highly concurrent, multi-team collaborative production environment, as the chief architect, you must immediately weld the following two bottom line specifications to the team:
1. Local retention is strictly prohibited
terraform.tfstate
(The Collaboration of Many People)
By default, after the Terraform runs, a
terraform.tfstate
File.
Disaster: If Zhang San and Li Si in the team run apply on their respective computers, because their local books terraform not synchronized, Terraform will determine that what the other party wrote is "illegal intrusion", thus frantically erasing and emptying each other's newly built servers and networks with one click in the global background.
Large factory standard solution: "remote state lock (Remote Backend)" must be configured ". Add a few lines of code to providers.tf to forcibly lock the state ledger in Google's own GCS bucket (Google Cloud Storage):
Terraform
terraform {
backend "gcs "{
bucket = "my-company-tfstate-bucket"# Lock the ledger in a secure drawer in the cloud
prefix = "terraform/state/network"
}
}
After configuration, as long as Zhang San is running the code, the cloud storage bucket will automatically lock (Lock), and Li Si will absolutely stop executing at the same time, thus completely eliminating the tragic accidents caused by multi-team code conflicts.
2. Mastering the Ultimate Art of Self-Destructing in Physics
At the end of the project, or when the development and test environment needs to be closed temporarily and completely on Friday, do not go to the console to delete one by one.
Hard core stop loss advice: knock in directly at the terminal:
Bashterraform destroy -auto-approve only takes 30 seconds, and the Terraform will cleanly erase the 6 network products on the drawing from Google's computer room like rewinding the tape, leaving no dead corner, completely
Eliminate idle sky-high bills at the end of the month caused by missing a gateway.
Summary
Using Terraform tools to automatically build GCP network architecture in batches, the core industrial essence lies in 16 words:
Drawing statement, variable decoupling, cloud locking, one-click self-destruction
.
You have completely got rid of the original operation and maintenance state of looking at the console of luck and being worried about human flesh on the mask. Turn all your infrastructure into clean code that can be version controlled (Git commit). The network architecture can be copied indefinitely and rolled back with one click like software. This is the most authentic and elegant console posture for modern cloud native architects when sailing out to sea.
