You can release an application that has a large number of instances or an application that has a complex service architecture in multiple phases. The application is upgraded on only a few instances in each phase. The phased release is complete when the application is upgraded on all the instances. This topic describes how to implement a phased release of an application in the Enterprise Distributed Application Service (EDAS) console.
During a phased release, an application is upgraded on only a few instances in each phase. If an error occurs during a phased release, you can terminate the process and roll back the application. You can release the application again after the error is fixed.
When an application in a Kubernetes cluster is released in multiple phases, the instances of the application are evenly distributed to each phase. If the instances cannot be evenly distributed, the number of instances allocated to an earlier phase is smaller than the number of instances allocated to a later phase.
For example, an application contains 10 instances. The application version on these instances is V1 and needs to be upgraded to V2.
The following figure shows how the application is released to these instances in three phases.
If you release an application in a Kubernetes cluster in multiple phases, a Deployment is created for the application release.
- Log on to the EDAS console.
- In the left-side navigation pane, click Applications. In the top navigation bar, select a region. In the upper part of the Applications page, select a microservice namespace.
- On the Applications page, select Container Service or Serverless Kubernetes Cluster from the Cluster Type drop-down list. Then, click the name of the application that you want to release.
- In the upper-right corner of the Application Overview page, choose .
- In the Phased Release section of the Select Deployment Mode page, click Start Deployment in the upper-right corner.
- On the Phased Release page, upload the application deployment package of the new version.
Parameter Description Application Runtime Environment The type of the runtime environment of the application. Default value: Standard Java Application Runtime Environment. Java Environment The Java runtime environment of the application. Valid values: Open JDK 8 [Latest Version:1.8.0_191], Open JDK 7, JDK 8, JDK 7, and Dragonwell 8. Current Environment The current runtime environment of the application. The current runtime environment is displayed only if the application is released by using JAR packages or WAR packages. EDAS automatically upgrades the Java environment or application runtime environment of your application to the latest version. File Uploading Method The file upload method. You can select Upload Package and upload a JAR or WAR package. You can also select Package Address and specify an address of a JAR or WAR package.Note The type of the deployment package must be the same as that used for the release of the last application version. JAR packages, WAR packages, and images are supported. A JAR package is used in this example. Upload Package If you set the File Uploading Method parameter to Upload Package, click Select File to select a JAR package. Package Address If you set the File Uploading Method parameter to Package Address, enter the URL of a JAR package.Note If you enter the URL of an Object Storage Service (OSS) object that has a signature, EDAS caches the file for subsequent operations, such as rollbacks and scale-outs, when you release the application. Version The version number of the deployment package. You can click Use Timestamp as Version Number on the right to generate a timestamp as the version number. Time Zone The time zone for the application. Specify the time zone of the specified region in UTC. Service Registration and Discovery The O&M method of your service registry. For more information, see Select an O&M method for your service registry.
- In the Release Policy section, set the parameters for the release policy.
The following table describes the parameters in the Release Policy section.
Parameter Description Release Batch The number of phases in which the application is released to the instances. Batch Mode The following processing methods are supported:
Note The Batch Mode parameter is available only if the value of the Release Batch parameter is greater than 1.
- Automatic: automatically releases the application in batches based on the interval specified by the Interval parameter. Interval: the interval for releasing the remaining batches in minutes
- Manual: manually triggers the release of the next batch.
Deployment Interval Between Batches If the number of instances is greater than 1, the application is deployed to the application instances at the specified interval. Unit: seconds.
- Optional:Configure advanced application settings in the Scheduling Rules, Startup Command, Environment Variables, Persistent Storage, Local Storage, Application Life Cycle Management, and Log Collection Settings sections as needed. For more information, see the steps for configuring advanced application settings in Use an image to deploy an application in an ACK cluster and Use a JAR or WAR package to deploy an application in an ACK cluster.
- Click OK.
Verify the results
Go to the application details page. In the left-side navigation pane, click Change List to view the status of the phased release. If the application is released in all phases, the phased release is complete.
On the application details page, view the instance deployment information. If the instance version becomes V2 and all instances are in the Running state, the release is successful.
Roll back the application
During a phased release, if the application is not upgraded to the new version on one or more instances, the release is not complete. When you upgrade an application, if an application instance in the first phase stops responding, you can go to the Change Details page and click Roll Back to roll back the released instances to the previous service pack and configuration.
- Exceptions such as deployment package unavailability and health check failures may lead to failures of application upgrades. The current application upgrade is automatically terminated and the application is rolled back.
- During an upgrade, the maximum timeout period for a single phase is 30 minutes. If the upgrade process is suspended due to a timeout error, you must go to the Change Details page to terminate the release and roll back the application.