External Application Load Balancer Module

This module allows managing Global HTTP/HTTPS Classic Load Balancers (GLBs). It's designed to expose the full configuration of the underlying resources, and to facilitate common usage patterns by providing sensible defaults, and optionally managing prerequisite resources like health checks, instance groups, etc.

Due to the complexity of the underlying resources, changes to the configuration that involve recreation of resources are best applied in stages, starting by disabling the configuration in the urlmap that references the resources that need recreation, then doing the same for the backend service, etc.

Examples

Examples
Deploying changes to load balancer configurations
- Changing the Network Endpoint Group
- Updating SSL certificate
Files
Variables
Outputs
Fixtures

Minimal HTTP Example

An HTTP load balancer with a backend service pointing to a GCE instance group:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = module.compute-vm-group-b.group.id },
        { backend = module.compute-vm-group-c.group.id },
      ]
    }
  }
}
# tftest modules=3 resources=9 fixtures=fixtures/compute-vm-group-bc.tf inventory=minimal-http.yaml e2e

Minimal HTTPS examples

HTTP backends

An HTTPS load balancer needs a certificate and backends can be HTTP or HTTPS. This is an example With HTTP backends and a managed certificate:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = module.compute-vm-group-b.group.id },
        { backend = module.compute-vm-group-c.group.id },
      ]
      protocol = "HTTP"
    }
  }
  protocol = "HTTPS"
  ssl_certificates = {
    managed_configs = {
      default = {
        domains = ["glb-test-0.example.org"]
      }
    }
  }
}
# tftest modules=3 resources=10 fixtures=fixtures/compute-vm-group-bc.tf inventory=http-backends.yaml  e2e

HTTPS backends

For HTTPS backends the backend service protocol needs to be set to HTTPS. The port name if omitted is inferred from the protocol, in this case it is set internally to https. The health check also needs to be set to https. This is a complete example:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = module.compute-vm-group-b.group.id },
        { backend = module.compute-vm-group-c.group.id },
      ]
      protocol = "HTTPS"
    }
  }
  health_check_configs = {
    default = {
      https = {
        port_specification = "USE_SERVING_PORT"
      }
    }
  }
  protocol = "HTTPS"
  ssl_certificates = {
    managed_configs = {
      default = {
        domains = ["glb-test-0.example.org"]
      }
    }
  }
}
# tftest modules=3 resources=10 fixtures=fixtures/compute-vm-group-bc.tf inventory=https-backends.yaml e2e

HTTP to HTTPS redirect

Redirect is implemented via an additional HTTP load balancer with a custom URL map, similarly to how it's done via the GCP Console. The address shared by the two load balancers needs to be reserved.

module "addresses" {
  source     = "./fabric/modules/net-address"
  project_id = var.project_id
  global_addresses = {
    "glb-test-0" = {}
  }
}

module "glb-test-0-redirect" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0-redirect"
  address = (
    module.addresses.global_addresses["glb-test-0"].address
  )
  health_check_configs = {}
  urlmap_config = {
    description = "URL redirect for glb-test-0."
    default_url_redirect = {
      https         = true
      response_code = "MOVED_PERMANENTLY_DEFAULT"
    }
  }
}

module "glb-test-0" {
  source              = "./fabric/modules/net-lb-app-ext"
  project_id          = var.project_id
  name                = "glb-test-0"
  use_classic_version = false
  address = (
    module.addresses.global_addresses["glb-test-0"].address
  )
  backend_service_configs = {
    default = {
      backends = [
        { backend = module.compute-vm-group-b.group.id },
      ]
      protocol = "HTTP"
    }
  }
  protocol = "HTTPS"
  ssl_certificates = {
    managed_configs = {
      default = {
        domains = ["glb-test.example.com"]
      }
    }
  }
}

# tftest modules=5 resources=14  fixtures=fixtures/compute-vm-group-bc.tf inventory=http-https-redirect.yaml e2e

Classic vs Non-classic

The module uses a classic Global Load Balancer by default. To use the non-classic version set the use_classic_version variable to false as in the following example, note that the module is not enforcing feature sets between the two versions:

module "glb-0" {
  source              = "./fabric/modules/net-lb-app-ext"
  project_id          = var.project_id
  name                = "glb-test-0"
  use_classic_version = false
  backend_service_configs = {
    default = {
      backends = [
        { backend = module.compute-vm-group-b.group.id },
        { backend = module.compute-vm-group-c.group.id },
      ]
    }
  }
}
# tftest modules=3 resources=9 fixtures=fixtures/compute-vm-group-bc.tf inventory=classic-vs-non-classic.yaml e2e

Health Checks

You can leverage externally defined health checks for backend services, or have the module create them for you.

By default a simple HTTP health check named default is created and used in backend services. If you need to override the default, simply define your own health check using the same key (default). For more complex configurations you can define your own health checks and reference them via keys in the backend service configurations.

Health checks created by this module are controlled via the health_check_configs variable, which behaves in a similar way to other LB modules in this repository. This is an example that overrides the default health check configuration using a TCP health check:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [{
        backend = module.compute-vm-group-b.group.id
      }]
      # no need to reference the hc explicitly when using the `default` key
      # health_checks = ["default"]
    }
  }
  health_check_configs = {
    default = {
      tcp = { port = 80 }
    }
  }
}
# tftest modules=3 resources=9 fixtures=fixtures/compute-vm-group-bc.tf inventory=health-check-1.yaml e2e

To leverage existing health checks without having the module create them, simply pass their self links to backend services and set the health_check_configs variable to an empty map:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [{
        backend = module.compute-vm-group-b.group.id
      }]
      health_checks = ["projects/${var.project_id}/global/healthChecks/custom"]
    }
  }
  health_check_configs = {}
}
# tftest modules=3 resources=8 fixtures=fixtures/compute-vm-group-bc.tf inventory=health-check-2.yaml

Backend Types and Management

Instance Groups

The module can optionally create unmanaged instance groups, which can then be referred to in backends via their key. This is the simple HTTP example above but with instance group creation managed by the module:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = "default-b" }
      ]
    }
  }
  group_configs = {
    default-b = {
      zone = "${var.region}-b"
      instances = [
        module.compute-vm-group-b.id
      ]
      named_ports = { http = 80 }
    }
  }
}
# tftest modules=3 resources=10 fixtures=fixtures/compute-vm-group-bc.tf inventory=instance-groups.yaml e2e

Managed Instance Groups

This example shows how to use the module with a manage instance group as backend:

module "win-template" {
  source          = "./fabric/modules/compute-vm"
  project_id      = var.project_id
  zone            = "${var.region}-a"
  name            = "win-template"
  instance_type   = "n2d-standard-2"
  create_template = true
  boot_disk = {
    initialize_params = {
      image = "projects/windows-cloud/global/images/windows-server-2019-dc-v20221214"
      size  = 70
    }
  }
  network_interfaces = [{
    network    = var.vpc.self_link
    subnetwork = var.subnet.self_link
    nat        = false
    addresses  = null
  }]
}

module "win-mig" {
  source            = "./fabric/modules/compute-mig"
  project_id        = var.project_id
  location          = "${var.region}-a"
  name              = "win-mig"
  instance_template = module.win-template.template.self_link
  autoscaler_config = {
    max_replicas    = 3
    min_replicas    = 1
    cooldown_period = 30
    scaling_signals = {
      cpu_utilization = {
        target = 0.80
      }
    }
  }
  named_ports = {
    http = 80
  }
}

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = module.win-mig.group_manager.instance_group }
      ]
    }
  }
}
# tftest modules=3 resources=8 inventory=managed-instance-groups.yaml e2e

Storage Buckets

GCS bucket backends can also be managed and used in this module in a similar way to regular backend services.Multiple GCS bucket backends can be defined and referenced in URL maps by their keys (or self links if defined externally) together with regular backend services, an example is provided later in this document. This is a simple example that defines a GCS backend as the default for the URL map:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_buckets_config = {
    default = {
      bucket_name = var.bucket
    }
  }
  # with a single GCS backend the implied default health check is not needed
  health_check_configs = {}
}
# tftest modules=1 resources=4 inventory=storage.yaml e2e

Network Endpoint Groups (NEGs)

Supported Network Endpoint Groups (NEGs) can also be used as backends. Similarly to groups, you can pass a self link for existing NEGs or have the module manage them for you. A simple example using an existing zonal NEG:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        {
          backend        = "myneg-b"
          balancing_mode = "RATE"
          max_rate       = { per_endpoint = 10 }
        }
      ]
    }
  }
  neg_configs = {
    myneg-b = {
      hybrid = {
        network    = var.vpc.self_link
        subnetwork = var.subnet.self_link
        zone       = "${var.region}-b"
        endpoints  = {}
      }
    }
  }
}
# tftest modules=1 resources=6 inventory=network-endpoint-groups.yaml e2e

Zonal NEG creation

This example shows how to create and manage zonal NEGs using GCE VMs as endpoints:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        {
          backend        = "neg-0"
          balancing_mode = "RATE"
          max_rate       = { per_endpoint = 10 }
        }
      ]
    }
  }
  neg_configs = {
    neg-0 = {
      gce = {
        network    = var.vpc.self_link
        subnetwork = var.subnet.self_link
        zone       = "${var.region}-b"
        endpoints = {
          e-0 = {
            instance   = "my-ig-b"
            ip_address = module.compute-vm-group-b.internal_ip
            port       = 80
          }
        }
      }
    }
  }
}
# tftest modules=3 resources=11 fixtures=fixtures/compute-vm-group-bc.tf inventory=zonal-neg-creation.yaml e2e

Hybrid NEG creation

This example shows how to create and manage hybrid NEGs:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        {
          backend        = "neg-0"
          balancing_mode = "RATE"
          max_rate       = { per_endpoint = 10 }
        }
      ]
    }
  }
  neg_configs = {
    neg-0 = {
      hybrid = {
        network = var.vpc.self_link
        zone    = "${var.region}-b"
        endpoints = {
          e-0 = {
            ip_address = "10.0.0.10"
            port       = 80
          }
        }
      }
    }
  }
}
# tftest modules=1 resources=7 inventory=hybrid-neg.yaml e2e

Internet NEG creation

This example shows how to create and manage internet NEGs:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = "neg-0" }
      ]
      health_checks = []
    }
  }
  # with a single internet NEG the implied default health check is not needed
  health_check_configs = {}
  neg_configs = {
    neg-0 = {
      internet = {
        use_fqdn = true
        endpoints = {
          e-0 = {
            destination = "www.example.org"
            port        = 80
          }
        }
      }
    }
  }
}
# tftest modules=1 resources=6 inventory=internet-neg.yaml e2e

Private Service Connect NEG creation

The module supports managing PSC NEGs if the non-classic version of the load balancer is used:

module "glb-0" {
  source              = "./fabric/modules/net-lb-app-ext"
  project_id          = var.project_id
  name                = "glb-test-0"
  use_classic_version = false
  backend_service_configs = {
    default = {
      backends = [
        { backend = "neg-0" }
      ]
      health_checks = []
    }
  }
  # with a single PSC NEG the implied default health check is not needed
  health_check_configs = {}
  neg_configs = {
    neg-0 = {
      psc = {
        region         = var.region
        target_service = "${var.region}-cloudkms.googleapis.com"
      }
    }
  }
}
# tftest modules=1 resources=5

Serverless NEG creation

The module supports managing Serverless NEGs for Cloud Run and Cloud Function. This is an example of a Cloud Run NEG:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = "neg-0" }
      ]
      health_checks = []
    }
  }
  # with a single serverless NEG the implied default health check is not needed
  health_check_configs = {}
  neg_configs = {
    neg-0 = {
      cloudrun = {
        region = var.region
        target_service = {
          name = "hello"
        }
      }
    }
  }
}
# tftest modules=1 resources=5 inventory=serverless-neg.yaml e2e

Serverless NEGs don't use the port name but it should be set to http. An HTTPS frontend requires the protocol to be set to HTTPS, and the port name field will infer this value if omitted so you need to set it explicitly:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = "neg-0" }
      ]
      health_checks = []
      port_name     = "http"
    }
  }
  # with a single serverless NEG the implied default health check is not needed
  health_check_configs = {}
  neg_configs = {
    neg-0 = {
      cloudrun = {
        region = var.region
        target_service = {
          name = "hello"
        }
      }
    }
  }
  protocol = "HTTPS"
  ssl_certificates = {
    managed_configs = {
      default = {
        domains = ["glb-test-0.example.org"]
      }
    }
  }
}
# tftest modules=1 resources=6 inventory=https-sneg.yaml e2e

Cross Project Backend

The module supports Cross Project Backends. This is an example of a referencing to a Backend in another project:

module "ralb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "ralb-test-0"

  backend_service_configs = {
    my_backend = {
      project_id = "backend_project_id" #Specify the project ID where the backend resides

      backends = [
        {
          backend = "neg-0"
        }
      ]
      health_checks = []
    }
  }
  urlmap_config = {
    default_service = "ralb-test-0-my_backend"
  }
}
# tftest modules=1 resources=5

URL Map

The module exposes the full URL map resource configuration, with some minor changes to the interface to decrease verbosity, and support for aliasing backend services via keys.

The default URL map configuration sets the default backend service as the default service for the load balancer as a convenience. Just override the urlmap_config variable to change the default behaviour:

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [{
        backend = module.compute-vm-group-b.group.id
      }]
    }
    other = {
      backends = [{
        backend = module.compute-vm-group-c.group.id
      }]
    }
  }
  urlmap_config = {
    default_service = "default"
    host_rules = [{
      hosts        = ["*"]
      path_matcher = "pathmap"
    }]
    path_matchers = {
      pathmap = {
        default_service = "default"
        path_rules = [{
          paths   = ["/other", "/other/*"]
          service = "other"
        }]
      }
    }
  }
}

# tftest modules=3 resources=10 fixtures=fixtures/compute-vm-group-bc.tf inventory=url-map.yaml e2e

SSL Certificates

The module also allows managing managed and self-managed SSL certificates via the ssl_certificates variable. Any certificate defined there will be added to the HTTPS proxy resource.

THe HTTPS example above shows how to configure manage certificated, the following example shows how to use an unmanaged (or self managed) certificate. The example uses Terraform resource for the key and certificate so that the we don't depend on external files when running tests, in real use the key and certificate are generally provided via external files read by the Terraform file() function.

resource "tls_private_key" "default" {
  algorithm = "RSA"
  rsa_bits  = 2048
}

resource "tls_self_signed_cert" "default" {
  private_key_pem = tls_private_key.default.private_key_pem
  subject {
    common_name  = "example.com"
    organization = "ACME Examples, Inc"
  }
  validity_period_hours = 720
  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "server_auth",
  ]
}

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_service_configs = {
    default = {
      backends = [
        { backend = module.compute-vm-group-b.group.id },
        { backend = module.compute-vm-group-c.group.id },
      ]
      protocol = "HTTP"
    }
  }
  protocol = "HTTPS"
  ssl_certificates = {
    create_configs = {
      default = {
        # certificate and key could also be read via file() from external files
        certificate = tls_self_signed_cert.default.cert_pem
        private_key = tls_private_key.default.private_key_pem
      }
    }
  }
}
# tftest modules=3 resources=12 fixtures=fixtures/compute-vm-group-bc.tf inventory=ssl-certificates.yaml e2e

Complex example

This example mixes group and NEG backends, and shows how to set HTTPS for specific backends.

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  backend_buckets_config = {
    gcs-0 = {
      bucket_name = var.bucket
    }
  }
  backend_service_configs = {
    default = {
      backends = [
        { backend = "group-zone-b" },
        { backend = "group-zone-c" },
      ]
    }
    neg-gce-0 = {
      backends = [{
        balancing_mode = "RATE"
        backend        = "neg-zone-c"
        max_rate       = { per_endpoint = 10 }
      }]
    }
    neg-hybrid-0 = {
      backends = [{
        balancing_mode = "RATE"
        backend        = "neg-hello"
        max_rate       = { per_endpoint = 10 }
      }]
      health_checks = ["neg"]
      protocol      = "HTTPS"
    }
  }
  group_configs = {
    group-zone-b = {
      zone = "${var.region}-b"
      instances = [
        module.compute-vm-group-b.id
      ]
      named_ports = { http = 80 }
    }
    group-zone-c = {
      zone = "${var.region}-c"
      instances = [
        module.compute-vm-group-c.id
      ]
      named_ports = { http = 80 }
    }
  }
  health_check_configs = {
    default = {
      http = {
        port = 80
      }
    }
    neg = {
      https = {
        host = "hello.example.com"
        port = 443
      }
    }
  }
  neg_configs = {
    neg-zone-c = {
      gce = {
        network    = var.vpc.self_link
        subnetwork = var.subnet.self_link
        zone       = "${var.region}-c"
        endpoints = {
          e-0 = {
            instance   = "my-ig-c"
            ip_address = module.compute-vm-group-c.internal_ip
            port       = 80
          }
        }
      }
    }
    neg-hello = {
      hybrid = {
        network = var.vpc.self_link
        zone    = "${var.region}-b"
        endpoints = {
          e-0 = {
            ip_address = "192.168.0.3"
            port       = 443
          }
        }
      }
    }
  }
  urlmap_config = {
    default_service = "default"
    host_rules = [
      {
        hosts        = ["*"]
        path_matcher = "gce"
      },
      {
        hosts        = ["hello.example.com"]
        path_matcher = "hello"
      },
      {
        hosts        = ["static.example.com"]
        path_matcher = "static"
      }
    ]
    path_matchers = {
      gce = {
        default_service = "default"
        path_rules = [
          {
            paths   = ["/gce-neg", "/gce-neg/*"]
            service = "neg-gce-0"
          }
        ]
      }
      hello = {
        default_service = "neg-hybrid-0"
      }
      static = {
        default_service = "gcs-0"
      }
    }
  }
}
# tftest modules=3 resources=19 fixtures=fixtures/compute-vm-group-bc.tf inventory=complex-example.yaml e2e

Deploying changes to load balancer configurations

Load balancers consists of many resources depending on each other. The Global external Application Load Balancer architecture for serverless apps diagram shows the structure of a Global external Application Load Balancer, but others are similar.

To prevent disruption to the traffic, any change to the configuration of the load balancer that requires replacing a resource currently in use by other resources will fail. For example, replacing a backend service that a URL map still references will fail because it would disrupt traffic during the replacement process.

The following changes result in resource replacements:

changing name, project, network, subnetwork, region, zone
(Backend service) changing of the load balancing scheme
(Forwarding rule) almost any change
(SSL certificate) changing of the key/certificate for un-managed and list of domains for managed SSL certificates
(Network Endpoint Groups) almost any change

Changing the Network Endpoint Group

Let's start with the example of a Load Balancer that is using Cloud Run via Serverless NEG:

module "addresses" {
  source     = "./fabric/modules/net-address"
  project_id = var.project_id
  global_addresses = {
    glb-0 = {}
  }
}

module "glb-0" {
  source     = "./fabric/modules/net-lb-app-ext"
  project_id = var.project_id
  name       = "glb-test-0"
  address    = module.addresses.global_addresses["glb-0"].address
  backend_service_configs = {
    default = {
      backends = [
        { backend = "neg-0" }
      ]
      health_checks = []
      port_name     = "http"
    }
  }
  # with a single serverless NEG the implied default health check is not needed
  health_check_configs = {}
  neg_configs = {
    neg-0 = {
      cloudrun = {
        region = var.region
        target_service = {
          name = "hello"
        }
      }
    }
  }
  protocol = "HTTPS"
  ssl_certificates = {
    managed_configs = {
      default = {
        domains = ["${module.addresses.global_addresses["glb-0"].address}.nip.io"]
      }
    }
  }
}

# tftest skip

Changing the target Cloud Run service name, tags, or URL mask requires replacing the associated network endpoint group (NEG). However, this replacement will fail if the NEG is currently used by a backend service. Forcing the replacement of the backend service will also fail if it's referenced by a URL map, and this cascade of failures continues until the entire load balancer is replaced.

To successfully implement the change, create a new NEG that points to the new Cloud Run service before modifying the existing load balancer configuration.

  ...
  neg_configs = {
    neg-0 = {
      cloudrun = {
        region = var.region
        target_service = {
          name = "hello"
        }
      }
    }
    neg-1 = {
      cloudrun = {
        region = var.region
        target_service = {
          name = "hello2"
        }
      }
    }
  }
  ...
# tftest skip

After applying this change, you can update the backend service to point to the new Cloud Run service:

  backend_service_configs = {
    default = {
      backends = [
        { backend = "neg-1" }
      ]
      health_checks = []
      port_name     = "http"
    }
  }

If you prefer to maintain the original naming convention, you can modify neg-0 to point to the hello2 service. After making this change, switch the backend configuration back to neg-0, and finally remove neg-1.

Updating SSL certificate

Most material changes to SSL certificates, such as adding a new domain or rotating the certificate, necessitate resource recreation. Modifying an existing certificate fails because it's currently used by the load balancer. To implement such a change, provision a new certificate first, then remove the old one in a separate step.

To illustrate, let's add an domain to the certificate in the previous example:

  ...
  ssl_certificates = {
    managed_configs = {
      default = {
        domains = ["${module.addresses.global_addresses["glb-0"].address}.nip.io"]
      }
      new = {
        domains = [
          "${module.addresses.global_addresses["glb-0"].address}.nip.io",
          "${replace(module.addresses.global_addresses["glb-0"].address, ".", "-")}.nip.io",
        ]
      }
    }
  }
  ...
# tftest skip

After provisioning this change, and verifying that the new certificate is provisioned (in the case of managed certificates), you can remove the old default certificate.

Files

name	description	resources
backend-service.tf	Backend service resources.	`google_compute_backend_service`
backends.tf	Backend groups and backend buckets resources.	`google_compute_backend_bucket`
groups.tf	None	`google_compute_instance_group`
health-check.tf	Health check resource.	`google_compute_health_check`
main.tf	Module-level locals and resources.	`google_compute_global_forwarding_rule` · `google_compute_managed_ssl_certificate` · `google_compute_ssl_certificate` · `google_compute_target_http_proxy` · `google_compute_target_https_proxy`
negs.tf	NEG resources.	`google_compute_global_network_endpoint` · `google_compute_global_network_endpoint_group` · `google_compute_network_endpoint` · `google_compute_network_endpoint_group` · `google_compute_region_network_endpoint_group`
outputs.tf	Module outputs.
urlmap.tf	URL map resources.	`google_compute_url_map`
variables-backend-service.tf	Backend services variables.
variables-health-check.tf	Health check variable.
variables-urlmap.tf	URLmap variable.
variables.tf	Module variables.
versions.tf	Version pins.

Variables

name	description	type	required	default
name	Load balancer name.	`string`	✓
project_id	Project id.	`string`	✓
address	Optional IP address used for the forwarding rule.	`string`		`null`
backend_buckets_config	Backend buckets configuration.	`map(object({…}))`		`{}`
backend_service_configs	Backend service level configuration.	`map(object({…})) }))`		`{}`
description	Optional description used for resources.	`string`		`"Terraform managed."`
group_configs	Optional unmanaged groups to create. Can be referenced in backends via key or outputs.	`map(object({…}))`		`{}`
health_check_configs	Optional auto-created health check configurations, use the output self-link to set it in the auto healing policy. Refer to examples for usage.	`map(object({…}))`		`{…}`
https_proxy_config	HTTPS proxy connfiguration.	`object({…})`		`{}`
labels	Labels set on resources.	`map(string)`		`{}`
neg_configs	Optional network endpoint groups to create. Can be referenced in backends via key or outputs.	`map(object({…}))`		`{}`
ports	Optional ports for HTTP load balancer, valid ports are 80 and 8080.	`list(string)`		`null`
protocol	Protocol supported by this load balancer.	`string`		`"HTTP"`
ssl_certificates	SSL target proxy certificates (only if protocol is HTTPS) for existing, custom, and managed certificates.	`object({…})`		`{}`
urlmap_config	The URL map configuration.	`object({…})`		`{…}`
use_classic_version	Use classic Global Load Balancer.	`bool`		`true`

Outputs

name	description	sensitive
address	Forwarding rule address.
backend_service_ids	Backend service resources.
backend_service_names	Backend service resource names.
forwarding_rule	Forwarding rule resource.
global_neg_ids	Autogenerated global network endpoint group ids.
group_ids	Autogenerated instance group ids.
health_check_ids	Autogenerated health check ids.
id	Fully qualified forwarding rule id.
neg_ids	Autogenerated network endpoint group ids.
psc_neg_ids	Autogenerated PSC network endpoint group ids.
serverless_neg_ids	Autogenerated serverless network endpoint group ids.

Fixtures

compute-vm-group-bc.tf

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

README.md

README.md

External Application Load Balancer Module

Examples

Minimal HTTP Example

Minimal HTTPS examples

HTTP backends

HTTPS backends

HTTP to HTTPS redirect

Classic vs Non-classic

Health Checks

Backend Types and Management

Instance Groups

Managed Instance Groups

Storage Buckets

Network Endpoint Groups (NEGs)

Zonal NEG creation

Hybrid NEG creation

Internet NEG creation

Private Service Connect NEG creation

Serverless NEG creation

Cross Project Backend

URL Map

SSL Certificates

Complex example

Deploying changes to load balancer configurations

Changing the Network Endpoint Group

Updating SSL certificate

Files

Variables

Outputs

Fixtures

Files

README.md

Latest commit

History

README.md

File metadata and controls

External Application Load Balancer Module

Examples

Minimal HTTP Example

Minimal HTTPS examples

HTTP backends

HTTPS backends

HTTP to HTTPS redirect

Classic vs Non-classic

Health Checks

Backend Types and Management

Instance Groups

Managed Instance Groups

Storage Buckets

Network Endpoint Groups (NEGs)

Zonal NEG creation

Hybrid NEG creation

Internet NEG creation

Private Service Connect NEG creation

Serverless NEG creation

Cross Project Backend

URL Map

SSL Certificates

Complex example

Deploying changes to load balancer configurations

Changing the Network Endpoint Group

Updating SSL certificate

Files

Variables

Outputs

Fixtures