Updated on 2024-05-28 GMT+08:00

Dark Launch (Canary)

After a component is created and deployed, you can upgrade a Running or Not ready component in dark launch (canary) mode.

In dark launch (canary) mode, a certain proportion of instances are upgraded, and traffic is directed to the new version to verify whether functions of the new version are normal. Then, the remaining instances will be upgraded in rolling mode. Dark launch ensures stability of the entire system. During initial dark launch, problems can be detected and fixed.

For details about dark launch (canary) types and details, see Table 1.

Table 1 Dark launch (canary) types and description

Type

Description

Microservice Dark Launch

Applies to ServiceComb and Spring Cloud applications. Dark launch tasks function on microservices. Multiple microservices can work together to roll out new features.

  1. The Java, Tomcat, or Docker technology stack must be selected for the component.
  2. The component must be bound to a microservice engine with security authentication disabled and multi-language access to service mesh disabled.
  3. ServiceComb 2.7.8 or later is required. Spring Cloud Huawei 1.10.4-2021.0.x or later is required.

ELB Dark Launch

Applies to ELB traffic-based components. Dark launch tasks function on ELB.

When creating and deploying a component, enable public network access for the component. For details, see Creating and Deploying a Component.

Upgrade in dark launch (canary) mode is supported only when the deployment environment is Kubernetes and there are two or more component instances.

For details about how to upgrade multiple component versions of the same application in batches, see Upgrading Components in Batches.

Prerequisites

You have created and deployed a component. For details, see Creating and Deploying a Component.

Procedure

  1. Log in to ServiceStage.
  2. Use either of the following methods to go to the component Overview page.

    • On the Application Management page, click the application to which the component belongs, and click the target component in Component List. Alternatively, right-click the component and go to the component Overview page from the shortcut menu.
    • On the Component Management page, click the target component. Alternatively, right-click the component and go to the component Overview page from the shortcut menu.

  3. Click Upgrade in the upper right corner of the page.
  4. Select Dark Launch (Canary) for Upgrade Type.
  5. Click Next and set the component version configuration information by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

    During the dark launch upgrade of a component microservice in this operation, do not use CSE to perform dark launch of the component microservice at the same time. Otherwise, this operation fails.

    For details about how to perform dark launch of a component microservice through CSE, see Dark Launch.

    Parameter

    Description

    Stack

    The value is fixed to the technology stack selected during component creation and deployment.

    *Software Package/Image

    The value is fixed to the component source selected during component creation and deployment.

    If you select Source code repository, create authorization by referring to Authorizing a Repository and set the code source.

    If you select a software package or image package, the option is fixed to the software package type (JAR, WAR, or ZIP) or image package type selected during component creation and deployment. It is determined by the selected technology stack type. For details, see Table 1.

    *Upload Method

    If the component source is software package or image package, select an uploaded software package or image package. For details about the upload method, see Component Source.

    *Command

    This parameter is mandatory when the component source is Source code repository, the component is deployed in the Kubernetes environment, and the selected technology stack type is Java, Tomcat, Node.js, Python, or PHP.

    • Default command or script: preferentially executes build.sh in the root directory. If build.sh does not exist, the code will be compiled using the common method of the selected language. Example: mvn clean package for Java.
    • Custom command: Commands are customized using the selected language. Alternatively, the default command or script is used after build.sh is modified.
      NOTICE:
      • If Custom command is selected, exercise caution when inputting sensitive information in the echo, cat, or debug command, or encrypt sensitive information to avoid information leakage.
      • To run the compilation command in the project subdirectory, you need to go to the project subdirectory and then run other script commands. For example:

        cd ./weather/

        mvn clean package

    *Dockerfile Address

    This parameter is mandatory when the component source is Source code repository, the component is deployed in the Kubernetes environment, and the selected technology stack type is Java, Tomcat, Node.js, Python, or PHP.

    Dockerfile Address is the directory where the Dockerfile is located relative to the root directory (./) of the project. The Dockerfile is used to build an image.

    If Dockerfile Address is not specified, the system searches for the Dockerfile in the root directory of the project by default. If the Dockerfile does not exist in the root directory, the system automatically generates the Dockerfile based on the selected operating environment.

    *Component Version

    Component version number, which can be automatically generated or customized.

    • Automatically-generated: Click Generate. By default, the version number is the time when you click Generate. The format is yyyy.mmdd.hhmms, where s is the ones place of the second in the timestamp. For example, if the timestamp is 2022.0803.104321, the version number is 2022.0803.10431.
    • Customized: Enter a value in the format of A.B.C or A.B.C.D. A, B, C, and D are natural numbers. For example, 1.0.0 or 1.0.0.0.
      NOTICE:

      The customized version number must be unique and cannot be the same as any historical version number of the component.

    Resources

    Components cannot be scheduled to nodes whose residual resources are fewer than the requested amount. For details about how to configure the request and limit parameters, see Managing Resources for Containers.

    You can customize CPU and Memory to set their quota, and change the maximum/minimum number of CPU cores and memory size (GiB) that can be used by components. To make modifications, select the item to be changed and enter a new value.

    Unselected parameters indicate no restriction.

    JVM Parameters

    This parameter is available when the technology stack type is Java or Tomcat. It configures the memory parameter size during Java code running.

    Enter the JVM parameter, for example, -Xms256m -Xmx1024m. Multiple parameters are separated by spaces. If the parameter is left blank, the value is empty.

    Tomcat

    This parameter is available when the technology stack type is Tomcat. It configures parameters such as the request path and port number of Tomcat.

    1. Select Tomcat. The Tomcat dialog box is displayed.
    2. Click Use Sample Code and edit the template file based on service requirements.
      NOTE:

      In Tomcat configuration, the default server.xml configuration is used. The context path is /, and no application path is specified.

      If you need to customize an application path, customize the Tomcat context path by referring to How Do I Customize a Tomcat Context Path?

    3. Click OK.

    Advanced Settings

    Set Component Configuration, Deployment Configuration, and O&M Monitoring by referring to 13.

    Dark Launch Policy

    • Traffic Ratio: percentage of traffic directed to the new version.
    • Current Traffic Ratio: percentage of traffic directed to the current version.

    *First Batch of Dark Launch Instances

    Number of instances for dark launch in the first batch. The value range is [1, Total number of instances – 1]. Total number of instances refers to the number of running instances of the component.

    For example, if there are 6 component instances and First Batch of Dark Launch Instances is set to 1, 1 instance will be upgraded in the first batch.

    Deployment Batch with Remaining Instances

    Number of batches whose remaining instances will be upgraded.

    For example, if there are 6 component instances, First Batch of Dark Launch Instances is set to 1, and Deployment Batch with Remaining Instances is set to 3, there are 5 instances remaining to be deployed in 3 batches, and these 5 instances will be upgraded in the sequence 2:2:1

  6. Click Upgrade.

    Wait until the component status changes from Upgrading/Rolling back to Running, indicating that the component version configuration is successfully upgraded.

Follow-Up Operations

Operation

Description

View System Monitoring

If the component is upgraded through dark launch (canary), choose System Monitoring to monitor the CPU and memory usage of instances of the dark launch version and the current version after the first batch of dark launch is complete.

Upgrade Remaining Instances in Rolling Mode

To upgrade the remaining component instances to the new version after the first batch of dark launch is successful and the functions of the new version are normal, perform the following operations:

  1. Select the deployment record of the Dark Launch (Canary) type.
  2. Click Upgrade Remaining Instances in Rolling Mode.
  3. In the displayed dialog box, click OK.

    The remaining instances are upgraded to the new version based on the upgrade policy set in 5.

Rolling Back a Component

The component version configuration can be rolled back in the following scenarios:

  • After the first batch of dark launch release is complete when the component version is upgraded through dark launch (canary).
  • After the version configuration of all component instances is upgraded to the new version.

To roll back the component configuration to the source version, refer to Rolling Back a Component.

Redeploying a Component

You can select a historical version configuration from the deployment record list and use the version configuration as a template to redeploy components. For details, see Redeploying a Component.