Skip to main content

Cloud Run

Exam guide§2.1

Run code without managing servers. Everything scales automatically and can scale to zero.

</>Write codeany languagePackage as containerimage in Artifact Registrygcloud run deploylaunch on Cloud Run
The Cloud Run deploy loop: write code in any language, package it as a container, then `gcloud run deploy` to launch it.
  • Deploy a container (from Artifact Registry) or deploy from source (--source, buildpacks). Must listen on $PORT, be stateless, respond to HTTP/gRPC/events.
  • Two resource types: services (request-based, HTTP/gRPC) and jobs (run-to-completion tasks).
  • Built on Knative (open API + runtime on Kubernetes), so the same container runs fully managed on Google Cloud, on GKE, or anywhere Knative runs - avoids lock-in.

Features & benefits​

Features:Benefits:Unique HTTPS endpoint for each serviceFast request-based auto scalingBuilt-in traffic managementPrivate and public servicesAccess resources in the VPC networkIntegrates with Google Cloud servicesServerlessSupports continuous delivery of codeAutomatic logging and error reportingPay-per-use pricing
Cloud Run features (what the platform does for a service) and the benefits they buy you.

Services and jobs​

Job with one container instanceTimeJob with multiple container instancesTimeArray job
A Cloud Run job runs one container instance, or - as an Array job - many identical instances in parallel to finish the same work faster.

Cloud Run runs a container two ways:

  • A service handles requests. It gives you a reliable HTTPS endpoint and autoscales; your only job is to listen on $PORT and handle HTTP/gRPC. Detail: Resource model.
  • A job runs code that does work and then quits - a script, batch task, or migration. It starts one container instance, or (an Array job) many identical instances in parallel to finish faster - e.g. process many Cloud Storage files at once, one per instance. Run it from gcloud, schedule it, or drive it from a workflow.

What's in this section​

Read top to bottom for a first pass; each page also stands alone as revision notes.

PageWhat you'll learn
Resource modelService, revision, container instance, job, task - the nouns and how they nest
Develop, test & deployApp fit, source-to-container, the runtime contract, execution environments, local testing
Container lifecycleThe five runtime states: starting, serving, idle, shutting down, stopped
Autoscaling & concurrencyScale to zero, min/max instances, concurrency, cold starts
Revisions & trafficImmutable revisions; split, pin, and tag traffic for canary and rollback
Secrets & env varsInject config and Secret Manager values into a container
Access & networkingInbound IAM (who can invoke), ingress, and reaching a VPC network
Service identityThe identity your code runs as when it calls other Google Cloud APIs
Integrating with servicesClient libraries, Memorystore, Cloud SQL, and managed integrations
Invocation & event triggersHow a service is invoked: HTTP/gRPC, Pub/Sub push, Eventarc, Cloud Scheduler, Cloud Tasks
Cloud Run functionsDeploy a single function; the Functions Framework and Cloud Storage triggers

Recap​

DECISIONCloud Run vs. Cloud Run functions?
Single small event handler→Cloud Run functions
Full app, custom container, any binary→Cloud Run
Web/API service, gRPC→Cloud Run
Route many GCP event sources to a service→Eventarc + Cloud Run
Pick this when: functions = one event handler; Cloud Run = a full container/app
0%0 of 147 pages studied