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 v2 branch. The v1 branch will maintain source compatibility with the initial release.

Custom domain mapping

Setting the dns_name will create a domain mapping for the webapp. Before setting this value you must have verified ownership of the domain with Google. Instructions on how to do this can be found in the DevOps division guidebook.

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

If allow_unauthenticated_invocations is not true, a Cloud Function will be created which authenticates via a service account, allowing the StackDriver monitoring to call the Cloud Function, with the Cloud Function authentication and proxying the request to the Cloud Run instance.

Because this requires a Cloud Function to be created, the cloudfunctions.googleapis.com service should be enabled on the project that houses the Cloud Run instance.

Static Egress IP

A static egress IP can be allocated for the cloud run instance, using the variable enable_static_egress_ip. This will configure the necessary resources to route outbound traffic from the cloud run through a static ip.

Important!

The static ip is configured with prevent_destroy = true, meaning that it cannot be destroyed without removing it from terraform state using terraform state rm and then manually destroying the resource within the GCP console. This is to prevent accidental destruction of an IP which is likely to be whitelisted within firewall configuration that lives outside of our deployments.

Secrets as Volumes and Env Vars

Secret Manager secrets can be as environment variables or volume mounts (files) in the running container.

At time of writing, this requires Cloud Run to run as BETA.

The service account that Cloud Run runs as needs access to the secrets for this feature to work. Thus, this module gives secretAccessor role to that service account for the secrets passed on secrets_volume and secrets_envars.

Any number of items in the list is supported and not defining these variables when calling this module is acceptable. The path of the mounted file will be based on path/name.

For the example configuration below the files will be /secrets-1/foobarfile1 and /secrets-2/foobarfile2. A common path for multiple secrets is not supported, they must be unique.

Note: name should only have alphanumeric characters, hyphens and underscores.

Setting version = "" is equivalent to version = "latest" but the variable is not optional.

module "webapp" {
  source = "git::https://gitlab.developers.cam.ac.uk/uis/devops/infra/terraform/gcp-cloud-run-app.git?ref=v3"

...

  secrets_volume = [
    {
      name    = "foobarfile1"
      path    = "/secret-1"
      id      = google_secret_manager_secret.secret-a.secret_id
      version = "latest"
    },
    {
      name    = "foobarfile2"
      path    = "/secret-2"
      id      = google_secret_manager_secret.secret-b.secret_id
      version = "2"
    }
  ]

  secrets_envars = [
      {
          name    = "FOOBAR1"
          id      = google_secret_manager_secret.secret-c.secret_id
          version = "latest"
      },
      {
          name    = "FOOBAR2"
          id      = google_secret_manager_secret.secret-d.secret_id
          version = ""
      }
  ]

...

Passing Image Names to the Module

Originally, the module did not deploy images except on the very first use (using gcr.io/cloudrun/hello:latest).

Currently, the module deploys the image from the mandatory variable image_name.