Use a deploy policy to restrict rollouts

This quickstart shows you how to prevent Cloud Deploy rollouts to a target during a specified time, and how to override that restriction.

In this quickstart, you'll do the following:

  1. Create a Skaffold configuration and a Kubernetes manifest or Cloud Run service definition to specify the (pre-built) container image to deploy.

  2. Define your Cloud Deploy delivery pipeline and one deployment target, pointing to one GKE cluster or Cloud Run service.

    This pipeline includes only one stage, for the one target.

  3. Configure a deploy policy for a target.

    The policy defines a range of dates during which to prohibit rollouts to that target.

  4. Create a release.

    Normally when you create a release, Cloud Deploy creates a rollout for the first target in your delivery pipeline's progression. In this case, because there is a policy preventing deployment to the target, the rollout for that target is not created.

  5. View the results in Google Cloud console.

    Because of the policy, you won't see a rollout for the release, and there is no pending action in the delivery pipeline visualization.

  6. Override the deploy policy.

    This override results in Cloud Deploy now creating the rollout for the target.

  7. View the results in Google Cloud console.

    Because the policy has now been overridden, you can see that there is a rollout in progress (or completed, if enough time has passed).

Before you begin

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Cloud Deploy, Cloud Build, GKE, and Cloud Storage APIs.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. Install the Google Cloud CLI.

  6. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  7. To initialize the gcloud CLI, run the following command: 

    gcloud init

  8. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the Cloud Deploy, Cloud Build, GKE, and Cloud Storage APIs.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  11. Install the Google Cloud CLI.

  12. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  13. To initialize the gcloud CLI, run the following command: 

    gcloud init

    14. If you already have the Google Cloud CLI installed, make sure you're running the latest version:

    gcloud components update
  14. Make sure the default Compute Engine service account has sufficient permissions.

    The service account might already have the necessary permissions. These steps are included for projects that disable automatic role grants for default service accounts.

    1. First add the clouddeploy.jobRunner role: 
      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/clouddeploy.jobRunner"
    2. Add the developer role for your specific runtime.
      • For GKE: 

        gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/container.developer"

      • For Cloud Run: 

        gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/run.developer"

    3. Add the iam.serviceAccountUser role, which includes the actAspermission to deploy to the runtime: 
      gcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/iam.serviceAccountUser" \
    --project=PROJECT_ID

Create your runtime environment

If you're deploying to Cloud Run, you can skip this command.

For GKE, create one cluster: quickstart-cluster-qsprod. The cluster's Kubernetes API endpoint must be network-reachable from the public internet. GKE clusters are externally accessible by default.

gcloud container clusters create-auto quickstart-cluster-qsprod \
                 --project=PROJECT_ID \
                 --region=us-central1

Prepare your Skaffold configuration and application manifest

Cloud Deploy uses Skaffold to provide the details for what to deploy and how to deploy it to your target.

In this quickstart, you create a skaffold.yaml file, which which identifies the Kubernetes manifest to be used to deploy the sample app.

  1. Open a terminal window.

  2. Create a new directory and navigate into it.

    mkdir deploy-policy-quickstart
cd deploy-policy-quickstart

  3. Create a file named skaffold.yaml with the following contents:

    GKE 

    apiVersion: skaffold/v4beta1
kind: Config
manifests:
  rawYaml:
  - k8s-pod.yaml
deploy:
  kubectl: {}

    Cloud Run 

    apiVersion: skaffold/v4beta1
kind: Config
manifests:
  rawYaml:
  - service.yaml
deploy:
  cloudrun: {}

    This file is a minimal Skaffold config. For this quickstart, you create the file. But you can also have Cloud Deploy create one for you, for basic, non-production applications.

    See the skaffold.yaml reference for more information about this configuration file.

  4. Create the manifest for your application—a service definition for Cloud Run or a Kubernetes manifest for GKE.

    GKE

    Create a file named k8s-pod.yaml, with the following contents:

    apiVersion: v1
kind: Pod
metadata:
  name: getting-started
spec:
  containers:
  - name: nginx
    image: my-app-image

    This file is a basic Kubernetes manifest, which is applied to the cluster to deploy the application. The container image to deploy is set here as a placeholder, my-app-image, which is replaced with the specific image when you create the release.

    Cloud Run

    Create a file named service.yaml, with the following contents:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-deploy-policy-run-service
spec:
  template:
    spec:
      containers:
      - image: my-app-image

    This file is a basic Cloud Run service definition, which is used to deploy the application. The container image to deploy is set here as a placeholder, my-app-image, which is replaced with the specific image when you