Upgrading a Component in Dark Launch Mode

Introduction to Dark Launch

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.

Prerequisites

• Only container-deployed stateless components can be upgraded in microservice dark launch mode. (If the component technology stack is Docker, multi-container deployment must be disabled). For details, see:
  • Creating and Deploying a Component Based on a Container Using UI Configurations
  • Creating and Deploying a Component Based on a Container Using YAML Configurations
• The component status is Running, Not ready, or Abnormal. For details about how to check the component status, see Viewing Component Details.

Upgrading a Component in Dark Launch Mode

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.
   • On the Component Management page, click the target component.

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

   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 Creating Repository Authorization 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. NOTE: If you select an image package: You can customize the container name. The name contains 1 to 63 characters, including lowercase letters, digits, and hyphens (-), and must start with a lowercase letter and end with a lowercase letter or digit. Click in the upper right corner of the selected image package to change the image package 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. 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. Otherwise, the current deployment record will overwrite the historical deployment record of the same version.
   *Container Name	If the component is deployed in a container and the technology stack is not Docker, you can customize the container name. The name contains 1 to 63 characters starting with a lowercase letter and ending with a lowercase letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed.
   Resources	You can customize CPU and Memory to set their quota, and set the maximum/minimum number of CPU cores and memory size (GiB) that can be used by components. In this way, you can set the number of resources required by each component instance. When resource Request is specified for a component instance, CCE uses this information to determine the node to which the component instance is scheduled. When resource Limit is specified for a component instance, CCE ensures that the resources occupied by the running component instance do not exceed the limit. CCE will also reserve the requested number of system resources for the component instance. For details about how to configure them, see Resource Management. To modify them, 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. Select Tomcat. The Tomcat dialog box is displayed. 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? Click OK.
   Container Settings	Set this parameter as required by referring to Managing Container Settings of a Container-Deployed Component.
   Advanced Settings	Set this parameter as required by referring to Managing Advanced Settings of a Container-Deployed Component.
   *Deployment Architecture	Click Select and select an instance deployment architecture for dark lunch. Click OK. NOTICE: You must choose the correct architecture. Otherwise, dark launch will fail and services will be affected. Click Change to reselect a deployment architecture.
   *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. NOTE: ELB dark launch supports only the Traffic ratio-based policies.
   *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. NOTE: For ELB dark launch, only With full criteria is supported.
   *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 Matching Condition. Set Matching Type. Currently, only Request header is supported. Set Parameter Name, that is, the key corresponding to Matching Type. Set Condition Type, that is, the matching rule that Condition Value meets. Equal: The value corresponding to Matching Type is equal to the configured Condition Value. Matching: Condition Value supports PERL-compatible regular expressions. It is supported by only microservice dark launch. Enumerated: Multiple Condition Value are separated by commas (,). Set Condition Value, that is, the value corresponding to Matching Type.
   *Instances Deployed 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 requires 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, 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: lossless service capacity, slow rollback, and when resources are needed in the cluster. This mode requires 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 requires two or more component instances. NOTE: To change the number of component instances to meet the requirements, see Configuring a Manual Scaling Policy.
   *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.

6. Click Upgrade.

   Wait until the component status changes from Upgrading/Rolling back the component to Running, indicating that the component has been upgraded.

Follow-Up Operations