If you want to upgrade an application that contains multiple instances, you can upgrade the application instances to different versions by using the canary release or phased release method based on your business requirements. This topic describes the canary release method. This topic also describes how to perform a canary release for an application and how to roll back an application.
Prerequisites
The number of instances in the application for which you want to perform a canary release is greater than 1.Background information
Canary release is a deployment method that is used to test the performance of a new version when the original deployment version remains available. A canary release can help you ensure system stability. During a canary release, you can identify and fix errors at the earliest opportunity.
To ensure the stability of an application, the number of application instances in a canary release cannot exceed 50% of the total number of application instances. The remaining application instances are released in specific batches. After the first batch of application instances are released, you can specify whether to release the next batch. Before you manually release the next batch, you can collect business data of the new version to decide whether to release the next batch.
- Canary release by traffic ratio: For example, you can forward 20% traffic to the new version and 80% traffic to the current version.
- Canary release by request content: For example, you can forward traffic that is generated by the requests sent by specific user IDs to the new version, and other traffic to the current version.
The canary release method provides more fine-grained traffic control than the phased release method. For more information about the phased release method, see Perform a phased release for an application.
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.
Log on to the SAE console.
In the left-side navigation pane, click Applications. In the top navigation bar, select a region. Then, click the name of an application.
In the upper-right corner of the Basic Information page, 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 a canary release. The following table describes the parameters.
Parameter Description Release Policy Select Canary Release. Instances for Canary Release The number of instances for which you want to perform the canary release. Remaining Batches After Canary Release The number of batches in which you want to release the remaining instances after the canary release. Batch Mode This parameter is required If you set the Remaining Batches After Canary Release parameter to a value that is greater than 1. Select Automatic or Manual. Interval Between Batches This parameter is required if you set the Batch Mode parameter to Automatic. Unit: minutes. Valid values: 0 to 30. Interval Within Batch The time interval at which the application instances in a batch are deployed if the number of application instances in each batch is greater than 1. Unit: seconds. Minimum Available Instances The minimum number of available instances per rolling upgrade.
By Number: Enter the minimum number of available instances. If you select Use System Recommended Value, the minimum number of available instances is set to 25% of the number of existing instances.
By Ratio: Enter a percentage.
NoteMake sure that at least one instance is available during application deployment and rollback. This ensures business continuity. If you set the value to 0, business interruptions occur when the application is upgraded.
If you specify a percentage, the minimum number of available instances is rounded up to the nearest integer. For example, five instances are available and you specify 25%. In this case, the minimum number of available instances is 2.
Enable Canary Release Rule of Microservices The canary release rule that you created for Spring Cloud or Dubbo applications. - Optional:Configure the advanced settings based on your business requirements.
- After you configure the settings, click Confirm.
- Use one of the following methods to check whether the configurations have taken effect.
- Method 1: On the Change Records page, view the change details and release status of the application. If all batches are executed, the application is upgraded.
- Method 2: On the Basic Information page, click the Instance Deployment Information tab to view the status of the instances. If Running is displayed in the Status column and the versions of the instances are changed to V2, the application is deployed.
Roll back an application
If one or more instances have not been upgraded when you use the canary release or phased release method to upgrade the instances of an application, the upgrade status of the application is Executing.
If no response is returned for the first release batch of application instances due to an exception, click Roll Back Now on the Change Details page to roll back the upgraded instances to the previous version and restore the application configurations to the original configurations before the upgrade.
If an application fails to be upgraded because an exception occurs (for example, a deployment package is unavailable or a health check fails) during an application change process, SAE stops the application and rolls back the application.
The application upgrade process in SAE requires approximately 30 minutes to complete. If an upgrade times out, SAE reports a timeout exception and stops the change process. In this case, you must manually terminate the release process and roll back the application on the Change Details page.
References
The following table describes the operations that you can perform on an application after you deploy the application on SAE.
Operation | References |
Lifecycle management operations, such as updating, starting, stopping, and deleting an application, and scaling in or scaling out the instances for an application | |
Performance optimization operations, such as configuring auto scaling policies for an application, binding Server Load Balancer (SLB) instances to an application, and starting or stopping applications in batches | |
Application status-based operations, such as managing logs, configuring monitoring settings, viewing application events, and viewing change records |