Professional Cloud Developer
Professional Cloud Developer
Intermediate
Gauge your current knowledge
Intermediate
Gauge your current knowledge
Deploying applications to Cloud Run
...
Professional Cloud Developer
Gauge your current knowledge
Gauge your current knowledge
When you deploy an application directly from source code to Cloud Run, you can skip writing a Dockerfile. Google Cloud uses Buildpacks and Cloud Build to automatically turn your code into a container. Buildpacks examine your source code to identify the programming language, such as Python or Java, and then locate and install all required dependencies by reading configuration files like package.json. Cloud Build runs this entire packaging process in the cloud, and once complete, it stores the final container image in Artifact Registry, which is a secure, managed repository for your software packages.
This automated system supports continuous delivery by automatically moving your code from a commit to a live, running service. When Cloud Run receives the image, it creates a serverless environment that scales up during traffic spikes and scales down to zero when idle to save costs. The process also improves security by providing a clear record of how the image was built and can automatically update base components to patch vulnerabilities. For sensitive data, you should use Secret Manager, and control who can trigger builds with IAM roles.
The command gcloud run deploy --source lets you deploy code directly without building a container yourself, using the same automated Buildpacks to create the image. For this to work, you must grant the Cloud Run Builder role to the service account so it has permission to build and deploy your code on your behalf. You control how your application runs using deployment flags; for example, --set-env-vars passes configuration settings like database passwords into the app as environment variables, letting you change settings without altering source code.
You also set resource constraints to manage performance and cost, defining how much CPU and memory each instance can use, and controlling how many requests one instance handles at a time (concurrency). You can automate deployments by setting up Cloud Build triggers so that every time you push new code, a new build and deployment starts automatically. To optimize for both performance and cost, you can set scaling rules, such as keeping a minimum number of instances ready to avoid slow cold starts when traffic arrives, and setting a maximum to prevent runaway costs during a traffic spike.
Container images created from your source code are stored in Artifact Registry, a private managed repository that ensures only your authorized Cloud Run services can pull the images to run them. For source deployments, Cloud Run can automatically create a repository in Artifact Registry to hold your images. Managing who and what can access these resources is done through IAM roles; a developer needs the Cloud Run Source Developer role to deploy from source, the Cloud Run service needs the Artifact Registry Reader role to pull the image, and Cloud Build needs the Cloud Run Builder role to create and manage the service.
Cloud Build uses a service account to do its work, and this account must have the correct permissions to access your source code and push images to Artifact Registry. To add stronger security to your deployment pipeline, you can use Binary Authorization, which only allows container images built by your trusted process to run. You can also use VPC Service Controls to create a security boundary around your resources, protecting them from data leaks.
When Cloud Run services respond to events from sources like Pub/Sub or Eventarc, the system must handle failures gracefully. A retry policy automatically attempts to deliver a message again when the first try fails, and if a message keeps failing after several attempts, it moves to a dead-letter queue where developers can review it later. This prevents one bad message from stopping the entire system. Because events might arrive more than once due to automatic retries, services must process events in an idempotent way, producing the same result whether it handles a message once or multiple times, which prevents duplicate records or wrong data in your database.
For data that lives in multiple places, developers choose between different replication strategies. Synchronous replication writes to multiple locations at once for the strongest consistency, while asynchronous replication is faster but may create conflicts if data changes in two places simultaneously. Multi-region deployments protect against regional outages by running services in different geographic areas.
Eventarc routes events from various Google Cloud sources to destinations like Cloud Run, and events follow the CloudEvents standard, which gives every event a consistent format that any application can understand. You create an Eventarc trigger to define which events reach your service, connecting to different event providers including Google Sources (events from Pub/Sub, Cloud Storage, or Firestore), Third-party events from outside Google Cloud, and Custom events from your own applications. Each trigger specifies an event provider and the specific event type that should start the process.
Filters narrow down which events actually reach your service, such as filtering to a specific storage bucket or particular action name, helping the system scale efficiently. The service account running the trigger needs the Cloud Run Invoker role to call your service and the Eventarc Event Receiver role to receive events from providers. Place your trigger, the event source, and your Cloud Run service in the same Region to reduce delay, and allow up to two minutes for the full configuration to take effect.
Event-driven architecture lets applications react automatically to changes like new messages or file uploads, and Eventarc connects these events to Cloud Run services so your code runs only when triggered. A Pub/Sub push subscription sends messages directly to a URL on your Cloud Run service via HTTP POST requests, which is preferred for Cloud Run because the service starts up automatically when a new message arrives. You configure the event provider, the event type, and the destination Cloud Run service.
Cloud Run services stay private by default; to let a trigger call your service, grant the Cloud Run Invoker role to the trigger's service account. Without this permission, requests fail with unauthenticated errors. While the default Compute Engine service account works for testing, create a custom service account for production to follow the principle of least privilege. Keep the trigger, event source, and Cloud Run service in the same Region to minimize latency, and ensure the Pub/Sub service agent has the Service Account Token Creator role to generate the OIDC tokens needed for secure message delivery.
Pub/Sub is an asynchronous messaging service that decouples publishers from subscribers; publishers send messages to a topic, and subscribers receive them through a subscription. This decoupling makes cloud-native applications more flexible and easier to scale. There are two subscription models: pull subscriptions where the application actively asks for messages, and push subscriptions where Pub/Sub delivers messages directly to a web endpoint via HTTP POST requests.
To connect Pub/Sub to Cloud Run, developers use Eventarc to create a trigger acting as an event receiver. Key components include event filters, which define which messages trigger the service; a destination, which is the Cloud Run service; and a transport topic, which is the Pub/Sub topic where original messages are sent. Configuring these triggers ensures events are delivered in the standard CloudEvents format, making data handling consistent. If a message cannot be delivered after several attempts, it can be sent to a dead-letter topic for later investigation.
Eventarc acts as a bridge connecting event providers to destinations like Cloud Run, and authentication ensures only trusted sources can trigger your application. The Cloud Run Invoker role allows a service account to call your application endpoint; without this role, the system blocks the request and shows an authentication error. Other key roles include Eventarc Event Receiver, which lets the trigger receive events from providers, and Pub/ Sub Publisher, which is required for sources like Cloud Storage.
A service account acts as the identity for your Eventarc trigger, and using a custom service account is a best practice to follow the Principle of Least Privilege. When configuring a trigger, you must link it to a service account that has permission to invoke your Cloud Run service, using OpenID Connect (OIDC) tokens to verify that the event source is legitimate. If the setup is incorrect, your service receives a message stating the request was not authenticated.
Eventarc helps you build event-driven architectures by routing signals from different sources to specific destinations, using a trigger as a bridge that listens for changes and starts your service. This setup allows for decoupled communication where services do not need to be directly connected to work together. To set up a trigger, you define the trigger type, which can be a Google source, a Custom source, or a Third-party provider, and select an event provider such as Cloud Storage or Pub/Sub along with a specific event type.
Precise delivery is handled through filters, which are rules that match specific criteria to ensure only the right events reach your application. Matching the trigger's location with the source and destination helps minimize latency and improve performance. You can create triggers using the Google Cloud console, the gcloud CLI, or Terraform, and verify the trigger is active by listing your triggers. Common configuration steps include selecting the correct destination service, defining the service URL path, and enabling Retry on failure for better reliability.
Apigee is an API management platform that helps developers design, secure, and scale their application interfaces, using the OpenAPI Specification to define a clear contract for how services should be accessed. To control who can access an API, developers implement security protocols like OAuth 2.0 and OpenID Connect (OIDC), which verify that only trusted users or services can interact with sensitive data. Common security measures include API key validation, OAuth scopes limiting specific actions a user can perform, and JWT verification checking digital signatures on identity tokens.
When deploying applications to Cloud Run, developers use IAM to manage permissions, preferring short-lived credentials and service accounts following the principle of least privilege. Threat protection policies defend against common vulnerabilities like injection attacks or unauthorized data access, and VPC Service Controls create a security perimeter that prevents data exfiltration by restricting how data moves between services.
Managing an API requires understanding its lifecycle, which includes stages like Stable, Beta, and Deprecated. Stable endpoints are reliable and rarely change, while Beta endpoints are still being developed and may have breaking changes. Developers use semantic versioning to track updates, often employing a URI versioning strategy that keeps the original endpoint unchanged to maintain backward compatibility. A systematic deprecation schedule gives users enough time to update their applications.
When migrating to a new version, developers must audit their code to find structural changes in data types or function names. API keys should not be provided as query parameters in URLs because they can be easily stolen; instead, use the x-goog-api-key HTTP header or a client library to pass credentials securely. Google Cloud provides tools like Apigee, API Gateway, and Cloud Endpoints to manage and protect interfaces, with Apigee being an enterprise-scale platform offering advanced security features.
Apigee provides a secure proxy layer between users and backend services, creating a facade that hides backend complexity while adding essential features. Individual proxies are grouped into API products, which serve as the central mechanism for authorization, bundling proxies together with a specific service plan defining how they can be used. Developers register their applications to receive an API key, which is required to authenticate every request.
Apigee uses policies to maintain performance and availability, including Spike Arrest to protect against sudden traffic surges, Quotas to enforce long-term consumption limits, and Response Caching to store frequently accessed data to reduce latency. Securing interfaces involves multiple protection layers including OAuth 2.0 and Transport Layer Security (TLS), ensuring only authorized users access sensitive data while keeping communication encrypted. API lifecycle management requires strategic versioning to ensure updates do not break existing client applications, which is vital for deploying applications to environments like Cloud Run where scalability and consistent performance are required.