You can release an application that is deployed on a large number of instances or has a complex service architecture in multiple phases. The application is updated only on a few instances in each phase. The phased release is complete when the application is updated on all the instances. This topic describes how to implement a phased release of an application in the Enterprise Distributed Application Service (EDAS) console.
Overview
During a phased release, an application is updated only on 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 in phases 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 allocated to each phase. If the instances cannot be evenly allocated, the number of instances allocated to an earlier phase is smaller than the number of instances allocated to a later phase.
Scenario
For example, an application is deployed on 10 instances, and the application version needs to be updated from V1 to V2 on all the instances.
The following figure shows how the application is released to the instances based on a specific policy in three phases.
Usage notes
If you release an application in a Kubernetes cluster in multiple phases, a Deployment is created for the application release.
Procedure
Log on to the EDAS console.
In the left-side navigation pane, choose . In the top navigation bar, select a region. In the upper part of the Applications page, select a microservices namespace from the Microservices Namespace drop-down list. Then, click the name of the application that you want to manage.
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
Specify a runtime environment for the application. Default value: Standard Java Application Runtime Environment.
Java Environment
Specify a Java environment for the application. Valid values: Open JDK 8 [Latest Version:1.8.0_191], Open JDK 7, Open JDK 17, Open JDK 11, JDK 8, JDK 7, Dragonwell 8, Dragonwell 17, and Dragonwell 11.
Current Environment
The current runtime environment of the application is displayed. The current runtime environment is displayed only if the application is deployed by using a JAR package or WAR package. EDAS automatically updates the Java environment or runtime environment of your application to the latest version.
File Uploading Method
Specify a file upload method. Valid values: Upload JAR Package and JAR Package Address.
NoteThe file upload method that you specify must be the same as the file upload method that you use to deploy the application. JAR packages, WAR packages, and images are supported. In this example, a JAR package is used.
Upload JAR Package
If you set the File Uploading Method parameter to Upload JAR Package, click Click to Upload to upload a JAR package.
JAR Package Address
If you set the File Uploading Method parameter to JAR Package Address, enter the URL of a JAR package.
NoteIf you enter the URL of an Object Storage Service (OSS) object that has a signature, EDAS caches the object for subsequent operations, such as rollbacks and scale-outs, when you release the application in phases.
Container Registry Repository Type
NoteThe Container Registry Repository Type parameter is available only if you deploy Java, Tomcat, or EDAS-Container (HSF) applications in ACK clusters. This parameter is unavailable if you deploy applications in ACK Serverless (ASK) clusters.
You must install the aliyun-acr-credential-helper component. For more information, see Use the aliyun-acr-credential-helper component to pull images without secrets.
If you want to use an image repository of Container Registry Enterprise Edition, configure access over VPCs. For more information, see Configure access over VPCs.
The image build task for the application runs in your cluster and consumes your resources. The default resource limit for a single image build task is 1 GB per core. For more information about how to adjust resource limits for image build tasks, see How do I adjust resource limits for image building?
If you use a repository of Container Registry Personal Edition or Container Registry Enterprise Edition to store the created image, the image build task runs in your cluster. Build tasks are subject to the following scheduling affinity and toleration rules:
EDAS rejects to schedule build tasks to nodes that have the
edas.image.build=disable
label.EDAS preferably schedules build tasks to nodes that have the
edas.image.build=enable
label. However, EDAS may also schedule build tasks to nodes that do not have theedas.image.build
label.Build tasks can tolerate nodes that have the
key=edas.image.build, effect=NoSchedule
taint.
NoteIf you do not want to schedule build tasks to specific nodes, add the
edas.image.build=disable
label to the nodes.If you want to use a node as a dedicated node of a build task, you can add the
edas.image.build=enable
label and thekey=edas.image.build, effect=NoSchedule
taint to the node. This prevents pods that do not tolerate the taint from being scheduled to the node.
Region of Container Registry
Select the region in which your Container Registry image resides. This parameter is required only if you set the Container Registry Repository Type parameter to Container Registry Enterprise Edition.
Container Registry
Select your container image. This parameter is required only if you set the Container Registry Repository Type parameter to Container Registry Enterprise Edition.
Image Repository Namespace
Select the microservice namespace in which your image repository resides from the drop-down list. You can also click + Create Namespace to create a microservice namespace.
Version
The version number of the JAR deployment package. Specify a version number or click Use Timestamp as Version Number to generate a version number.
Time Zone
The time zone for the application. Specify the time zone of the specified region in UTC.
Single-pod Resource Quota
The CPU, memory, and temporary storage that you want to reserve for a pod. If you want to specify a limit, enter a numeric value. Default value: 0. A value of 0 specifies that no limit is imposed. The maximum or minimum quotas of CPU, memory, and temporary storage are subject to the cluster performance.
Configure 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
NoteThe Batch Mode parameter is displayed only if you set the Release Batch parameter to a value greater than 1.
Valid values: Automatic and Manual.
Automatic: The system automatically releases the application in phases at an interval that is specified by the Interval parameter. The Interval parameter specifies the interval at which the phases are released. Unit: minutes.
Manual: You must manually trigger the release of the next phase.
Deployment Interval Between Batches
Specify an interval at which the application is deployed to the instances in each phase if the number of instances is greater than 1. Unit: seconds.
(Optional) Configure advanced settings based on your business requirements, such as the parameters in the Scheduling Rules, Startup Commands, Environment Variables, Persistent Storage, Local Storage, Application Life Cycle Management, and Log Collection Settings sections. For more information, see Advanced settings.
After you configure the parameters, click OK.
Check the result
On the change list page of the application, view the status of the phased release and the value of the Version parameter on the right of the Description parameter. If all phases are in the Success state and the value of the Version parameter is changed to V2, the phased release is successful.
Roll back an application
During a phased release, if the application is not updated to the new version on one or more instances, the phased release is in the Executing state. When you update an application, if an application instance in the first phase stops responding, you can go to the change list page and click Roll Back to roll back the application on the instance to the deployment package and configurations of the previous version.
Errors may occur during a phased release. For more information about how to troubleshoot errors, see How do I troubleshoot issues in a change process?
Errors such as deployment package unavailability and health check failures may lead to failures of application updates. The current application update is automatically terminated, and the application is rolled back.
During an update, the maximum timeout period for a single phase is 30 minutes. If the update process is suspended due to a timeout error, you must go to the change list page to terminate the process and roll back the application.