You can use Cloud Tasks to securely enqueue a task to be asynchronously processed by a Cloud Run service. Typical use cases include:
- Preserving requests through unexpected production incidents
- Smoothing traffic spikes by delaying work that is not user-facing
- Speeding user response time by delegating slow background operations to be handled by another service, such as database updates or batch processing
- Limiting the call rate to backing services like databases and third-party APIs
This page shows how to enqueue tasks that are securely pushed via the HTTPS protocol to a private Cloud Run service. It describes required behavior for the private Cloud Run service, required service account permissions, task queue creation, and task creation.
Before you start
Enable the Cloud Tasks API on the project you are using.
Deploying a Cloud Run service to handle tasks
To deploy a service that accepts tasks sent to the task queue,
deploy the service in the same way as any other
Cloud Run service. The Cloud Run service must return an
HTTP 200
code to confirm success after processing of the task is complete.
Tasks will be pushed to this Cloud Run service as HTTPS requests by Cloud Tasks.
The response to Cloud Tasks must occur within its configured timeout. For workloads that need to run longer than the maximum Cloud Tasks timeout, consider using Cloud Run jobs.
Deploy with Terraform
To learn how to apply or remove a Terraform configuration, see Basic Terraform commands.
To create a service, add the following to your .tf
file:
Creating a task queue
Command line
To create a task queue, use the command
gcloud tasks queues create QUEUE-ID
replacing QUEUE-ID with the name you want to give to your task queue:
it must be unique in your project. If you are prompted to create an App Engine
app in your project, respond y
to create it. Cloud Tasks uses
this for the queue: make sure you choose the same location as you are using for
your Cloud Run service.
The default task queue configuration should work in most cases. However, you can optionally set different rate limits and retry parameters if you want.
Terraform
To learn how to apply or remove a Terraform configuration, see Basic Terraform commands.
To create a task queue, add the following to your .tf
file:
Apply the changes by entering terraform apply
.
Creating a service account to associate with the tasks
You must create a service account that will be associated with the enqueued tasks. This service account must have the Cloud Run Invoker IAM role to allow the task queue to push tasks to the Cloud Run service. .
Console
In the Google Cloud console, go to the Service Accounts page.
Select a project.
Enter a service account name to display in the Google Cloud console.
The Google Cloud console generates a service account ID based on this name. Edit the ID if necessary. You cannot change the ID later.
Optional: Enter a description of the service account.
Click Create and continue.
Optional: Click the Select a role field.
Select Cloud Run > Cloud Run Invoker.
Click Done.
Command line
Create the service account:
gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \ --display-name "DISPLAYED_SERVICE_ACCOUNT_NAME"
Replace
- SERVICE_ACCOUNT_NAME with a lower case name unique within
your Google Cloud project, for example
my-invoker-service-account-name
. - DISPLAYED_SERVICE_ACCOUNT_NAME with the name you want to
display for this service account, for example, in the console, for example,
My Invoker Service Account
.
- SERVICE_ACCOUNT_NAME with a lower case name unique within
your Google Cloud project, for example
For Cloud Run, give your service account permission to invoke your service:
gcloud run services add-iam-policy-binding SERVICE \ --member=serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/run.invoker
Replace
- SERVICE with the name of the service you want to be invoked by Cloud Tasks.
- SERVICE_ACCOUNT_NAME with the name of the service account.
- PROJECT_ID with your Google Cloud project ID.
Grant your service account access to the project so that it has permission to complete specific actions on the resources in your project:
gcloud projects add-iam-policy-binding RESOURCE_ID \ --member=PRINCIPAL --role=roles/run.invoker
Replace
RESOURCE_ID: Your Google Cloud project ID.
PRINCIPAL: An identifier for the principal, or member, which usually has the following form: PRINCIPAL_TYPE:ID. For example,
user:my-user@example.com
. For a full list of the values that PRINCIPAL can have, see the Policy Binding reference.
Terraform
To learn how to apply or remove a Terraform configuration, see Basic Terraform commands.
Add the following to your .tf
file:
Create the service account:
For Cloud Run, give your service account permission to invoke your service:
Apply the changes by entering terraform apply
.
Creating HTTP tasks with authentication tokens
When you create a task to send to the task queue, you specify the project, the location, queue name, the email of the previously created service account to associate with tasks, the URL of the private Cloud Run service that will run the task, and any other data you need to send. You can choose to hardcode these values, though values like the project ID, location, and service account email can be dynamically retrieved from the Cloud Run metadata server.
Refer to the
Cloud Tasks API documentation for details on the
task request body.
Note that requests that contain data payloads must use the HTTP PUT
or
POST
method.
The code that enqueues the tasks must have the necessary IAM permissions to do so, such as the Cloud Tasks Enqueuer role. Your code will have the necessary IAM permissions if you use the default service account on Cloud Run.
The following examples create task requests that also include the creation of a header token. OIDC tokens are used in the examples. To use an OAuth token, replace the OIDC parameter with the language appropriate OAuth parameter in constructing the request.
Python
Note the requirements.txt
file:
Java
Note the pom.xml
file:
Go
Node.js
Note the package.json
file:
What's next
- Logging and viewing logs
- Monitoring health and performance
- Triggering from Pub/Sub
- Invoking with HTTPS
- Running services on a schedule