Deploying and implementing Cloud Run and Cloud Functions resources

Study guide for Associate Cloud Engineer, Unit 3 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Deploying and implementing Cloud Run and Cloud Functions resources. Considerations include:

1. Deploying an application
2. Deploying an application for receiving Google Cloud events (e.g., Pub/Sub events, Cloud Storage object change notification events, Eventarc)
3. Determining where to deploy an application by using Cloud Run (fully managed), Cloud Run for Anthos, or Cloud Functions

Deploying Cloud Run and Cloud Run functions

Ship it, wire it to events, and put it in the right place

Deploy — gcloud run deploy from an image or from source, and move traffic between revisions. Receive events — Eventarc triggers and Pub/Sub push, each with its own identity. Choose where — Cloud Run, Knative serving on your own clusters, or Cloud Run functions.

Unit 2 chose the platform; this topic deploys to it. The guide lists three considerations. The first is deploying an application. The second is deploying an application that receives Google Cloud events — Pub/Sub events, Cloud Storage object change notifications, and Eventarc. The third is determining where to deploy: Cloud Run fully managed, Cloud Run for Anthos, or Cloud Functions. Two of those names are older than Google's current documentation, and we will translate both when we reach them. Everything here is hands-on. Each slide ends in a command, a flag, or a setting you would actually type, and each one is quoted from the page Google publishes for it.

Deploying an application

One command, two starting points: an image or your source

• From an image: gcloud run deploy SERVICE --image IMAGE_URL
• From source: gcloud run deploy with --source; no Docker needed
• No Dockerfile? Buildpacks detect the language and build the image
• Every deploy or configuration change creates an immutable revision

Worked example (synthetic). A team with a Python app and no Dockerfile runs one gcloud run deploy --source . command. Buildpacks build the image, it lands in cloud-run-source-deploy, and the service is live — no local Docker install.

Deploying to Cloud Run is one command with two starting points. If you already have a container image, the command is gcloud run deploy, the service name, and the image flag with the image address — and Google recommends Artifact Registry as the place that image lives. If you have source code instead, the same gcloud run deploy command takes the source flag. That path uses Google Cloud's buildpacks and Cloud Build to build the container image for you, without having to install Docker on your machine. A Dockerfile is used if one is present, but it is not required: with no Dockerfile, buildpacks detect the language, fetch the dependencies and produce the image. The first time, Cloud Run even creates the Artifact Registry repository, named cloud-run-source-deploy, in your region. One detail the exam likes: if you supply neither flag, the deploy command attempts a source deployment. And every deploy — or any configuration change — creates an immutable revision, which is what the next figures are about.

Image deploy against source deploy

Same command; what differs is who builds the image

Figure. Two cards comparing image deployment, which uses gcloud run deploy with the image flag on an image you built, and source deployment, which uses the source flag and lets Cloud Build and buildpacks build the image. A band beneath lists the three roles the deployer needs either way.

Worked example (synthetic). An engineer is told to "add a build step" to a source deploy. The correction is that --source already runs Cloud Build; a separate gcloud builds submit is only needed when you want more control and deploy with --image.

Laid side by side, the two paths are the same command, and the difference is who builds the image. With an image deploy you built it, and Cloud Run imports it. With a source deploy, Cloud Build and buildpacks build it, and Google notes that running gcloud run deploy with the source flag eliminates the need to run gcloud builds submit yourself. The reverse is also documented: for more control, build the image with Cloud Build — for example gcloud builds submit — and then deploy it with the image flag. Beneath both cards is the permission set a deployer needs whichever path they take, and it is a favourite exam detail: Cloud Run Developer on the service, Service Account User on the service identity, and Artifact Registry Reader on the repository that holds the image.

Revisions and where traffic goes

A deploy creates a revision; traffic is a separate decision

Worked example (synthetic). A team changes one environment variable and is surprised by a new revision in the history. That is expected: configuration changes create revisions even with an unchanged image.

Deploying and serving are two decisions in Cloud Run, and this table separates them. Google is explicit that changing any configuration setting creates a new revision, even with no change to the container image, and that each revision is immutable. Whether that revision receives traffic is up to you. Deploy with the no-traffic flag and it serves nothing. Revision tags let you test a revision that is not serving traffic. Rolling back is a traffic change, not a redeploy: gcloud run services update-traffic, the service, and to-revisions with the old revision set to one hundred. And if you want recognisable revision names, the revision-suffix flag replaces the automatic suffix.

A gradual rollout, step by step

Deploy dark, move traffic in steps, keep the way back open

Figure: A flow chart of a gradual rollout: deploy the new revision with no traffic, send it a small share with update-traffic, check performance, then either increase the share step by step until it receives all traffic, or send all traffic back to the old revision.

Worked example (synthetic). A payments team wants to expose a new revision to a small share of requests first. It deploys with --no-traffic, then raises the new revision's value step by step with update-traffic.

Put together, the commands make a gradual rollout, and Google documents it in this order. Deploy the new revision with no traffic. Then use update-traffic to give it a small share — Google's own example value is five. After the revision's performance is satisfactory, repeat the update-traffic step and increase the value as desired, until the new revision receives all of it. If it is not satisfactory, the way back is the same command pointed at the old revision. Two rules sit under the whole flow: Cloud Run lets you choose which revisions receive traffic and in what share, and when you write the split in a service file, the values must add up to one hundred.

Who deploys, and who the service runs as

Two identities; the default one is the one to replace

Figure. Two cards: the deployer account, which runs the deploy command and is not the service identity unless configured to be, and the service identity, the service account the running instance uses, which defaults to the Compute Engine default service account while Google recommends a user-managed account with minimal permissions.

Worked example (synthetic). A service needs to read one Cloud Storage bucket. Rather than leaving it on the Compute Engine default service account, the engineer creates a dedicated service account with only that access and sets it as the service identity.

Every Cloud Run service involves two identities, and the exam tests which is which. The deployer account is whoever runs the deploy. The service identity is the service account that the Cloud Run instance itself uses when it calls Google Cloud. They are not the same thing: Google says an account used to deploy is only used as the service identity if you configure that same account in the Cloud Run configuration. Out of the box, Cloud Run provides the Compute Engine default service account as the default service identity. Google's recommendation is a user-managed service account instead — one you create yourself with the most minimal set of permissions the service needs.

Deploying an application that receives events

An Eventarc trigger turns a Google Cloud event into an HTTP request

• Eventarc trigger: filters plus a route to the target service
• Events arrive at the service as HTTP requests
• Sources: audit logs, direct events such as Cloud Storage, Pub/Sub messages
• Cloud Storage triggers: bucket and service in the same project
• The trigger has an identity; left unset, it is the Compute Engine default

Worked example (synthetic). A photo service must run whenever a user uploads a file. The engineer deploys the service, then creates an Eventarc trigger on the bucket with the object-finalized event type, running as a dedicated service account.

The second objective deploys an application that reacts to something happening in Google Cloud, and the mechanism is Eventarc — a service that lets you build event-driven architectures without implementing or maintaining the underlying infrastructure. You create an Eventarc trigger by specifying filters and a route: the event source and the target Cloud Run service. When an event matches the filters, the service is invoked automatically, and the event arrives as a hypertext transfer protocol (HTTP) request, so the service is an ordinary web service underneath. Triggers can fire on audit logs, on direct events such as an update to a Cloud Storage bucket, and on messages published to a Pub/Sub topic. Two constraints catch people out. For a Cloud Storage trigger, the service and the bucket must be in the same project. And every trigger has an identity: if you do not specify a service account, it uses the Compute Engine default service account. Google also advises deploying the service in the same region as the trigger in most scenarios.

Two ways an event reaches a private service

Each path authenticates with a service account you choose

Figure: Two paths into one private Cloud Run service. A Cloud Storage object-finalized event goes through an Eventarc trigger running as a service account. A Pub/Sub message goes through a push subscription configured with a push authentication service account. Both arrive as HTTP requests.

Worked example (synthetic). A team keeps its order service private and wires both an upload trigger and a Pub/Sub topic to it. Each path is given its own service account that is allowed to invoke the service.

Both event paths end the same way — a hypertext transfer protocol (HTTP) request to the service — and both can reach a private service, which is how Google's tutorials build them. The Pub/Sub tutorial deploys the service with the no-allow-unauthenticated flag, which restricts unauthenticated access, and notes that keeping the service private lets you rely on Cloud Run's automatic Pub/Sub integration to authenticate requests. The push subscription is created with the push-auth-service-account flag, which activates authentication for the push, and that invoker service account is given permission to invoke the service. The Eventarc path is the same idea: triggers are linked to service accounts that they use as their identity when invoking, and that account must be allowed to invoke the target.

The four Cloud Storage event types

Pick the event type that matches what actually happened to the object

Worked example (synthetic). A thumbnail service triggered on metadataUpdated never runs for new uploads. New and overwritten objects fire finalized.

Cloud Storage triggers are created with gcloud eventarc triggers create, with the bucket and an event type as filters, and choosing the type is the part the exam tests. Finalized fires when you create a new object or overwrite an existing one — the upload case. Deleted fires when an object is soft deleted. Archived fires when a live version of an object becomes a noncurrent version. And metadata updated fires when the metadata of an existing object changes. In Google's words, Cloud Run can be triggered from Cloud Storage using Eventarc in response to changes in Cloud Storage; which change is the event type you choose.

Where to deploy: three options, in today's names

The guide's three choices, and what Google calls each one now

Worked example (synthetic). An exam option reads "Cloud Run for Anthos". Translate it to Knative serving on your own Google Kubernetes Engine clusters, and the scenario that fits it — a hybrid estate — becomes obvious.

The third objective names three places to deploy, and two of the names have changed. Cloud Run, fully managed, is still Cloud Run: a fully managed application platform for running your code, function or container on Google's own infrastructure. Cloud Run for Anthos is now Knative serving. The old documentation address now leads to Knative serving, and its release notes still record the former name — including the point at which Cloud Run for Anthos became a separate experience from the managed Cloud Run product. Knative serving is Google's managed Knative offering; you enable it in your own Google Kubernetes Engine (GKE) cluster, and it exists to build and deploy serverless workloads across hybrid and multi-cloud environments. And Cloud Functions has been renamed Cloud Run functions: a function is now a Cloud Run service deployed from source code. The exam will still use the guide's names, so read them as these three.

Choosing where to deploy

Ask about the clusters first, then about the shape of the code

Figure: A decision flow. If the workload must run on your own clusters across hybrid or multi-cloud, choose Knative serving. Otherwise, if it is a single function bound to an event or a webhook, choose a Cloud Run function. Otherwise, if it runs to completion rather than serving requests, choose a Cloud Run job; if not, a Cloud Run service.

Worked example (synthetic). A retailer needs a small endpoint that a payment provider calls on each transaction. It is a webhook, so it is a Cloud Run function deployed with --allow-unauthenticated, not a cluster workload.

As a decision, ask about the clusters before the code. If the workload must run on your own Kubernetes clusters, across hybrid or multi-cloud environments, that is Knative serving — the product the guide calls Cloud Run for Anthos. Otherwise it belongs on Cloud Run, and the question becomes its shape. A function bound to events suits asynchronous work such as lightweight data processing or cloud automations, and because a function gets an HTTPS endpoint automatically, Google calls functions a perfect candidate for webhooks; a public webhook adds the allow-unauthenticated flag. Function deployments build from source with buildpacks and Cloud Build, and you name the entry point in your code. Work that runs to completion is a Cloud Run job, and everything that answers requests at a stable endpoint is a Cloud Run service. One compatibility note: existing functions can still use gcloud functions deploy, and Google documents that command separately for backward compatibility.

What this topic actually tests

Four habits, three objectives

Image or source? --image if you built it, --source if you want Cloud Build to. Deploy or serve? Revisions are created on every change; traffic moves only when you say so. Which identity? The deployer, the service, the trigger — each a separate service account. Which name? Cloud Run for Anthos is Knative serving; Cloud Functions is Cloud Run functions.

Close on four habits. First, image or source: the image flag deploys an image you built, and the source flag lets Cloud Build and buildpacks build it for you, Dockerfile optional. Second, deploying is not serving: every change creates an immutable revision, and traffic moves only when you move it — which is what makes no-traffic deploys, gradual rollouts and one-command rollbacks possible. Third, identity: the deployer, the running service and the event trigger each act as a service account, the defaults are the Compute Engine default service account, and Google recommends replacing them with user-managed accounts that hold only what they need. Fourth, translate the guide's names: Cloud Run for Anthos is Knative serving on your own clusters, and Cloud Functions is Cloud Run functions.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 3
• Deploying container images to Cloud Run
• Deploy services from source code
• Manage revisions
• Trigger services with Eventarc
• Trigger from Cloud Storage — Cloud Run
• What is Cloud Run
• Knative serving release notes
• Knative serving documentation
• Knative serving architecture overview
• Deploy functions to Cloud Run
• Cloud Run functions comparison
• Rollbacks, gradual rollouts, and traffic migration
• Introduction to service identity — Cloud Run
• Use Pub/Sub with Cloud Run
• Deploy a Cloud Run function