Deploy your application

This page describes how to use Google Cloud Deploy to get your application into your intended target runtime environments. Before you do this, you need to create your delivery pipeline and targets.

This page includes how to do the following:

  • Invoke your delivery pipeline to create a release.

  • Promote that release.

  • Approve or reject the promotion.

  • Abandon a release.

  • Manually deploy directly to a specific target.

Before you begin

This section describes the things you need to have in place before you can deploy your application using Google Cloud Deploy.

Invoke your delivery pipeline to create a release

You can now submit your application to be deployed according to the delivery pipeline you created.

  1. Run your regular continuous-integration (CI) process, creating the deployable artifact or artifacts.

  2. Initiate the delivery pipeline by calling Google Cloud Deploy to create a release.

    Run the following command from the directory containing your Skaffold config:

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

    Where:

    RELEASE_NAME is a name to give to this release. The name must be unique among all releases for this delivery pipeline.

    You can specify dynamic release names by including '$DATE' or '$TIME' or both. For example, if you invoke this command at 3:07pm UTC, 'rel-$TIME' resolves to rel-1507. '$DATE' and '$TIME' must be in single-quotes, and the time is UTC time on the machine where you invoke the command.

    PIPELINE_NAME is the name of the delivery pipeline that will manage deployment of this release through the progression of targets. This name must match the name field in the pipeline definition.

    REGION is the name of the region in which you're creating the release, for example us-central1. This is required.

This command uploads a tarball containing your configs to a Cloud Storage bucket and creates the release. Google Cloud Deploy also automatically creates a rollout and deploys your image to the first target defined in the delivery pipeline.

In addition to the parameters shown with this command, you can include either of the following options:

  • --images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>

    A collection of image name to image full-path replacements.

  • --build_artifacts=<path/file>

    A reference to a Skaffold build artifacts output file, which can be passed in to represent the image full path replacements

These two options are mutually exclusive.

You can also include the a flag to have Google Cloud Deploy generate a skaffold.yaml file for you:

  • --from-k8s-manifest=MANIFEST

    The generated Skaffold config is based on the manifest you pass this flag. Using this flag with either the --skaffold-file flag or the --source flag, generates an error. See Generating your skaffold.yaml for more details.

Change the deployment timeout

For deployments to GKE and Anthos target clusters, there are three separate timeouts that affect how long the system waits for Kubernetes to report a stable deployment:

  • Cloud Build has a timeout of 1 hour on operations that Cloud Build performs for Google Cloud Deploy.

    You can change this timeout in the configuration for your execution environment.

  • Skaffold has a health-check timeout (deploy.statusCheckDeadlineSeconds), which is the amount of time, in seconds, to wait for deployments to stabilize.

    The default is 600 seconds (10 minutes). To use this timeout, deploy.statusCheck must be set to true. By default, it is. If statusCheck is false, there is no status check, the rollout is marked successful after kubectl apply finishes successfully.

  • For Kubernetes resources of kind: Deployment, there's Deployment.spec.progressDeadlineSeconds, which is the amount of time Kubernetes waits for the Deployment to report as stable.

    This timeout is applicable to Deployment resources only. Here's how these first two timeouts work together:

    • If Deployment.spec.progressDeadlineSeconds, in Kubernetes, is unset, then the Skaffold health-check timeout is the effective timeout, whether it's the default or is explicitly set.

    • If Deployment.spec.progressDeadlineSeconds, in Kubernetes, is set, then Skaffold ignores its own health-check timeout, and the Kubernetes progress deadline is the effective timeout. However, if the Kubernetes timeout is explicitly set to 600 (10 minutes), then Skaffold assumes that it's the default (unset) and ignores it, and the Skaffold timeout is used (if set).

    • If neither timeout is set, then the effective timeout is the Skaffold default of 600 (10 minutes).

    Besides Deployments, other Kubernetes resources can have timeouts, which do not influence the stability timeout. If any of these are present, review them to ensure they are not in conflict with the stability timeout.

    If Skaffold (or Cloud Build) times out, the GKE deployment continues to run. Google Cloud Deploy shows a failure, but it can still succeed or fail on the GKE cluster.

To change your deployment stability timeout:

  1. Ensure that deploy.statusCheck is set to true in skaffold.yaml.

    true is the default. When true, Skaffold waits for health checks to report a stable deployment, subject to the timeout value in the next step.

  2. In skaffold.yaml, set statusCheckDeadlineSeconds to the number of seconds you want to wait.

    deploy:
      ...
      statusCheck: true
      statusCheckDeadlineSeconds: 600
      ...
    

    The default is 600 (10 minutes). Skaffold waits this amount of time for a stable deployment. If this time is exceeded before the deployment is stable, the deployment fails.

  3. In your Kubernetes manifest, for resources of kind: Deployment, set Deployment.spec.progressDeadlineSeconds to the same value as you set for statusCheckDeadlineSeconds.

What's next