Editing a Batch Deployment Release Task
Edit a batch deployment release task that has not been released based on service changes.
Prerequisites
You have created a batch deployment release task but not released it. For details, see Creating a Batch Deployment Release Task.
Editing a Batch Deployment Release Task
- Log in to ServiceStage.
- Choose Release Management. The Release Management page is displayed.
- Select the target release task in the To release state.
- Edit directly: Click More > Edit in the Operation column.
- Edit after confirming the release task details: Click the target release task to go to its Release Management page, confirm the configurations of each component, and click Edit.
- Modify the release task by referring to the following table. Parameters marked with an asterisk (*) are mandatory.
Parameter
Description
*Release Task
Name of a release task.
Enter 2 to 64 characters. Start with a letter and end with a letter or digit. Only use letters, digits, underscores (_), and hyphens (-).
Description
Description of a release task. Enter up to 128 characters.
- Set Best Effort Policy.
- Click to enable Best Effort Policy. If a component fails to be released, continue to release other components.
- Click to disable Best Effort Policy. If a component fails to be released, the release task fails.
- To delete a component from the release task, click Delete in the Operation column of the target component.
- To add components, click Create Component to create components to be added to the release task in batches.
- A maximum of 64 components can be created in a batch deployment release task.
- Create a component. For details, see Creating and Deploying a Component Based on a Container Using UI Configurations.
- Reset the version configurations of each component by referring to the following table.
Parameter
Description
Component
Component name.
Enter 2 to 64 characters. Start with a letter and end with a letter or digit. Only use letters, digits, underscores (_), and hyphens (-).
- Components with the same name in different applications can be deployed in the same environment.
- Components with the same name in the same application can be deployed in different environments.
Component Version
Version number of a component.
- By default, the version number of the original components in the release task is the original version number of the components, and the version number of the new components in the release task is the time when you perform 7. 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.
- 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.
NOTE:You can perform the following operations to synchronize component versions in batches:
- Move the cursor to the Component Version text box of the specified component and click .
- Select other components whose versions need to be synchronized.
- Click OK.
Application
Select the application to which the component belongs. You can perform the following operations to synchronize the applications to which components belong in batches:
- Move the cursor to the Application drop-down list of the specified component and click .
- Select other components whose applications need to be synchronized.
- Click OK.
Environment
Select the component deployment environment. Only the Kubernetes environment can be selected.
NOTICE:If the component has been bound to a specified microservice engine, distributed cache, or cloud database instance but the specified instance is not bound to the environment selected for the component, an error is reported during advanced settings pre-check.
You can perform the following operations to synchronize the environments to which components belong in batches:
- Move the cursor to the Environment drop-down list of the specified component and click .
- Select other components whose environments need to be synchronized.
- Click OK.
After the environment is reset, the cluster to which the component belongs is changed to the cluster bound to the new environment, and the namespace to which the component belongs is changed to the default namespace of the cluster bound to the new environment.
Cluster
Select the CCE cluster where the component is deployed and running.
You can perform the following operations to synchronize the clusters to which components belong in batches:
- Move the cursor to the Cluster drop-down list of the specified component and click .
- Select other components whose clusters need to be synchronized.
- Click OK.
After the cluster is set, the cluster is changed only when the selected cluster is bound to the environment to which the component belongs. In addition, the namespace to which the component belongs is changed to the default namespace of the new cluster.
Namespace
Select the namespace of the CCE cluster in the environment where the build is executed, which is used to isolate build data. For details, see Managing Namespaces.
You can perform the following operations to synchronize the namespaces to which components belong in batches:
- Move the cursor to the Namespace drop-down list of the specified component and click .
- Select other components whose namespaces need to be synchronized.
- Click OK.
After the namespace is set, the namespace is changed only when the selected namespace exists in the cluster to which the component belongs.
Image Package
Click , and select the component source again. For details, see Component Source.
Instances
Set the number of running component instances. The value range is 1–200.
You can perform the following operations to synchronize the number of component instances in batches:
- Move the cursor to the Instances text box of the specified component and click .
- Select other components whose number of component instances need to be synchronized.
- Click OK.
Deployment Sequence
Set the deployment sequence of all components to be added to the release task.
- If the selected components depend on each other, for example, the startup of a component depends on other components, set Deployment Sequence so that the depended components are deployed first.
For example, for components A, B, and C to be added to the release task, the startup of component A depends on components B and C. Therefore, set Deployment Sequence of components B and C to 1, and set Deployment Sequence of component A to 2.
- If the components do not depend on each other, retain the default value of Deployment Sequence. All components will be deployed in the same batch.
- Reset the component build parameters.
This parameter is available when the technology stack type is Java, Tomcat, Node.js, Python, or PHP.
- Locate the target component and click Build in the Operation column.
- Set the parameters by referring to the following table. Parameters marked with an asterisk (*) are mandatory.
Parameter
Description
*Command
If the component source is Source code repository, set Command based on service requirements.
- 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:
mvn clean package
*Dockerfile Address
If the component source is Source code repository, set Dockerfile Address based on service requirements.
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.
*Organization
An organization is used to manage images generated during component build.
*Build
Select the type of the environment used to build an image. The build environment must be a Kubernetes environment, and can access the Internet.
You are advised to select Use current environment. If the CCE cluster in the current environment cannot access the Internet and you have planned an independent build environment, you can select Use independent environment.
- Use independent environment: Use an independent build environment to build an image. The CCE clusters in the independent build environment and in the current component deployment environment must have the same CPU architecture. Otherwise, the component deployment fails.
- Use current environment: Use the deployment environment to which the component belongs to build an image. In the current environment, masters and nodes in the CCE cluster must have the same CPU architecture. Otherwise, the component build fails.
*Environment
- If Use independent environment is selected for Build, select an independent build environment different from that to which the component belongs.
- If Use current environment is selected for Build, select the deployment environment to which the component belongs.
*Namespace
Select the namespace of the CCE cluster in the environment where the build is executed, which is used to isolate build data. For details, see Managing Namespaces.
Node Label
In the following cases, set a node label to deliver the build job to the fixed node bound with an EIP to ensure that the component can be successfully built and deployed:
- If Use independent environment is selected for Build, set a node label to deliver the build job to the node in the independent environment, to ensure that the node CPU architecture is the same as that of the node in the current component deployment environment.
- If Use current environment is selected for Build and the CPU architecture of a node is different from that of the master node in the environment, set a node label to deliver the build job to the node that has the same CPU architecture as the master node.
For details about how to add a label, see Managing Node Labels.
- Click OK.
- Locate the target component and click Advanced Settings in the Operation column.
- Click to enable public network access.
- Set Public Network Load Balancer.
- Select a load balancer that has been bound to an EIP in the selected environment.
- If no load balancer exists, click Add One. On the Edit Environment page that is displayed, click Add Optional Resource to add created load balancers to the environment.
- To create ELB resources, refer to the following table.
Scenario
Reference
Use the domain name to access an application.
- An EIP has been bound to the load balancer and must be in the same VPC and subnet as the compute resources managed in the current component deployment environment.
- Components must be bound with different load balancers in different deployment environments to avoid route errors.
- Set Client Protocol.
- HTTP has security risks. You are advised to select HTTPS.
- If HTTPS is selected, click Use existing to select an existing certificate.
If no certificate exists, click Create new to create a server certificate. For details, see Adding a Certificate.
- Set Domain Name.
- If Automatically generated is selected, the automatically generated domain name is valid only for seven days.
- If Bound is selected, enter a domain name.
- Set Listening Port.
Enter the listening port number of the application process.
Figure 1 Configuring public access
- Set Public Network Load Balancer.
- Set Cloud Service Settings by referring to Managing Cloud Service Settings of a Container-Deployed Component.
- You can perform the following operations to synchronize the bound microservice engines, distributed caches, or cloud databases of components in batches:
- Move the cursor to the microservice engine, distributed cache, or cloud database bound to the specified component, and click .
- Select other components whose configurations need to be synchronized.
- Click OK.
The change is synchronized only when the selected microservice engine, distributed cache, or cloud database is bound to the environment to which the selected component belongs.
- You can perform the following operations to delete microservice engines, distributed caches, or cloud databases for components in batches:
- Move the cursor to the microservice engine, distributed cache, or cloud database bound to the specified component, and click .
- Click Delete, select other components whose configurations need to be synchronized, and click OK.
To delete the microservice engine, distributed cache, or cloud database only for the current component, click Cancel.
- You can perform the following operations to rebind a microservice engine, distributed cache, or cloud database to a component:
- Move the cursor to the microservice engine, distributed cache, or cloud database bound to the specified component, and click .
- Select a managed microservice engine, distributed cache, or cloud database in the current environment, and click OK.
- You can perform the following operations to synchronize the bound microservice engines, distributed caches, or cloud databases of components in batches:
- Set Container Settings by referring to Managing Container Settings of a Container-Deployed Component.
- Set Advanced Settings by referring to Managing Advanced Settings of a Container-Deployed Component.
- Click OK.
- Perform subsequent operations based on whether to release the release task by referring to the following table.
Release or Not
Operation
Yes
- Click Complete and Execute. The system automatically checks whether the advanced settings of each component are correct.
- If an error is reported, perform the following operations and then continue:
- In the displayed dialog box, confirm the information and click OK.
- Click Advanced Settings in the Operation column of the component for which the error is reported.
- Reset the advanced settings of the component based on the error information by referring to Managing Cloud Service Settings of a Container-Deployed Component to Managing Advanced Settings of a Container-Deployed Component.
- If the advanced settings pass the pre-check, the components in the release task will be deployed in batches as configured.
You can view the release records and release task information, and Cloning a Batch Deployment Release Task and Deleting a Release Task.
No
- Click Finish. The system automatically checks whether the advanced settings of each component are correct.
- If an error is reported, perform the following operations and then continue:
- In the displayed dialog box, confirm the information and click OK.
- Click Advanced Settings in the Operation column of the component for which the error is reported.
- Reset the advanced settings of the component based on the error information by referring to Managing Cloud Service Settings of a Container-Deployed Component to Managing Advanced Settings of a Container-Deployed Component.
- If the advanced settings pass the pre-check, a release task in the To release state will be generated.
On the Release Management page, you can view release task information, and Releasing a Release Task, Cloning a Batch Deployment Release Task, Editing a Batch Deployment Release Task, and Deleting a Release Task.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot