Creating and Deploying a Component Based on a Container Using UI Configurations

*Component Name

Name of a component, which cannot be changed after the component is created and deployed.

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

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.

*Environment

Select Kubernetes or VM + Kubernetes.

For details, see Environment Overview.

*Deployment Mode

Select Container.

This parameter is mandatory when Environment is set to VM + Kubernetes. For details, see Deploying a Component.

*Application

Application to which the component belongs.

*Workload Type

A workload is an application running on Kubernetes. No matter how many components are there in your workload, you can run it in a group of Kubernetes pods. A workload is an abstract model of a group of pods in Kubernetes. Select a workload type as required.

• Stateless: Workloads are completely independent and have the same functions. They support auto scaling and rolling upgrade. Typical scenario: Nginx.
• Stateful: Workloads have persistent storage and support orderly deployment, scaling, and deletion. Typical scenario: MySQL-HA and etcd.

*Workload

The workload name is automatically generated by default, and can also be customized.

The default workload name consists of the Component Name and Environment you set, and six random characters generated by the system. The total length cannot exceed 52 characters.

• If the Component Name contains 45 characters or fewer, the default workload name is:

  All of the component name-All or part of the environment name-Six random characters generated by the system

  Underscores (_) in the name will be replaced with hyphens (-), and uppercase letters will be converted to lowercase letters.

  For example, if the component name is Com_calc and the environment is env-cce, the default workload name is:

  com-calc-env-cce-1uw8g0

• If the Component Name contains more than 45 characters, the default workload name is:

  First 45 characters of the component name-Six random characters generated by the system

  Underscores (_) in the name will be replaced with hyphens (-), and uppercase letters will be converted to lowercase letters.

  For example, if the component name is C_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, the default workload name is:

  c-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-1uw8g0

You can also customize the workload name.

• If Workload Type is Stateful, enter 1 to 52 characters starting with a lowercase letter and ending with a letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed.
• If Workload Type is Stateless, enter 1 to 63 characters. Start with a lowercase letter and end with a lowercase letter or digit. Only use lowercase letters, digits, and hyphens (-).

The workload name cannot be changed after the component is created and deployed.

Description

Component description.

1. Click and enter up to 128 characters.
2. Click to save the component description.

*Stack

1. Select a component technology stack type based on the component deployment mode. For details, see Table 1.
2. Select a technology stack version from the Name drop-down list.
3. Set JVM to configure the memory parameter size during Java code running. This parameter is available when a Java or Tomcat technology stack is selected.

   Click Stack Settings and set JVM, for example, -Xms256m -Xmx1024m. Multiple parameters are separated by spaces.

4. Set Tomcat to configure the parameters such as Tomcat request path and port number. This parameter is available when a Tomcat technology stack is selected.
   1. Click Stack Settings and select Tomcat. The Tomcat dialog box is displayed.
   2. 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?

   3. Click OK.

*Source Code/Software Package

• If you select Source code repository, create authorization by referring to Authorizing a Repository and set the code source.
• If you select a software package (JAR, WAR, or ZIP), the software package type supported by the component source 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.

*Container Name

This parameter is mandatory when the component is deployed based on a container.

• By default, the container name is the same as the workload name in 3. You can also 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.
• If the source of the component selected for Upload Method is image package and multi-container deployment is enabled, you need to customize a container name for the new container. 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.

*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:

    cd ./weather/

    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.

YAML Mode

Disable it to use the UI configurations to deploy components.

*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.

*Instances

Set the number of component instances running in the environment. The value range is 1–200.

*Namespace

Select the namespace of the container where the component instance is located.

*Service Name

Enter the name of the service that can be accessed by external services.

A service is an abstract method that exposes a group of applications running on a pod as network services.

*Port Settings

Set the following port parameters:

• Port Name: name of the port for communication between pods.
• Container Port: port used by an application for listening in a container.
• Access Port: port for accessing the service.

To add port settings, click Add Setting.

Microservice Engine

Binding a microservice engine

Cloud Service Engine is a one-stop management platform for microservice solutions. After microservice components are connected to CSE, you can use service registry, service governance, and configuration management of CSE. In this way, you can focus on service development and improve product delivery efficiency and quality.

Choose Cloud Service Settings > Microservice Engine and bind a microservice engine. For details, see Binding a Microservice Engine.

Distributed Cache Service

Binding a distributed cache

In a distributed system, the distributed cache service provides scalable and reliable user session management.

Choose Cloud Service Settings > Distributed Cache Service and bind a distributed cache. For details, see Binding a Distributed Cache.

Relational Database Service

Binding a cloud database

The cloud database is required for persistent storage of application data.

Choose Cloud Service Settings > Relational Database Service and bind a cloud database. For details, see Binding a Cloud Database.

Scheduling Policy

Configuring the scheduling policy

For container-deployed components, ServiceStage divides the components into minimum deployment instances based on the deployment features of the components. The application scheduler monitors application instance information in real time. When detecting that a new pod needs to be scheduled, the application scheduler calculates all remaining resources (compute, storage, and network resources) in the cluster to obtain the most appropriate scheduling target node.

Choose Advanced Settings > Scheduling Policy and configure the scheduling policy. For details, see Configuring a Scheduling Policy of a Component Instance.

Tolerance Policy

Configuring the tolerance policy

For container-deployed components, tolerations allow the scheduler to schedule pods to nodes with target taints. Tolerances work with node taints. Each node allows one or more taints. If no tolerance is configured for a pod, the scheduler will schedule the pod based on node taint policies to prevent the pod from being scheduled to an inappropriate node.

Choose Advanced Settings > Tolerance Policy and configure the tolerance policy. For details, see Configuring a Tolerance Policy of a Component Instance.

Performance Management

Configuring performance management

The Application Performance Management (APM) service helps you quickly locate problems and identify performance bottlenecks to improve your experience. ServiceStage allows you to configure application performance management during or after component deployment.

APM can be configured for components whose technology stack type is Java, Tomcat, or Docker.

Choose Advanced Settings > Performance Management and configure performance management. For details, see Configuring Application Performance Management.

Custom Monitoring

Configuring custom monitoring

ServiceStage allows you to obtain monitoring data based on custom metrics. You can set custom metric monitoring during or after component deployment. Components deployed based on CCE support custom monitoring.

Choose Advanced Settings > O&M Policy and configure custom monitoring. For details, see Configuring Custom Monitoring of a Component.