Article 31 – Deployment Manager & Terraform

Your manager says: “We need a new staging environment. Please create an exact replica of production — the VPC, subnets, firewall rules, GKE cluster, Cloud SQL database, all of it.”

You open the Cloud Console and start clicking. Three days later, after a painful, error-filled process, you have something that looks like production. But is it exactly the same? Probably not. And now your manager asks you to do it again for the QA team.

This manual, click-based approach — “ClickOps” — is slow, prone to human error, impossible to version control, and unscalable. The fix is Infrastructure as Code (IaC).

What Is Infrastructure as Code?

Write down a blueprint of what you want your cloud environment to look like. An engine reads that blueprint and makes it reality. Simple concept, revolutionary impact:

• Version Control — Infrastructure blueprints live in Git. Full history of every change.
• Peer Review — Firewall rule changes go through pull requests before being applied.
• Automation — Integrate IaC into CI/CD to build and tear down environments automatically.
• Repeatability — Same blueprint deploys identical environments every time. No configuration drift.

Google Cloud supports two primary IaC tools.

Cloud Deployment Manager (CDM) — Google’s Native Tool

CDM lets you define GCP resources in a YAML configuration file. You hand the file to the Deployment Manager service, and it makes the API calls to create, update, or delete resources until reality matches your blueprint.

# my-deployment.yaml
resources:
- name: my-vpc-network
  type: compute.v1.network
  properties:
    autoCreateSubnetworks: false

# Deploy the configuration
gcloud deployment-manager deployments create my-first-deployment \
    --config my-deployment.yaml

For modularity, you create reusable templates using Jinja or Python instead of writing one massive YAML file.

CDM is GCP-only and stateless — it relies on GCP as the source of truth.

Terraform — The Industry Standard

Terraform is the de facto industry standard for IaC. It is an open-source tool by HashiCorp using its own language called HCL (HashiCorp Configuration Language).

The workflow is a three-step process:

1. Write — Define your infrastructure in .tf files. Specify a provider (google) and declare resources.

provider "google" {
  project = "my-gcp-project"
  region  = "us-central1"
}

resource "google_compute_network" "vpc_network" {
  name                    = "my-terraform-vpc"
  auto_create_subnetworks = false
}

2. Plan — This is Terraform’s killer feature. Run terraform plan and it shows you exactly what it will do: “I will create 1 VPC, modify 2 firewall rules, and destroy 1 old VM.” You review and approve before anything happens.

3. Apply — Run terraform apply and Terraform executes the plan.

State Management: Terraform keeps a state file that maps your code to real resources in the cloud. This file is the single source of truth for what Terraform manages.

CDM vs. Terraform

Choose CDM if your org is 100% GCP and wants a native, agentless service.

Choose Terraform if you use multiple clouds, want the larger ecosystem, or consider the terraform plan workflow essential. For most organizations today, Terraform is the standard choice.

Common Pitfalls and Best Practices

Pitfall: “ClickOps Drift” — making manual console changes to IaC-managed resources. Next time you run IaC, it tries to revert your manual changes.
Best Practice: Once a resource is managed by code, all changes go through code and review.

Pitfall: Terraform state file on your local laptop. Laptop dies, state is gone.
Best Practice: Use a remote backend (Cloud Storage bucket) for your state file. Central, secure, and lockable.

Pitfall: Monolithic configuration files for the entire infrastructure.
Best Practice: Use modules (Terraform) or templates (CDM) for reusable, composable components. Keep it DRY.

Pitfall: Secrets hardcoded in config files and committed to Git.
Best Practice: Use Secret Manager and reference secrets in your IaC code.

Quick Reference

# -- Cloud Deployment Manager --
gcloud deployment-manager deployments create [NAME] \
    --config [FILE] --preview                    # Preview
gcloud deployment-manager deployments update [NAME] \
    --config [FILE]                              # Apply
gcloud deployment-manager deployments delete [NAME]  # Delete

# -- Terraform --
terraform init      # Initialize directory and download providers
terraform fmt       # Format code
terraform plan      # Show execution plan
terraform apply     # Apply changes
terraform destroy   # Destroy infrastructure