Canary Deployments to Cloud Run

This document describes how to configure and use canary deployments to deploy your applications to Cloud Run (services only—not jobs) using Cloud Deploy.

A canary deployment is a progressive rollout of a new version of your application, where you gradually increase the percentage of traffic sent to the new version, while monitoring the application's performance. This helps you to catch potential problems early and minimize the impact on your users.

How canary deployments work for Cloud Run

When you deploy to Cloud Run using a canary deployment strategy, Cloud Deploy updates your existing service with a new revision. The new revision receives a specified percentage of traffic, and the old revision continues to receive the remainder. You gradually increase the traffic split to the new revision over time.

Using Cloud Deploy, you can configure canary deployments to Cloud Run in a single stage or in multiple stages.

The instructions here include only what is specific to canary configuration. The document Deploy a Cloud Run service or job has the general instructions for configuring and executing your deployment pipeline.

Make sure you have the required permissions

In addition to other Identity and Access Management permissions you need for using Cloud Deploy, you need the following permissions in order to perform additional actions that might be needed for a canary deployment:

clouddeploy.rollouts.advance
clouddeploy.rollouts.ignoreJob
clouddeploy.rollouts.cancel
clouddeploy.rollouts.retryJob
clouddeploy.jobRuns.get
clouddeploy.jobRuns.list
clouddeploy.jobRuns.terminate

See IAM roles and permissions for more information about what available roles include these permissions.

Prepare your `skaffold.yaml`

Your skaffold.yaml file defines how your Cloud Run service definitions are rendered and deployed. For a canary deployment to Cloud Run, ensure it correctly points to your service definition file(s) and defines any necessary build artifacts (like container images). No special canary-specific configuration is required within skaffold.yaml itself beyond what's needed for a standard deployment. You might use Skaffold profiles to manage different service definition variations for custom canary phases.

Prepare your service definition

Your normal Cloud Run service definition file is sufficient, but without a traffic stanza. Cloud Deploy manages splitting traffic for you between the last successful revision and the new revision.

Example service.yaml (without traffic stanza):

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-cloudrun-service
spec:
  template:
    spec:
      containers:
      - image: gcr.io/my-project/my-cloudrun-app
        ports:
        - containerPort: 8080

Configure an automated canary

Configure an automated canary directly within your delivery pipeline definition for a specific Cloud Run stage. Cloud Deploy automatically instructs Cloud Run to split traffic between the last stable revision and the new revision according to the specified percentages.

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

In this configuration:

PERCENTAGES is a comma-separated list of percentage values representing your canary increments, for example [25, 50, 75]. Note that this doesn't include 100, because 100% percent deployment is assumed in the canary, and is handled by the stable phase.
You can enable deployment verification (verify: true). If you do so, a verify job is added to each canary phase.
PREDEPLOY_ACTION

Is the same as the ACTION_NAME that you used in your skaffold.yaml to define the custom action you want to run before deploying.
POSTDEPLOY_ACTION

Is the same as the ACTION_NAME that you used in your skaffold.yaml to define the custom action you want to run after deploying.

Configure a custom canary

You can configure your canary manually instead of relying fully on the automation provided by Cloud Deploy. With custom canary configuration, you specify the following, in your delivery pipeline definition:

Rollout phase names

In a fully-automated canary, Cloud Deploy names the phases for you (canary-25, canary-75, stable, for example). With a custom canary, however, you can give each phase any name, as long as it's unique among all phases for this canary stage, and it honors resource ID restrictions. But the final (100%) phase name must be stable.
Percentage goals for each phase

Specify the percentages separately, per phase.
Skaffold profiles to use for the phase

You can use a separate Skaffold profile for each phase, or the same profile, or any combination. And each profile can use a different Cloud Run service definition. You can also use more than one profile for a given phase. Cloud Deploy combines them.
Whether there is a verify job for the phase

Remember that if you're enabling verify, you need to configure your skaffold.yaml for verification also.
Whether there are predeploy or postdeploy jobs for the phase

If you're enabling predeploy or postdeploy jobs, you need to configure your skaffold.yaml for those jobs.

All target types are supported for custom canary.

Custom canary configuration elements

The following YAML shows the configuration for the phases of fully custom canary deployment:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

In this YAML

PHASE1_NAME

Is the name of the phase. Each phase name must be unique.
[ "PROFILE_NAME" ]

Is the name of the profile to use for the phase. You can use the same profile for each phase, or a different one for each, or any combination. Also, you can specify more than one profile. Cloud Deploy uses all of the profiles you specify, plus the profile or manifest used by the overall stage.
stable

The final phase must be named stable.
PERCENTAGE1

Is the percentage to deploy for the first phase. Each phase must have a unique percentage value, and that value must be a whole percentage (not 10.5, for example), and the phases must be in ascending order.
verify: true|false

Tells Cloud Deploy whether to include a verify job for the phase. Note that for each phase to use verify, Skaffold uses the same profile for verify that is specified for render and deploy for that phase.
PREDEPLOY_ACTION

Is the same as the ACTION_NAME that you used in your skaffold.yaml to define the custom action you want to run before deploying.
POSTDEPLOY_ACTION

Is the same as the ACTION_NAME that you used in your skaffold.yaml to define the custom action you want to run after deploying.

The percentage for the last phase must be 100. Phases are executed according in the order you configure them in this customCanaryDeployment stanza, but if the percentage values are not in ascending order, the command to register the delivery pipeline fails with an error.

Note that the configuration for a custom canary doesn't include a runtimeConfig stanza. If you include runtimeConfig, it's considered a custom-automated canary.

Configure a custom-automated canary

This combines custom phase definition (names, percentages, profiles, verify, hooks) with Cloud Deploy's automatic traffic management for Cloud Run. You define the phases, but Cloud Deploy handles instructing Cloud Run to shift traffic based on the percentages.

To configure this, include both the runtimeConfig.cloudRun.automaticTrafficControl: true setting and the customCanaryDeployment section (defining phaseConfigs) within the strategy.canary block. Cloud Deploy will use the specified Skaffold profiles for rendering the service definition (which still shouldn't have a traffic stanza) but will automatically manage traffic according to the phase percentages.

serialPipeline:
  stages:
  - targetId: cloudrun-prod
    profiles: []
    strategy:
      canary:
        # Include runtimeConfig for automatic traffic management
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        # Include customCanaryDeployment for phase customization
        customCanaryDeployment:
          phaseConfigs:
          - phaseId: "warmup-cr"
            percentage: 10
            profiles: ["base-config"] # Profile rendering service def (no traffic stanza)
            verify: true
          - phaseId: "scaling-cr"
            percentage: 50
            profiles: ["base-config"] # Can use the same profile
            verify: true
          - phaseId: "stable"
            percentage: 100
            profiles: ["base-config"]
            verify: true

Execute the Cloud Run canary

Register Pipeline and Targets: Apply your delivery pipeline and Cloud Run target configuration files.
```
gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
gcloud deploy apply --file=cloudrun-targets.yaml --region=REGION
```
The delivery pipeline includes the automated or custom canary configuration, for your chosen runtime.

Create a Release: Start the deployment, providing the image name.


gcloud deploy releases create RELEASE_NAME \
                                --delivery-pipeline=PIPELINE_NAME \
                                --region=REGION

The delivery pipeline identified by PIPELINE_NAME contains the automated or custom canary configuration described in this document.

Advance the canary:
gcloud CLI
```
gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION
```
Where:

ROLLOUT_NAME is the name of the current rollout which you're advancing to the next phase.

RELEASE_NAME is the name of the release that this rollout is part of.

PIPELINE_NAME is the name of the delivery pipeline you're using to manage deployment of this release.

REGION is the name of the region in which the release was created, for example us-central1. This is required.

See the Google Cloud SDK reference for more information about the gcloud deploy rollouts advance command.
Google Cloud console
1. Open the Delivery pipelines page.
2. Click your pipeline shown in the list of delivery pipelines.
  
  The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress.
3. On the Rollouts tab, under Delivery pipeline details, click the name of your rollout.
  
  The rollout details page is shown, for that rollout.
  
  Notice that in this example, the rollout has a canary-50 phase and a stable phase. Your rollout might have more phases or different phases.
4. Click Advance rollout.
  
  The rollout is advanced to the next phase.

Skipped phases

If you deploy a canary and your application has not been deployed to that runtime yet, Cloud Deploy skips the canary phase and runs the stable phase. See Skipping phases the first time to find out why this happens.

What's next

Try the canary deployment quickstart.
Find out how to manage the lifecycle of your canary's rollouts.
Learn more about parallel deployment.
Learn more about Cloud Deploy deployment strategies.
Learn more about Cloud Run.

Canary Deployments to Cloud Run Stay organized with collections Save and categorize content based on your preferences.