logo

GCP - Cloud Run

Auth

Build Locally

# Build an ARM64 version, if you want to test it on your mac.
$ docker buildx build . -t foo.com/my_image_arm64:0.1 --platform linux/arm64

# Build an AMD64 version to run on Cloud Run.
$ docker buildx build . -t foo.com/my_image_amd64:0.1 --platform linux/amd64

Run on macOS

This creates a ~/.config/gcloud/application_default_credentials.json.

$ gcloud auth application-default login

When running locally, mount the application_default_credentials.json we just created (-v for volume), and specify GOOGLE_APPLICATION_CREDENTIALS (-e for env):

$ docker run -v ~/.config/gcloud/application_default_credentials.json:/root/cred.json  -e GOOGLE_APPLICATION_CREDENTIALS=/root/cred.json foo.com/my_image_arm64:0.1

Upload to Artifact Registry

Assuming you selected us-west4 region:

Config:

$ gcloud auth configure-docker us-west4-docker.pkg.dev

To list artifact repositories:

$ gcloud artifacts repositories list --project=myproject

Tag and push

$ docker tag foo.com/my_image_amd64:0.1 \
us-west4-docker.pkg.dev/myproject/myrepo/my_image_amd64:0.1

$ docker push us-west4-docker.pkg.dev/myproject/myrepo/my_image_amd64:0.1

Run Job

Create Job

$ gcloud run jobs create my-job --region us-west4 --image us-west4-docker.pkg.dev/myproject/myrepo/my_image_amd64:0.1

Describe Job

$ gcloud run jobs describe my-job --region us-west4

Execute Job

$ gcloud run jobs execute my-job --region us-west4

Does Cloud Run Scale Down to 0?

Yes.

If the Minimum number of instances 0, it will scale down to 0 when there's no traffic. This is very useful to reduce cost for low traffic or prototype apps. If you want to keep at least 1 instance running, to void startup delays, set it to >0.

By Cloud Console:

  • Go to Cloud Run page
  • Click Edit & deploy new revision.
  • Modify Minimum number of instances
  • Click Deploy

By gcloud:

gcloud run services update SERVICE_NAME --min-instances=0 --region=REGION_NAME

Best practices for storing API Keys

For Google Cloud Run, the best practice for using API keys is to integrate with Google Cloud Secret Manager. This is the most secure method because it separates your sensitive data from your container image and application code. Cloud Run is designed to work seamlessly with Secret Manager, offering two primary ways to access secrets:

1. Referencing as an Environment Variable (Recommended)

This is the most common and straightforward method. When you deploy or update your Cloud Run service, you configure it to link an environment variable to a secret in Secret Manager. The value of the secret is then injected into the container at startup.

  • How it works: You create a secret in Secret Manager, for example, my-api-key. Then, during deployment, you use the Google Cloud console, gcloud CLI, or a YAML file to map an environment variable (e.g., API_KEY) to that secret.
  • Security benefits: The secret never exists in your source code, the container image, or even in your deployment manifest. Cloud Run handles the secure retrieval and injection for you.
  • Caveat: If you update the secret in Secret Manager, the Cloud Run service will not automatically get the new value. You must deploy a new revision of your service to load the updated secret.

2. Mounting as a Volume

This method allows your application to access the secret as a file within the container's file system.

  • How it works: You specify a volume mount in your Cloud Run service configuration that references the secret. The secret's value will be available at a specified file path inside the container.
  • Security benefits: Similar to environment variables, the secret is not part of the image. This approach can be more flexible for applications that are designed to read configurations from files.
  • Benefit of this method: Unlike with environment variables, when you update a secret in Secret Manager and configure the volume to use the "latest" version, the running container can access the new secret value without a full redeployment. This is useful for secrets that need to be rotated frequently.

What's under the hood of Cloud Run?

Cloud Run is based on Knative

Under the hood, Cloud Run is based on knative. You can tell that by checking the config yaml:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: your-service-name
spec: ...

Cloud Run Relationship with GCE and GKE

  • If --platform=managed, Cloud Run does NOT run in GKE. It is serverless, so it is managed by Google for you.
  • If --platform=gke it will run on a GKE cluster. It is used to be called Cloud Run for Anthos, however the term Anthos is deprecated, the new name is Knative serving.
  • GKE uses GCE instances as Nodes; however Cloud Run does NOT depend on GCE.

Is Cloud Run service / job running in a virtual machine?

If Cloud Run does NOT depend on GCE, is it running inside a VM?

The 1st gen of Cloud Run used a sandboxing technology called gVisor. Instead of a full virtual machine, gVisor creates a lightweight, isolated environment for your container.

The 2nd gen of Cloud Run uses a microVM for each instance of your container. This VM is extremely lightweight, with a stripped-down guest operating system (stripped-down from the GCE VM), which allows it to start up very quickly.

logo
PRIVACY POLICYABOUT中文