Deployment options
Cloud Run offers multiple deployment options. All deployment options result in a container image that runs as a Cloud Run service or job on Cloud Run's fully managed and highly scalable infrastructure.
Container images
Any container image which adhere to Cloud Run's container runtime contract can be deployed to a Cloud Run service or job.
Sources
For convenience, Cloud Run lets you build and deploy source code
from a single command.
When deploying sources, Cloud Build transforms the code into a container
image stored in Artifact Registry.
You can deploy sources that include a Dockerfile or are written in one of
the supported language runtimes.
Sources can be deployed to a Cloud Run service or job.
Functions
You can deploy single-purpose functions that respond to events emitted from your cloud infrastructure and services. Your function is triggered when an event being watched is fired.
A functions deployment is a special type of source deployment, where you only have to provide the function code. You can write Cloud Run functions using a number of supported programming languages.
Functions are deployed as Cloud Run services.
Continuous source deployment from git
Cloud Run helps you configure continuous deployment from Git.
Like source deployments, you can deploy sources that include a
Dockerfile or are written in one of the supported language runtimes.
Continuous deployment from Git is available for Cloud Run services and can be manually configured in Cloud Build for Cloud Run jobs.
Cloud Run services
The service is one of the main resource of Cloud Run. Each service is located in a specific Google Cloud region. For redundancy and failover, services are automatically replicated across multiple zones in the region they are in. A given Google Cloud project can run many services in different regions.
Each service exposes a unique endpoint and automatically scales the underlying infrastructure to handle incoming requests. You can deploy a service from a container, repository, or source code.
The following diagram shows the Cloud Run resource model for services:
The diagram shows a Google Cloud project containing three Cloud Run
services, Service A, Service B and Service C, each of which has several revisions.
In the diagram, Service A is receiving many requests, which results in the
startup and running of several instances, each running a single container. Note
that Service B is not receiving requests, so no instance is started yet.
Service C is running multiple containers per instance within each revision: note that only
the ingress container receives the request. Every instance with multiple
containers scales as an independent unit.
Cloud Run service revisions
Each deployment to a service creates a revision. A revision consists of one or more container images, along with configuration such as environment variables, memory limits, or request concurrency value.
Revisions are immutable: once a revision has been created, it cannot be modified. For example, when you deploy a container image to a new Cloud Run service, the first revision is created. If you then deploy a different container image to that same service, a second revision is created. If you subsequently set an environment variable, a third revision is created, and so on.
Requests are automatically routed as soon as possible to the latest healthy service revision.
Cloud Run service instances
Each service revision receiving requests is automatically scaled to the number of instances needed to handle all these requests. Note that instances can receive many requests at the same time. With the request concurrency setting, you can set the maximum number of requests that can be sent in parallel to each instance of a revision.
Cloud Run jobs
Each job is located in a specific Google Cloud region and executes one or more containers to completion. A job consists of one or multiple independent tasks that are executed in parallel in a given job execution.
Cloud Run job executions
When a job is executed, a job execution is created in which all job tasks are started. All tasks in a job execution must complete successfully for the job execution to be successful. You can set timeouts on task and specify the number of retries in case of task failure. If any task exceeds its maximum number of retries, that task is marked as failed and the job is marked as failed. By default, tasks execute in parallel up to a maximum of 100, but you can specify a lower maximum if any of your backing resources require it.
Cloud Run job tasks
Every job execution executes a number of tasks in parallel. Each task runs one instance, and might retry it.