To upgrade an application with multiple instances, you can use a canary or phased release. This topic describes what a phased release is and explains how to configure a phased release and rollback for an application.
Prerequisites
The application has more than one instance.
Background information
A phased release deploys an application in batches. Only a portion of the instances are upgraded in each batch. If a failure occurs during the process, you can immediately terminate the release and roll back the changes. After you fix the issue, you can restart the release.
During a phased release, the application instances are evenly distributed among the deployment batches. This means the release occurs in multiple stages, with each stage including the same number of instances. You can choose manual or automatic approval for each batch. If the instances cannot be evenly distributed, later batches will contain more instances than earlier ones.
Phased releases can only be used for applications with more than one instance. If you use the command line in IntelliJ IDEA to perform a phased release for an application with only one instance, the system reports an error.
Example scenario
An application has 10 instances, all running Version 1. You need to upgrade all instances to Version 2. Assume the application instances are deployed in three batches. The phased release process .
Procedure
After you redeploy an application, the application is restarted. To prevent unpredictable errors such as business interruptions, we recommend that you deploy applications during off-peak hours.
On the SAE Application List page, select the destination region and namespace. Click the ID of the target Application to open its details page.
On the Basic Information page of the application, click Deploy Application.
Configure deployment parameters.
NoteThe deployment method of an application is based on the deployment method that you selected for the application for the first time. Configure the parameters based on the selected method.
Deployment with WAR Packages: Upload another WAR package or enter the path of a newly deployed WAR package, and configure the runtime environment and other settings.
Deployment with JAR Packages: Upload another JAR package or enter the path of a newly deployed JAR package, and configure the runtime environment and other settings.
Deployment with ZIP Packages: Upload another ZIP package or enter the path of a newly deployed ZIP package, and configure the runtime environment and other settings.
Image: In the Configure Image section, click Modify Image. In the Modify Image panel, select another image repository or image version.
In the Release Policy Settings section, configure the phased release.
Parameter
Description
Release Policy
Select Phased Release.
Release Batches
Set the number of batches for the application instance release.
Interval Within Batch
The deployment interval between application instances within a batch if the batch contains more than one instance. Unit: seconds.
Peak Volume
This corresponds to the MaxSurge parameter in Kubernetes (K8s). It specifies the number of instances that can be created beyond the expected number of instances.
ImportantThis feature is currently in invitational preview. To use this feature, contact the technical staff in the DingTalk group (ID: 32874633) to enable it.
NoteIf Minimum Available Instances is set to 100% (which means MaxUnavailable is 0), Peak Volume cannot be 0.
When calculated as a percentage, the value is rounded up. For example, if you set the value to 25% and there are 5 instances, the Peak Volume is 2.
Minimum Available Instances
The minimum number of available instances during each rolling upgrade.
NoteSet Minimum Available Instances to 1 or greater to ensure service continuity. If you set this parameter to 0, your application's service is interrupted during the upgrade.
When calculated as a percentage, the value is rounded up. For example, if you set the value to 25% and there are 5 instances, the Minimum Available Instances is 2.
After you complete the configuration, click OK.
Verify the configuration in one of the following ways:
Method 1: On the Change History page of the application, view the change details and release status. If all batches are executed successfully, the application is updated.
Method 2: On the Basic Information page of the application, click the Instance List tab to view the running status of the instances. If the Status is Running, the application is deployed successfully.
Roll back an application
When you upgrade application instances using a canary or phased release, the application upgrade status is Executing as long as the upgrade is not complete for all instances.
While tracking the application upgrade, if the first batch of instances stops responding because of an unexpected exception, you can click Roll Back Now on the Change Details page to ensure business continuity. This action reverts the upgraded instances to their previous version and restores the original configuration.
During the application change process, if the upgrade fails because of exceptions, such as an unavailable deployment package or a failed health check, SAE automatically stops the current application and rolls it back.
An application upgrade in SAE has a timeout period of 30 minutes. If the upgrade exceeds this time, SAE reports a timeout exception and pauses the change process. You must then manually terminate the release and roll back the application on the Change Details page.
More information
After you deploy an application in SAE, you can perform the following operations on the application.
Operation | References |
Application lifecycle management operations such as updating, scaling, starting, stopping, and deleting applications | |
Operations to improve application performance, such as automatic scaling, CLB binding, and batch start and stop | |
Application status-based operations, such as managing logs, configuring monitoring settings, viewing application events, and viewing change records |