README.md

GCP Cloud Run manager terraform module

This module manages a Cloud Run-hosted container. It takes care of making sure the container is connected to a Cloud SQL instance and sets environment variables on the application.

Specify the project to deploy into on the command line. So, for example, to deploy to the project my-project:

$ terraform init
$ terraform apply -var project=my-project

In this example, terraform is configured to use default application credentials. For Google APIs and these credentials should correspond to a user with owner or editor access to the target project. You can use the gcloud command line tool to set your personal credentials as application default credentials. See the gcloud auth application-default command output for more information.

Versioning

The master branch contains the tip of development and corresponds to the v4 branch. The v1, v2 and v3 branches will maintain source compatibility with the initial release.

Ingress style

There are two supported ingress styles depending on var.ingress_style variable.

var.ingress_style can be:

• domain-mapping (default): passing DNS domains as var.dns_names or var.dns_name, which takes precedence over var.dns_names, will create domain mappings to the Cloud Run service. Before setting this, you must have verified ownership of the provided domains with Google. Instructions on how to do this can be found in the DevOps division guidebook.

• load-balancer: a load balancer will be configured instead of a domain mapping. The DNS domains in var.dns_names or var.dns_name, which takes precedence over var.dns_names, will get Google-managed or custom TLS certificates depending on var.use_ssl_certificates and var.ssl_certificates. An IPv6 address can also be allocated to the load balancer if var.enable_ipv6 is true.

Monitoring and Alerting

If the variable alerting_email_address is set, the module adds basic uptime alerting via email for failing http polling.

If the variable disable_monitoring is true, the module will disable monitoring. This is different from disabling alerting; if no alerting email addresses are provided, the uptime checks will still be configured, there just won't be any alerts sent if they fail. Disabling monitoring will also disable alerting as without any monitoring there is nothing to alert(!)

See variables.tf for how to configure alerting and monitoring.

Note that the project containing resources to be monitored must be in a Stackdriver monitoring workspace and this must be configured manually. At the time of writing there is no terraform support for this. This module will error when applying if this is not so.

Stackdriver distinguishes between workspaces and projects within those workspaces. Each workspace must have a host project and that project must be the default project of the google.stackdriver provider used by this module. The google.stackdriver must be configured with credentials allowing monitoring resources to be created in the host project.

If the workspace host project differs from the project which contains the resources to be monitored, you can use a provider alias:

provider "google" {
  project = "my-project"

  # ... some credentials for the *project* admin ...
}

provider "google" {
  project = "stackdriver-host-project"
  alias   = "host"

  # ... some credentials for the *product* admin ...
}

module "cloud_run_service" {
  # ... other parameters ...

  providers = {
    google.stackdriver = google.host
  }
}

Monitoring instances which require service account authentication