Call an API operation to implement the canary release of an application in a Kubernetes cluster - Enterprise Distributed Application Service

This topic describes how to use Enterprise Distributed Application Service (EDAS) SDK for Java to call an API operation to implement the canary release of an application by using JAR, WAR, or image files in a Kubernetes cluster.

Prerequisites

Background information

When you call an API operation to implement the canary release of an application, you must manually confirm to proceed with the update in the remaining phases after the pods of the first phase of the canary release are updated. Before you confirm to update the pods of the remaining phases, you can verify the update on a small number of pods. If the verification is successful, you can proceed with the update in the remaining phases. This way, you can update all pods of the application to a new version.

When you call an API operation to implement the canary release of an application, we recommend that you use the method for automatically updating the pods of the remaining phases, except for the pods of the first phase of the canary release. If you want to manually update the pods of the remaining phases, you must call the ContinuePipeline operation to manually confirm to update the pods of the remaining phases.

In this topic, two sample policies for the canary release are provided. You can select and modify a policy based on your business requirements.

Update two pods in the first phase of the canary release and configure the system to automatically update the remaining pods in two phases at an interval of 1 minute.
```
{"type":"GrayBatchUpdate","batchUpdate":{"batch":2,"releaseType":"auto","batchWaitTime":1},"grayUpdate":{"gray":2}}
```
Update two pods in the first phase of the canary release and manually update the remaining pods in two phases.
```
{"type":"GrayBatchUpdate","batchUpdate":{"batch":2,"releaseType":"manual"},"grayUpdate":{"gray":2}}
```

Implement the canary release of an application by using a JAR or WAR file

Run the following sample code to implement the canary release of an application by using a JAR or WAR file:

The following sample code provides an example on how to implement the canary release of an application in an EDAS Kubernetes by using a JAR file. Advanced parameters that are related to scheduling rules, startup commands, and environment variables are not included in the code. For more information about API parameters, see DeployK8sApplication.

Note

If you want to use a WAR file to implement the canary release of an application, add the following parameters to the sample code based on your business requirements:

// The version of Tomcat on which the deployment and update package depends. This parameter is applicable to Spring Cloud and Apache Dubbo applications that are deployed by using WAR files. 
request.setWebContainer("apache-tomcat-7.0.91");  
// The version of EDAS Container on which the deployment and update package depends. This parameter is applicable to High-speed Service Framework (HSF) applications that are deployed by using WAR files.      
request.setEdasContainerVersion("3.5.9");

import com.aliyuncs.DefaultAcsClient;
import com.aliyuncs.exceptions.ClientException;
import com.aliyuncs.exceptions.ServerException;
import com.aliyuncs.profile.DefaultProfile;
import com.aliyuncs.edas.model.v20170801.DeployK8sApplicationRequest;
import com.aliyuncs.edas.model.v20170801.DeployK8sApplicationResponse;

public class DeployK8sApplication {

    public static void main(String[] args)  {
        // The AccessKey pair of an Alibaba Cloud account has permissions on all API operations. Using these credentials to perform operations in EDAS is a high-risk operation. We recommend that you use a Resource Access Management (RAM) user to call API operations or perform routine O&M. To create a RAM user, log on to the RAM console. 
        // In this sample code, the AccessKey ID and AccessKey secret are included in the environment variables. You can save your AccessKey ID and AccessKey secret to your configuration file. 
        // To prevent key leaks, we recommend that you do not include your AccessKey ID and AccessKey secret in the code. 
        String aliyun_user_ak = System.getenv("ACCESS_KEY_ID");
        String aliyun_user_sk = System.getenv("ACCESS_KEY_SECRET");
        // The ID of the region where you want to implement the canary release of the application. 
        String region_id = "cn-hangzhou";

        DefaultProfile defaultProfile = DefaultProfile.getProfile(region_id, aliyun_user_ak, aliyun_user_sk);
        DefaultAcsClient client = new DefaultAcsClient(defaultProfile);

        // Initiate an API request and configure the related parameters. 
        DeployK8sApplicationRequest request = new DeployK8sApplicationRequest();
        // The ID of the application. 
        request.setAppId("6bbc57a2-a017-4bec-b521-49a15bd3****");
        // The URL and the version of the JAR or WAR file. 
        request.setPackageUrl("https:doc***.oss-cn-hangzhou.aliyuncs.com/sc-****-D-0.0.2-SNAPSHOT.jar");
        request.setPackageVersion("2021-04-15 16:41:52");
        The version of the Java development kit (JDK) on which the deployment and update package depends. Valid values: Open JDK 7 and Open JDK 8. 
        request.setJDK("Open JDK 8");
        // The custom policy for phased-release. In this example, the following policy is used: Update two pods in the first phase of the canary release and configure the system to automatically update the remaining pods in two phases at an interval of 1 minute. 
        request.setUpdateStrategy("{\"type\":\"GrayBatchUpdate\",\"batchUpdate\":{\"batch\":2,\"releaseType\":\"auto\",\"batchWaitTime\":1},\"grayUpdate\":{\"gray\":2}}");
        // The traffic throttling policy of the canary release. In this example, the following traffic throttling policy is used: Forward 50% of the traffic to the canary group. 
        request.setTrafficControlStrategy("{\"http\":{\"rules\":[{\"conditionType\":\"percent\",\"percent\":50}]}}");
        // The number of pods. 
        request.setReplicas(4);
        // The CPU quota and the memory quota of the pods. The value 0 indicates that no limits are specified. 
        request.setCpuLimit(0);
        request.setMemoryLimit(0);
        request.setCpuRequest(0);
        request.setMemoryRequest(0);
        // The minimum number of CPU cores that are required. Unit: cores. The value 0 indicates that the minimum number of CPU cores has no limit. 
        request.setMcpuRequest(0);
        // The maximum number of CPU cores that are allowed. Unit: cores. The value 0 indicates that the maximum number of CPU cores has no limit. 
        request.setMcpuLimit(0);
        // The description of the change record. 
        request.setChangeOrderDesc("Canary release (JAR file)");

        try {
            DeployK8sApplicationResponse response = client.getAcsResponse(request);
            System.out.println("ChangeOrderId=" + response.getChangeOrderId() + "\nMessage=" + response.getMessage());
        } catch (ServerException e) {
            e.printStackTrace();
        } catch (ClientException e) {
            e.printStackTrace();
        }
    }
}

Sample response:

ChangeOrderId=5886e6f9-05b1-42f0-a3d4-5d90558e****
Message=success

Call the GetChangeOrderInfo operation to query the IDs of the pipelines (PipelineId) that match the phases of the cannery release.
Sample returned response after you call the GetChangeOrderInfo operation:
```
{
  "Message": "success",
  "RequestId": "19C54DC3-C66C-40D0-AEED-8D5A1F00F3BA",
  "Code": 200,
  "changeOrderInfo": {
    "Status": 8,
    "Desc": "Canary release (JAR file)",
    "PipelineInfoList": {
      "PipelineInfo": [
        {
          "PipelineStatus": 2,
          "PipelineName": "Canary Change",
          ......
          "PipelineId": "ca7221a6-2c39-40b5-b40a-53fd3d99****"
          ......
          "PipelineId": "e228e628-f722-43bc-9c2b-45076c3a****"
          ......
          "PipelineId": "d6dcb857-2ff0-4db9-90fa-a2d9db7b****"
          ......
          // The sample response is incomplete and is only for reference.
```
Note
The sample code uses the following canary release policy: Update two pods in the first phase of the canary release and configure the system to automatically update the remaining pods in two phases at an interval of 1 minute. After the two pods of the first phase of the canary release are updated, you must manually confirm to proceed with the update in the remaining phases. Three pipeline IDs (PipelineId) are returned after you call the GetChangeOrderInfo operation. The second pipeline ID (Pipeline) indicates that you must manually confirm to proceed with the update in the remaining phases.
The canary release policy specifies that the remaining pods are automatically updated in two phases at an interval of 1 minute. Therefore, you do not need to manually confirm to proceed with the update in the remaining phases. Instead, the system automatically updates the remaining pods.
Call the ContinuePipeline operation to manually confirm to update the pods of the remaining phases.
Sample response:
```
{
  "Message": "success",
  "RequestId": "050392EE-959D-4144-AA02-3A1E7CE2F736",
  "Code": 200
}
```

Implement the canary release of an application by using an image

Run the following sample code to implement the canary release of an application by using an image.

The following sample code provides an example on how to implement the canary release of an application in an EDAS Kubernetes cluster by using an image. Advanced parameters that are related to scheduling rules, startup commands, and environment variables are not included in the code. For more information about API parameters, see DeployK8sApplication.

import com.aliyuncs.DefaultAcsClient;
import com.aliyuncs.exceptions.ClientException;
import com.aliyuncs.exceptions.ServerException;
import com.aliyuncs.profile.DefaultProfile;
import com.aliyuncs.edas.model.v20170801.DeployK8sApplicationRequest;
import com.aliyuncs.edas.model.v20170801.DeployK8sApplicationResponse;

public class DeployK8sApplication {

    public static void main(String[] args)  {
        // The AccessKey pair of an Alibaba Cloud account has permissions on all API operations. Using these credentials to perform operations in EDAS is a high-risk operation. We recommend that you use a RAM user to call API operations or perform routine O&M. To create a RAM user, log on to the RAM console. 
        // In this sample code, the AccessKey ID and AccessKey secret are included in the environment variables. You can save your AccessKey ID and AccessKey secret to your configuration file. 
        // To prevent key leaks, we recommend that you do not include your AccessKey ID and AccessKey secret in the code. 
        String aliyun_user_ak = System.getenv("ACCESS_KEY_ID");
        String aliyun_user_sk = System.getenv("ACCESS_KEY_SECRET");
        // The ID of the region where the application resides. 
        String region_id = "cn-hangzhou";

        DefaultProfile defaultProfile = DefaultProfile.getProfile(region_id, aliyun_user_ak, aliyun_user_sk);
        DefaultAcsClient client = new DefaultAcsClient(defaultProfile);

        // Initiate an API request and configure the related parameters. 
        DeployK8sApplicationRequest request = new DeployK8sApplicationRequest();
        // The ID of the application. 
        request.setAppId("6bbc57a2-a017-4bec-b521-49a15bd3****");
        // The address of the image. 
        request.setImage("registry-vpc.cn-hangzhou.aliyuncs.com/image-demo-project/provider:2.0");
        // The custom policy of the canary release. In this example, the following policy is used: Update two pods in the first phase of the canary release and manually update the remaining pods in two phases. 
        request.setUpdateStrategy("{\"type\":\"GrayBatchUpdate\",\"batchUpdate\":{\"batch\":2,\"releaseType\":\"manual\"},\"grayUpdate\":{\"gray\":2}}");
        // The traffic throttling policy of the canary release. In this example, the following traffic throttling policy is used: Forward 50% of the traffic to the canary group. 
        request.setTrafficControlStrategy("{\"http\":{\"rules\":[{\"conditionType\":\"percent\",\"percent\":50}]}}");
        // The number of pods. 
        request.setReplicas(4);
        // The CPU quota and the memory quota of the pods. The value 0 indicates that no limits are specified. 
        request.setCpuLimit(0);
        request.setMemoryLimit(0);
        request.setCpuRequest(0);
        request.setMemoryRequest(0);
        // The minimum number of CPU cores that are required. Unit: cores. The value 0 indicates that the minimum number of CPU cores has no limit. 
        request.setMcpuRequest(0);
        // The maximum number of CPU cores that are allowed. Unit: cores. The value 0 indicates that the maximum number of CPU cores has no limit. 
        request.setMcpuLimit(0);
        // The description of the change record. 
        request.setChangeOrderDesc("Canary release (image)");

        try {
            DeployK8sApplicationResponse response = client.getAcsResponse(request);
            System.out.println("ChangeOrderId=" + response.getChangeOrderId() + "\nMessage=" + response.getMessage());
        } catch (ServerException e) {
            e.printStackTrace();
        } catch (ClientException e) {
            e.printStackTrace();
        }
    }
}

Sample response:

ChangeOrderId=a7431f9e-7e05-4590-aef8-17088f0****
Message=success

You can call the GetChangeOrderInfo operation to query the IDs of the pipelines (PipelineId) that match the phases of the cannery release.
Sample returned response after you call the GetChangeOrderInfo operation:
```
{
  "Message": "success",
  "RequestId": "1B1127FB-251C-4946-AA20-D4FF5DF4788F",
  "Code": 200,
  "changeOrderInfo": {
    "Status": 8,
    "Desc": "Canary release (JAR file)",
    "PipelineInfoList": {
      "PipelineInfo": [
        {
          "PipelineStatus": 2,
          "PipelineName": "Canary Change",
          ......
          "PipelineId": "09e7d9aa-e79d-49ef-99b9-5405532d****"
          ......
          "PipelineId": "1ea53844-2c60-46f1-b46d-df3b34d0****"
          ......
          "PipelineId": "d99da075-b87d-4fe7-bbb6-ae1c6c26****"
          ......
          // The sample response is incomplete and is only for reference.
```
Note
The sample code uses the following canary release policy: Update two pods in the first phase of the canary release and manually update the remaining pods in two phases. After the two pods of the first phase of the canary release are updated, you must manually confirm to proceed with the update in the remaining phases. Three pipeline IDs (PipelineId) are returned after you call the GetChangeOrderInfo operation. The second pipeline ID (PipelineId) indicates that you need to manually confirm to proceed with the update in the remaining phases. The third pipeline ID indicates that you must manually confirm to update the pods of the next phase after the pods of the first phase in the remaining phases are updated.
Call the ContinuePipeline operation to manually confirm to update the pods of the remaining phases.
Sample response:
```
{
  "Message": "success",
  "RequestId": "B8ECF6F7-672D-40E9-91DD-1C33F06D4FD8",
  "Code": 200
}
```
Call the ContinuePipeline operation to manually confirm to update the pods of the next phase.
Sample response:
```
{
  "Message": "success",
  "RequestId": "7BB4F043-7C28-4A0E-B6A5-D4023EB24388",
  "Code": 200
}
```
Note
The sample code uses the following canary release policy: Update two pods in the first phase of the canary release and manually update the remaining pods in two phases. You must manually confirm to update the pods of a single phase when you update the remaining phases except for the first phase of the canary release. If the canary release policy requires you to manually confirm to update the pods of multiple phases in the remaining phases, you must specify the correct pipeline ID (PipelineId) and repeat this step.
Before you repeat this step, take note of the interval between two phases. You can manually confirm the next phase only after an interval elapses. By default, the interval of two phases is 10 seconds.

Check the result

After you implement the canary release of an application, you can call the GetChangeOrderInfo operation to view the change details and change status of the application. For more information about specific API parameters, see GetChangeOrderInfo.

Sample returned response after you call the GetChangeOrderInfo operation:

{
    "Message": "success",
    "RequestId": "10DA427D-AF74-4ECE-BB0A-EECC0EBF7548",
    "Code": 200,
    "changeOrderInfo": {
        "Status": 2,
        "Desc": "Canary release (***)",
        "PipelineInfoList": {
            "PipelineInfo": [
                {
                   ......
                   // The sample response is incomplete and is only for reference.

You can check whether the canary release of the application is successful based on the value of the changeOrderInfo.Status parameter. Valid values of the changeOrderInfo.Status parameter:

0: Ready
1: In progress
2: Successful
3: Failed
6: Terminated
8: Waiting to manually confirm the next phase during a manual phased-release
9: Waiting to automatically confirm the next phase during an automatic phased-release
10: Failed due to a system exception