GCP

Components of a GCP HTTP(s) LoadBalancer

dmr

• 2 min read

I had a task to create a GCP http(s) load balancer using terraform, I need to recognise that I did not know were to start from.Creating the load balancer from the console is quite easy, you create the instance template, managed instance group and the firewall, but when I started to read on how to do the same in terraform I was a bit confused.
The creation of the http(s) firewall translates to this 5 resources in terraform:

google_compute_backend_service
google_compute_global_forwarding_rule
google_compute_target_http_proxy
google_compute_url_map
google_compute_health_check

At a first glance it was a bit confusing for me, but after I started reading about each one separately it started to make sense.

So the above resources translates like this.

google_compute_backend_service

  • A Backend Service defines a group of virtual machines that will serve traffic for load balancing.
  • This resource is a global backend service, appropriate for external load balancing or self-managed internal load balancing.
  • For managed internal load balancing, use a regional backend service instead.

google_compute_global_forwarding_rule

  • Global forwarding rules are used to forward traffic to the correct load balancer for HTTP load balancing.
  • Global forwarding rules can only be used for HTTP load balancing.
  • This binds an ip and port to a target HTTP(s) proxy.

google_compute_target_http_proxy

  • Represents a TargetHttpProxy resource, which is used by one or more global forwarding rule to route incoming HTTP requests to a URL map.

google_compute_url_map

  • UrlMaps are used to route requests to a backend service based on rules that you define for the host and path of an incoming URL.

google_compute_health_check

  • Health Checks determine whether instances are responsive and able to do work.
  • Health Checks poll instances at a specified interval.
  • Instances that do not respond successfully to some number of probes in a row are marked as unhealthy.
  • No new connections are sent to unhealthy instances, though existing connections will continue.
  • The health check will continue to poll unhealthy instances.
  • If an instance later responds successfully to some number of consecutive probes, it is marked healthy again and can receive new connections.

Now by putting all this togheter you will be able to create a http(s) load balancer.
It will take some time to get comfortable with this approach, but after you get used with it, you will see that all makes sense.
In a future post I will add also the terraform code which it will include

  • Network configuration (VPC and subnets)
  • Firewall rules
  • Instance template
  • Backend configuration
  • Forwarding rules
  • Http proxy
  • Url maps
  • Health check

in order to create the load balancer.