Mastering GCP Infrastructure with Terraform: Regional HTTPS Load Balancer with Cloud DNS - Part 3

Introduction

?? Welcome to Part 3 of the series, "Mastering GCP Infrastructure with Terraform: Regional HTTPS Load Balancer with Cloud DNS." In Part 2, we built a secure networking layer by setting up a custom Virtual Private Cloud (VPC), defining subnets, and configuring firewall rules.

In Part 3, we’ll create the backend infrastructure for our application. This includes defining instance templates, configuring Managed Instance Groups (MIGs), and setting up health checks and autoscaling. Together, these components ensure scalability, high availability, and automated management of backend resources.

By the end of this part, your infrastructure will be ready to handle dynamic workloads effectively.

Building the Backend Infrastructure

Backend infrastructure is the foundation of any scalable application. Using Terraform, we’ll automate the setup for consistent and reliable deployments.

1. Instance Template

resource "google_compute_region_instance_template" "myapp1" {
    name               = "${local.name}-myapp1-template"
    description        = "Instance template for App1"
    machine_type       = var.machine_type
    network_interface {
        subnetwork = google_compute_subnetwork.mysubnet.id
    }
    disk {
        source_image = data.google_compute_image.my_image.self_link
        auto_delete  = true
        boot         = true
    }
    metadata_startup_script = file("${path.module}/webserver.sh")
    labels = {
        environment = local.environment
    }
}
        

Instance Template: Acts as a blueprint for creating VM instances.

• machine_type: Specifies the type of VM (e.g., e2-micro for cost-efficiency).
• disk: Uses a Debian 12 image as the boot disk.
• network_interface: Connects the VM to the previously created mysubnet.
• metadata_startup_script: Executes a script to install and configure a web server automatically.

2. Health Checks

resource "google_compute_region_health_check" "myapp1" {
    name                = "${local.name}-myapp1-health-check"
    check_interval_sec  = 5
    timeout_sec         = 5
    healthy_threshold   = 2
    unhealthy_threshold = 3
    http_health_check {
        request_path = "/index.html"
        port         = 80
    }
}
        

Purpose: Verifies the health of backend instances to ensure only healthy VMs handle traffic.

Key Parameters:

• check_interval_sec: Probes every 5 seconds.
• healthy_threshold: Marks an instance as healthy after 2 successful checks.
• unhealthy_threshold: Marks an instance as unhealthy after 3 failures.
• http_health_check: Sends requests to /index.html on port 80 to verify the application’s availability.

3. Managed Instance Group (MIG)

resource "google_compute_region_instance_group_manager" "myapp1" {
    name                      = "${local.name}-myapp1-mig"
    base_instance_name        = "${local.name}-myapp1"
    region                    = var.gcp_region1
    distribution_policy_zones = data.google_compute_zones.available.names
    version {
        instance_template = google_compute_region_instance_template.myapp1.id
    }
    named_port {
        name = "webserver"
        port = 80
    }
    auto_healing_policies {
        health_check        = google_compute_region_health_check.myapp1.id
        initial_delay_sec   = 300
    }
}
        

Managed Instance Group (MIG): Automatically manages a group of identical VM instances

• version: Uses the previously defined instance template.
• named_port: Registers the webserver port (80) for use by the load balancer.
• auto_healing_policies:

1. Monitors instance health using the health check.
2. Waits 5 minutes (300 seconds) before performing health checks to allow instances to initialize fully.

4. Autoscaling

resource "google_compute_region_autoscaler" "myapp1" {
    name   = "${local.name}-myapp1-autoscalar"
    target = google_compute_region_instance_group_manager.myapp1.id
    autoscaling_policy {
        min_replicas      = 2
        max_replicas      = 6
        cooldown_period   = 60
        cpu_utilization {
            target = 0.8
        }
    }
}
        

Autoscaling dynamically adjusts the number of VM instances based on CPU usage.

• min_replicas: Ensures at least 2 instances are always running.
• max_replicas: Caps the maximum number of instances at 6.
• cpu_utilization: Scales up when CPU usage exceeds 80%.
• cooldown_period: Waits 60 seconds between scaling events to avoid frequent adjustments.

5. Outputs for Debugging

output "myapp1_mig_id" {
  value = google_compute_region_instance_group_manager.myapp1.id
}

output "myapp1_mig_instance_group" {
  value = google_compute_region_instance_group_manager.myapp1.instance_group
}

output "myapp1_mig_self_link" {
  value = google_compute_region_instance_group_manager.myapp1.self_link
}
        

These outputs expose critical details of the MIG, such as:

• id: Unique identifier for the instance group.
• instance_group: Internal name used by GCP to reference the group.
• self_link: Full API path to the MIG.

Why These Steps Matter

1. Scalability: MIGs combined with autoscaling allow your infrastructure to handle fluctuating workloads dynamically.
2. High Availability: By distributing instances across multiple zones, the system ensures resilience to regional failures.
3. Health Monitoring: Health checks and auto-healing ensure only healthy instances handle user traffic.

What’s Next?

In Part 4, we’ll focus on configuring the Regional HTTPS Load Balancer and integrating Cloud DNS. These components will ensure secure and efficient traffic routing to your backend infrastructure.

?? How do you manage scalability in your cloud infrastructure? Let’s discuss in the comments! ??

Conclusion

In Part 3, we’ve successfully:

• Created Instance Templates to ensure consistent VM configurations.
• Configured Managed Instance Groups for automated scaling and self-healing.
• Set up health checks and autoscaling policies for resilience and efficiency.

These steps provide a robust backend infrastructure for our scalable web application.