Cloud Run functions

Exam guide§2.1

Cloud Run functions deploy a single function instead of a whole container - Google builds the container for you. They cover code that runs in response to something happening (an HTTP call or an event) rather than a long-running service you package yourself.

Cloud Run functions

• Cloud Run functions (formerly Cloud Functions) - deploy a single function, Google builds the container. Best for lightweight event glue.
• Two generations; 2nd gen is built on Cloud Run and gets its features (concurrency, longer timeouts, traffic splitting).

≡FactsAPIs a function depends on

Before deploying, enable the services a function is built from and triggered through:

• Cloud Functions (cloudfunctions) and Cloud Run (run) - the function and its underlying service.
• Cloud Build (cloudbuild) and Artifact Registry (artifactregistry) - build the source into a container image and store it.
• Eventarc (eventarc) and Pub/Sub (pubsub) - deliver events to event-driven functions.
• Cloud Logging (logging) and Cloud Storage (storage) - runtime logs and bucket triggers.

Functions Framework

Functions Framework is Google's open-source FaaS library. You register your code under a named function entry point and the framework wraps it as a web server, so the same function runs unchanged in three places: Cloud Run functions, Cloud Run, and your local machine.

• HTTP functions register with functions.http('entryPoint', (req, res) => …) - read the request, send a response.
• Event-driven functions register with functions.cloudEvent('entryPoint', cloudEvent => …) - triggered by a CloudEvent (e.g. a Cloud Storage change).

Because the framework runs the function locally, you can unit-test before deploying: its testing module (getFunction) loads the registered function so a test runner (e.g. Mocha + Sinon) can invoke it with mock request/response objects - no deploy, no cloud round-trip.

⚠GotchaEntry point is not the service name

The function entry point is the name passed to functions.http / functions.cloudEvent (e.g. convertTemp), and it must match the --entry-point flag / Function entry point field. It is not the service name (e.g. temperature-converter). Mismatch it and the container starts but no function is found.

Triggering from Cloud Storage

A Cloud Storage function runs in response to changes in a bucket. Under the hood these are Pub/Sub notifications from Cloud Storage, routed to the function through Eventarc. For the full set of ways to invoke a Cloud Run service or function (HTTP, Pub/Sub, Eventarc, Scheduler, Cloud Tasks), see Invocation & event triggers.

≡FactsCloud Storage event types

• finalize - a new object is created (or an overwrite completes).
• delete - an object is deleted.
• archive - an object version is archived.
• metadata update - an object's metadata changes.

⚠GotchaCloud Storage triggers need IAM plumbing first

Because the trigger flows Cloud Storage -> Pub/Sub -> Eventarc, three grants must exist before you deploy:

• The Cloud Storage service agent needs Pub/Sub Publisher (roles/pubsub.publisher) to publish the notifications.
• The runtime service account (default: the Compute Engine default service account) needs Eventarc Event Receiver (roles/eventarc.eventReceiver).
• The Eventarc service agent needs Eventarc Service Agent (roles/eventarc.serviceAgent).

Miss one and the deploy fails with a permissions error. APIs also take a minute to propagate - wait, then retry.

CommandsDeploy a Cloud Storage-triggered function

gcloud functions deploy temperature-data-checker \

--gen2 --runtime nodejs22 \

--entry-point checkTempData \

--source . --region $REGION \

--trigger-bucket $BUCKET \

--trigger-location $REGION \

--max-instances 1

Every change to a file in --trigger-bucket invokes the function. Read the emitted console.log output with gcloud functions logs read <name> --gen2 --region $REGION.