Advanced
Тема интерфейса

Dark Launch

You can select a historical version configuration from the deployment record list and use the version configuration as a template to redeploy components in dark launch mode.

In dark launch 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 types and description, see Table 1.

Table 1 Dark launch 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.

The component must be accessible from the public network and bound to an ELB.

Note

Only components deployed in the Kubernetes environment support dark launch.

The component version configuration that has been rolled back by referring to Rolling Back a Component cannot be used as a template to redeploy the component.

Prerequisites

You have upgraded a component. For details, see Upgrading a Single Component or Upgrading Components in Batches.

Procedure

  1. Log in to ServiceStage.
  2. Use either of the following methods to go to the Deployment Records page.

    • On the Application Management page, click the application to which the component belongs, and click the target component in Component List. In the left navigation pane, choose Deployment Records.
    • On the Component Management page, click the target component. In the left navigation pane, choose Deployment Records.

  3. In the Deployment Records list, select the deployment record of the historical version to be used as the configuration template.
  4. Click Redeploy in the upper right corner of the page. The Redeploy dialog box is displayed.
  5. Select Dark Launch for Deployment Type and click OK.
  6. Configure the component version by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

    Notice

    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 will fail.

    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 configuration of the selected historical version and cannot be changed.

    *Software Package/Image

    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 if 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 if 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.

    Resources

    The value is fixed to the configuration of the selected historical version and cannot be changed.

    JVM Parameters

    The value is fixed to the configuration of the selected historical version and cannot be changed.

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

    Tomcat

    The value is fixed to the configuration of the selected historical version and cannot be changed.

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

    Advanced Settings

    The value is fixed to the configuration of the selected historical version and cannot be changed.

    *Deployment Architecture

    Click Select, select an instance deployment architecture for dark lunch, and click OK.

    NOTICE:

    Choose the correct architecture. Otherwise, dark launch will be fail and services are affected.

    Dark Launch Policy

    Select a dark lunch policy.

    • Traffic ratio-based: Flexibly and dynamically adjust the traffic ratio of different versions.
    • Content-based: Control the version to which the request is sent according to the request.

    Traffic Ratio

    When Dark Launch Policy is set to Traffic ratio-based, set the traffic ratio.

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

    *Takes effect

    When Dark Launch Policy is set to Content-based, set the effective mode of the dark launch policy.

    • With single criterion: The dark launch policy takes effect when any matching rule is met.
    • With full criteria: The dark launch policy takes effect when all matching rules are met.

    *Matching Rule

    When Dark Launch Policy is set to Content-based, set the matching rule for the dark launch policy to take effect.

    Click Add Match Condition and set Matching Type, Parameter Name, Condition Type, and Condition Value.

    *Instances for Dark Launch

    Select a mode for adding an instance during dark launch.

    • Blue-green

      Add new version instances with the same number as the old version instances, and switch traffic to the new version based on dark launch rules. After verification based on the dark launch rules, switch all traffic to the new version and delete the old version

      Scenarios: lossless service capacity, fast rollback, and when resources are needed in the cluster.

      This mode is supported only when there is one or more component instances.

    • Canary (increase, then decrease)

      Add new version instances with the specified number, and switch traffic to the new version based on dark launch rules. After verification based on the dark launch rules, add some new instances, delete corresponding old instances, and switch traffic. Repeat this process until all traffic is switched to the new instances and old instances are deleted.

      Scenarios: lossless service capacity, slow rollback, and when resources are needed in the cluster.

      This mode is supported only when there are two or more component instances.

    • Canary (decrease, then increase)

      Delete some old instances and add corresponding new instances, and switch traffic to the new version based on dark launch rules. After verification based on the dark launch rules, delete some old instances, add corresponding new instances, and switch traffic. Repeat this process until all traffic is switched to the new instances and old instances are deleted.

      Scenarios: lossy service capacity and slow rollback.

      This mode is supported only when there are two or more component instances.

    *First Batch of Dark Launch Instances

    Set this parameter when Instances for Dark Launch is set to Canary (increase, then decrease) or Canary (decrease, then increase).

    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

    Set this parameter when Instances for Dark Launch is set to Canary (increase, then decrease) or Canary (decrease, then increase). That is, the 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.

    *Graceful Time Window

    You can set a graceful scale-in time window to save important data before a component instance stops. The value ranges from 0 to 9999, in seconds. The default value is 30.

    For example, if an application has two instances and only one instance will be kept after the scale-in operation, you can still perform certain operations on the instance to be stopped in the specified time window.

  7. Click Upgrade.

    In the Deployment Records area, you can view the deployment progress and wait until the deployment is complete.