Parameter processing method and apparatus

Abstract

The present specification provides a parameter processing method and device, which is applied to a container platform. The parameter processing method comprises the following steps: determining a dependent application and a main application associated with the dependent application in response to an environment change request; generating a dependent parameter corresponding to the main application based on a parameter object defined by the dependent application; determining a target resource object corresponding to the dependent application, and parsing an interface parameter contained in the parameter object based on the target resource object to obtain an interface identifier; constructing a connection parameter of the main application based on the dependent parameter and the interface identifier, and updating a configuration file of the main application by using the connection parameter; and the updated configuration file enables the main application and the dependent application to work cooperatively in a target running environment.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a parameter processing method. This specification also relates to a parameter processing apparatus, a computing device, and a computer-readable storage medium. Background Technology

[0002] In container technology, many applications, such as microservices and container applications, often need to communicate and interact with other applications or systems. In this scenario, the parameters and other information (such as IP address and port) of the dependent applications need to be written into the configuration files of other applications so that the applications can collaborate with each other.

[0003] In existing container technologies, binding applications typically requires manual parameter configuration, which is time-consuming, labor-intensive, and prone to errors. Therefore, a more efficient method is urgently needed to solve these problems. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a parameter processing method. This specification also relates to a parameter processing apparatus, a computing device, and a computer-readable storage medium to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a parameter processing method is provided, including:

[0006] In response to an environment change request, determine the dependent application and the main application associated with the dependent application;

[0007] Generate the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application;

[0008] Determine the target resource object corresponding to the dependent application, and parse the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier;

[0009] The connection parameters of the main application are constructed based on the dependency parameters and the interface identifier, and the configuration file of the main application is updated using the connection parameters;

[0010] The updated configuration file enables the main application and the dependent application to work together in the target runtime environment.

[0011] Optionally, before the step of generating the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application is executed, the method further includes:

[0012] Define the name parameters, interface parameters, description parameters, and query parameters corresponding to the dependent application;

[0013] The parameter object of the dependent application is generated based on the name parameter, the interface parameter, the description parameter, and the query parameter;

[0014] The process of generating the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application includes:

[0015] The name parameter contained in the parameter object defined by the dependent application is determined, and the configuration parameters of the main application are updated based on the name parameter to obtain the dependency parameters corresponding to the main application.

[0016] Optionally, before the step of determining the target resource object corresponding to the dependent application is executed, the method further includes:

[0017] Based on the parameter object, the dependent application is deployed to the target runtime environment;

[0018] After the step of updating the main application's configuration file using the connection parameters is executed, the method further includes:

[0019] The main application is deployed to the target runtime environment based on the updated configuration file.

[0020] Optionally, determining the target resource object corresponding to the dependent application includes:

[0021] Create a set of resource objects that includes control resource objects, service resource objects, and container resource objects;

[0022] Select the resource object that matches the category parameter and label parameter in the parameter object from the set of resource objects, and use it as the target resource object corresponding to the dependent application.

[0023] Optionally, the step of parsing the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier includes:

[0024] Determine the node interface parameters from the interface parameters contained in the parameter object, and determine the object port parameters corresponding to the node interface parameters in the target resource object;

[0025] The parameter value of the object port parameter is used as the interface identifier.

[0026] Optionally, constructing the connection parameters of the main application based on the dependency parameters and the interface identifier includes:

[0027] Update the name parameter in the dependency parameters to the interface identifier, and use the updated dependency parameters as the connection parameters of the main application.

[0028] Optionally, after the step of parsing the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier is performed, the method further includes:

[0029] Create a parameter file corresponding to the dependent application, and store the interface identifier in the parameter file;

[0030] Once the parameters to be parsed corresponding to the dependent application are parsed, status parameters are generated and stored in the parameter file. The status parameters stored in the parameter file are used to characterize the available status of the interface identifier.

[0031] Optionally, creating the parameter file corresponding to the dependent application and storing the interface identifier in the parameter file includes:

[0032] The interface identifier is encrypted;

[0033] Create a parameter file corresponding to the dependent application, and store the encrypted interface identifier in the parameter file;

[0034] Before the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier is executed, the following steps are also included:

[0035] The encrypted interface identifier is read from the parameter file and decrypted to obtain the interface identifier.

[0036] Optionally, before the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier is executed, the method further includes:

[0037] If the availability status of the interface identifier in the parameter file is determined to be that the parameter is available, the interface identifier is read from the parameter file;

[0038] Perform the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier.

[0039] According to a second aspect of the embodiments of this specification, a parameter processing apparatus is provided, comprising:

[0040] The determination module is configured to determine the dependent application and the main application associated with the dependent application in response to an environment change request.

[0041] The generation module is configured to generate the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application.

[0042] The parsing module is configured to determine the target resource object corresponding to the dependent application, and parse the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier;

[0043] The update module is configured to construct the connection parameters of the main application based on the dependency parameters and the interface identifier, and update the configuration file of the main application using the connection parameters; wherein the updated configuration file enables the main application and the dependent application to work together in the target runtime environment.

[0044] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising:

[0045] Memory and processor;

[0046] The memory is used to store computer-executable instructions that, when executed by a processor, implement the steps of the parameter processing method.

[0047] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the parameter processing method.

[0048] The parameter processing method provided in this specification, in response to an environment change request, determines the dependent application and the main application associated with the dependent application; generates the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application; determines the target resource object corresponding to the dependent application, and parses the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier; constructs the connection parameters of the main application based on the dependency parameters and the interface identifier, and updates the configuration file of the main application using the connection parameters; wherein, the updated configuration file enables the main application and the dependent application to work together in the target runtime environment.

[0049] One embodiment of this specification, upon receiving an environment change request, automatically defines the parameter object of the dependent application, parses the interface parameters contained in the parameter object, and updates the main application's configuration file based on the interface identifier obtained from the parsed interface parameters. This achieves automatic parameter binding between the dependent application and the main application, and the updated configuration file enables the main application and the dependent application to work collaboratively in the target runtime environment. It automates the binding of parameters between the dependent application and the main application, avoiding manual parameter configuration and thus improving parameter configuration efficiency and accuracy. Attached Figure Description

[0050] Figure 1 A schematic diagram of a parameter processing method according to an embodiment of this specification is shown;

[0051] Figure 2 This is a flowchart of a parameter processing method provided in one embodiment of this specification;

[0052] Figure 3 This is a flowchart illustrating a parameter processing method for microservice application parameter processing, provided in one embodiment of this specification.

[0053] Figure 4 This is a parameter processing flowchart of a parameter processing method provided in one embodiment of this specification;

[0054] Figure 5 This is a schematic diagram of parameter definition for a parameter processing method provided in one embodiment of this specification;

[0055] Figure 6 This is a schematic diagram of the structure of a parameter processing device provided in one embodiment of this specification;

[0056] Figure 7 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0057] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0058] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0059] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0060] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0061] Container technology: Effectively divides the resources of a single operating system into isolated groups in order to better balance conflicting resource usage demands among these isolated groups.

[0062] Kubernetes (often called K8s) is an open-source container cluster management system used to automatically deploy, scale, and manage containerized applications. Kubernetes can automatically select a working container for use within a container cluster.

[0063] Redis (Remote Dictionary Server) is an open-source, ANSI C-based, network-enabled, in-memory or persistent, log-structured, key-value database that provides APIs for multiple languages.

[0064] Sentinel Service: Monitors the master server in the master-slave replication structure. If the master server becomes unreachable, it will promote the corresponding slave database server to the master database server and continue to monitor the new master database server. After the failed master database server recovers, it will automatically become the slave host of the current master server.

[0065] In container technology, applications often need to communicate and interact with other applications or systems. In this case, the information of the dependent applications (such as IP address and port) needs to be written to the configuration files of other applications so that they can collaborate. The dependent application can be middleware such as Redis, and the application communicating and interacting with the dependent application can be the main application such as a microservice application.

[0066] Figure 1 A schematic diagram of a parameter processing method according to an embodiment of this specification is shown, such as... Figure 1 As shown, the container platform implements parameter binding between the dependent application and the main application. Upon receiving an environment change request, the container platform determines the dependent application and the associated main application in response. It defines a parameter object for the dependent application and generates the corresponding dependency parameters for the main application based on this object. After deploying the dependent application, an initial resource object is created, and the target resource object corresponding to the dependent application is determined within this object. The interface parameters contained in the parameter object are parsed based on the target resource object to obtain the interface identifier. The connection parameters for the main application are constructed based on the dependency parameters and the interface identifier, and the main application's configuration file is updated using these parameters. This achieves parameter binding between the main application and the dependent application, and the updated configuration file enables the main application and the dependent application to work collaboratively in the target runtime environment.

[0067] One embodiment of this specification, upon receiving an environment change request, automatically defines the parameter object of the dependent application, parses the interface parameters contained in the parameter object, and updates the main application's configuration file based on the interface identifier obtained from the parsed interface parameters. This achieves automatic parameter binding between the dependent application and the main application, and the updated configuration file enables the main application and the dependent application to work collaboratively in the target runtime environment. It automates the binding of parameters between the dependent application and the main application, avoiding manual parameter configuration and thus improving parameter configuration efficiency and accuracy.

[0068] This specification provides a parameter processing method, and also relates to a parameter processing apparatus, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0069] Figure 2 A flowchart of a parameter processing method according to an embodiment of this specification is shown, which specifically includes the following steps:

[0070] Step S202: In response to the environment change request, determine the dependent application and the main application associated with the dependent application.

[0071] Specifically, the environment can be the business environment in container technology. The environment change request can carry information about the dependent application and the main application. After the environment change request is parsed and processed, it can realize application deployment, application parameter binding, etc., and deploy the main application in the business environment. Correspondingly, the dependent application can be any application contained in the environment. The dependent application can be middleware such as Redis, or it can be an application. The main application refers to the application that has a dependency relationship with the dependent application. The main application can be a microservice application, an application, etc. The main application can achieve parameter binding between the main application and the dependent application by writing the parameters corresponding to the dependent application in the configuration file.

[0072] Therefore, in container technology, application deployment can lead to changes in the business environment associated with the container platform, and the container platform can receive environment change requests. The environment change request is parsed to obtain the dependent application information and the associated main application information. Then, the dependent application is determined based on the dependent application information, and the main application is determined based on the main application information. This enables subsequent updates to the main application configuration file.

[0073] In practical applications, when deploying a main application in a business environment, the main application typically depends on other applications or middleware to provide services. Parameters obtained from the dependent applications can be written into the main application's configuration file to complete parameter binding between the main application and the dependent applications. Furthermore, in practical applications, applications can often communicate and interact; parameter binding between applications is the foundation for such communication and interaction. The IP address, port, and other information of the dependent applications are written into the main application's configuration file, thereby completing the change in the business environment, i.e., the deployment of the main application.

[0074] Step S204: Generate the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application.

[0075] Specifically, after determining the dependent application and the associated main application in response to the environment change request, the dependency parameters of the main application can be generated based on the parameter object defined by the dependent application. Here, the parameter object refers to the parameter used to represent the attributes of the dependent application. The parameter object can contain name parameters, interface parameters, description parameters, and query parameters. The query parameters include category parameters and tag parameters. The parameter object can be the parameter that the main application needs to use in the dependent application. The parameter object is the exposed parameter of the dependent application. The dependency parameter refers to the parameter generated based on the name parameter contained in the parameter object. The dependency parameter can exist in the form of key-value pairs. The name parameter is the value in the key-value pair. The key in the key-value pair can be generated based on the name parameter and the name information of the dependent application.

[0076] Based on this, after determining the dependent application and the main application associated with the dependent application in response to the environment change request, the parameter object defined by the dependent application is determined, as well as the name parameter contained in the parameter object. Based on the name information of the dependent application and the name parameter, the dependency parameters corresponding to the main application are generated, so that after parsing the parameter object to obtain the interface identifier, the connection parameters can be generated based on the interface identifier and the dependency parameters.

[0077] Furthermore, when defining the parameter object of the dependent application, considering that the parameter object is used for subsequent parameter binding with the main application, in order for the defined parameter object to accurately represent the resource object corresponding to the dependent application, the parameter object needs to contain multiple parameters with different meanings. The specific implementation is as follows:

[0078] Define the name parameter, interface parameter, description parameter, and query parameter corresponding to the dependent application; generate a parameter object of the dependent application based on the name parameter, interface parameter, description parameter, and query parameter; the step of generating the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application includes: determining the name parameter contained in the parameter object defined by the dependent application, and updating the configuration parameters of the main application based on the name parameter to obtain the dependency parameters corresponding to the main application.

[0079] Specifically, the name parameter represents the name or key-value pair of the dependent application. The dependent application can be Redis, and the name parameter can be `key:svc_sentinel_port`, representing the sentinel port. The interface parameter exists in the form of an expression, and the expression corresponding to the interface parameter is used to extract the parameter value from the Kubernetes resource object, that is, to obtain the port information from the Kubernetes resource object. The description parameter represents the text description of the object parameter, which explains the function of the object parameter. The description parameter can be represented by a label, and the description parameter can be the port of the external sentinel service. The query parameter is used to select the target object resource from the created Kubernetes resource object. The query parameter includes category parameters and label parameters, which are used to define the conditions for querying the resource object.

[0080] The configuration parameters of the main application refer to the usage parameters defined for the main application. The configuration parameters can be updated based on the parameter object, which is used to establish parameter connections between the object parameters and the configuration parameters, and to integrate the characteristics of the object parameters into the configuration parameters, thereby enabling the dependent application to establish a parameter connection with the main application. Correspondingly, the dependent parameters are the main application parameters generated based on the configuration parameters and the name parameters contained in the parameter object.

[0081] Based on this, define the name parameters, interface parameters, description parameters, and query parameters corresponding to the dependent application; generate the parameter object of the dependent application based on the name parameters, interface parameters, description parameters, and query parameters; generate the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application, including: determining the name parameters contained in the parameter object defined by the dependent application, and updating the configuration parameters of the main application based on the name parameters to obtain the dependency parameters corresponding to the main application.

[0082] For example, if the dependent application is Redis and the main application is a microservice, define a parameter object for the dependent application. This parameter object contains a name parameter key: `svc_sentinel_port`, an interface parameter `jsonpath`, a description parameter `label`, and query parameters `listOptions`. The main application's configuration parameter can be defined as `redis.sentinel.port`. Combining this with the name parameter key `svc_sentinel_port` in the parameter object, updating the configuration parameter yields the main application's dependent parameter: `redis.sentinel.port = ${svc_sentinel_port}`.

[0083] In summary, we define the name parameters, interface parameters, description parameters, and query parameters of the dependent application, and form a parameter object of the dependent application composed of these parameters. This allows us to accurately determine the connection parameters of the main application based on the parameter object when binding parameters with the main application.

[0084] Step S206: Determine the target resource object corresponding to the dependent application, and parse the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier.

[0085] Specifically, after generating the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application, the target resource object corresponding to the dependent application can be determined. Then, the interface parameters contained in the parameter object are parsed based on the target resource object to obtain the interface identifier. Here, the target resource object refers to the resource corresponding to the parameter object of the dependent application. The dependent application can contain multiple resource objects, and the target resource object is the resource object that matches the category parameter and tag parameter in the parameter object. Interface parameters refer to the parameter expressions contained in the parameter object used for parameter value extraction. The target resource object contains object port parameters, object node port parameters, and object attribute parameters. Correspondingly, the interface identifier refers to the interface information corresponding to the object node port parameter in the target resource object. The interface identifier can be a number or a combination of numbers.

[0086] Based on this, after generating the dependency parameters corresponding to the main application from the parameter objects defined by the dependent application, control resource objects, service resource objects, and container resource objects corresponding to the dependent application are created. These resource objects form a resource object set. The target resource object corresponding to the dependent application is determined from the resource object set based on the category and tag parameters of the dependent application. The interface parameters contained in the parameter objects are then parsed based on the target resource object to obtain the interface identifier.

[0087] In practical applications, after determining the parameter objects of the dependent application, the dependent application can be deployed first in the target runtime environment. After the dependent application is deployed, Kubernetes resources containing various resource object types, such as control resource objects, service resource objects, and container resource objects, are created. Before parsing the parameter objects of the dependent application, the target resource object needs to be selected from the created resource objects based on the query parameters in the parameter objects for parsing the interface parameters in the parameter objects.

[0088] Furthermore, considering that the normal operation of the dependent application requires resource support, resource objects also need to be created after defining the parameter object of the dependent application. Resource objects can have multiple types. To meet the needs of subsequent parameter parsing, multiple types of resource objects can be created to facilitate selection among them. The specific implementation is as follows:

[0089] Create a resource object set containing control resource objects, service resource objects, and container resource objects; select resource objects from the resource object set that match the category parameters and label parameters in the parameter object as the target resource objects corresponding to the dependent application.

[0090] Specifically, control resource objects, service resource objects, and container resource objects are all resources that can be created in a cluster scenario. In a Kubernetes (k8s) scenario, the control resource object is the Deployment, which is the most common controller for stateless applications, supporting operations such as application scaling and rolling updates. The service resource object is the Service, which is a fixed access interface provided by a Pod object that is elastically variable and has a lifecycle, used for service discovery and access. The container resource object is the Pod, which is the smallest unit for running and scheduling containers. A single Pod can run multiple containers simultaneously. The category parameter in the parameter object is used to represent the resource type, and the tag parameter is used to filter resource objects. That is, after the resource type is determined, resources that meet the filtering conditions are filtered based on the tag parameter. The filtering conditions can be containing specific tags, for example, filtering resource objects containing the tag app.orcastack.io / service-type:"sentinel" as target resource objects.

[0091] Based on this, control resource objects, service resource objects, and container resource objects are created, forming a resource object set. The category parameters and tag parameters contained in the parameter object are determined. Resource objects matching the category parameters in the parameter object are selected from the resource object set. Then, resource objects matching the preset tags corresponding to the tag parameters are selected from the resource objects matching the category parameters in the parameter object, and these are used as the target resource objects for the dependent application.

[0092] Continuing with the previous example, we create resource objects such as Deployment, Service, and Pod in the cluster. The query parameters in the dependent application include `kind` and `labels`, where `kind` is the Service type and `labels` is `app.orcastack.io / service-type:"sentinel"`. Then, among the created resource objects, we select the Service resource object that matches the Service type. Based on the label `app.orcastack.io / service-type:"sentinel"`, we select the resource object that matches the label from the Service resource objects that match the Service type as the target resource object.

[0093] In summary, resource objects that match the category and tag parameters in the parameter objects are selected from the set of resource objects containing control resource objects, service resource objects, and container resource objects, and these are used as the target resource objects for the dependent application. This ensures a high degree of matching between the selected resource objects and the parameter objects of the dependent application, facilitating subsequent parameter parsing.

[0094] Furthermore, considering that the parameter object contains many parameters, including type parameters and name parameters, and not every parameter can be used for subsequent parameter parsing, after determining the target resource object, it is necessary to perform implementation parameter matching in the target resource object based on the interface parameters contained in the parameter object. The specific implementation is as follows:

[0095] Determine the node interface parameters from the interface parameters contained in the parameter object, and determine the object port parameters corresponding to the node interface parameters in the target resource object; use the parameter value of the object port parameters as the interface identifier.

[0096] Specifically, the interface parameters exist in the form of expressions. The interface parameters include port parameters, name parameters, and node interface parameters. The expression corresponding to the interface parameter can be {.spec.ports[? (@.name=="tcp-sentinel")].nodePort}, where the node interface parameter nodePort can be used as the parsed parameter. The port number corresponding to nodePort in the target resource object is used as the parameter value of the object port parameter, that is, the interface identifier.

[0097] Based on this, the node interface parameters are determined from the interface parameters contained in the parameter object, and the corresponding object port parameters are determined in the target resource object. The parameter value of the object port parameter is used as the interface identifier. Alternatively, the port parameter `ports` is determined from the interface parameters contained in the parameter object, and the corresponding target port parameter is determined in the target resource object. The parameter value of the target port parameter is used as the interface identifier.

[0098] Continuing with the previous example, when parsing the interface parameters contained in the parameter object, since the expression for the interface parameter, {.spec.ports[?(@.name=="tcp-sentinel")].nodePort}, contains many parameters, all of which can be parsed as objects, and the parsing result can be used as the interface identifier. The parameters nodePort, spec, etc., in the expression are matched with spec:type:NodePort, selector:app.kubernetes.io / name:redis, ports:-port:80, name:"tcp-sentinel", nodePort:30008, etc., in the target resource object, and 30008 is determined to be the interface identifier.

[0099] In summary, by using parameter matching, the object port parameter corresponding to the node interface parameter is determined in the target resource object, and the parameter value of the object port parameter is used as the interface identifier, thereby improving the accuracy of parameter matching.

[0100] Furthermore, considering that at least one interface identifier is obtained after parsing the parameter object, to facilitate the main application's subsequent retrieval of the interface identifier, it can be encrypted and stored after parsing. If a large number of interface identifiers are obtained, each interface identifier can also be stored in an encrypted manner in a parameter file, so that the main application can securely retrieve parameters from the parameter file later. The specific implementation is as follows:

[0101] Create a parameter file corresponding to the dependent application and store the interface identifier in the parameter file; when the parameters to be parsed corresponding to the dependent application are parsed, generate status parameters and store them in the parameter file, wherein the status parameters stored in the parameter file are used to characterize the available status of the interface identifier.

[0102] Specifically, the parameter file is used to store the interface identifier obtained by parsing the parameter object. The interface identifier can be stored in the parameter file according to a preset parameter storage format. The parameter file can be a secret file. The parameter to be parsed is the parameter that needs to be parsed in at least one participating object corresponding to the dependent application. The status parameter is used to indicate the availability status of the interface identifier after it is stored in the parameter file. A status parameter of "true" means that the parameter is available. Conversely, a status parameter of "false", or the absence of a status parameter of "true" in the parameter file, means that the parameter is unavailable.

[0103] Based on this, a parameter file corresponding to the dependent application is created. The interface identifier is converted to a storage format and stored in the parameter file. When the parameters to be parsed for the dependent application are successfully parsed, status parameters are generated and stored in the parameter file. The status parameters stored in the parameter file represent the availability status of the interface identifier. If no status parameters are stored in the parameter file, it indicates that the interface identifier stored in the parameter file is in an unavailable state.

[0104] Following the previous example, after parsing and obtaining the parameter value 30008, a storable parameter can be generated based on this value: {"svc_sentinel_port":"30008"}, and stored in the secret file using base64 encryption. After all the parameters to be parsed for the dependent application have been parsed, a status parameter: the var-parsed:"true" tag, is stored in the secret file to indicate that parsing is complete and the parameters stored in the secret file are in an available state.

[0105] In summary, encrypting the interface identifier improves the security of the stored interface identifier; storing status parameters in the parameter file marks the readable state of the parameter file, thus facilitating subsequent parameter reading.

[0106] Step S208: Construct the connection parameters of the main application based on the dependency parameters and the interface identifier, and update the configuration file of the main application using the connection parameters; wherein, the updated configuration file enables the main application and the dependent application to work together in the target runtime environment.

[0107] Specifically, after identifying the target resource object corresponding to the dependent application and parsing the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier, the connection parameters of the main application can be constructed based on the dependency parameters and the interface identifier. The connection parameters are then used to update the main application's configuration file. The updated configuration file enables the main application and the dependent application to work collaboratively in the target runtime environment. The connection parameters are used to establish business connections with the dependent application. These parameters include those obtained by parsing the interface parameters corresponding to the dependent application, used to achieve parameter binding between the main application and the dependent application. The main application's configuration file provides configuration parameters during deployment. When the main application and the dependent application work collaboratively, the main application can communicate and interact with the dependent application.

[0108] Based on this, after determining the target resource object corresponding to the dependent application and parsing the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier, the name parameter in the dependency parameters is updated based on the interface identifier. That is, the name parameter in the dependency parameters is replaced with the interface identifier, thus completing the construction of the main application's connection parameters based on the dependency parameters and the interface identifier. The connection parameters are then used to update the main application's configuration file, allowing the connection parameters to be stored there. The updated configuration file enables the main application and the dependent application to work collaboratively in the target runtime environment. The main application's operation can depend on the dependent application, and communication and interaction between the main application and the dependent application can be achieved while they are working.

[0109] Furthermore, after defining the parameter object of the dependent application, the dependent application can provide services after deployment. Before binding parameters between the dependent application and the main application, the dependent application can be deployed first, which facilitates parameter parsing of the parameter object defined by the dependent application. After the connection parameters are written in the main application, it can also provide services to the outside world after deployment. The specific implementation is as follows:

[0110] Based on the parameter object, the dependent application is deployed to the target runtime environment; after the step of updating the configuration file of the main application using the connection parameters is executed, the method further includes: deploying the main application to the target runtime environment based on the updated configuration file.

[0111] Based on this, after defining the parameter object corresponding to the dependent application, the dependent application can be deployed to the target runtime environment based on the parameter object. The dependent application, running in the target runtime environment, can provide corresponding services. Corresponding to the deployment of the dependent application, after updating the main application's configuration file using connection parameters, the parameter binding between the dependent application and the main application is completed. The main application can then be deployed to the target runtime environment based on the updated configuration file, enabling it to run and provide corresponding services. When the main application needs to interact or communicate with the dependent application, since the dependent application has already been parameter-bound with the main application, it can interact or communicate with the dependent application. Updating the main application's configuration file using connection parameters completes the parameter binding between the dependent application and the main application.

[0112] Using the previous example, the dependent application is Redis middleware, and the main application is a microservice. When the main application needs to call Redis middleware, since both the dependent application and the main application have been deployed and parameter binding has been completed between them, the main application and the dependent application can work together to provide services.

[0113] In summary, by deploying the dependent application and then deploying the main application after updating its configuration file based on the interface identifier, the main application and the dependent application can work together to provide services.

[0114] Furthermore, when parsing the interface parameters contained in the parameter object based on the target resource object, it actually involves matching the interface parameters with the target resource object. After obtaining the interface identifier, the dependency parameters can be updated based on the interface identifier. The name parameter in the dependency parameters is treated as an unknown and replaced with the interface identifier. The specific implementation is as follows:

[0115] Update the name parameter in the dependency parameters to the interface identifier, and use the updated dependency parameters as the connection parameters of the main application.

[0116] Therefore, the dependency parameters include a name parameter, which is treated as an unknown. This name parameter can be replaced with the interface identifier; that is, the unknown is updated to the interface identifier. The updated dependency parameters then become the connection parameters for the main application, containing the interface identifier and the corresponding configuration parameters.

[0117] Continuing with the previous example, the main application's dependency parameter is redis.sentinel.port = ${svc_sentinel_port}, and the interface identifier is 30008. The storage format of the interface identifier in the parameter file is {"svc_sentinel_port":"30008"}. You can replace "${svc_sentinel_port}" in the dependency parameter redis.sentinel.port = ${svc_sentinel_port} with the interface identifier 30008 to obtain the main application's connection parameter redis.sentinel.port = 30008.

[0118] In summary, updating the name parameter in the dependency parameters to the interface identifier allows the main application's dependency parameters to be updated based on the interface identifier corresponding to the dependent application, thereby improving the accuracy of parameter updates.

[0119] Furthermore, after parsing and obtaining the interface identifier, it can be stored in an encrypted manner to ensure data security. Considering that the interface identifier obtained after parsing the parameter object of the dependent application is stored in an encrypted manner in the parameter file, decryption is also required when reading the interface identifier from the parameter file. The specific implementation is as follows:

[0120] The interface identifier is encrypted; a parameter file corresponding to the dependent application is created, and the encrypted interface identifier is stored in the parameter file; before the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier is executed, the method further includes: reading the encrypted interface identifier from the parameter file and decrypting it to obtain the interface identifier.

[0121] Therefore, base64 encryption can be used to encrypt the interface identifier. A parameter file corresponding to the dependent application is created, and the encrypted interface identifier is stored in the parameter file in a preset storage format. Before constructing the main application's connection parameters based on the dependency parameters and the interface identifier, the encrypted interface identifier is read from the parameter file and decrypted using the appropriate decryption method to obtain the interface identifier. Then, the main application's connection parameters are constructed based on the dependency parameters and the decrypted interface identifier.

[0122] In summary, after parsing and obtaining the interface identifier, the interface identifier is encrypted and stored in the parameter file. Correspondingly, when retrieving the interface identifier from the parameter file, it is necessary to decrypt it to obtain the interface identifier. Then, the connection parameters of the main application are constructed based on the dependency parameters and the decrypted interface identifier. Through encryption and decryption, the data security of the interface identifier is ensured.

[0123] Furthermore, considering that there is at least one parameter object corresponding to the dependent application, and at least one parameter to be parsed for each dependent application, and if not all parameters to be parsed for the dependent application are parsed and stored in the parameter file, then parameters cannot be read from the parameter file. Therefore, the availability of parameters in the parameter file can be marked by storing status parameters in the parameter file, as implemented below:

[0124] If the availability status of the interface identifier in the parameter file is determined to be that the parameter is available, the interface identifier is read from the parameter file; and the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier is executed.

[0125] Specifically, the availability status indicates whether the interface identifier stored in the parameter file can be read. The availability status can be either parameter available or parameter unavailable. If all the parameters to be parsed for the dependent application have been parsed and stored in the parameter file, the availability status of the interface identifier in the parameter file is parameter available. Conversely, if not all the parameters to be parsed for the dependent application have been parsed or not stored in the parameter file, the availability status of the interface identifier in the parameter file is parameter unavailable.

[0126] Based on this, before reading the interface identifier from the parameter file, it is determined whether the interface identifier stored in the parameter file is in an available state. If the interface identifier in the parameter file is in an available state, it means that all the parameters to be parsed for the dependent application have been parsed and stored in the parameter file. At this time, the interface identifier stored in the parameter file can be read, and the main application's configuration file can be updated. If the interface identifier in the parameter file is in an unavailable state, it means that not all the parameters to be parsed for the dependent application have been parsed or not all of them are stored in the parameter file. At this time, the interface identifier stored in the parameter file cannot be read. It is necessary to wait until the interface identifier in the parameter file is in an available state before reading the interface identifier from the parameter file. Then, based on the dependency parameters and the read interface identifier, the connection parameters of the main application are constructed to realize the parameter binding between the main application and the dependent application.

[0127] In practical applications, after parsing all the parameters to be parsed for the dependent application to obtain the interface identifier and storing it in the parameter file, the availability status of the interface identifier in the parameter file can be marked by storing status parameters in the parameter file. Then, before reading the interface identifier in the parameter file, it can be determined whether there is a status parameter in the parameter file. If it exists, it means that the interface identifier in the parameter file is readable; if it does not exist, it means that the interface parameter in the parameter file is not readable.

[0128] In addition, the readability of the interface identifier stored in the parameter file can be determined by checking the storage status of the status parameter. That is, if the status parameter contains "true", it means that the interface identifier stored in the parameter file is readable; conversely, if the status parameter does not contain "true" or contains "false", it means that the interface identifier stored in the parameter file is not readable.

[0129] Continuing with the previous example, after all the parameters to be parsed for the dependent application have been parsed and encrypted and stored in the parameter file, a status parameter will be stored in the parameter file to indicate that all the parameters to be parsed for the dependent application have been parsed and stored in the parameter file. The status parameter can be var-parsed:"true", and it acts as a label. When the main application updates the configuration file, it needs to read the interface identifier stored in the parameter file: {"svc_sentinel_port":"30008"}. Before reading the interface identifier, it checks whether the status parameter is stored in the parameter file. If the status parameter var-parsed:"true" is stored in the parameter file, it means that the interface identifier in the parameter file is readable. If the status parameter is not present in the parameter file, it means that the interface identifier in the parameter file is not readable.

[0130] In summary, one embodiment of this specification, upon receiving an environment change request, automatically defines the parameter object of the dependent application, parses the interface parameters contained in the parameter object, and updates the main application's configuration file based on the interface identifier obtained from parsing the interface parameters. This achieves automatic parameter binding between the dependent application and the main application, and the updated configuration file enables the main application and the dependent application to work collaboratively in the target runtime environment. It automates the binding of parameters between the dependent application and the main application, avoiding manual parameter configuration and thus improving parameter configuration efficiency and accuracy.

[0131] The following is in conjunction with the appendix Figure 3 Taking the parameter processing method provided in this specification as an example in the application of parameter processing in microservice applications, the parameter processing method will be further explained. Figure 3 This specification illustrates a parameter processing method for microservice application parameter processing according to an embodiment of the present invention, which specifically includes the following steps:

[0132] Step S302: Determine the dependent application and the main application associated with the dependent application.

[0133] In container technology, applications can communicate and interact based on parameter binding. For example, if 50 applications are deployed in environment A, and you want to replicate environment B and deploy the same 50 applications in environment A within environment B, then the 50 applications in environment B need to establish a connection between them through parameter binding to complete the environment replication. Parameter binding between any two applications can be achieved using the parameter processing method provided in this embodiment. When performing parameter binding between applications, the dependent application and the main application are first determined. In practical applications, the dependent application can be middleware such as Redis, and the main application can be a microservice, etc.

[0134] Step S304: Define the name parameter, interface parameter, description parameter and query parameter corresponding to the dependent application to form the exposure parameters of the dependent application.

[0135] Define the exposed parameters of the dependent application (Redis). The exposed parameters can include: name parameter (key), interface parameter (jsonpath), description parameter (label), and query parameter (listOptions), etc.

[0136] Step S306: Update the usage parameters of the main application based on the name parameters included in the exposed parameters to obtain the dependency parameters corresponding to the main application.

[0137] The dependency parameters of the main application are defined based on the dependent application Redis and the name parameter (key:svc_sentinel_port): redis.sentinel.port = ${svc_sentinel_port}, where redis.sentinel.port is the parameter used.

[0138] Step S308: Deploy the dependent application to the target runtime environment based on the exposed parameters.

[0139] Step S310: Create a resource object set containing control and service types.

[0140] After the dependent application is deployed, various types of Kubernetes resources such as control and service are created.

[0141] Step S312: Select the resource object that matches the category parameter and label parameter in the exposure parameters from the resource object set, and use it as the target resource object corresponding to the dependent application.

[0142] In Kubernetes resources, select the Server resource object that matches the kind and labels in the query parameters (listOptions) as the target resource object.

[0143] Step S314: Determine the node interface parameters from the interface parameters included in the exposed parameters, and determine the object port parameters corresponding to the node interface parameters in the target resource object, and use the parameter value of the object port parameters as the interface identifier.

[0144] Based on the expression corresponding to the interface parameter (jsonpath) in the exposed parameters and the Server resource object, the parameter value 30007 is obtained, which is the interface identifier.

[0145] Step S316: Create a parameter file corresponding to the dependent application and encrypt and store the interface identifier in the parameter file.

[0146] Step S318: If the parameters to be parsed corresponding to the dependent application are parsed, generate status parameters and store them in the parameter file. The status parameters stored in the parameter file are used to characterize the available status of the interface identifier.

[0147] Create a secret file, encrypt and store the parsed parameters in the secret file, and record the parameter parsing status by adding status tags.

[0148] Step S320: If the available status of the interface identifier in the parameter file is determined to be that the parameter is available, the interface identifier is read from the parameter file.

[0149] Step S322: Construct the connection parameters of the main application based on the dependency parameters and interface identifiers, and update the configuration file of the main application using the connection parameters.

[0150] Once the parameter parsing of the dependent application is completed based on the status label, the interface identifier stored in the secret file is read and stored in the main application's configuration file in the form of redis.sentinel.port=30007.

[0151] Step S324: Deploy the main application to the target runtime environment based on the updated configuration file. The updated configuration file enables the main application and the dependent applications to work together in the target runtime environment.

[0152] In practical applications, the parameter binding process between the dependent application and the main application can be found in [reference needed]. Figure 4 . Figure 4 This is a flowchart illustrating the parameter processing method provided in one embodiment of this specification. Figure 4 As shown, parameter binding between the dependent application and the main application can be achieved through the following three steps:

[0153] Step 1: Define the exposed parameters of the dependent application and the usage parameters of the main application. The dependent application can be Redis, and the main application can be a microservice. The exposed parameters are defined as follows: Figure 5 As shown in (a).

[0154] The parameter can be defined as: redis.sentinel.port = ${svc_sentinel_port}.

[0155] Step two: After defining the exposure parameters of the dependent application, deploy the dependent application and parse the exposure parameters. Before parsing the exposure parameters, create multiple Kubernetes resources in the cluster, such as Service objects, which may include the Service objects associated with listOptions in step one. Filter objects of type Service using the kind and labels in listOptions. Service objects are shown below. Figure 5 As shown in (b).

[0156] The `jsonpath` parameter from the exposed parameters is used for parsing. The `nodePort:30007` parameter is obtained by parsing the `Service` object. A secret file is created, and the parsed parameter is saved in the format `{"svc_sentinel_port":"30007"}`. The parameter can be stored using base64 encryption. After all parameters that need parsing are completed, the `var-parsed:"true"` tag is added to indicate that parsing is complete. The main application waits for the exposed parameters of the dependent application to be parsed, and determines whether parsing is complete by checking if the `var-parsed:"true"` tag exists in the secret file.

[0157] Step 3: After confirming the presence of the `var-parsed:"true"` tag in the secret file, read parameter 30007 from the secret file and combine it with the parameter `redis.sentinel.port = ${svc_sentinel_port}`, storing it in the main application's configuration file as `redis.sentinel.port = 30007`. This achieves parameter binding between the dependent application and the main application.

[0158] In summary, one embodiment of this specification, upon receiving an environment change request, automatically defines the exposed parameters of the dependent application, parses the interface parameters contained within the exposed parameters, and updates the main application's configuration file based on the interface identifier obtained from the parsed interface parameters. This achieves automatic parameter binding between the dependent application and the main application, and the updated configuration file enables the main application and the dependent application to work collaboratively in the target runtime environment. It automates the binding of parameters between the dependent application and the main application, avoiding manual parameter configuration and thus improving parameter configuration efficiency and accuracy.

[0159] Corresponding to the above method embodiments, this specification also provides embodiments of parameter processing devices. Figure 6 A schematic diagram of a parameter processing device according to an embodiment of this specification is shown. Figure 6 As shown, the device includes:

[0160] The determination module 602 is configured to determine the dependent application and the main application associated with the dependent application in response to an environment change request.

[0161] The generation module 604 is configured to generate the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application.

[0162] The parsing module 606 is configured to determine the target resource object corresponding to the dependent application, and parse the interface parameters contained in the parameter object based on the target resource object to obtain the interface identifier;

[0163] The update module 608 is configured to construct the connection parameters of the main application based on the dependency parameters and the interface identifier, and update the configuration file of the main application using the connection parameters; wherein the updated configuration file enables the main application and the dependent application to work together in the target runtime environment.

[0164] In an optional embodiment, the generation module 604 is further configured to:

[0165] Define the name parameter, interface parameter, description parameter, and query parameter corresponding to the dependent application; generate a parameter object of the dependent application based on the name parameter, interface parameter, description parameter, and query parameter; the step of generating the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application includes: determining the name parameter contained in the parameter object defined by the dependent application, and updating the configuration parameters of the main application based on the name parameter to obtain the dependency parameters corresponding to the main application.

[0166] In an optional embodiment, the parsing module 606 is further configured to:

[0167] Based on the parameter object, the dependent application is deployed to the target runtime environment; after the step of updating the configuration file of the main application using the connection parameters is executed, the method further includes: deploying the main application to the target runtime environment based on the updated configuration file.

[0168] In an optional embodiment, the parsing module 606 is further configured to:

[0169] Create a resource object set containing control resource objects, service resource objects, and container resource objects; select resource objects from the resource object set that match the category parameters and label parameters in the parameter object as the target resource objects corresponding to the dependent application.

[0170] In an optional embodiment, the parsing module 606 is further configured to:

[0171] Determine the node interface parameters from the interface parameters contained in the parameter object, and determine the object port parameters corresponding to the node interface parameters in the target resource object; use the parameter value of the object port parameters as the interface identifier.

[0172] In an optional embodiment, the parsing module 606 is further configured to:

[0173] Update the name parameter in the dependency parameters to the interface identifier, and use the updated dependency parameters as the connection parameters of the main application.

[0174] In an optional embodiment, the update module 608 is further configured to:

[0175] Create a parameter file corresponding to the dependent application and store the interface identifier in the parameter file; when the parameters to be parsed corresponding to the dependent application are parsed, generate status parameters and store them in the parameter file, wherein the status parameters stored in the parameter file are used to characterize the available status of the interface identifier.

[0176] In an optional embodiment, the update module 608 is further configured to:

[0177] The interface identifier is encrypted; a parameter file corresponding to the dependent application is created, and the encrypted interface identifier is stored in the parameter file; before the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier is executed, the method further includes: reading the encrypted interface identifier from the parameter file and decrypting it to obtain the interface identifier.

[0178] In an optional embodiment, the update module 608 is further configured to:

[0179] If the availability status of the interface identifier in the parameter file is determined to be that the parameter is available, the interface identifier is read from the parameter file; and the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier is executed.

[0180] In summary, one embodiment of this specification, upon receiving an environment change request, automatically defines the parameter object of the dependent application, parses the interface parameters contained in the parameter object, and updates the main application's configuration file based on the interface identifier obtained from parsing the interface parameters. This achieves automatic parameter binding between the dependent application and the main application, and the updated configuration file enables the main application and the dependent application to work collaboratively in the target runtime environment. It automates the binding of parameters between the dependent application and the main application, avoiding manual parameter configuration and thus improving parameter configuration efficiency and accuracy.

[0181] The above is a schematic scheme of a parameter processing device according to this embodiment. It should be noted that the technical solution of this parameter processing device and the technical solution of the parameter processing method described above belong to the same concept. For details not described in detail in the technical solution of the parameter processing device, please refer to the description of the technical solution of the parameter processing method described above.

[0182] Figure 7 A structural block diagram of a computing device 700 according to an embodiment of this specification is shown. The components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0183] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 740 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0184] In one embodiment of this specification, the above-described components of the computing device 700 and Figure 7 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 7The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0185] The computing device 700 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 700 can also be a mobile or stationary server.

[0186] The processor 720 is used to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above parameter processing method.

[0187] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the parameter processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the parameter processing method described above.

[0188] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the above-described parameter processing method.

[0189] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the parameter processing method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the parameter processing method described above.

[0190] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0191] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0192] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this specification is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this specification. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this specification.

[0193] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0194] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. These embodiments have been selected and specifically described in this specification to better explain the principles and practical applications of this specification, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A parameter processing method, characterized in that, Applied to container platforms, including: In response to an environment change request, the dependent application and the main application associated with the dependent application are determined, wherein the dependent application is any application in the business environment, and the main application is an application that has a dependency relationship with the dependent application. The main application generates dependency parameters based on the parameter object defined by the dependent application. The parameter object represents the attribute of the dependent application and includes name parameters, interface parameters, description parameters, and query parameters. The dependency parameters are generated based on the name parameters. The target resource object corresponding to the dependent application is determined, and the interface parameters are parsed based on the target resource object to obtain the interface identifier, wherein the interface parameters include port parameters, name parameters and node interface parameters; The connection parameters of the main application are constructed based on the dependency parameters and the interface identifier, and the configuration file of the main application is updated using the connection parameters; The updated configuration file enables the main application and the dependent application to work together in the target runtime environment.

2. The method according to claim 1, characterized in that, Before the step of generating the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application is executed, the method further includes: Define the name parameters, interface parameters, description parameters, and query parameters corresponding to the dependent application; The parameter object of the dependent application is generated based on the name parameter, the interface parameter, the description parameter, and the query parameter; The process of generating the dependency parameters corresponding to the main application based on the parameter object defined by the dependent application includes: The name parameter included in the parameter object defined by the dependent application is determined, and the configuration parameters of the main application are updated based on the name parameter to obtain the dependency parameters corresponding to the main application, wherein the configuration parameters of the main application are the usage parameters corresponding to the main application.

3. The method according to claim 1, characterized in that, Before the step of determining the target resource object corresponding to the dependent application is executed, the method further includes: Based on the parameter object, the dependent application is deployed to the target runtime environment; After the step of updating the main application's configuration file using the connection parameters is executed, the method further includes: The main application is deployed to the target runtime environment based on the updated configuration file.

4. The method according to claim 1, characterized in that, Determining the target resource object corresponding to the dependent application includes: Create a set of resource objects that includes control resource objects, service resource objects, and container resource objects; Select the resource object that matches the category parameter and tag parameter in the query parameters from the set of resource objects, and use it as the target resource object corresponding to the dependent application.

5. The method according to claim 1, characterized in that, The step of parsing the interface parameters based on the target resource object to obtain the interface identifier includes: Determine the node interface parameters from the interface parameters contained in the parameter object, and determine the object port parameters corresponding to the node interface parameters in the target resource object; The parameter value of the object port parameter is used as the interface identifier.

6. The method according to claim 2, characterized in that, The process of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier includes: Update the name parameter in the dependency parameters to the interface identifier, and use the updated dependency parameters as the connection parameters of the main application.

7. The method according to claim 1, characterized in that, After the step of parsing the interface parameters based on the target resource object to obtain the interface identifier is executed, the method further includes: Create a parameter file corresponding to the dependent application, and store the interface identifier in the parameter file; Once the parameters to be parsed corresponding to the dependent application are parsed, status parameters are generated and stored in the parameter file. The status parameters stored in the parameter file are used to characterize the availability status of the interface identifier. The parameters to be parsed are parameters that need to be parsed in at least one parameter object corresponding to the dependent application.

8. The method according to claim 7, characterized in that, The step of creating the parameter file corresponding to the dependent application and storing the interface identifier in the parameter file includes: The interface identifier is encrypted; Create a parameter file corresponding to the dependent application, and store the encrypted interface identifier in the parameter file; Before the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier is executed, the following steps are also included: The encrypted interface identifier is read from the parameter file and decrypted to obtain the interface identifier.

9. The method according to claim 7, characterized in that, Before the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier is executed, the following steps are also included: If the availability status of the interface identifier in the parameter file is determined to be that the parameter is available, the interface identifier is read from the parameter file; Perform the step of constructing the connection parameters of the main application based on the dependency parameters and the interface identifier.

10. A parameter processing device, characterized in that, include: The determination module is configured to determine the dependent application and the main application associated with the dependent application in response to an environment change request, wherein the dependent application is any application in the business environment and the main application is an application that has a dependency relationship with the dependent application. The generation module is configured to generate dependency parameters corresponding to the main application based on the parameter object defined by the dependent application. The parameter object represents the attribute of the dependent application and includes name parameters, interface parameters, description parameters, and query parameters. The dependency parameters are parameters generated based on the name parameters. The parsing module is configured to determine the target resource object corresponding to the dependent application, and parse the interface parameters based on the target resource object to obtain the interface identifier, wherein the interface parameters include port parameters, name parameters and node interface parameters; The update module is configured to construct the connection parameters of the main application based on the dependency parameters and the interface identifier, and update the configuration file of the main application using the connection parameters; wherein the updated configuration file enables the main application and the dependent application to work together in the target runtime environment.

11. A computing device, characterized in that, It includes a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the steps of the parameter processing method according to any one of claims 1 to 9.

12. A computer-readable storage medium storing computer instructions, characterized in that, When executed by the processor, this instruction implements the steps of the parameter processing method according to any one of claims 1 to 9.

Images