Skip to content

Cloud Run

Introduction

Cloud Run is a managed compute platform that lets you run containers directly on top of Google's scalable infrastructure. For more information on Cloud Run please see the Official Documentation

Prerequisites

To use Cloud Run we recommend using the Artifact Registry to deploy your containers.

Google Cloud Access

You will need access to Jax's Google Cloud. If you don't already have access, contact the RIT Service Desk.

Cloud Run Containers

Configure

Deploying a container to cloud run is easy. Just click create service and select your container. Some configuration items we recommend are the following:

  • CPU is only allocated during request processing.

    Warning

    If your container does any sort of setup i.e. database inserting post startup you will need to set this to always allocated otherwise the CPU will deallocate and your application will stop post-processing.

  • Autoscaling [min: 1 max: 5]

    Info

    To reduce cold starts (no instances running) always leave at least 1 instance running and to avoid cost hyperinflation set the max number of instances to 5 and work your way up.

  • Ingress Internal + Load Balancing.

  • Authentication Require Authentication

    Warning

    "Allow unauthenticated" if it is a public facing backend which does not need any authentication.

    The SOP for a public release involves a few steps. See Cloud Armor for how to proceed.

Load Balancing, DNS, and CloudCDN

In most scenarios you will have an associated front-end client that you would also like to deploy. To do this, you will need a load balancer. While CloudRun will natively auto-scale your API's you still would like to put this service under your own DNS. Together with a load balancer you can enable a DNS, route API requests to your CloudRun instance and all static content requests to your front-end client hosted in a bucket.

Create a static IP address

You should create a static IP (that will be used subsequently when creating a load-balancer) under the "VPC Network" service. This is the public IP that you will give to your domain name admin so that your DNS will be redirected to it. Only one external IP is needed (the access type will be set to "external").

Create Load Balancer

To create an application load balancer, while in google console search for "load balancer".

  • Select start configuration for Application Load Balancer HTTP/S
  • Choose your configuration settings, most will be global to internal VM's.

You will then continue to configure the different load balancer pieces. You only need one load balancer for all your environments.

Front-End Configuration (Load Balancer)

The front-end of the load balancer includes most of the "front" facing items including certificates, routing, and DNS.

  1. Give the load balancer a good name
    • We recommend appending "-lb" to the project name.
  2. ALWAYS in this century use HTTPS. Select it from the dropdown in protocol.

Certificates and DNS

For certificate creation see Google Managed Certificates. With a certificate you will need a DNS entry, which you can Contact JAX IT to get set up.

  1. Use the previously created static IP
  2. the SSL policy can be "GCP default" (where a Google generated certificate will be used) or a custom certificate which will have to be added separately in "Network policy -> SSL policies -> create policy".

Back-End (Load Balancer)

Adding your cloud run instance to the load balancer

This is the part where all services, buckets etc. can be added. Adding a Cloud Run service can be done via the "load balancer creation page" by clicking on "create backend service" or directly under the Cloud Run page. Then when created, these services should be selectable when creating the backend configuration of the load-balancer.

Configurations:

  • Backend Type: Serverless Network Endpoint Group (NEG)
  • In the next section you will need to create a NEG if you do not have one
  • Select cloud run and then your cloud run instance
  • Cloud CDN disabled
  • Logging enabled (who doesn't love logging?)

Cloud Armor

Cloud Armor is how you are able to control traffic to your backend services. By default no armor policy is applied and the "Authentication" policy on your Cloud Run service controls access. The process to enable public access to your applications looks like the following:

Public Release Process
  1. Apply Cloud Armor configuration for JAX Security Cloud Scanner IP's
    • Deny All default rule
    • Add rule to allow Cloud Scanner IP's
      • 34.201.223.128/25
      • 44.192.244.0/24
      • 44.206.3.0/24
      • 54.175.125.192/26
      • 13.59.252.0/25
      • 18.116.198.0/24
      • 3.132.217.0/25
      • <your-ip>
  2. Open a IT Service Desk Ticket with your name, the application, a brief description of data, and the DNS + External load balancer IP. Request to have it security scanned and approval to go public.
  3. Upon approval, remove cloud armor policy to go public.

CloudCDN & Static Content

Static content comes in many forms but in this case it is usually a client application written in a front-end framework that is then transpiled to javascript. It can include a distribution of javascript, html, and images. An important aspect to deploying static content is where you host it, particularly if your application is used worldwide. It is ideal that load times are similar no matter where you are which is why hosting content via a bucket and on CloudCDN is something you should consider.

Adding your static web content to load balancer is best done by putting your static content in a public bucket. You will need to manage versioning of this content.

To do this, in your load balancer click "create backend bucket" Configurations: - Bucket: Select the bucket with your static content - Cloud CDN enabled (careful of pricing!)

For more information please reach out to CS-SDE Team

Routing rules

These determine how your traffic will be directed. They can be directed to a backend service or a storage bucket.

  1. Select simple host and path rule for the Mode (advanced will enable you to provide these rules using a yaml file
  2. Enter a host name, its corresponding path and backend. An example for a development environment instance would be the following: 
    Host 1: myapp-dev.jax.org
Path 1: /*
Backend 1: myapp-frontend-dev-01 (the name of the frontend dev bucket of your app)
Host 2: myapp-dev.jax.org
Path 2: /api/v1/* (the path to your API/backend app and its endpoints)
Backend 2: myapp-backend-dev-01 (the name of your API/backend Cloud Run instance)