Rolling Release
After a component is created and deployed, you can upgrade a Running or Not ready component in rolling release mode.
In rolling release mode, only one or more instances are upgraded at a time and then added to the production environment. This process repeats until all old instances are upgraded. Services will not be interrupted during the upgrade.
For details about how to upgrade multiple components 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
- Log in to ServiceStage.
- Use either of the following methods to go to the component Overview page.
- On the Application Management page, click the application to which the target component belongs, and click the component in Component List.
- On the Component Management page, click the target component.
- In the upper right corner of the page, click Upgrade.
- Select Rolling Release for Type.
- 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
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
This parameter is available when the component is deployed in the Kubernetes environment.
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 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 size during Java code running.
Enter the JVM parameter, for example, -Xms256m -Xmx1024m. Multiple parameters are separated by spaces.
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.
- Click OK.
Advanced Settings
If the component is deployed in the Kubernetes environment, set Microservice Engine, Component Configuration, Deployment Configuration, and O&M Monitoring by referring to 10.
If the DCS instance bound to the component must be accessed using a password, move the cursor to this DCS instance and click
to enter the access password again.
*Deployment Batches
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 Batches is set to 2, these component instances are upgraded in two batches, and each batch involves two component instances.
*Graceful Time Window
This parameter is available when the component is deployed in the Kubernetes environment.
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.
Figure 1 Setting rolling upgrade configuration
- 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 |
---|---|
Redeploy 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. |
- Prerequisites
- Procedure
- Follow-Up Operations