Deploying Apps with Zero Downtime (Beta)

This topic describes how developers use beta Cloud Foundry Command Line Interface (cf CLI) commands to push updates to their apps without incurring downtime.

For information about the traditional method for addressing app downtime while pushing app updates, see Using Blue-Green Deployment to Reduce Downtime and Risk.

Prerequisites

The procedures in this topic require the following:

  • You must have cf CLI v6.40 or later.
  • The zero-downtime app deployment feature must be enabled for your installation.

Commands

This section describes the beta commands for working with zero-downtime app deployments.

Deploy an App

To deploy an app without incurring downtime, run the following command:

cf v3-zdt-push APP-NAME

Note: Ensure that you understand the Limitations of this feature before running the command.

For more information about this command, see How it Works.

Cancel a Deployment

To stop the deployment of an app that you pushed, run the following command:

Note: The v3-cancel-zdt-push command is designed to revert the app to its original state as quickly as possible, and does not guarantee zero downtime.

cf v3-cancel-zdt-push APP-NAME

This reverts the app to its state from before the deployment started by doing the following:

  • Scaling up the original web process
  • Removing any deployment artifacts
  • Resetting the current_droplet on the app

Restart an App

Restart your app without downtime using the following command. This is useful when applying configuration updates that require a restart, such as environment variables or service bindings.

cf v3-zdt-restart APP-NAME

How It Works

This section describes the beta cf v3-zdt-push command and its limitations.

cf v3-zdt-push Process

This section describes the process of pushing an app with cf v3-zdt-push.

  1. The cf v3-zdt-push command does the following:
    1. Stages the updated app package
    2. Creates a droplet with the updated app package
    3. Creates a deployment with the new droplet and any new configuration.
      • This starts a new process with one instance that shares the route with the old process.
      • At this point, if you run cf app on your app, you see a web process and a web-deployment-DEPLOYMENT-UUID process.
      • For more information about the deployment object, see the Deployments section of the CAPI v3 docs.
  2. Once the command creates the deployment, the cc_deployment_updater BOSH job runs in the background, updating deployments as follows:
    1. Adds another instance of the new web process and removes an instance from the old web process.

      Note: This only happens if all instances of the new web process are currently running.

    2. Repeats the above step until the new web process reaches the desired number of instances.
    3. Removes the old web process. The new web process now fully replaces the old web process.
    4. Restarts all non-web processes of the app.
    5. Sets the deployment to DEPLOYED.

Limitations

The following table describes the limitations to consider when using the beta v3-zdt-push command.

Limitation Description
Multiple app versions During a deployment, Cloud Foundry serves both the old and new version of your app at the same route. This could lead to user issues if you push backwards-incompatible API changes.
Database migrations Deployments do not handle database migrations. If you are migrating an app database and the old app is not compatible with the migration, you may still have downtime.
Non-web processes The v3-zdt commands only run web processes through the zero-downtime update sequence described above. The commands restart worker and other non-web processes in bulk after updating all web processes.

The CAPI v3 API introduces the concept of processes as runnable units of an app. Each app has a web process by default. You can specify additional processes with a procfile, and in some cases buildpacks create additional processes. For more information about processes, see the Processes section of the CAPI v3 documentation.
Quotas Pushing updates to your app with a v3-zdt command creates an extra instance of your app. If there is not enough quota available, the deployment does not work. Administrators may need to increase quotas to account for zero-downtime deployments.
Simultaneous apps when interrupting a push If you run v3-zdt-push for an app before your previous v3-zdt-push command for the same app has completed, your first push gets interrupted. Until the last deployment completes, there may be many versions of the app running at once. Eventually, the app runs the code from your most recent push.
Create a pull request or raise an issue on the source for this page in GitHub