Select an execution environment for services (original) (raw)

All Cloud Run instances are sandboxed, the sandboxing technology and available features differs depending on the selected execution environment.

The first generation execution environment is based on gVisorand features fast cold starttimes and emulation of most, but not all operating system calls.

The second generation execution environment is a microVM and provides full Linux compatibility rather than system call emulation. This execution environment provides:

Although the second generation execution environment generally performs faster under sustained load, it has longer cold start timesthan first generation for some services.

Both execution environments have the same pricing. See the Cloud Run pricing pagefor details.

Selecting an execution environment for a Cloud Run service

Cloud Run services by default don't have an execution environment specified, which means Cloud Run selects the execution environment based on the features used. If you don't specify an execution environment for your service, Cloud Run can select either the first generation or the second generation environment.

Cloud Run jobs and worker pools only use the second generation execution environment, and this cannot be changed.

How to choose an execution environment

You should use first generation if any of the following apply:

You should use second generation if any of the following apply to your Cloud Run service:

Required roles

To get the permissions that you need to configure and deploy Cloud Run services, ask your administrator to grant you the following IAM roles:

If you are deploying a serviceor function from source code, you must also have additional roles granted to you on your project and Cloud Build service account.

For a list of IAM roles and permissions that are associated with Cloud Run, seeCloud Run IAM rolesand Cloud Run IAM permissions. If your Cloud Run service interfaces with Google Cloud APIs, such as Cloud Client Libraries, see theservice identity configuration guide. For more information about granting roles, seedeployment permissionsand manage access.

Set and update execution environment

Any configuration change leads to the creation of a new revision. Subsequent revisions will also automatically get this configuration setting unless you make explicit updates to change it.

The default for Cloud Run services is unspecified, which means that Cloud Run selects a suitable execution environment. Alternatively, you can specify an execution environment. To use second generation, you must specify at least 512 MiB of memory.

You can set the execution environment using the Google Cloud console, the gcloud command line, or a YAML file when you create a new service ordeploy a new revision:

Console

  1. In the Google Cloud console, go to Cloud Run:
    Go to Cloud Run
  2. Select Services from the Cloud Run navigation menu, and clickDeploy container to configure a new service. If you are configuring an existing service, click the service, then click Edit and deploy new revision.
  3. If you are configuring a new service, fill out the initial service settings page, then click Containers, Networking, Security to expand the service configuration page.
  4. Click the Container tab.
    image
    • Select the desired execution environment using the option buttons. Keep "Default" to let Cloud Run select a suitable execution environment.
  5. Click Create or Deploy.

gcloud

You can update the execution environmentfor a given service by using the following command:

gcloud run services update SERVICE --execution-environment ENVIRONMENT

Replace SERVICE with the name of your service and ENVIRONMENTwith the desired execution environment. Specify the value gen1 for first generation or gen2 for second generation.

You can also set the execution environment duringdeployment using the command:

gcloud run deploy --image IMAGE_URL --execution-environment ENVIRONMENT

Replace the following:

YAML

  1. If you are creating a new service, skip this step. If you are updating an existing service, download its YAML configuration:
    gcloud run services describe SERVICE --format export > service.yaml
  2. set the run.googleapis.com/execution-environment annotation:
    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
    name: SERVICE
    spec:
    template:
    metadata:
    annotations:
    run.googleapis.com/execution-environment: ENVIRONMENT

Replace the following:

  1. Create or update the service using the following command:
    gcloud run services replace service.yaml

Terraform

To learn how to apply or remove a Terraform configuration, seeBasic Terraform commands.

Add the following to agoogle_cloud_run_v2_service resource in your Terraform configuration: 

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-execution-environment"
  location = "REGION"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    execution_environment = "ENVIRONMENT"
  }
}

Replace the following:

View Execution environment settings

To view the current Execution environment settings for your Cloud Run service:

Console

  1. In the Google Cloud console, go to the Cloud Run Services page:
    Go to Cloud Run
  2. Click the service you are interested in to open the Service detailspage.
  3. Click the Revisions tab.
  4. In the details panel at the right, the Execution environment setting is listed under the Container tab.

gcloud

  1. Use the following command:
    gcloud run services describe SERVICE
  2. Locate the Execution environment setting in the returned configuration.

Graceful shutdowns

When a Cloud Run instance is shutting down, it receives aSIGTERM signalto enable a 10 second graceful shutdown.

Handling SIGTERM signal

We recommend that your container install a SIGTERM handler, especially if you are using request-based billing.

Handling SIGTERM gives your container a chance to perform any necessary cleanup tasks such as flushing logs before exiting. If your container does not catch SIGTERM, it will still be given 10 seconds to perform these tasks; those 10 seconds are billed.

How to check whether your container handles SIGTERM

To determine whether your container has a SIGTERM handler installed:

  1. Start Cloud Shell. You can findActivate Cloud Run button Activate Cloud Shell in the header of the documentation page you're on. You may need to authorize it and wait for it to provision. Alternatively, start a standalone session.
  2. Run the container locally in Cloud Shell:
    docker run IMAGE_URL
    Replace IMAGE_URL with a reference to the container image, for example, us-docker.pkg.dev/cloudrun/container/hello:latest. If you use Artifact Registry, the repository REPO_NAME must already be created. The URL follows the format of LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  3. Open another tab in Cloud Shell and get a list of the containers running in the current Cloud Shell session:
    docker container ls
    You need to locate the container ID returned from the command.
  4. Using the container ID, send your container a SIGTERM signal
    docker kill -s SIGTERM CONTAINER_ID
  5. Return to the tab where you invoked docker run to see whether the container has exited (stopped). If the SIGTERM signal caused your container to exit, your container is handling SIGTERM.

How to handle SIGTERM

If your container does not handle SIGTERM, the simplest way to add a SIGTERM handler is to wrap your service with tini. Doing this makes your service run as a subprocess of tini, which takes on the role of the container init process. Refer to the Docker instructionsfor instructions.

Alternatively, you can change your application to directly handle SIGTERM.

What's next