BREAKING CHANGE: migrate to cloud run v2 resources

The Cloud Run Domain Mapping service is still in Pre-GA status after
more than 3 years. Google's documentation now suggest using load balancers
or Firebase Hosting as an alternative as there are limitations with the domain mapping service.
We are removing it from this module as it seems as though it will soon be deprecated.

BREAKING CHANGE: Remove Cloud Run Domain Mapping

This commit refactors the uptime_monitoring module to no longer require
an additional "stackdriver" aliased google provider.
This was a source of confusion as it did some "magic" with regards to
passing project IDs around.
The two projects are now clearly defined as either `project` or
`monitoring_scoping_project` to avoid any confusion.

This is initially planned to execute Django database migrations. However,
other use cases will exist I'm sure.

BREAKING CHANGE: The default SSL policy restricts TLS to >= 1.2 and
sets the SSL profile to MODERN.

BREAKING CHANGE: Upgrading to v3 of the gcp-site-monitoring module
will cause uptime check functions to be destroyed/re-created during the
next Terraform apply.

Currently uses sql_instance_connection_name which causes
issues when the provided value is not known until apply.

The dashboard, defined in ./dashboard.json, contains:
- Request counts broken down by response code class (ignoring 404s).
- Request latencies for 50th, 95th and 99th percentile.
- Container CPU and memory utilisations for 50th, 95th and 99th percentile.
- Container instance count and billable instance time.

Wajdi Hajji authored 3 years ago and Arun Patel committed 3 years ago

(cherry picked from commit a068f599)

Arun Patel authored 3 years ago and Wajdi Hajji committed 3 years ago

This works with Terraform v0.14.10; the data source is read before
the plan walk, so the existing deployed image can be determined.
However, it is suggested that future Terraform may combine the
refresh and plan walks which *may* result in a cyclic dependancy.

Arun Patel authored 3 years ago and Wajdi Hajji committed 3 years ago

This works with Terraform v0.14.10; the data source is read before
the plan walk, so the existing deployed image can be determined.
However, it is suggested that future Terraform may combine the
refresh and plan walks which *may* result in a cyclic dependancy.

This works with Terraform v0.14.10; the data source is read before
the plan walk, so the existing deployed image can be determined.
However, it is suggested that future Terraform may combine the
refresh and plan walks which *may* result in a cyclic dependancy.

Rather than ship our own monitoring module, make use of the
gcp-site-monitoring module. This effectively makes this module require
0.13 so a major version bump is required.

Closes #13

It would appear that the "run.googleapis.com/ingress" annotation can be
set to "all" without having to enable the beta launch stage. Indeed it
*has* to be set to "all" since attempting to unset it causes Cloud Run
to immediately reset it.

The "run.googleapis.com/ingress-status" annotation is maintained by the
infrastructure Google-side so ignore changes to it.

Provide a variable which allows ingress type to be specified. This
allows placing the service behind Cloud Load Balancer.

Provide variables which allow extra annotations to be added to the Cloud
Run service and the service template.

Also remove the alerting_enabled default to false for two reasons:
1) To force the developer to make a decision on monitoring
2) If alerting_enabled is true but alerting_email_address is not set up, then there is not much point as we don't have any other channel set up.