To upgrade an application with multiple instances, you can use a canary release or a phased release. This topic describes phased releases and explains how to configure a phased release and perform a rollback.
Prerequisites
The application has more than one instance.
Background information
A phased release deploys an application in batches, upgrading only a portion of the instances in each batch. If a failure occurs during the phased release, you can stop the process and immediately roll back. After resolving the issue, you can restart the deployment.
During a phased release, application instances are deployed in batches and distributed evenly across them. You can choose to review each batch manually or automatically. If the instances cannot be distributed evenly, earlier batches contain fewer instances, and later batches contain more.
A phased release can be used only when an application has more than one instance. If you use the command line in IntelliJ IDEA to perform a phased release for an application that has only one instance, the system reports an error.
Scenario example
For example, an application has 10 application instances that need to be upgraded from version V1 to V2. If the upgrade is deployed in three batches, the phased release process is .
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 a region and namespace at the top, and click the ID of the target application to open the application details page.
On the Basic Information page of the target 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, you can configure the phased release.
Configuration Item
Description
Release Policy
Select Phased Release.
Publish Batches
Set the number of batches for the application instance release.
Interval Between Deployments In A 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 in invitational preview. To request access, contact our team in the DingTalk group (ID: 32874633).
NoteIf Minimum Alive Instances is set to 100% (which means MaxUnavailable is 0), Peak Volume cannot be 0.
If you use 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 Surviving Instances
The minimum number of instances that must remain active during each rolling upgrade.
NoteWe recommend that you set Minimum Alive Instances to 1 or greater to ensure business continuity. If you set this parameter to 0, your application is interrupted during the upgrade.
If you use a percentage, the value is rounded up. For example, if you set the value to 25% and there are 5 instances, the Minimum Alive Instances is 2.
After completing the configuration, click OK.
Verify that the configuration is effective in one of the following ways:
Method 1: On the Change History page of the application, you can view the change details and release status. The application is updated if all batches are successfully executed.
Method 2: On the Instance List tab of the application's Basic Information page, you can check the running status of the instances. The deployment is successful if the Execution Status is Running.
Application rollback
When you upgrade application instances using a grayscale or phased release, the upgrade status remains In Progress until all instances are upgraded.
While monitoring the application upgrade, if an error causes the first batch of instances to stop responding, click Roll Back Immediately on the Change Details page to ensure business continuity. This reverts the upgraded instances to the previous version and restores the previous configuration.
If an error, such as an unavailable deployment package or a failed health check, occurs during the deployment process, the application upgrade fails. SAE stops the current deployment and performs a rollback.
An application upgrade in SAE times out after about 30 minutes. If a timeout occurs, SAE pauses the change process. You can then go to the Change Details page to manually terminate the release process and roll back the application.
Stop a release
To terminate an in-progress change, click Terminate Release on the Change Details page.
Stopping a release may cause multiple versions of the application to run at the same time:
Instances that are already deployed: These instances continue to run in their current state and are not rolled back.
Instances being deployed: The deployment of these instances continues. After the deployment is complete, they run the new version from this release.
Instances that are not yet deployed (including all instances in unexecuted batches): These instances continue to run in their current state. The release process does not continue for them.
New instances from Auto Scaling: New instances that are created by Auto Scaling use the new version from this release.
After you stop a release, redeploy the application or roll back to a previous version as soon as possible. This ensures that all application instances run the same version.
More information
After you deploy an application in SAE, you can perform the following operations on the application.
Operation | References |
Lifecycle management operations, such as updating, scaling, starting, stopping, and deleting an application | |
Operations to improve application performance, such as auto scaling, CLB instance binding, and batch start and stop | |
Operations related to the application running status, such as log management, monitoring management, viewing application events, and viewing change records |