Creating a Component Based on a Container Using Manual Configurations

Prerequisites

• An application has been created because components can only be added to applications. For details, see Creating an Application.
• An environment supported by container-based deployment has been created and resources have been managed because components need to be deployed in an environment.
  • For the environment types supported by container-based deployment, see Component Deployment Modes.
  • For details about how to create an environment and manage resources, see Environment Management.
• An organization has been created because images generated during component build need to be managed by organization. For details, see Creating an Organization.
• A namespace has been bound to the CCE cluster to isolate build data and component instances. For details, see Managing Namespaces.
• If you create a component based on a source code repository, repository authorization has been created. For details, see Creating Repository Authorization.
• If you create a component based on a software package:
  • Upload the software package to the SWR repository. For details, see Uploading a Software Package.

    If PKIToken is disabled, the SWR repository is not supported.

  • Upload the software package to the OBS bucket. For details, see Streaming Upload (PUT).
  • If the package type is software package and you need to use JFrog (example) as the software package repository, you can download the package from the HTTP/HTTPS custom file address. Upload the software package to the corresponding custom file address in advance.

  If the software package fails to be uploaded, see What If a Software Package Fails to Be Uploaded?

• If you create a component based on an image package, prepare the image by referring to Component Source.

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

1. Log in to ServiceStage.
2. Select a component creation mode.
   • To create a component from scratch, go to 3.
   • To create a component based on a component draft, go to 4.

3. To create a component from scratch, perform the following operations:
   1. Use any of the following methods to go to the Create Component page.
      • Choose Component Management > Create Component > Create Now.
      • On the Application Management page, select the application for which you want to create a component, and click More > Create Now in the Operation column.
      • On the Application Management page, click the application for which you want to create a component. On the displayed Overview page, click Create Component.
   2. Go to 5.

4. To create a component based on a component draft, perform the following operations:
   1. Use either of the following methods to go to the Create Component page.
      • On the Application Management page, click the application where the component draft is located. The Component Management page is displayed. In the component list, click the target component whose Status is Draft.
      • On the Component Management page, click the target component whose Status is Draft.
   2. Go to 5.

5. 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	Select Kubernetes or VM + Kubernetes. For details, see Environment Overview.
   *Select Cluster	Select a CCE cluster for deploying and running the component when Environment is an HA environment.
   *Namespace	Namespace of the container where the component instance is located, which is used to isolate the component instance. For details, see Managing Namespaces.
   *Deployment Mode	Select Container. This parameter is mandatory when Environment is set to VM + Kubernetes. For details, see Component Deployment Modes.
   *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: Deployments do not store any data or status while they are running. Typical scenario: Nginx. Stateful: StatefulSets store data and statuses while they are running. Typical scenario: MySQL. DaemonSet: A DaemonSet runs a pod on each node in a cluster and ensures that there is only one pod. This works well for certain system-level applications, such as log collection and resource monitoring, since they must run on each node and need only a few pods. A good example is kube-proxy. DaemonSets are closely related to nodes. If a node becomes faulty, the DaemonSet will not create the same pods on other nodes. Job: It is a one-time task that runs to completion. It can be executed immediately after being created. It is completed after it exits normally (exit 0). A job is a resource object that is used to control batch tasks. Jobs are different from long-term servo tasks (such as Deployments and StatefulSets). The former is started and terminated at specific times, while the latter runs unceasingly unless being terminated. The pods managed by a job automatically exit after the job is completed based on user configurations. Typical scenarios: database migration, batch computing, and CI/CD pipeline tasks.
   *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 (-). If Workload Type is DaemonSet, 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 (-). If Workload Type is Job, 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.
   *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. Each component can have a maximum of 20 labels. If your organization has configured tag policies for ServiceStage, add tags to trackers based on the policies. If a tag does not comply with the tag policies, environment creation may fail. Contact your administrator to learn more about tag policies. Click Add Label. In the Add Label dialog box, click Add Label. Enter a key and value. The key cannot be the built-in app, casid, or version. 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 (.). It is recommended that you create a predefined tag on TMS to add the same tag to different resources. Click OK.
   Description	Component description. Click and enter up to 128 characters. Click to save the component description.

6. In the Component Package area, configure the component package by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

   Parameter	Description
   *Stack	Select a component technology stack type based on the component deployment mode. For details, see Table 1. Only enabled technology stacks in the Enabling state can be selected. For details, see Enabling a Technology Stack. If a custom Kubernetes cluster is bound to the environment selected in Environment in 5, only the Docker technology stack is supported. Select a technology stack version from the Name drop-down list. Only enabled technology stack versions in the Enabling state can be selected. For details, see Enabling a Technology Stack Version. 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 enter the JVM parameter. For example: -Xms256m -Xmx1024m Multiple parameters are separated by spaces. 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. Click Stack Settings and select Tomcat. The Tomcat dialog box is displayed. Click Use Sample Code and edit the template file based on service requirements. Tomcat settings use the default server.xml configuration with / as the context path and without an application path. To customize an application path, see How Do I Customize a Tomcat Context Path? Click OK.
   *Source Code/Software Package	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 (JAR, WAR, or ZIP), the software package type is determined by the selected technology stack type. For details, see Table 1.
   *Upload Method	If the package type is software package or image package, select an uploaded software package or image package. For details about the upload method, see Component Source. If the package type is software package and you need to use JFrog (example) as the software package repository, you can select Custom file address. Enter the HTTP/HTTPS custom file download address where the software package is located. 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. If the package type is image package: Select Multi-container to enable multi-container deployment. Containers share network and storage resources and collaborate with each other. Click Select Image Package to select an image package for the container. Select a container and click to specify it as the initialization container for installing tools or scripts before the service container starts. At least one container must be specified as the service container (non-initialization container). For details about container initialization, see Init Containers. 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 container to change the container image package source or delete the container.
   Image Access Credential	An image access credential is a secret, which is used to store the authentication information required for pulling images from a private repository. For a public repository image, you can retain the default settings or do not set this parameter. For a private repository image, this parameter is mandatory. Otherwise, the image fails to be pulled. 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.
   *Container Name	By default, the container name is the same as the workload name in 5. 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 package type 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.

7. In the Build Job area, set build parameters by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

   This parameter is mandatory when the selected technology stack type is Java, Tomcat, Node.js, Python, or PHP in 6.

   Parameter	Description
   *Command	If the package type 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. 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 package type 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 cluster in the build environment must be able to access the Internet. You are advised to select Use current environment. If the 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 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 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 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.

8. Perform the following operations based on whether to continue setting component parameters:
   • If yes, click Next and go to 9.
   • If no, click Save as Draft.

     The component is saved as a draft in the component list of the application selected in 5. When you create a component but do not complete the parameter settings, you can save the draft to prevent the parameters from being lost due to factors such as page closing. You can use the saved component draft to continue creating a component.

9. In the Resources area, configure the resources required by the container-deployed component by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

   Parameter	Description
   *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, the cluster uses this information to determine the node to which the component instance is scheduled. When resource Limit is specified for a component instance, the cluster ensures that the resources occupied by the running component instance do not exceed the limit. The cluster 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. If the package type selected for Upload Method in 6 is image package and multi-container deployment is enabled, set this parameter for each container instance as required.
   *Instances	When Workload Type in 5 is Stateless, Stateful, or Job, set the number of component instances running in the environment. The value ranges from 1 to 200.

   Figure 1 Configuring the resources required by the container-deployed component
   

10. In the Headless Service Settings area, set the service name and port number of the component by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

    This operation is required when Workload Type is Stateful in 5. This operation enables pods in a StatefulSet to access each other and provides a fixed access domain name for each pod.

    Parameter	Description
    *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. Service names of components deployed in the same cluster must be unique. Otherwise, component deployment will fail.
    *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.

11. In the Access Mode area, enable Public Network Access.

    Access modes can be configured if Workload Type of the component in 5 is Stateless, Stateful, or DaemonSet and a CCE cluster is bound to the selected environment.

    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.

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

    1. Set Public Network Load Balancer.

       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.

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

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

    3. 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.
    4. Set Listening Port.

       Enter the listening port number of the application process.

    Figure 2 Configuring public access
    

12. In the Local Time area, set the time zone of the container.

    By default, the time zone is the same as that of the region where the container node is located.

13. Set Cloud Service Settings.

    Cloud Service Settings can be set only if a CCE cluster is bound to the environment selected in 5.

    Operation Type	Operation	Description
    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. If the package type selected for Upload Method in 6 is image package and multi-container deployment is enabled, the microservice engine cannot be bound. To upgrade and maintain components in dark launch mode, bind the ServiceComb engine or registry/configuration center. 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 Distributed Cache.
    Relational Database Service	Binding a cloud database	RDS 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.
    GaussDB	Binding a GaussDB instance	GaussDB is required for persistent storage of application data. Choose Cloud Service Settings > GaussDB and bind a GaussDB instance. For details, see Binding a GaussDB Instance.
    Distributed Message Service for RocketMQ	Binding a DMS for RocketMQ instance	DMS for RocketMQ is required for application components to store and consume messages. Choose Cloud Service Settings > Distributed Message Service for RocketMQ and bind a RocketMQ instance. For details, see Binding a DMS for RocketMQ Instance.
    Cloud Search Service	Binding a CSS instance	Uses the multi-condition search, statistics, and report capabilities of structured and unstructured text provided by the Elasticsearch cluster of Cloud Search Service (CSS) to analyze component logs in all scenarios. Choose Cloud Service Settings > Cloud Search Service and bind a CSS instance. For details, see Binding a CSS Instance.

14. Set Container Settings.
    If the package type selected for Upload Method in 6 is image package and multi-container deployment is enabled, set this parameter for each container instance as required.

    Operation Type	Operation	Description
    Environment Variable	Configuring environment variables	Environment variables are set in the container running environment and can be modified after component deployment to ensure application flexibility. Environment variables set for a component are local environment variables and take effect only for this component. Choose Container Settings > Environment Variable and configure environment variables. For details, see Adding an Environment Variable of a Component.
    Startup Command	Configuring a startup command	A startup command is used to start a container. Choose Container Settings > Startup Command and configure the startup command. For details, see Configuring the Startup Command and Lifecycle of a Component.
    Data Storage	Configuring data storage	Container storage is a component that provides storage for applications. Multiple types of storage are supported. A component can use any amount of storage. Cloud storage can be configured if a CCE cluster is bound to the environment selected in 5. Choose Container Settings > Data Storage and configure data storage. For details, see Configuring Data Storage.
    Lifecycle	Configuring the lifecycle	For container-deployed components, ServiceStage provides callback functions for the lifecycle management of applications. For example, if you want an application component to perform a certain operation before stopping, you can register a hook function. Choose Container Settings > Lifecycle and configure the lifecycle. For details, see Configuring the Startup Command and Lifecycle of a Component.
    Log Collection	Configuring log collection	For container-deployed components, ServiceStage supports setting of application log policies. You can view related logs on the AOM console. You can configure a log policy during or after component deployment. If no configuration is performed, the system collects standard application output logs by default. Choose Container Settings > Log Collection and configure log collection. For details, see Configuring a Log Policy of an Application.
    Health Check	Configuring health check	Health check periodically checks application health status during running of container-deployed components. Health check can be configured if Workload Type of the component in 5 is Stateless, Stateful, or DaemonSet. Choose Container Settings > Health Check and configure health check. For details, see Configuring Health Check.

15. Set Application Settings.

    Set the component configuration file by referring to Managing Application Settings of a Container-Deployed Component. This implements multi-environment component release and upgrade with one-time configuration through file mounting.

    If the package type selected for Upload Method in 6 is image package and multi-container deployment is enabled, set this parameter for each container instance as required.

16. Set Advanced Settings.

    Operation Type	Operation	Description
    Upgrade Policy	Configuring an upgrade policy	Upgrade policy can be configured if Workload Type of the component in 5 is Stateless, Stateful, or DaemonSet. In practice, component upgrade is a common scenario. Components deployed based on a container in ServiceStage support the following upgrade policies: RollingUpdate: New pods are created gradually, and then old pods are deleted. This policy is used by default when you create and deploy a component based on a container, upgrade a component in rolling release mode, upgrade a component in dark launch mode, and upgrade components in batches. Recreate: Old pods are deleted, and then new pods are created. This policy is used by default when you upgrade a component in single-batch release mode. Choose Advanced Settings > Upgrade Policy and configure the upgrade policy. For details, see Configuring a Component Upgrade Policy.
    Scheduling Policy	Configuring the scheduling policy	Scheduling policy can be configured if Workload Type of the component in 5 is Stateless, Stateful, or DaemonSet. 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	Tolerance policy can be configured if Workload Type of the component in 5 is Stateless, Stateful, or DaemonSet. 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	Performance management can be configured if Workload Type of the component in 5 is Stateless, Stateful, or DaemonSet and a CCE cluster is bound to the selected environment. 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 Performance Management of a Container-Deployed Component.
    Custom Monitoring	Configuring custom monitoring	Custom monitoring can be configured if Workload Type of the component in 5 is Stateless, Stateful, or DaemonSet and a CCE cluster is bound to the selected environment. 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.
    Job	Configuring job settings	Job settings can be configured if Workload Type of the component in 5 is Job. Configure job settings to complete batch processing tasks efficiently and reliably. You can configure job parameters to implement flexible task management and resource optimization. Choose Application Settings > Job and configure job settings. For details, see Configuring Component Job Settings.

17. Perform subsequent operations based on whether to deploy the component by referring to the following table.

    Deploy or Not	Procedure
    Yes	Click Create and Deploy. On the View Deployment History page, view the deployment logs and wait until the component deployment is complete. If "Querying the Status of a Workload Instance" is displayed, click View Event to view details. If the technology stack type of the component selected in 6 is Java, Tomcat, Node.js, Python, or PHP, the system creates a build job of the System created type after the component is deployed. For details, see Viewing Build Jobs. When deploying a component whose Workload Type is Stateless, Stateful, or DaemonSet in 5, you can click Suspend to stop the deployment if the component configuration is incorrect. Then, click Upgrade and reconfigure the component by referring to Upgrading a Single Component.
    No	Click Save as Draft. The component is saved as a draft in the component list of the application selected in 5. When you create a component but do not complete the parameter settings, you can save the draft to prevent the parameters from being lost due to factors such as page closing. You can use the saved component draft to continue creating a component.

Follow-up Operations

• Creating a Component Based on a Container Using Manual Configurations and Creating a Component Based on a Container Using YAML Configurations for Draft components.
• Upgrading a Component in Single-batch Release Mode and Upgrading a Component in Rolling Release Mode for Running, Not ready, Abnormal, and Failed components.
• Upgrading a Component in Dark Launch Mode for Running, Not ready, and Abnormal components.
• Upgrading Components in Batches for Running, Not ready, and Abnormal components.
• Cloning Components in Batches for Running, Not ready, and Abnormal components.
• Configuring a Scaling Policy of a Component Instance for Running and Not ready components.
• Maintain components by referring to Component O&M after the components are created and deployed.
• For Running components with public access enabled, you can Changing the Component Access Domain Name to access services provided by the component using domain names.
• For Running components, you can Configuring the Component Access Mode to access the services provided by the component in a preset mode.