On this page

Show all

Help Center/ ServiceStage/ User Guide/ Component Management/ Creating and Deploying a Component/ Creating a Component by Importing a CCE Workload

Creating a Component by Importing a CCE Workload

Updated on 2024-12-16 GMT+08:00

View PDF

This section describes how to import a workload from CCE to create and deploy a component.

This method is appliable only for container-based deployment.

Prerequisites

An application has been created because components can be imported only under an application. For details, see Creating an Application.
The target stateless or stateful workload has been created on CCE and has not been imported. For details, see Creating a Workload.
An environment has been created and bound with resources such as the CCE cluster of the target workload for deploying and running components in a Kubernetes environment. For details, see Environment Management.
A namespace has been created to isolate build data for creating and deploying components in a Kubernetes environment. For details, see Creating a Namespace.
An organization has been created to manage the images generated during component build. For details, see Creating an Organization.
A Docker technology stack has been enabled and is in the Enabling state. If the Docker technology stack is not enabled, enable it by referring to Enabling a Technology Stack.

Creating a Component by Importing a CCE Workload

Log in to ServiceStage.
Use either of the following methods to go to the Import Component page.
- Choose Component Management > Import Component.
- On the Application Management page, click the application for which you want to create a component. On the displayed Overview page, click Import Component.

In the Select Component dialog box, configure the target workload by referring to the following table and click OK.

Parameter	Description
CCE Cluster	CCE cluster to which the workload to be imported belongs.
Namespace	Namespace to which the workload to be imported belongs.
Workload Type	Type of the workload to be imported. 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	Name of the workload to be imported. NOTE: A workload that has been imported cannot be imported again.

In the Basic Information area, configure the component by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

Parameter	Description
*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 CCE clusters in the same HA 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.
*Application	Application to which the component belongs.
*Environment	Component deployment environment. By default, the Kubernetes environment bound to the CCE cluster of the workload is selected. If the workload cluster is not bound to any Kubernetes environment, bind the cluster to a Kubernetes environment by referring to Binding a CCE Cluster.
*Deployment Mode	The value is fixed to Container. This parameter is mandatory when Environment is set to VM + Kubernetes. NOTE: The environment type is VM + Kubernetes if both CCE clusters and VMs are managed in the environment.
*Namespace	The value is the namespace to which the workload selected in 3 belongs.
*Workload Type	The value is the workload type selected in 3.
*Workload	The value is the workload name selected in 3.
*Label	ServiceStage allows you to add labels of the key-value pair type to manage and select components, for example, for Configuring a Scheduling Policy of a Component Instance. Click Add Label. In the Add Label dialog box, click Add Label. Enter a key and value. The key contains 1 to 63 characters. Start and end with a letter or digit. Only use digits, letters, underscores (_), hyphens (-), and periods (.). The value contains 0 to 63 characters. Start and end with a letter or digit. Only use digits, letters, underscores (_), hyphens (-), and periods (.). NOTICE: The key cannot be the built-in app, casid, or version. Click OK.
Description	Component description. Click and enter up to 128 characters. Click to save the component description.

In the Component Package area, retain the fixed values.
Click Next.

In the Access Mode area, enable Public Network Access.

After public network access is enabled for a component, you can use a public network domain name to access the component through an ELB bound with an EIP to use services provided by the component.

NOTE:

If a component is upgraded and maintained in ELB dark launch mode after being created and deployed, you need to enable public network access for the component. For details about ELB dark launch, see Upgrading a Component in Dark Launch Mode.
After a component with public network access enabled is created and deployed, you can change the configured component access domain name by referring to Changing the Component Access Domain Name.
By default, public network access is disabled for a component. After a component is created and deployed, you can also configure the component access mode. For details, see Configuring the Component Access Mode.

Click

to enable public access and set the following parameters:

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.	Creating a Shared Load Balancer. See Creating a Dedicated Load Balancer.
ELB dark launch	See Creating a Dedicated Load Balancer.

NOTE:

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 Cloud Service Settings.

Operation Type	Operation	Description
Microservice Engine	Binding a microservice engine	Microservice 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 Container-Deployed Component to a Microservice Engine. NOTE: If multi-container deployment is enabled, the microservice engine cannot be bound. After a component is created by importing a CCE workload, if you need to upgrade and maintain the component in dark launch mode, bind the ServiceComb engine or registry/configuration center in this step. For details, see Upgrading a Component in Dark Launch Mode.
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 Container-Deployed Component to a Distributed Cache Instance.
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 Container-Deployed Component to a Cloud Database.

Operation Type

Operation

Description

Microservice Engine

Binding a microservice engine

Microservice 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 Container-Deployed Component to a Microservice Engine.

NOTE:

If multi-container deployment is enabled, the microservice engine cannot be bound.
After a component is created by importing a CCE workload, if you need to upgrade and maintain the component in dark launch mode, bind the ServiceComb engine or registry/configuration center in this step. For details, see Upgrading a Component in Dark Launch Mode.

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 Container-Deployed Component to a Distributed Cache Instance.

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 Container-Deployed Component to a Cloud Database.

Click Create Now.

Perform subsequent operations as required by referring to the following table.

Operation	Procedure
Do not enable the component	Click Back to Component Management. On the component list page, the imported component status is Imported and to be restarted. To enable the component, see Starting and Stopping a Component Instance.
Enable the component	Click Enable Component Now. Click Restart. The component is successfully enabled and is in the Running state.