Dark Launch (Canary)

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 (Canary) for 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	The value is fixed to the component source selected during component creation and deployment.
   *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	Version number of a component. Automatically-generated: Click Generate. By default, the version number is the timestamp 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.1214.172318, the version number is 2022.1214.17238. You can also customize the version number 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	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.
   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.

7. Click Upgrade.

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