Redeploying a Component in Rolling Release Mode

Prerequisites

• You have upgraded a component. For details, see Upgrading a Single Component or Upgrading Components in Batches.
• 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.

Redeploying a Component in Rolling Release Mode

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, click the target component in Component List, and choose Deployment Records in the left navigation pane.
   • On the Component Management page, click the target component and choose Deployment Records in the left navigation pane.

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 Rolling Release for Deployment Type and click OK.
6. Configure the component version by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

   Parameter	Description
   Stack	Select a component technology stack and version. For details, see Technology Stack.
   *YAML Mode	Uses YAML configurations to redeploy components if the component is deployed in the Kubernetes environment. Disabled: The UI configurations are used to redeploy components. Enabled: The YAML configurations are used to redeploy components. The latest load information of the component is automatically synchronized from CCE where the target component is deployed for component redeployment after modification. Alternatively, click Import YAML File to import the edited YAML configuration file of the target component. NOTE: If YAML configurations are used to redeploy components, the parameters in the YAML configuration file are described in Deployment.
   *Software Package/Image	The value is fixed to the component source selected during component creation and deployment. For container-deployed components with YAML Mode disabled: 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. For container-deployed components with YAML Mode enabled: 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, the option is fixed to the software package type (JAR, WAR, or ZIP) selected during component creation and deployment. It is determined by the selected technology stack type. For details, see Table 1. This parameter is unavailable when the technology stack is Docker. For VM-deployed components: If the component source is software package, the value is fixed to the software package type (JAR, WAR, ZIP, or compressed package) selected during component creation. It is determined by the selected technology stack type. For details, see Table 1.
   *Upload Method	For container-deployed components with YAML Mode disabled: 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. For container-deployed components with YAML Mode enabled: If the component source is software package, select an uploaded software package. For details about the upload method, see Component Source. This parameter is unavailable when the technology stack is Docker. For VM-deployed components: If the component source is software package, you can select an uploaded software package. For details about the upload method, see Component Source. If the component source is software package and Custom file address is selected, perform the following operations: Enter the custom HTTP/HTTPS file download address of the software package. Determine whether to enable authentication. If authentication is disabled, any user can download the software package in the custom file address by default. Click to enable authentication. Only authenticated users can download the software package in the custom file address. Authentication mode can be User name and password authentication or User-defined Header Authentication. The authentication mode and the corresponding authentication parameters are determined by the authentication mode supported by the server where the custom file directory is located.
   Image Access Credential	This parameter is available for container-deployed components. You can select up to 16 image access credentials. Click Create Secret to create an image access credential. Secret Type must be kubernetes.io/dockerconfigjson. For details, see Creating a Secret.
   *Command	This parameter is mandatory when the component is deployed based on a container, YAML Mode is disabled, the component source is Source code repository, 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 is deployed based on a container, YAML Mode is disabled, the component source is Source code repository, 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	This parameter is mandatory when the component is deployed based on a container, the technology stack is not Docker, and YAML Mode is disabled. 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	The value is fixed to the configuration of the selected historical version and cannot be changed. This parameter is available when the component is deployed based on a container and YAML Mode is disabled.
   JVM Parameters	The value is fixed to the configuration of the selected historical version and cannot be changed. This parameter is available when the component is deployed based on a container, YAML Mode is disabled, and 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 component is deployed based on a container, YAML Mode is disabled, and the technology stack type is Tomcat. It configures parameters such as the request path and port number of Tomcat.
   Cloud Service Settings	If the component is deployed based on a container and YAML Mode is disabled, set Microservice Engine and Distributed Cache Service by referring to Managing Cloud Service Settings of a Container-Deployed Component. If the component is deployed based on VM, set Microservice Engine by referring to Binding a VM-Deployed Component to a Microservice Engine.
   Container Settings	The value is fixed to the configuration of the selected historical version and cannot be changed. If the component is deployed based on a container and YAML Mode is disabled, the component container settings are displayed.
   VM Settings	The value is fixed to the configuration of the selected historical version and cannot be changed. If the component is deployed based on VM, the configured VM settings are displayed.
   Application Settings	The value is fixed to the configuration of the selected historical version and cannot be changed.
   Advanced Settings	The value is fixed to the configuration of the selected historical version and cannot be changed.
   *Deployment Batch	Number of batches in which component instances are upgraded. The value range is [1, Total number of instances]. Total number of instances refers to the number of running instances of the component. For example, if there are 4 component instances and Deployment Batch is set to 2, these component instances are upgraded in two batches, and each batch involves two component instances.
   *Pause Before Stop	This parameter is available when the component is deployed based on VM. The Rx traffic will be processed during this period of time. The value ranges from 0 to 600, in seconds. The default value is 30.
   Best Effort Mode	This parameter is available when the component is deployed based on VM. Click to enable the best effort mode. If the upgrade fails, the remaining instances will be upgraded. NOTICE: Exercise caution when enabling the best effort mode. After the best effort mode is enabled, all instances may fail to be upgraded in extreme cases, affecting service functions.

7. Click Upgrade.
   • Wait until the component status changes from Upgrading/Rolling back the component to Running, indicating that the component has been redeployed.
   • On the Deployment Records page, view the deployment logs.

     For container-deployed components, if "Querying the Status of a Workload Instance" is displayed, click View Event to view details.

     For VM-deployed components, if "Creation of the VM application instance failure", "Query of the VM task status failure", or "Query of the VM application instance status failure" is displayed, click View Event to view details in the event list.