You can use Jenkins to build CI/CD pipelines and implement an end-to-end canary release by using the CI/CD pipelines. After you use pipeline scripts to integrate the build, deployment, and test stages into one process, you can determine the subsequent steps that you need to perform based on the canary release result. If a new version is proven to be stable, you can adjust the routing rule to gradually increase the percentage of canary traffic that is routed to the new version until all traffic is routed to the new version. If an issue is found in the new version, you need to immediately roll back to the old version and troubleshoot the issue. The entire process implements automated management from the build stage to the canary release stage. This ensures the security and stability of service updates. This topic describes how to implement an end-to-end canary release by using CI/CD pipelines in Jenkins.
Overall architecture
In most cases, you can perform a canary release based on one of the following items:
A specific small percentage of traffic.
Specific rules, such as specific headers or cookies.
Tags that are used to mark canary traffic and displayed on the client or web browser. For example, you can use the tags that are carried in headers.
The following figure shows the canary release process of the demo described in this topic.
Preparations
Enable Microservices Governance for microservice applications in an ACK cluster
Activate Microservices Governance. For more information, see Activate Microservices Governance.
Enable Microservices Governance for microservice applications in a Container Service for Kubernetes (ACK) cluster. For more information, see Enable Microservices Governance for microservice applications in an ACK cluster.
Deploy demo applications
Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
In the left-side navigation pane of the details page, choose .
On the Deployments page, click Create from YAML.
Configure the parameters and click Create.
In this example, the following applications are deployed: spring-cloud-a (Application A), spring-cloud-b (Application B), spring-cloud-c (Application C), nacos-server, and spring-cloud-zuul. The nacos-server application is deployed as a registry and the spring-cloud-zuul application is deployed as an ingress application. The applications are called in the following order: spring-cloud-zuul -> spring-cloud-a -> spring-cloud-b -> spring-cloud-c.
The spring-cloud-zuul application handles the default 100 QPS and additional 10 QPS for requests that are attached with the
x-mse-tag: gray
header. This header is a built-in canary header in MSE. If requests are attached with thex-mse-tag: gray
header after Microservices Governance is activated and the agent is installed, the requests attached with this header are automatically routed to downstream nodes that are tagged with gray. You can replace gray with the tag values of other nodes based on your business requirements.Yet Another Markup Language (YAML) code for the spring-cloud-zuul ingress application
YAML code for the base version of spring-cloud-a
YAML code for the base version of spring-cloud-b
YAML code for the base version of spring-cloud-c
YAML code for nacos-server
After the applications are deployed, view the traffic that passes through Application A in the MSE console, and verify that all traffic is routed to untagged nodes and no traffic is routed to canary nodes.
Configure the permissions to push images to an image repository
In this example, the source code needs to be packaged into images and then pushed to an image repository. You must make sure that Jenkins has the permissions to push images to the image repository. For more information, see Deploy Jenkins in an ACK cluster and then create and deploy an application.
Create a lane
Log on to the MSE console, and select a region in the top navigation bar.
In the left-side navigation pane, choose Microservices Governance > Full link grayscale.
On the Full link grayscale page, click Create Lane Group and Lane. If a lane group is available in the microservices namespace that you select, click + Create Lane Group.
In the Create Lane Group panel, select the ingress application and the applications involved in the call process, and click OK.
Parameter
Description
Lane Group Name
Enter a name for the lane group.
Ingress Type
Select Java Microservice Gateway.
Lane Group Traffic Entry
Select your ingress application from the drop-down list.
Lane Group Application
Select all applications related to your ingress application or ingress gateway.
After the lane group is created, the lane group is displayed in the section of applications involved in the lane group on the Full link grayscale page. Check whether the ingress application and the involved applications are properly selected. To modify the information about the lane group, click and edit the information.
On the Full link grayscale page, select the same microservice namespace as the lane group that you created. In the lower part of the page, click Click to Create First Split Lane.
If a lane is available in the microservice namespace that you select, click Create Lane.
ImportantAfter you configure an end-to-end canary release for applications, these applications no longer support features such as canary release and tag-based routing.
In the Create Lane panel, configure the parameters and add the applications that match the rule to the gray lane. Then, click OK.
Parameter
Description
Add Node Tag
Manually add a tag for your canary application nodes. The tag is used to distinguish the nodes from other nodes.
Enter lane information
Lane Tag: the tag of the matched traffic in the lane.
Confirm Matching Relationship: allows you to check whether the number of tagged application nodes is as expected.
Configure Routing and Canary Release Rules
Path: the path to be matched. You can select multiple paths. If you do not specify this parameter, a random path is matched.
Condition Mode: the relationship between routing conditions.
Conditions
Parameter Type: the source of a parameter. Valid values: Parameter (request parameter), Header (request header), Cookie, and Body Content (JSON-formatted request body).
Parameter: the name of the parameter.
Condition: the match rule.
Value: the value that is used to match the parameter.
Traffic that does not meet the conditions is routed to an untagged application node in the base version.
After the configuration is complete, the gateway routes traffic based on specific rules.
Traffic that does not meet the rule for canary release is routed to the base version.
Traffic that meets the rule for canary release is routed to the canary version.
Configure a Jenkins pipeline
In this example, the source code needs to be packaged into images and then pushed to an image repository. You must make sure that Jenkins has the permissions to push images to the image repository. For more information, see Set up Jenkins to build an application delivery pipeline.
Create a Secret named jenkins-docker-cfg in the Jenkins namespace by using the generated config.json
file.
kubectl create secret generic jenkins-docker-cfg -n jenkins --from-file=/root/.docker/config.json
Create an end-to-end canary release pipeline in Jenkins
You can use Jenkins pipelines for automated releases. A pipeline can provide canary release, observability, and rollback capabilities for application releases to ensure production safety.
In the left-side navigation pane of the Jenkins dashboard, click New Item.
Enter the item name, select a pipeline, and then click OK.
On the page that appears, click the Pipeline tab. On the Pipeline tab, configure the parameters, enter a path in the Script Path field, and then click Save.
Definition: Select Pipeline script from SCM from the drop-down list.
SCM: Select Git from the drop-down list.
Repository URL: Enter a URL of the Git repository. In this example, the repository URL is https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/mse-simple-demo.
NoteAlibaba Cloud cannot pull the source code from GitHub. In this case, the source code from Gitee is used instead.
Script Path: Enter Jenkinsfile.
The following parameter configurations are provided for your reference. You can also edit a Jenkinsfile and add the file to the specified path of the Git repository. This path is the specified script path of the pipeline.
Build a Jenkins pipeline
On the Jenkins dashboard, click on the right of the pipeline.
Click Build.
NoteIf you build a Jenkins pipeline for the first time, you must pull the configuration from the Git repository and initialize the pipeline. If an error is reported during this process, you can click Build with Parameters to generate relevant parameters, specify the parameters, and then build the Jenkins pipeline again.
View the deployment status. The code packaging, image building and releasing, and canary deployment stages are complete, and the stage for completing the canary deployment is pending confirmation.
If the result passes verification, perform a full release. For more information, see Perform a full release of the application.
If the result does not pass verification, perform a rollback. For more information, see Roll back an application.
Verify the result
Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. In the left-side pane, choose .
On the Deployments page, confirm that the created spring-cloud-a-gray application is displayed and its image version is replaced with the
spring-cloud-a:gray
version.On the details page of the cluster, choose
, select the required namespace, and then click the public endpoint of the zuul-slb service to view the actual call result.If you use a non-canary header, traffic is routed to the nodes for the base version of spring-cloud-a.
curl command:
curl http://182.92.XX.XX/A/a
Output:
A[10.4.XX.XX] -> B[10.4.XX.XX] -> C[10.4.XX.XX]%
If you use a header with the canary release tag, traffic is routed to the canary node of spring-cloud-a.
curl command:
curl http://182.92.XX.XX/A/a?name=xiaoming
Output:
Agray[10.4.XX.XX] -> B[10.4.XX.XX] -> C[10.4.XX.XX]%
Log on to the MSE console. On the application details page, confirm that canary traffic is routed to the canary node.
Perform a full release of the application
After the result passes verification, confirm to perform a full release of the application.
On the Jenkins dashboard, click the name of the desired pipeline.
Click the stage for which you want to enable full release, enter true in the Are you sure that you want to enable a full release dialog box, and then click OK.
In the ACK console, confirm that the spring-cloud-a-gray application is deleted and its image version is replaced with the
spring-cloud-a:gray
version.In the MSE console, confirm that canary traffic disappears.
Roll back the application
Roll back the application if the result does not pass verification.
On the Jenkins dashboard, click the name of the desired pipeline.
Click the stage for which you want to disable full release, enter false in the Are you sure that you want to enable a full release dialog box, and then click OK.
In the ACK console, confirm that the spring-cloud-a-gray application is deleted and its image version is still the original version.
In the MSE console, confirm that canary traffic does not exist.