Configuring rolling app deployments

You can use Cloud Foundry Command Line Interface (cf CLI) commands or the Cloud Foundry API (CAPI) to push your apps to VMware Tanzu Application Service for VMs (TAS for VMs) using a rolling deployment.

For information about the traditional method for addressing app downtime while pushing app updates, see Using blue-green deployment to reduce downtime and risk.

For more information about CAPI, see the Cloud Foundry API (CAPI) documentation.

Prerequisites

The procedures in this topic require one of the following:

cf CLI v7: Install cf CLI v7.
CAPI V3: If you use CAPI V3, you must install the cf CLI.

Commands

This section describes the commands for working with rolling app deployments.

Deploy an app

To deploy an app without incurring downtime:

Caution Ensure that you understand the limitations of this feature before running the command. For more information, see Limitations.

For cf CLI v7, run:
```
cf push APP-NAME --strategy rolling --max-in-flight MAX_IN_FLIGHT
```
Where APP-NAME is the name that you want to give your app. Where MAX_IN_FLIGHT specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1.

Important cf CLI v7 exits when one instance of each process is healthy. It also includes a --no-wait flag on push for users who do not want to wait for the operation to complete. cf push used with the --no-wait flag exits as soon as one instance is healthy.

If the deployment hangs indefinitely, cancel the process and run it again with the step above. To cancel, see Cancel a Deployment below.
For CAPI V3:
1. Log in to the cf CLI.
```
cf login
```
2. Create an empty app by running the following curl command with POST /v3/apps. Record the app GUID from the output.
```
cf curl /v3/apps \
  -X POST \
  -H "Content-type: application/json" \
  -d '{
    "name": "APP-NAME",
    "relationships": {
      "space": {
        "data": {
          "guid": "SPACE-GUID"
        }
      }
    }
  }'
```
  Where:
  - APP-NAME is the name that you want to give your app.
  - SPACE-GUID is the space identifier that you want to associate with your app.
3. Create a package with the following curl command with POST /v3/packages. Record the package GUID from the output.
```
cf curl /v3/packages \
  -X POST \
  -H "Content-type: application/json" \
  -d '{
    "type": "bits",
    "relationships": {
      "app": {
        "data": {
          "guid": "APP-GUID"
        }
      }
    }
  }'
```
  Where APP-GUID is the app GUID that you recorded in the previous step. This app GUID is a unique identifier for your app.
4. Upload the package bits by running the following curl command with POST /v3/packages/PACKAGE-GUID/upload.
```
cf curl /v3/packages/PACKAGE-GUID/upload \
-X POST \
-F bits=@"PACKAGED-APP" \
```
  Where:
  - PACKAGE-GUID is the package GUID that you recorded in the previous step.
  - PACKAGED-APP is your app packaged in a file such as .zip.
5. Create the build by running the following curl command with POST /v3/builds. Record the droplet GUID from the output.
```
cf curl /v3/builds \
  -X POST \
  -H "Content-type: application/json" \
  -d '{
    "package": {
       "guid": PACKAGE-GUID"
    }
  }'
```
  Where PACKAGE-GUID is the package GUID that you recorded in a previous step.
6. Deploy your app by running the following curl command with POST /v3/deployments. To verify the status of the deployment or take action on the deployment, record the deployment GUID from the output.
```
cf curl /v3/deployments \
-X POST \
-H "Content-type: application/json" \
-d '{
  "droplet": {
    "guid": "DROPLET-GUID"
  },
  "strategy": "rolling",
  "options": {
    "max_in_flight": MAX_IN_FLIGHT
  },
  "relationships": {
    "app": {
      "data": {
        "guid": "APP-GUID"
      }
    }
  }
}'
```
  Where DROPLET-GUID and APP-GUID are the GUIDs that you recorded in earlier steps. Where MAX_IN_FLIGHT is an integer that specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1.

For more information about this command, see How It Works below.

Cancel a deployment

To stop the deployment of an app that you pushed:

For cf CLI v7, run:
```
cf cancel-deployment APP-NAME
```
Where APP-NAME is the name of the app.
For CAPI V3, run:
```
cf curl /v3/deployments/DEPLOYMENT-GUID/actions/cancel" -X POST
```
Where DEPLOYMENT-GUID is the GUID of the deployment that you recorded after following the CAPI procedure in Deploy an App above.

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

The cancel command is designed to revert the app to its original state as quickly as possible and does not guarantee zero downtime.

Restart an app

To restart your app without downtime, run the appropriate command below. Restart an app to apply configuration updates that require a restart, such as environment variables or service bindings.

For cf CLI v7, run:
```
cf restart APP-NAME --strategy rolling
```
Where APP-NAME is the name of the app.

For CAPI V3, run:

cf curl /v3/deployments \
-X POST \
-H "Content-type: application/json" \
-d '{
  "droplet": {
    "guid": "DROPLET-GUID"
  },
  "strategy": "rolling",
  "options": {
    "max_in_flight": MAX_IN_FLIGHT
  },
  "relationships": {
    "app": {
      "data": {
        "guid": "APP-GUID"
      }
    }
  }
}'

Where DROPLET-GUID and APP-GUID are the GUIDs that you recorded in earlier steps. Where MAX_IN_FLIGHT is an integer that specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1.

How it works

This section describes the rolling deployments and their limitations.

Rolling deployment process

This section describes the process of pushing an app with a rolling deployment strategy.

The cf push APP-NAME --strategy rolling 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 up to max_in_flight processes that shares the route with the old process.
  - Now, if you run cf app on your app, you see multiple web processes.
    For more information about the deployment object, see the Deployments section of the CAPI V3 documentation.
After the command creates the deployment, the cc_deployment_updater BOSH job runs in the background, updating deployments as follows:
1. Adds up to max_in_flight instances of the new web process and removes instances from the old web process. This step repeats until the new web process reaches the required number of instances.
  Important This happens only if all instances of the new web process are running.
2. Removes the old web process. The new web process now fully replaces the old web process.
3. Restarts all non-web processes of the app.
4. Sets the deployment to DEPLOYED.

Limitations

The following table describes the limitations of when using rolling deployments.

Limitation	Description
Multiple app versions	During a deployment, TAS for VMs 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. Migrating an app database when the existing app is not compatible with the migration can result in downtime.
Non-web processes	Rolling deployments only run web processes through the rolling 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 Processes in the CAPI V3 documentation.
Quotas	Pushing updates to your app using a deployment strategy creates up to `max_in_flight` new instances (defaults to 1). If you lack sufficient quota, the deployment fails. Administrators might need to increase quotas to accommodate deployments.
Simultaneous apps when interrupting a push	If you push app before your previous push command for the same app has completed, your first push gets interrupted. Until the last deployment completes, there might be many versions of the app running at the same time. Eventually, the app runs the code from your most recent push.
V3 APIs	During a rolling deploy for an app, requests to the V3 APIs for scaling or updating a process fail with an error message like `Cannot scale this process while a deployment is in flight.`. For more information, see Scale a process or Update a process in the CAPI V3 documentation.
New or stopped applications	When pushing an application for the first time, or if the app is stopped, no deployment strategy is used and all application instances are started immediately.

View the status of rolling deployments

You can use CAPI to view the status of rolling deployments.

To view the status of a rolling deployment:

Log in to the cf CLI:
```
cf login
```
Find the GUID of your app by running:
```
cf app APP-NAME --guid
```
Where APP-NAME is the name of the app.
Find the deployment for that app by running:
```
cf curl GET /v3/deployments?app_guids=APP-GUID&status_values=ACTIVE
```
Where APP-GUID is the GUID of the app. Deployments are listed in chronological order, with the latest deployment displayed as the last in a list.
Run:
```
cf curl GET /v3/deployments/DEPLOYMENT-GUID
```
Where DEPLOYMENT-GUID is the GUID of the rolling deployment.

cf curl GET /v3/deployments/DEPLOYMENT-GUID returns the following properties about the status of rolling deployments:

status.value: Indicates if the deployment is ACTIVE or FINALIZED.
status.reason: Provides detail about the deployment status.
status.details: Provides the timestamp for the most recent successful health check. The value of the status.details property can be nil if there is no successful health check for the deployment. For example, there might be no successful health check if the deployment was cancelled.

The following table describes the possible values for the status.value and status.reason properties:

`status.value`	`status.reason`	Description
`ACTIVE`	`DEPLOYING`	The deployment is deploying.
`ACTIVE`	`CANCELLING`	The deployment is cancelling.
`FINALIZED`	`DEPLOYED`	The deployment was deployed.
`FINALIZED`	`CANCELLED`	The deployment was cancelled.
`FINALIZED`	`SUPERSEDED`	The deployment was stopped and did not finish deploying because there was another deployment created for the app.
`FINALIZED`	`DEGENERATE`	The deployment was created incorrectly by the system.