Help Center> ServiceStage> User Guide> Component Management> Creating and Deploying a Component
Updated on 2024-07-09 GMT+08:00
View PDF

Creating and Deploying a Component

This section describes how to create and deploy a component on ServiceStage.

ServiceStage allows you to create components with the same name in the same application. During component deployment, for components with the same name:

  • Components with the same name in the same application cannot be deployed in the same environment.
  • Components with the same name in different applications can be deployed in the same environment.

Prerequisites

  1. An application has been created because components can only be added to applications. For details, see Creating an Application.
  2. An environment has been created and resources have been managed because components need to be deployed in a specified environment. For details, see Environment Management.
  3. An organization has been created because the image generated by the component deployment needs to be managed based on an organization. For details, see Creating an Organization.
  4. (Optional) A namespace has been created, if you want to create and deploy a component in a Kubernetes environment. For details, see Creating a Namespace.
  5. If you create a component based on a source code repository, create repository authorization first. For details, see Authorizing a Repository.
  6. If you create a component based on a software package, the software package has been uploaded to the SWR software repository or OBS bucket.

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

Procedure

  1. Log in to ServiceStage.
  2. Use any of the following methods to go to the Create Component page:

    • Choose Component Management > Create Component.
    • On the Application Management page, select the application for which you want to create a component, and click Create Component 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.

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

    Kubernetes environment:

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

    VM environment:

    • 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

    Component deployment environment.

    *Deployment Mode

    Component deployment mode. This parameter is mandatory when Environment is set to VM + Kubernetes.

    • Container-based deployment: CCE is a highly scalable, enterprise-class hosted Kubernetes service for you to run containers and applications. With CCE, you can easily deploy, manage, and scale containerized applications on the cloud platform.
    • VM-based deployment: A VM, or an HECS, is a basic computing unit that consists of vCPUs, memory, OS, and EVS disks. After creating an ECS, you can use it like using your local computer or physical server to deploy components.
    NOTE:

    If CCE clusters and VMs are managed in an earlier version, the environment type is VM + Kubernetes after the upgrade to the current version.

    *Application

    Application to which the component belongs.

    *Workload

    This parameter is mandatory when the component is deployed based on CCE.

    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 62 characters.

    • If the Component Name contains 55 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 55 characters, the default workload name is:
      First 55 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-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-1uw8g0

    You can also customize the workload 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.

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

    *Container

    This parameter is mandatory when the component is deployed based on CCE.

    By default, the container name is the same as the workload name.

    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.

    Description

    Component description.

    1. Click to enter the component description.
    2. Click to save the component description.

      Click to cancel the setting.
    Figure 1 Setting the basic component information

  4. 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
    1. Select a component technology stack type based on the component deployment mode. For details, see Table 1.
    2. Select a technology stack from the Name drop-down list.
    3. (Optional) 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. (Optional) Set Tomcat parameters 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, 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.

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

    This area is mandatory when the component is deployed based on CCE and the selected technology stack type is Java, Tomcat, Node.js, Python, or PHP.

    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. For 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
    • Use independent environment: Select an independent build environment different from that to which the component belongs.
    • Use current environment: 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

    You can use a node label to deliver the build job to a fixed node bound with an EIP.

    For details about how to add a label, see Managing Node Labels.

    YAML Mode
    • Disabled: The GUI configurations are used to deploy components.
    • Enabled: The YAML configurations are used to deploy components.
    Figure 2 Configuring build parameters

  6. Click Next.

    • If the component is deployed based on CCE and YAML Mode is enabled in 5, perform 7 to 9.
    • If the component is deployed based on VM, perform 10 to 14.
    • If the component is deployed based on CCE and YAML Mode is disabled in 5, perform 10 to 14.

  7. (Optional) In the Access Mode area, click to enable Public Network Access.

    This operation is supported when the component is deployed based on CCE.
    • 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 Dark Launch (Canary).
    • 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.
    1. Set Public Network Load Balancer.
      • Select an Elastic Load Balance (ELB) resource that has been bound to an elastic IP address (EIP) in the selected environment.
      • If no ELB resource exists, click Add One. On the Edit Environment page that is displayed, click Add Optional Resource to add created ELB resources to the environment.
      • For details about how to create an ELB resource, see Creating a Shared Load Balancer.
        • An ELB needs to be bound to an EIP, and must be in the same VPC and subnet as the compute resources managed in the current component deployment environment.
        • Components must be bound to different ELBs in different deployment environments to avoid route errors.
    2. (Optional) 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 Creating a Certificate.

    3. Set Domain Name.
      • If Automatically generated is selected, the automatically generated domain name is valid only for seven days.

        Domain names cannot be automatically generated in LA-Sao Paulo1 and LA-Mexico City2.

      • If Bound is selected, enter a domain name.
    4. Set Listening Port.

      Set the listening port of the application process.

    Figure 3 Configuring public access

  8. Import or edit the YAML configuration file of the component.

    This operation is supported when the component is deployed based on CCE and YAML Mode is enabled in 5. For details about the parameters in the YAML configuration file, see Deployment.

    • Click Import YAML File to import the edited YAML configuration file.
    • Edit the configuration parameters as required.

    You can change name in the YAML configuration by referring to the description of Workload Name in 3. The workload name cannot be changed after the component is created and deployed.

  9. Click Create and Deploy.

    On the Deployment Records page, view the deployment logs and wait until the component deployment is complete.

    Figure 4 Viewing component deployment logs

  10. In the Resources area, set the resources required by the component.

    • If the component is deployed based on CCE, set the parameters by referring to the following table. Parameters marked with an asterisk (*) are mandatory.

      Parameter

      Description

      *Resources

      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 Resource Management.

      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. To make modifications, 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.
      Figure 5 Deploying resources of a Kubernetes component
    • For components deployed based on VM, if Resource Type is set to ECS, select the ECS that has been managed in the component deployment environment; if Resource Type is set to AS, select the AS group to be used from the Resources drop-down list, and then select the ECS in the AS group to deploy the component.
      • The selected ECS must have the VM agent installed. For details, see Installing a VM Agent.
      • AS groups are not supported in LA-Sao Paulo1 and LA-Mexico City2.

  11. (Optional) 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.
    • 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.
      • Select an Elastic Load Balance (ELB) resource that has been bound to an elastic IP address (EIP) in the selected environment.
      • If no ELB resource exists, click Add One. On the Edit Environment page that is displayed, click Add Optional Resource to add created ELB resources to the environment.
      • For details about how to create an ELB resource, see Creating a Shared Load Balancer.
        • An ELB needs to be bound to an EIP, and must be in the same VPC and subnet as the compute resources managed in the current component deployment environment.
        • Components must be bound to different ELBs in different deployment environments to avoid route errors.
    2. (Optional) 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 Creating a Certificate.

    3. Set Domain Name.
      • If Automatically generated is selected, the automatically generated domain name is valid only for seven days.

        Domain names cannot be automatically generated in LA-Sao Paulo1 and LA-Mexico City2.

      • If Bound is selected, enter a domain name.

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

    This parameter is available when the component is deployed based on CCE.

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

  13. (Optional) Set Advanced Settings.

    • If the component is deployed based on CCE, refer to the following table.

      Operation Type

      Operation

      Description

      Microservice Engine

      Binding a Microservice Engine

      Bind the microservice engine and connect the component to it.

      NOTE:

      After a component developed based on ServiceComb 2.7.8 or later or Spring Cloud Huawei 1.10.4-2021.0.x or later is connected to a microservice engine, the following attributes are injected into the properties parameter of the MicroServiceInstance parameter when a microservice instance is created in the microservice engine:

      1. CAS_APPLICATION_ID: ID of the application to which the component belongs.
      2. CAS_COMPONENT_NAME: component name.
      3. CAS_ENVIRONMENT_ID: ID of the component deployment environment.
      4. CAS_INSTANCE_ID: component instance ID.
      5. CAS_INSTANCE_VERSION: component instance version.

      For details about the MicroServiceInstance parameter, see MicroServiceInstance.

      1. Choose Advanced Settings > Microservice Engine.
      2. Click Bind Microservice Engine.
      3. Select a microservice engine instance that has been bound in the environment.
      4. Click OK.
        NOTE:

        Move the cursor to a bound microservice engine and perform the following operations:

        • Bind the microservice engine again: Click , select the target microservice engine again, and click OK.
        • Delete a bound microservice engine: Click .
      5. (Optional) If an exclusive microservice engine is bound, specify Addons.
        • Mesher: Enter the listening port number of the application process to enable multi-language access to service mesh. You can use Mesher to connect components that are not developed in the microservice framework to the microservice engine.
        NOTE:
        • For non-microservice components developed using Java, Tomcat, or Docker, you can enable Mesher and use Mesher to connect the components to CSE for microservice registry and discovery.
        • For components developed using Python, PHP, or Node.js, forcibly enable Mesher and connect the components to CSE for microservice registry and discovery.

      Distributed Cache Service

      Binding a Distributed Cache

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

      Choose Advanced Settings > Distributed Cache Service and bind a DCS instance. For details, see Configuring Distributed Cache Service.

      Cloud Database

      Binding a Cloud Database

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

      Expand Advanced Settings > Cloud Database and bind cloud database. For details, see Configuring Relational Databases.

      Component Configurations

      Configuring Environment Variables

      Environment variables are set in the container running environment and can be modified after component deployment, ensuring the flexibility of applications. Environment variables set for a component are local environment variables and take effect only for this component.

      Choose Advanced Settings > Component Configuration and set environment variables. For details, see Configuring Environment Variables of a Component.

      Deployment Configurations

      Setting Startup Commands

      A startup command is used to start a container.

      Choose Advanced Settings > Deployment Configuration and set the startup command. For details, see Configuring the Lifecycle of a Component.

      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.

      Choose Advanced Settings > Deployment Configuration and configure data storage. For details, see Configuring Data Storage.

      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 Advanced Settings > Deployment Configuration and configure the lifecycle. For details, see Configuring the Lifecycle of a Component.

      Configuring the Scheduling Policy

      For container-based deployment components, ServiceStage splits 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 > Deployment Configuration and configure the scheduling policy. For details, see Configuring a Scheduling Policy of a Component Instance.

      O&M and Monitoring

      Configuring Log Collection

      For container-based deployment 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 Advanced Settings > O&M Monitoring and configure log collection. For details, see Configuring a Log Policy of an Application.

      Configuring Health Check

      Health check periodically checks application health status during running of container-based deployment components.

      Choose Advanced Settings > O&M Monitoring and configure health check. For details, see Configuring Health Check.

      Configuring Performance Management

      Performance management 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 > O&M Monitoring and configure performance management. For details, see Configuring Application Performance Management.

      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. This section applies to components deployed using CCE.

      Choose Advanced Settings > O&M Monitoring and configure custom monitoring. For details, see Configuring Custom Monitoring of a Component.
      Figure 6 Setting advanced settings of a Kubernetes component
    • If the component is deployed based on VM, refer to the following table.

      Operation

      Description

      Configuring Environment Variables

      Environment variables are set in the container running environment and can be modified after component deployment, ensuring the flexibility of applications. Environment variables set for a component are local environment variables and take effect only for this component.

      For details about how to set environment variables, see Configuring Environment Variables of a Component.

      Binding a Microservice Engine

      Components whose technology stack type is Java or Tomcat can be bound to microservice engines for microservice governance.

      1. Click Bind Microservice Engine.
      2. Select a microservice engine instance that has been bound in the environment and click OK.
      Figure 7 Setting advanced settings of a VM component

  14. Click Create and Deploy.

    On the Deployment Records page, view the deployment logs and wait until the component deployment is complete.

    Figure 8 Viewing component deployment logs

Parent topic: Component Management