Skip to content

GCP Run

Introduction

Coherence, based on the open-source cnc framework, offers you choices in the architecture your app will use to deploy to GCP. Each architecture has a different goal in terms of trade-offs between cost, compliance, scale, and complexity. Unlike a "black box" platform, usingcnc you're able to customize these deployments further based on your needs, giving you total control.

The run flavor uses Cloud Run for web-facing workloads, and GKE Autopilot for workers and scheduled tasks. It manages a shared VPC configuration with private networking across the 2 systems, and provides unified environments that are full-featured and enterprise-ready. This flavor chooses security & compliance best practices over low cost. See run-lite for a free-friendly option.

Resources Used

Networking

  • A unique VPC is configured for each application. Multiple services in one application share a VPC.
  • Regional Load Balancing is used to route traffic to the right verion and service in your VPC
  • Managed SSL Certificates are used to secure connections to the application with no maintainence required.
    • For custom domains, all you need to do tell us the domain and point an A record in your DNS provider to the IP for your application (shown in the Coherence UI).
    • GCP support for custom domains with wildcard subdomains requires you to provide your own SSL certificate at this time, and upload it to the SSL Certificates interface in the GCP console

Build & Deploy

  • Cloud Build is used to build and deploy all the configured services. Build steps are parallelized as much as possible.

Data Storage

Each environment in Coherence gets a database on a shared instance (for review apps). It gets its own memorystore instance. For production, a distinct instance will be used - you also have the option to provide the name of an existing Cloud SQL instance and we will configure your app to use that instance. Generally we recommend this as a best practice. See the coherence.yml docs for more details.

  • Cloud SQL is used to provide database resources. Backups & high availability are not configured by default and the instance type is a micro - changing these in the UI or with the CLI will not be treated as drift.
  • Memorystore is used to provde hosted redis instances. Similar to Cloud SQL, backups and availability are confiigured for effeciency by default but changes to these configurations will not be overwriten by Coherence.
  • Google Cloud Storage resources for object storage are also supported, the bucket information will be provided via environment varialbes to your application.

Container Orchestration

GCP's Cloud Run is unique when compared to ECS in AWS because it offers scale-to-0 autoscaling. This can keep costs very low, it's a true "serverless" container orchestration layer. However, it has some limitations when it comes to long-running jobs. So, we integrate it seamlessly with GKE to provide you with the best experience possible across best-in-class tools on GCP, each for their own purpose.

  • Cloud Run for both frontend and backend. We configure GCP's CDN in front of the frontend service type.
    • The reason to use Cloud Run for the frontend vs Google Cloud Storage is due to the need for redirects based on 404 so you can do proper client-side routing in a Single Page App. We deploy nginx in Cloud Run (all configured and managed for you) for this purpose.
    • GCP’s solution is Firebase sites which has its own separate integration into other GCP services, see Reddit or Stack Overlow
  • Google Kubernetes Engine is used for running async workers (like a celery/sidekiq queue worker) and for running scheduled tasks (cron tasks) if those are configured. The GKE control plane incurs a monthly cost in additon to deployed workloads.

Observability & Monitoring

  • GCP Operations Suite (formerly Stackdriver) is configured to collect logs and metrics. You can adjust log filters and retention rules in the GCP console to control the cost of log ingestion and storage, if required as you scale.

Security & Configuration

  • IAM Role and Policy are used for providing permissions to the services. Distinct identies are provisioned with minimum permissions for different app components, such as building, deploying, and executing the application.
  • Secrets Manager is used to store Environment Variables.
  • Workload Identity as well as Cloud Run and Cloud Build Service Account integrations are used to assume app service accounts as needed without ever touching a key file.
  • Compute Engine is used to provide a bastion host so that external connectivity to resources in the VPC is possible, from either your local network or Coherence's toolboxes.

Default Labels

For convenience and auditability, Coherence adds default labels to all cloud resources where applicable: 

    default_labels = {
        environment = "your-collection-name"
        managed_by = "coherence"
        application = "your-application-name"
    }