Runtime parameters-Compute Nest(Compute Nest)-阿里云帮助中心

Enable runtime parameters during service creation to let users modify configuration parameters through a graphical interface in Compute Nest, without manually editing configuration files.

Background

Users often need to modify runtime parameters such as the port or maximum connections during a service's lifecycle. This typically requires logging on to the underlying ECS instance or ACK cluster to edit configuration files or ConfigMaps. With runtime parameters enabled, Compute Nest provides a GUI for editing these parameters directly, eliminating manual file edits.

Procedure

Click My Services > Create Service > Build Custom Service > Private Service or Fully Managed Service.
Configure the service settings and the ROS template based on your service's requirements.
On the service creation page, go to the Service O&M (Optional) section and enable Runtime Parameters.
You can define runtime parameters for multiple configuration files. First, define a Parameter Group Name, which helps Compute Nest distinguish between different files. Next, specify the Command File Format. Compute Nest supports common formats such as cnf, json, yaml, properties, and xml. Finally, enter the entire configuration file content in the Parameter File Settings field.

For example, for a MySQL configuration file, set the Parameter Group Name to mysql, select cnf as the Command File Format, and enter the complete MySQL configuration (such as the parameters under the [mysqld] section like bind-address, default_storage_engine, and binlog_format) in the Parameter File Settings field. Then, click Add Modifiable Parameter to define the parameters that users can modify in the table below. For each parameter, you must configure a Parameter name, Type, Description, Default Value, and Constraint.
Define the modifiable parameters. A configuration file can contain many parameters, but you should expose only a subset to users. You must define this subset and the constraints for each parameter. Note the following guidelines:
- When you configure an editable parameter, the Parameter name must exactly match the parameter name in the Parameter File Settings. For file formats with a hierarchical structure, such as JSON, YAML, and XML, use a period (.) to separate the levels. For example, for the following YAML parameter:
```
root:
  properties:
    value: 1
```
  The parameter name can be entered as: root.properties.value
- Supported parameter types are String, Number, List, Boolean, and Json.
- The available constraints depend on the parameter type. The Json and Boolean types do not support constraints. The String type supports "Valid value" and "match expression". The Number type supports "Valid value" and "extreme values". The List type supports only the "Valid value" constraint.
  - Valid Value: Defines a set of predefined values for users to choose from. Users cannot enter custom values. For example:
    
    Set Parameter name to max_user_connections, select String as the Type, enter Maximum user connections for the Description, and set the Default Value to 50. For Constraint, select Valid Value and configure the allowed values as 10, 20, 30, 40, and 50.
  - Match Expression: Lets you specify a regular expression that user input must match. You must also provide a description of the expression for user reference. For example:
    
    Set Parameter name to max_allowed_packet, select String for the Type, enter The maximum cache size for the Description, and set the Default Value to 256M. For Constraint, select Match Expression, set the regular expression to \d+M, and provide a user-facing description, such as "Enter the cache size ending with M. For example, enter 1024M for 1 GB."
  - Parameter Extreme Value: Lets you define the minimum and maximum values for a numerical input. You can set a minimum, a maximum, or both. For example:
    
    Set Parameter name to max_connections, select Number for the Type, enter Maximum Connection for the Description, and set the Default Value to 512. For Constraint, select Parameter Extreme Value, set the minimum value to 10, and the maximum value to 1024.

In your ROS template, define resources to write the configuration file content. The resources you define depend on your deployment method. For example, assume you configured a parameter group named 'mysql' in the Runtime Parameters section.

If your software is deployed on an ECS instance, you typically need to write the configuration to a specific file on the instance. You can use the ALIYUN::ECS::RunCommand resource in your ROS template to execute a write script:
```
Resources:
  InstanceRunCommand:
    Type: ALIYUN::ECS::RunCommand
    Properties:
      Sync: true
      CommandContent: |
        cat > /root/mysql.cnf << "EOF"
        {{ serviceConfigParam }}
        EOF
        
        sudo systemctl restart mysql
      Type: RunShellScript
      InstanceIds:
        Fn::GetAtt:
          - EcsInstanceGroup
          - InstanceIds
      Timeout: '300'
```
Here, {{ serviceConfigParam }} is a pseudo parameter supported by Compute Nest. Compute Nest replaces this pseudo parameter with the content of the configured parameter file. For a single configuration file, use {{ serviceConfigParam }}. For multiple configuration files, use the format {{ serviceConfigParam.ConfigGroupName }}. For example, for configuration files with the Parameter Group Names 'File1' and 'File2', the corresponding pseudo parameters are {{ serviceConfigParam.File1 }} and {{ serviceConfigParam.File2 }}. Note: To apply changes after a user modifies a parameter, you must include a command in the RunCommand resource to reload the configuration. In this example, sudo systemctl restart mysql restarts the MySQL service to apply the new configuration.

If your software is deployed on an ACK cluster, you typically use a ConfigMap to store the configuration. For example:

Resources:
  ClusterApplication:
    Type: ALIYUN::CS::ClusterApplication
    Properties:
      YamlContent: |
            apiVersion: apps/v1
            kind: StatefulSet
            metadata:
              name: mysql-demo
            spec:
              replicas: 1
              selector:
                matchLabels:
                  app: mysql
              template:
                metadata:
                  labels:
                    app: mysql
                spec:
                  containers:
                    - name: mysql
                      image: mysql:latest
                      ports:
                        - containerPort: 3306
                      volumeMounts:
                        - name: mysql-config
                          mountPath: /etc/mysql/conf.d
                  volumes:
                    - name: mysql-config
                      configMap:
                        name: mysql-config
            ---
            apiVersion: v1
            kind: ConfigMap
            metadata:
              name: mysql-config
            data:
              my.cnf: |
              {{ serviceConfigParam }}
      ClusterId: c989ca998e381*************
      DefaultNamespace: mysql-demo

The preceding YAML deploys a StatefulSet that mounts a ConfigMap to store runtime parameters. The key in this ConfigMap is 'my.cnf', and its value is the configuration file content represented by the pseudo parameter.

Configure the remaining settings and save the service.