Parameter arrangement method and device and computer readable medium

Abstract

The invention provides a parameter arrangement method which comprises the steps that user attributes in a development configuration file of a cloud native application are obtained, the user attributes comprise public attributes, and the public attributes are used for indicating attributes allowed to be modified through an operation and maintenance configuration file in the deployment process of the cloud native application; in a cloud native application deployment process, replacing a parameter value of a matched public attribute in user attributes by using a parameter value of an application dynamic attribute in a preset operation and maintenance configuration file; generating user attribute configuration according to the replaced parameter value of the matched public attribute; and updating an original arrangement file of the cloud native application according to the user attribute configuration to obtain an updated arrangement file. The invention further provides parameter arrangement equipment and a computer readable medium.

Description

Technical Field

[0001] The present disclosure relates to the technical field of cloud environment parameter orchestration, and in particular to a parameter orchestration method, device, and computer-readable medium. Background Art

[0002] When deploying applications in a cloud environment, parameter orchestration is required. However, the parameter orchestration methods used in related technologies are not suitable for operations and maintenance personnel. They struggle to understand the relationships between components in the system, have poor application customization capabilities, and lack the ability to deploy complex cloud-native microservice application systems. Summary of the Invention

[0003] The present disclosure provides a parameter programming method, device, and computer-readable medium.

[0004] In a first aspect, embodiments of the present disclosure provide a parameter orchestration method, comprising: obtaining user attributes from a development configuration file of a cloud-native application, wherein the user attributes include public attributes, and the public attributes are used to indicate attributes that can be modified via an operations configuration file during the deployment of the cloud-native application; during the deployment of the cloud-native application, replacing the parameter values ​​of matching public attributes in the user attributes with parameter values ​​of application dynamic attributes in a preset operations configuration file; generating a user attribute configuration based on the replaced parameter values ​​of the matching public attributes; and updating the original orchestration file of the cloud-native application based on the user attribute configuration to obtain an updated orchestration file.

[0005] In a second aspect, an embodiment of the present disclosure provides a parameter programming device, which includes a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements any one of the parameter programming methods of the embodiments of the present disclosure.

[0006] In a third aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, and when the computer program is executed by a processor, any parameter arrangement method of the embodiment of the present disclosure is implemented.

[0007] It can be seen that according to the embodiment of the present disclosure, some of the default parameters in the original application blueprint are replaced by the corresponding parameters in the development configuration file defined by the application developer, and some other default parameters are actually replaced by the corresponding parameters in the operation and maintenance configuration file defined by the operation and maintenance personnel, that is, the application developer and the operation and maintenance personnel can adaptively orchestrate the parameters they are concerned about respectively. Therefore, the embodiment of the present disclosure can "decouple" the originally complex relationship in the cloud native parameter orchestration according to the principle of different concerns of different roles (application developers, operation and maintenance personnel) without changing the original cloud platform. Each role can only use the corresponding orchestration file to focus on its own content, and different roles can do their work more focused and professionally; thereby solving the problems of poor application customization capabilities in complex cloud native application systems, lack of complex cloud native microservice application system deployment capabilities, and poor portability of microservice systems between multi-cloud platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the accompanying drawings of the embodiments of the present disclosure:

[0009] Figure 1 This diagram shows the relationship between container orchestration controllers in a container orchestration platform in some scenarios.

[0010] Figure 2 A schematic diagram of the cloud-native application blueprint;

[0011] Figure 3 Schematic diagram of the instantiation process of a cloud-native application blueprint;

[0012] Figure 4 A flow chart of a parameter arrangement method provided in an embodiment of the present disclosure;

[0013] Figure 5 A flowchart of processing a macro function provided by an embodiment of the present disclosure;

[0014] Figure 6 An architectural diagram of the parameter arrangement method provided in an embodiment of the present disclosure;

[0015] Figure 7 A schematic diagram illustrating the relationship between the various participants in the parameter arrangement method provided in an embodiment of the present disclosure;

[0016] Figure 8 A schematic diagram of the system framework for parameter arrangement provided in an embodiment of the present disclosure;

[0017] Figure 9 A flowchart of editing a development configuration file provided in an embodiment of the present disclosure;

[0018] Figure 10 A flowchart for defining an operation and maintenance configuration file provided in an embodiment of the present disclosure;

[0019] Figure 11 A schematic diagram of the processing flow of cloud native application attribute replacement and customization capabilities provided by an embodiment of the present disclosure;

[0020] Figure 12 A flowchart of parameter orchestration of a cloud-native application provided for an exemplary embodiment of the present disclosure;

[0021] Figure 13 A schematic diagram of a process flow for using a development configuration file to assist cloud-native applications in using technical services provided in an embodiment of the present disclosure;

[0022] Figure 14 A schematic diagram of the processing process of the delivery strategy provided in the embodiment of the present disclosure;

[0023] Figure 15 A block diagram of a parameter arrangement device provided in an embodiment of the present disclosure;

[0024] Figure 16 A block diagram of an electronic device provided for an embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] To enable those skilled in the art to better understand the technical solutions of the present disclosure, the parameter programming method, device, and computer-readable medium provided by the embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0026] The present disclosure will be described more fully hereinafter with reference to the accompanying drawings, but the illustrated embodiments may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that the present disclosure will be thorough and complete and will fully understand the scope of the present disclosure to those skilled in the art.

[0027] The accompanying drawings of the embodiments of the present disclosure are used to provide a further understanding of the embodiments of the present disclosure and constitute a part of the specification. Together with the detailed embodiments, they are used to explain the present disclosure and do not constitute a limitation of the present disclosure. The above and other features and advantages will become more apparent to those skilled in the art by describing the detailed embodiments with reference to the accompanying drawings.

[0028] The present disclosure may be described with reference to plan views and / or cross-sectional views by way of ideal schematic views of the present disclosure. Therefore, the exemplary illustrations may be modified according to manufacturing techniques and / or tolerances.

[0029] In the absence of conflict, the various embodiments of the present disclosure and the various features therein may be combined with each other.

[0030] The terms used in this disclosure are only used to describe specific embodiments and are not intended to limit the disclosure. As used in this disclosure, the term "and / or" includes any and all combinations of one or more related enumerated items. As used in this disclosure, the singular forms "a" and "the" are also intended to include plural forms, unless the context clearly indicates otherwise. As used in this disclosure, the terms "comprising" and "made of" specify the presence of features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof.

[0031] Unless otherwise defined, all terms (including technical and scientific terms) used in this disclosure have the same meanings as those commonly understood by those skilled in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning unless expressly defined in this disclosure.

[0032] The present disclosure is not limited to the embodiments shown in the accompanying drawings. In the absence of conflict, the embodiments and features in the embodiments of the present disclosure may be combined with each other in any manner. Therefore, the specific configurations and processes shown by way of example in the accompanying drawings are illustrative and are not intended to be limiting.

[0033] With the continuous development of internet technology and the diversification of application scenarios, application architecture design is becoming increasingly complex. Application architecture design can include, for example, monolithic architecture and composite architecture. Monolithic architecture is a traditional application architecture characterized by developing, deploying, and running the application as a whole. Composite architecture, on the other hand, decomposes the application into standard components, which are then assembled into a complete application.

[0034] In monolithic applications, development, testing, delivery, and deployment are all focused on a single component. Functional modules are coupled and deployed uniformly, without the concept of "orchestration." In cloud environments (especially cloud-native technologies), microservices and containerization are widely used. While these technologies offer significant advantages in agility and portability, they also introduce new challenges to application delivery and operations.

[0035] To address dependency management, service discovery, resource management, and high availability issues among the numerous small services that are split during the migration from a monolithic architecture to a microservice system, cloud environment parameter orchestration is required. Parameter orchestration generally involves the following three aspects: resource orchestration, workload orchestration, and service orchestration. Resource orchestration is responsible for resource allocation, such as limiting available resources within a tenant. The scheduler can select specific scheduling strategies based on different resources. Workload orchestration is responsible for sharing workloads between resources. For example, the open source container orchestration platform (Kubernetes, K8s) schedules container packages (Pods) to appropriate worker nodes through different controllers and manages their lifecycles. Service orchestration is responsible for service discovery and high availability. For example, Kubernetes can expose services within the cluster through service resources and expose services outside the cluster through application access portals (Ingress).

[0036] For example, the microservice system in the related technology can perform container orchestration. For example, it can use Kubernetes' native non-markup language (yaml) resources as a basis, and use an interface visual method to declare template parameters to define applications and cloud services, thereby providing users with container orchestration capabilities.

[0037] In some related technologies, cloud environment parameter orchestration may include the following methods: Kubernetes native resource orchestration, cloud native application blueprint (Helm Chart).

[0038] Kubernetes, the leading container orchestration platform, provides application developers and operations personnel with the necessary orchestration capabilities for container deployment, management, and scaling. Kubernetes manages cloud-native applications at a service-level, supports resource descriptions in YAML, and supports service registration, discovery, and routing management, providing users with the ability to automatically deploy, scale, and manage containerized applications.

[0039] Figure 1 This is a diagram showing the relationship between container orchestration controllers in a container orchestration platform in some scenarios. Figure 1 In Kubernetes, there are five commonly used controllers to help users orchestrate containers. These controllers are Deployment controller, StatefulSet controller, DaemonSet controller, CronJob controller, and Job controller.

[0040] The Deployment controller is often used as a stateless instance controller; the StatefulSet controller is a stateful instance controller; the DaemonSet controller can run on selected nodes, with one replica running on each node. Its characteristic is that its Pod scheduling does not go through the scheduler, but is directly bound to the node name (NodeName) when the Pod is created; the CronJob controller involves scheduled tasks and is a higher-level controller. It is somewhat similar to the Deployment controller. When a scheduled task is triggered, a Job can be created to execute the specific task.

[0041] exist Figure 1 Kubernetes also includes a ReplicaSet controller, which controls the number of replicas of its managed pods, ensuring they maintain a preset number. In some scenarios, when a user changes the number of replicas, the Deployment controller can interact with the ReplicaSet controller it controls. After learning the new replica count, the ReplicaSet controller can scale out by adding or removing the pods it controls.

[0042] Figure 1 The diagram also shows pod scheduling policies in a Kubernetes cluster, such as "definitely not scheduled (NoSchedule)". In some scenarios, pod scheduling policies may also include "try not to schedule (PreferNoSchedule)" and "evict already running pods (NoExecute)".

[0043] In real-world scenarios, applications deployed on Kubernetes clusters can be quite complex, with a series of objects typically interacting internally to keep the program running. For example, when deploying a highly available, rolling-update application, with requirements for uninterrupted service, persistent data without loss, automatic capacity expansion when the application load is too high, and support for Hypertext Transfer Protocol Secure (HTTPS) access, a Deployment controller is required to deploy the desired pods and specify the number of replicas; dynamically allocate storage volumes through StorageClass; specify the pod's access policy through the Service to allow external access to the pod's services; and finally, associate these resources together through resource labels.

[0044] In some scenarios, as the number of cloud-native applications within microservice systems increases, describing the system directly through YAML files becomes difficult and complex, requiring the combined use of a large number of Kubernetes resources. Kubernetes native resource orchestration lacks an application concept and only supports application management through services and labels. This makes managing cloud-native applications with a large number of services more difficult. For example, Kubernetes hard-codes various resource types for the cloud platform, failing to fully leverage the capabilities provided by the cloud ecosystem and lacking portability across multiple cloud platforms. Furthermore, the relatively complex definitions and numerous attributes of these native resource orchestrations place a heavy burden on application developers (referred to as developers).

[0045] In related technologies, the configuration management file of a cloud-native application blueprint can include the following three parameters: scaling, rolling upgrades, and other related parameters that application operations personnel are concerned about; images, ports, startup parameters, and other related parameters that application developers are concerned about; and platform policy parameters that platform operations personnel are concerned about.

[0046] Typically, Kubernetes uses an "all-in-one" resource YAML file to declare how applications should be deployed to the underlying cluster. These YAML files often contain declarations for different roles, such as application developers, application operations personnel, and platform operations personnel. Many of these roles have overlapping concerns (coupling of concerns), which makes collaboration difficult for different roles. The lack of unified standards introduces a large amount of manual operations that require the intervention of different roles, and system deployers need to learn additional application-related features.

[0047] In some scenarios, Helm is a package manager provided by Kubernetes, and each package can be called a Chart. Each Chart is a collection of files with a specific directory tree structure. Charts can be used to describe applications and are a collection of files related to Kubernetes resource objects. Helm can treat all resource files in Kubernetes as part of an application template and can be used to simplify the deployment and management of applications in Kubernetes. When users want to perform operations on application templates, they do not need to tell Helm which object to change. They only need to pass in the application template name, and Helm will help users perform the corresponding operations on each object under the application template.

[0048] Below through Figure 2 and Figure 3 Describes the file structure and instantiation process of cloud-native application blueprints. Figure 2 This is a diagram of the file structure of a cloud-native application blueprint; Figure 3Schematic diagram of the instantiation process of a cloud-native application blueprint.

[0049] First, combine Figure 2 Describe the file structure of Helm Chart, Figure 2 The following diagram schematically shows the file structure of the native application blueprint Helm Chart. In some scenarios, Helm contains a set of application templates of YAML files, called Helm Chart packages. Chart is a collection of files with a specific directory tree structure. Figure 2 As shown in the figure, the Helm Chart package can include: description file Chart.yaml, dependency file directory Charts, template file directory templates, and orchestration file values.yaml.

[0050] Among them, the Chart.yaml file of the current Chart is a YAML file used to describe the chart information, which can contain the metadata information of the Chart, such as version, name, description, etc.; the Charts directory is used to store other charts that the current Chart depends on; the templates directory is used to store all YAML template files that define all cloud-native applications; the variable arrangement file values.yaml is a parameter configuration file, which is used to store at least one of the following configuration item parameters: the value of the variable used in the template file in the templates directory, the default value of the parameter customized when installing the Chart, etc.

[0051] Continue to refer Figure 2 , in the Charts directory of the current Chart, including other Chart files that the current Chart depends on, such as the database management tool (MySQL) and the remote dictionary service (Remote Dictionary Server, Redis).

[0052] Taking the MySQL file directory as an example, the directory contains the corresponding Chart.yaml file, the custom template file _helpers.tpl, the template file directory templates, and the orchestration file values.yaml. Furthermore, the templates directory in the MySQL file directory contains the container package management configuration file statefulset.yaml.

[0053] Among them, _helpers.tpl is a file starting with an underscore. Helm regards this file as a public library definition file, which is mainly used to define common sub-templates, functions, etc. _helpers.tpl can be reused in the entire chart.

[0054] For statefulset.yaml, this file is the configuration file for Kubernetes to create a MySQL pod. Figure 2 The Redis file directory structure is similar to the MySQL file directory, so I will not go into details here.

[0055] It should be understood that in Helm, a Chart may depend on any number of other Charts. If the current Chart has some dependencies on Charts from other packages, you can add another Chart's structure in this directory.

[0056] Continue to refer Figure 2 In the templates directory of the current Chart, the following files are included: the note file Notes.txt, the custom template file _helpers.tpl, the deployment file deployment.yaml, and the service file service.yaml.

[0057] Notes.txt is used to store help information after the Chart package is deployed. This help information involves, for example, how to use the current Chart, list the default settings, etc.; deployment.yaml is used to indicate how to deploy containers (pods). For example, the deployment controller in the above embodiment can call the kubernetes cluster to create deployment resources, set the default number of container copies, configure container update policies, etc. based on this file; service.yaml is used to indicate how to create service-type resources. For example, the Service controller in the above embodiment creates kubernetes service-type resources based on the content in this file.

[0058] In cloud-native application platforms, applications are delivered in the form of images. The business logic of business applications is packaged within the images, and the platform leverages relevant operations and maintenance capabilities to effectively manage cloud-native applications and support overall application lifecycle management. An instance (Release) can be a deployment entity based on a chart. When a chart is run by Helm, a corresponding release is generated. This release then creates real, operational resource objects in Kubernetes.

[0059] The following combination Figure 3 Describe the Helm Chart instantiation process, which can include the following steps:

[0060] like Figure 3As shown in "A1, Pull", the container image (Container Image) is pulled through the Image Service. One important function of the container image is to serve as a portable application packaging form, so that the packaged application can run without distinction in a variety of operating environments.

[0061] like Figure 3 As shown in "A2, Push" in the figure, push the pulled container image to Kubernetes to transfer the container image.

[0062] like Figure 3 As shown in "A3, Reference," Image Service can host Helm charts by referencing them. Specifically, Image Service provides Helm chart hosting capabilities, allowing users to push, pull, and manage Helm charts in batches.

[0063] like Figure 3 As shown in "A4, Merge", Helm is used to merge the user attribute configuration (UserValues.yaml) with the original orchestration file Helm Chart to obtain an updated orchestration file. The updated orchestration file is then rendered to obtain a rendered yaml file.

[0064] like Figure 3 As shown in "A5, Deployment", the rendered YAML file is submitted to Kubernetes, and the container image pre-delivered to Kubernetes is deployed using YAML (refer to the description of "A2, Push" above) to complete the application instantiation.

[0065] pass Figure 3 It can be seen that Helm provides a way to "package" applications and the ability to parameterize cloud-native application configurations, which to a certain extent solves the problem of the lack of Kubernetes application management capabilities, realizes the efficient reuse of YAML resources, and simplifies the application deployment process.

[0066] However, in actual scenarios, Helm still has some shortcomings. For example, Helm can realize the ability to package applications, but this ability is for application developers. System deployers (operators) cannot intuitively understand the relationship between the components in the system. Although Helm provides values.yaml input, for the system, operators cannot accurately and quickly select appropriate deployment parameters based on the actual scale; secondly, the customization of cloud-native applications is limited to the configuration options pre-orchestrated by application development. Operators cannot add application, security, cluster-related tags and other functions to application yaml resources during actual deployment, and cannot conveniently solve governance-related capabilities, so the application customization capability is poor; in addition, Helm does not have the ability to deploy complex cloud-native microservice application systems, does not support service startup sequence management, and the operation and maintenance object is usually a single application. It has no dependencies on services within a complex application system, such as cloud resources (File Transfer Protocol (FTP)). Protocol, FTP), database (datebase, db), Redis, distributed publish-subscribe messaging system Kafka, etc.). Although the dependencies between services can be resolved by defining dependency relationships, the ability to pass parameters across applications is poor. In addition, for a single application, Helm supports operation and maintenance personnel to select the corresponding values.yaml (user values.yaml) according to different cloud environments to instantiate cloud-native applications. However, for complex microservice systems, a large number of values.yaml files need to be maintained to adapt to the differences in application configurations in different environments. Therefore, the portability of microservice systems between multi-cloud platforms is poor.

[0067] In a first aspect, an embodiment of the present disclosure provides a parameter arrangement method. Figure 4 FIG. 1 is a flow chart showing a parameter arrangement method according to an embodiment of the present disclosure. Figure 4 As shown, the parameter arrangement method includes the following steps.

[0068] S410: Obtain user attributes in a development configuration file of the cloud-native application. The user attributes include public attributes. The public attributes are used to indicate attributes that are allowed to be modified through the operation and maintenance configuration file during the deployment of the cloud-native application.

[0069] In this step, cloud native can be understood as a method for creating and running applications on cloud computing. Cloud native applications are applications designed, developed, deployed, and run on cloud platforms. Cloud native applications can include the following features: containerization, dynamic management, and microservices orientation. Specifically, containerization refers to running applications and processes in containers as independent units of application deployment; dynamic management refers to the dynamic management and scheduling of applications through a centralized orchestration and scheduling system; and microservices orientation refers to clarifying dependencies between services based on a microservices architecture, decoupling them from each other, and improving application flexibility and maintainability.

[0070] In this step, a development configuration file is defined by the application developer to help them describe the application instance (release), other dependent application instances, and the parameters required to instantiate these application instances. It can also be used to define parameters that can be modified by operations personnel during application deployment. In some scenarios, a development configuration file may only support the definition of a single application instance.

[0071] In some embodiments, each development configuration file may correspond to one application; for example, each spd file may correspond to and only correspond to one application (eg, a target application).

[0072] In the description of the following embodiments, the development configuration file may be referred to as: a cloud-native service instantiation configuration file, a service instantiation configuration file, an instantiation configuration file, or a small product definition (Small Product Definition, Spd) file.

[0073] In this step, user attributes (Values) are used to modify the original orchestration file of the cloud-native application (such as the original values.yaml file in the application blueprint). User Values ​​contain at least public attributes (public). Public attributes can be exposed to the operation and maintenance configuration file (resource file) for modification. In other words, public attributes can be exposed to the resource file to allow operation and maintenance personnel to modify them during deployment.

[0074] S420 , during the cloud native application deployment process, the parameter values ​​of the application dynamic attributes in the preset operation and maintenance configuration file are used to replace the parameter values ​​of the matching public attributes in the user attributes.

[0075] As an example, each operation and maintenance configuration file includes application properties of multiple applications. For example, each resource file may include application properties of multiple applications, that is, the operation and maintenance personnel can use one resource file to complete the deployment of multiple applications at the same time.

[0076] In this step, the operation and maintenance configuration file is a file defined by the operation and maintenance personnel, which is also called the "cloud resource configuration file", abbreviated as resource. The parameter values ​​of the application dynamic properties in the operation and maintenance configuration file are used to replace the parameter values ​​of the public properties in the development configuration file, thereby completing the replacement of the public properties in the spd file according to the resource file.

[0077] S430: Generate user attribute configuration according to the replaced parameter values ​​of the matching public attributes.

[0078] In this step, according to the parameter values ​​of the public attributes in the replaced spd file, a user attribute configuration can be generated as the configuration information of the user Values ​​required for instantiating the application.

[0079] S440: Update the original orchestration file of the cloud native application according to the user attribute configuration to obtain an updated orchestration file.

[0080] Exemplarily, the original orchestration file values.yaml in the Helm Chart is updated according to the user attribute configuration to obtain an updated values.yaml. The updated values.yaml can be used as the final orchestration file of the Helm Chart for parameter orchestration in a cloud environment (such as resource orchestration, workload orchestration, service orchestration, etc.).

[0081] According to the parameter orchestration method of the embodiment of the present disclosure, during the cloud-native application deployment process, the parameter values ​​of the application dynamic attributes in the operation and maintenance configuration file can be used to replace the parameter values ​​of the matching public attributes contained in the user attributes in the development configuration file of the cloud-native application. The replaced parameter values ​​of the matching public attributes are then used to generate a user attribute configuration, and the generated user attribute configuration is used to update the original orchestration file of the cloud-native application to obtain an updated orchestration file. This parameter orchestration method provides operation and maintenance personnel with application customization capabilities, allowing them to adaptively orchestrate the parameters of interest based on the operation and maintenance configuration file when deploying a cloud-native application system.

[0082] According to this method, the attributes that operation and maintenance personnel are concerned about can be replaced by the parameter values ​​of public attributes in the development configuration file. Without changing the original cloud platform, the development configuration of the cloud native application can be "decoupled" according to the focus of the role (operation and maintenance personnel), and the attributes that the operation and maintenance personnel need to pay attention to can be exposed to the operation and maintenance configuration file so that they can be modified by the operation and maintenance personnel when the cloud native application is deployed. In this way, the application can be customized through parameter replacement, so that the operation and maintenance personnel have system-level parameter orchestration capabilities when deploying cloud native applications, solving the problem of poor application customization capabilities in complex cloud native application systems.

[0083] In order to better understand the parameter arrangement method of the embodiment of the present disclosure, the parameter items in the development configuration file and the operation and maintenance configuration file are described in detail below through Table 1 and Table 2.

[0084] In the parameter orchestration method of the disclosed embodiment, a cloud-native service instantiation development configuration file (SPD) may include component information and component dependency information. The component information assists application developers in describing application instances, while the component dependency information assists application developers in describing other application instances on which the application depends. The development configuration file may also include parameters required to instantiate these application instances and define parameters that can be modified by operations and maintenance personnel during application deployment. An SPD supports the definition of only one application instance release.

[0085] Table 1 shows the definition of the main fields in the spd file.

[0086] Table 1 Main fields of the development configuration file (spd file)

[0087]

[0088]

[0089] As shown in Table 1, the development configuration file includes user attributes (user values). User values ​​are used to modify the original orchestration file (such as the original values.yaml file in the application blueprint). Attribute replacement information can be used to define parameter replacement rules. Attribute replacement information includes private attributes and public attributes. Private attributes are only accessible within the development configuration file and are not open to the operation and maintenance configuration file. However, public attributes are accessible to the operation and maintenance configuration file.

[0090] The specific structure of resource can be found in Table 2 below.

[0091] Table 2 shows the definition of the main fields in the resource file

[0092] Table 2 Main fields of the operation and maintenance configuration file (resource file)

[0093]

[0094]

[0095] Table 2 shows the main fields of the resource file, which include, for example, common attributes (commonParas), which are used to replace public attributes in the development configuration file.

[0096] For operations personnel, updating application blueprints (patching) based on resource files allows them to modify application deployment parameters and customize applications during system deployment. These capabilities can be orchestrated through the configuration of dynamic application properties (releaseParas) and application delivery policies (policies). In the parameter orchestration method, operation and maintenance configuration files can help operators describe cloud environment differences, simplify deployment configuration, and provide cloud-native application customization and parameter replacement capabilities. Therefore, they are also called cloud resource definition files.

[0097] In some embodiments, before step S410, the method further includes: setting the attributes that are allowed to be modified in the user attributes of the development configuration file as macro variables, and declaring the macro variables in the public attributes; the macro variables are used to transfer the parameter values ​​of the corresponding attributes; in the case where the application dynamic attributes include common attributes, the step of replacing the parameter values ​​of the matching public attributes in the user attributes with the parameter values ​​of the application dynamic attributes in the preset operation and maintenance configuration file in the above step S420 may specifically include the following steps:

[0098] S11, determining a preset general attribute replacement parameter in the general attribute;

[0099] In this step, referring to the description of the general attribute configuration in Table 2 above, the general attributes are unified configuration attributes of each application in the system, and the general attribute replacement parameters are used to replace the parameter values ​​of the public attributes with the same name in the spd file.

[0100] S12, obtaining a first matching attribute in the public attributes as a macro variable; wherein the parameter name of the first matching attribute matches the parameter name in the general attribute replacement parameter.

[0101] In this step, macro variables are identifiers with specific values ​​created through macro definitions. They are typically used to represent constant values ​​or complex expressions. The compiler replaces any occurrences of the macro variable with its value. For example, matching in this step means that the parameter name of the first matching attribute of the macro variable is identical or equivalent to the parameter name in the replacement parameter of the general attribute.

[0102] In this step, the first matching attribute in the cloud-native application is pre-defined as a macro variable and exposed to the resource file to allow it to be modified by operation and maintenance personnel during deployment.

[0103] S13: Use the parameter value of the general attribute replacement parameter to replace the parameter value of the first matching attribute.

[0104] In this step, since the macro variable can be replaced with its corresponding value or expression, the parameter value of the first matching attribute of the macro variable can be replaced by using the parameter value of the general attribute replacement parameter.

[0105] For example, when the macro variable name of a public attribute in the spd file is the same as the parameter name of a common attribute replacement parameter in the resource file, the parameter value of the common attribute replacement parameter in the resource file can be used to replace the parameter value corresponding to the macro variable name of the public attribute in the spd file.

[0106] Through the above steps S11-S13, the parameter values ​​of the common attributes in the operation and maintenance configuration file can be used to replace the parameter values ​​of the matching attributes in the development configuration file.

[0107] In some embodiments, when the application dynamic attributes further include application attributes, after the above step S13, the method may further include the following steps:

[0108] S14, determining application attribute replacement parameters of the application instance preset in the application attributes.

[0109] In this step, referring to the description of application attributes in Table 2 above, application attributes are used to describe application parameter configuration, including the application instance name and an attribute replacement list. Exemplarily, the attribute replacement list includes: at least one application attribute replacement parameter of the application instance corresponding to the application instance name.

[0110] S15, determining a second matching attribute in the public attribute as a macro variable, the name of the application instance is the same as the application instance name in the development configuration file, and the parameter name corresponding to the second matching attribute matches the parameter name in the application attribute replacement parameter.

[0111] As an example, the matching in this step means that the parameter name of the second matching attribute as the macro variable is the same as or identical to the parameter name in the applied attribute replacement parameter.

[0112] In this step, the second matching attribute in the cloud-native application is pre-defined as a macro variable and exposed to the resource file to allow it to be modified by operation and maintenance personnel during deployment.

[0113] S16: Use the parameter value of the application attribute replacement parameter to replace the parameter value of the second matching attribute.

[0114] For example, when the application instance name defined in the spd file is consistent with the name of the application instance in the resource file, and the macro variable name of a public attribute of the spd file is the same as the parameter name of an application attribute replacement parameter in the resource file, the parameter value of the application attribute replacement parameter in the resource file can be used to replace the parameter value corresponding to the macro variable name of the public attribute in the spd file.

[0115] Through the above steps S14-S16, the parameter values ​​of the application attributes in the operation and maintenance configuration file can be used to replace the parameter values ​​of the matching attributes in the development configuration file.

[0116] According to the method of the embodiment of the present disclosure, the public attributes in the spd can be defined as macro variables and declared in the public attribute replacement list of the spd. When the same macro variable name exists in the public attribute replacement list in the spd file, the macro variable of the common attribute in the resource can be directly used for replacement.

[0117] In the resource file of the embodiment of the present disclosure, the priority of the application attribute replacement parameter is greater than the priority of the general attribute replacement parameter, that is, the replacement priority of the application attribute replacement parameter is higher than the replacement priority of the general attribute replacement parameter. A high replacement priority means: the parameter value of the high-priority replacement parameter shall prevail.

[0118] In some embodiments, the development configuration file includes component dependency information, which is used to indicate the service instances in the cloud environment system that the cloud native application depends on; the user attributes also include private attributes, which are used to indicate the attributes of the service instance that are allowed to be replaced.

[0119] In this step, referring to the description of private attributes in Table 1 above, the user attributes in the spd file can include not only public attributes but also private attributes. Private attributes are not exposed to the operation and maintenance configuration file, but can be used to assist cloud-native applications in using technical services. For example, they can assist cloud-native applications (for application developers) in using cloud environments or Kubernetes native resources within the system.

[0120] In this embodiment, before the step of replacing the parameter values ​​of the matching public attributes in the user attributes with the parameter values ​​of the application dynamic attributes in the preset operation and maintenance configuration file in step S420, the following steps are also included:

[0121] S21, obtain the private attribute replacement parameters preset in the private attributes; wherein the private attribute replacement parameters include: the parameter name and parameter value source in the predetermined resource attribute of the service instance, the parameter value source is defined as a macro function expression, and the macro function expression is used to indicate: the parameter value of the predetermined resource attribute stored in the cloud environment system resources.

[0122] Exemplarily, the private attribute replacement parameter may be in the form of a parameter list, which records: the parameter name and parameter value source of each predetermined resource attribute of the service instance that the cloud native application depends on.

[0123] As an example, the predefined resource attributes of a service instance (see the description of private attribute replacement parameters in Table 1) can include: sensitive data (Secret) attributes, application configuration (ConfigMap) attributes. Secret attributes can include, for example, database usernames, keys, tokens, and other information; ConfigMap attributes can include, for example, service ports, operating parameters, file paths, and other information. The differences between Secret attributes and ConfigMap attributes include, but are not limited to, the fact that Secret attributes require encrypted storage, while ConfigMap attributes do not.

[0124] In this step, by replacing parameters with private attributes, the parameter value source (the specific parameter value corresponding to the attribute name) of the predetermined resource attributes of the technical service that the cloud native application depends on (for example, needs to be called or mounted) can be defined as a macro function expression. The macro function expression can be simply referred to as a macro function.

[0125] S22, obtaining parameter values ​​of predetermined resource attributes from cloud environment system resources through macro function expressions.

[0126] S23, using the parameter values ​​of the predetermined resource attributes in the cloud environment system resources to replace the macro function expression.

[0127] In the above steps S22 and S23, the macro function is processed, and the parameter value of the predetermined resource attribute of the Kubernetes native resource indicated by the macro function is used as the return value of the macro function. Then, the return value of the macro function (such as the specific parameter value of the Secret attribute) is used to replace the macro function involved in the private attribute replacement parameter.

[0128] S24, obtaining a resource configuration file created in the cloud native application deployment tenant, where the resource configuration file includes parameter names and corresponding parameter values ​​of predetermined resource attributes.

[0129] As an example, a resource configuration file created by a tenant deploying a cloud-native application may be, for example, a Kubernetes resource configuration file created by a tenant where an application instance of the cloud-native application is located. The resource configuration file may include, for example, a corresponding secret attribute or a corresponding configmap attribute.

[0130] S25 , obtaining a third matching attribute as a macro variable in the private attribute, wherein the parameter name corresponding to the third matching attribute matches the parameter name of the predetermined resource attribute.

[0131] As an example, the parameter name corresponding to the third matching attribute may be the same as the parameter name of the predetermined resource attribute.

[0132] In the spd file, you can pre-define the "predetermined resource attributes (secret attributes / configmap attributes) that need to be assisted in generating in the values.yaml file" as macro variables, and declare the macro variables in the private attribute replacement parameters of the spd file (refer to the description information of the private attribute replacement parameters in Table 1 above).

[0133] In the description of the embodiments of the present disclosure, "predetermined resource attributes that need to be generated for auxiliary in the values.yaml file" can be understood as: in the original orchestration file (values.yaml) in the application blueprint, corresponding attributes are generated to assist the native application in connecting to the technical services that the native application depends on, such as secret / configmap attributes.

[0134] S26 , when the variable type of the macro variable corresponds to the attribute type of the predetermined resource attribute, the parameter value of the third matching attribute is replaced by the created parameter value of the predetermined resource attribute.

[0135] Exemplarily, the variable type of the macro variable is a Secret type or a configmap type. If the variable type of the macro variable corresponds to the variable type corresponding to the predetermined resource attribute (Secret attribute / configmap attribute) (Secret attribute corresponds to Secret attribute type, configmap attribute corresponds to configmap attribute type), the attribute (Secret) parameter value created in the cloud native application deployment tenant in step S23 can be used to replace the parameter value corresponding to the matching parameter name in the private attribute.

[0136] In the embodiment of the present disclosure, the predetermined resource attributes (Secret attributes / configmap attributes) of the service instance that the cloud native application depends on can be defined as macro variables in the private attribute replacement parameters in the spd file, and the value source of the specific attribute value of the predetermined resource attribute can be indicated by the macro function. When the system is instantiated, first, the parameter value of the predetermined resource attribute indicated by the macro function can be obtained from the cloud environment system resources, and the macro function can be replaced (that is, for the service instance that the cloud native application depends on, the parameter value of the predetermined resource attribute stored in the cloud environment system resources is first replaced). Then, in the resource configuration file created by the application deployment tenant, the attribute value of the predetermined resource attribute generated when the file is created can be obtained and used to replace the matching macro variable in the private attribute replacement parameter (that is, the parameter value of the predetermined resource attribute in the configuration file created by the application deployment tenant is used to assign the parameter value of the predetermined resource attribute replaced from the cloud environment system resources). This is beneficial for application developers to have the ability to orchestrate applications to assist in the use of Kubernetes native resources in the cloud environment or system.

[0137] According to the method of the embodiment of the present disclosure, private attributes can be defined as macro variables and declared in the SPD private attribute replacement list, so that cloud environment system resources (such as Kubernetes native resources) can be used in SPD based on macro functions, and specific attributes within the cloud environment system resources can be linked to the final application blueprint through the private attribute replacement capability of SPD, allowing cloud native applications to use these cloud environment system resources.

[0138] In some embodiments, the macro function expression includes input parameter information and query path information; the input parameter information includes: application version number, application type and naming information.

[0139] As a specific example, the macro function can be expressed as the following expression (1):

[0140] get_apiserver_property:[$(ApiVersion:version number, Kind:type, Name:name, Namespace:namespace), path](1)

[0141] The above expression (1) can be simplified as the following expression (2):

[0142] get_apiserver_property:[$(version number, type, name, namespace), path](2)

[0143] The above expressions (1) and (2) are both macro function expressions, where ApiVersion is used to indicate the application version number; Kind is used to indicate the application type; Name is used to indicate the application name; and Namespace is used to indicate the namespace, which can be used, for example, for tenant-level configuration isolation (corresponding to different tenants).

[0144] It can be seen from the above expression (2) that in actual use, the input parameter information of the macro function in expression (1) can ignore the name of any keyword ("ApiVersion:", "Kind:", "Name:", "Namespace:") and only use the value corresponding to each keyword. However, the value corresponding to each keyword must be sorted in a predetermined order, for example, specified in the order of ApiVersion, Kind, Name and Namespace.

[0145] In this embodiment, S22 may specifically include the following steps:

[0146] S31, according to the application version number, searching for a corresponding application resource list from the cloud environment system resources.

[0147] In this step, the application resource list (Api Resources) of the cloud environment system resources can be queried according to the application version number ApiVersion.

[0148] S32: Search the application resource list for an application resource of the same type as the application type.

[0149] S33: Generate query link information according to the resource name, application version number and naming information of the found application resource.

[0150] Exemplarily, the naming information includes an application name Name and a namespace Namespace.

[0151] Through the above steps S32-S33, for the application resource of the same type as the application resource, the resource name (ResourceName) of the application resource is obtained, and then the query link information of the cloud resource is generated based on the ApiVersion, ResourceName, Name and Namespace of the application resource.

[0152] Exemplarily, the query link information may be a Uniform / Universal Resource Locator (URL).

[0153] S34, querying the resource data of the application resources from the cloud native application server by querying the link information.

[0154] Exemplarily, the cloud native application server (Kubernetes ApiServer) is accessed through the URL to query the corresponding resource instance information.

[0155] S35: Using the query path information, query and obtain the parameter value of the predetermined resource attribute under the path corresponding to the resource data.

[0156] Exemplarily, the path attribute in the macro function get_apiserver_property is used, and the specific value of the predetermined resource attribute under the corresponding path of the resource data obtained from the query in step S34 is used as the return value of the macro function.

[0157] Through the above steps S31-S35, the specific values ​​of the attributes of the application instance in the cloud native resources can be quickly queried through the macro function, so that the application's reference to the native resources during the application instantiation process can be realized through the macro function.

[0158] In the embodiment of the present disclosure, the macro function can be recorded as "get_apiserver_property", which can be used in the user properties (values) and property replacement information (replaces) of the spd file, and can reference cloud environment resources to the values.yaml of the application blueprint, thereby entering the final blueprint resources.

[0159] For ease of understanding, the following Figure 5 Describes the specific process of obtaining native resource instance attribute values ​​through macro functions. Figure 5 A flowchart of obtaining native resource instance attribute values ​​through a macro function according to an exemplary embodiment of the present disclosure is shown.

[0160] like Figure 5 As shown, the steps of processing the macro function and obtaining the native resource instance attribute value through the macro function may specifically include the following steps.

[0161] S501, initiate a macro function processing operation.

[0162] The expression of the macro function can be based on the above expression (1) or expression (2), which will not be repeated here.

[0163] S502, obtaining macro function input parameters.

[0164] In this step, the macro function input parameters are the ApiVersion, Kind, Name, and Namespace of the application resource.

[0165] S503: Query the application resource list corresponding to the version number from the cloud environment system resources.

[0166] In this step, the API resource list for the resource is queried based on the ApiVersion in the macro function input parameter.

[0167] S504: Process the application resources in the application resource list in sequence.

[0168] S505, as shown in "Whether the resource types are consistent", determine whether the application type in the macro function input parameter is consistent with the application resource type in the application resource list.

[0169] In this step, it is determined whether the application type (Kind) of the macro function input parameter is consistent with the type of the current application resource in the application resource list (ApiResource). If yes, continue to execute S506; if not, jump to step S504.

[0170] S506: Obtain resource name.

[0171] In this step, the ResourceName of the current application resource is obtained.

[0172] S507: Generate a query link.

[0173] Specifically, the query URL of the cloud resource may be generated according to the application version number (ApiVersion), resource name (ResourceName), application name (Name), and namespace (Namespace) of the application resource.

[0174] S508: Access corresponding resource instance information from the cloud native application server.

[0175] As an example, according to the generated URL of the resource data of the application resource, the KubernetesApiServer is accessed to query the corresponding resource instance information. As an example, the resource data can be in the form of a REST file, that is, a file stored in the res format, naming method and folder structure defined by the developer.

[0176] S509, as shown in "Getting the path attribute corresponding to the instance", uses the query path information in the macro function to query the specific value of the resource attribute under the path corresponding to the resource data as the return value of the macro function.

[0177] Use the path attribute in the macro function to query the specific value of the resource attribute under the path corresponding to the resource data returned in step S508 as the return value of the macro function.

[0178] Through the above steps S501-S509, macro functions can be used to obtain any attribute value of the native resource instance defined on Kubernetes.

[0179] In some embodiments, step S440 may specifically include: merging the user attribute configuration with the original orchestration file to obtain an updated orchestration file; wherein, when the user attribute configuration and the original orchestration file have the same attribute, the parameter value of the corresponding attribute in the updated orchestration file adopts the parameter value of the attribute in the user attribute configuration.

[0180] In this embodiment, a merge operation is performed on the user attributes (user values) and the default configuration parameters of the cloud-native application blueprint, values.yaml. The merge rule is that the configuration in the user values ​​is used as the basis for the merge. In other words, the updated orchestration file can be obtained by "merging" the user attributes with the original orchestration file. During the merge, the configuration in the user attributes is used as the basis for attributes with the same name.

[0181] It should be understood that for attributes that only exist in the user attributes or only in the original orchestration file, they should be directly “merged into (added to)” the updated orchestration file.

[0182] In this embodiment, the user attribute configuration is merged with the original orchestration file to obtain an updated orchestration file. The updated orchestration file can be used to update the original orchestration file in the cloud native application.

[0183] In some embodiments, after obtaining the updated arrangement file in S440, the following steps may also be performed:

[0184] S450: Obtain a cloud-native application blueprint corresponding to the original orchestration file.

[0185] For example, the original orchestration file of the cloud-native application blueprint Helm Chart is values.yaml.

[0186] S451: Generate an executable orchestration file of the cloud-native application blueprint using the updated orchestration file. The executable orchestration file is used to orchestrate the cloud-native application.

[0187] For example, when deploying a Kubernetes application through Helm, you need to render the cloud-native application resource templates under the Helm Chart template into a resource description file in the YAML format that can be recognized by Kubernetes.

[0188] In this embodiment, an updated orchestration file (updated values.yaml) is used to render the cloud-native application resource template under the Helm Chart template to form a rendered Yaml that can be executed by Kubernetes. This file is an executable orchestration file, and the cloud-native application can be orchestrated using this executable orchestration file.

[0189] In some embodiments, after the step of generating the executable arrangement file in step S451, the following steps are further included:

[0190] S460: Obtain a delivery strategy in the operation and maintenance configuration file. The delivery strategy includes preset strategy parameters. The strategy parameters are used to indicate target resources and corresponding resource update operations.

[0191] Exemplarily, the policy parameter lists (patches) under the delivery policies (policies) in the operation and maintenance configuration file (resource file) can be read in sequence, and the policy parameter lists are used to record: at least one target resource and the resource update operation corresponding to each target resource.

[0192] S461, obtaining a target resource from the cloud environment system resources, where the target resource is an executable orchestration file resource that matches the target resource.

[0193] In this step, the group, version, type, name and namespace of the target resource are matched with the group, version, type, name and namespace of the executable orchestration file generated in step S451.

[0194] S462: Execute corresponding resource update operation on the target resource.

[0195] As an example, a resource update operation can be performed on the target resource according to JSON6902. JSON6902 can be used to specify which attribute in a Kubernetes resource is to be added (add), replaced (replace), copied (copy), or removed (remove), thereby providing a precise resource update method to support resource update operations such as add, replace, copy, and remove.

[0196] In this embodiment, the resource file may also include a delivery policy for extending the operation and maintenance features (functions) of the entire system. After obtaining the updated orchestration file, the template file in the rendered application blueprint (such as the template of the Helm Chart package) may be continued to be used to obtain an executable configuration that can be run by the cloud platform (such as a k8s executable yaml resource), and then the executable configuration may be modified and updated (patch) according to the delivery policy in the resource.

[0197] Therefore, the disclosed embodiments can allow operation and maintenance personnel to add environment support features to cloud-native applications in the current cluster based on the characteristics of different cloud environments without modifying the cloud platform, such as adding a monitoring sidecar service to all applications in the system on a cloud platform with monitoring, or adding environment tags, security, monitoring, etc. on other cloud platforms.

[0198] In some embodiments, during the cloud-native application deployment process, the parameter orchestration method may further include: receiving input application deployment parameters through a first interactive interface, where the application deployment parameters include at least one of the following: cloud environment characteristic parameters and application scale attributes.

[0199] For example, when deploying cloud-native applications, operation and maintenance personnel are allowed to uniformly set various cloud environment characteristics (such as non-root, tags, etc.) and application scale-related properties through an interactive interface, which is conducive to simplifying the parameter orchestration and deployment of complex cloud-native systems.

[0200] In this embodiment, the parameter arrangement method may further include: receiving an execution instruction for a predetermined macro function expression through a second interactive interface, the execution instruction being used to trigger: obtaining a parameter value of a predetermined resource attribute stored in a cloud environment system resource according to the predetermined macro function expression.

[0201] Exemplarily, in the second interactive interface, a macro function editing interface and a run instruction trigger control are provided. The macro function editing interface can edit the macro function to be used, and the run instruction trigger control is used to trigger the running of the macro function. The macro function assists application developers in using the cloud environment or Kubernetes native resources in the system. For example, it can support the creation of sercet / configmap links into the cloud native application Helm Chart blueprint values.yaml.

[0202] In this embodiment, the parameter arrangement method further includes: editing predetermined operation and maintenance parameters through a third interactive interface, where the predetermined operation and maintenance parameters are used to configure operation and maintenance parameters under different cloud environment scales and operation and maintenance difference scenarios.

[0203] For example, when deploying cloud-native applications, the operation and maintenance parameters exposed by the cloud-native applications can be configured through the third interactive interface according to the scale and operation and maintenance differences of different cloud environments, thereby adding richer operation and maintenance features based on the original Helm Chart resource template.

[0204] According to the parameter orchestration method of the embodiment of the present disclosure, during the cloud-native application deployment process, the parameter values ​​of the application dynamic attributes in the operation and maintenance configuration file can be used to replace the parameter values ​​of the matching public attributes contained in the user attributes in the development configuration file of the cloud-native application. The replaced parameter values ​​of the matching public attributes are then used to generate a user attribute configuration, and the generated user attribute configuration is used to update the original orchestration file of the cloud-native application to obtain an updated orchestration file. This parameter orchestration method provides operation and maintenance personnel with application customization capabilities, allowing them to adaptively orchestrate the parameters of interest based on the operation and maintenance configuration file when deploying a cloud-native application system.

[0205] In actual application scenarios, illustratively, when cloud environment parameter orchestration (cloud native parameter orchestration) is performed using the parameter orchestration method of an embodiment of the present disclosure, the following processing steps may be included:

[0206] First, application developers write a corresponding spd file for each application (APP) instance (Release). The spd file includes user attributes, and defines the attributes in the user attributes that require the attention of operation and maintenance personnel as public attributes. The public attributes are exposed to the resource file, so that operation and maintenance personnel can modify the public attributes in the spd file through the resource file and finally complete the configuration of the original orchestration file; at the same time, application developers can also define the cloud environment system resources that need to be referenced in the user attributes as private attributes, thereby completing the purpose of linking the cloud environment system resources to the final application blueprint.

[0207] Secondly, the operation and maintenance personnel write resource files based on the resource scale and operation and maintenance capabilities of the specific cloud environment to modify the public attributes in the spd file.

[0208] Then, when the system is instantiated, the cloud environment parameter orchestration device (such as the deployer) can use the private attributes in the spd to link to the cloud environment system resources required by the cloud-native application, and then complete the replacement of the public attributes in the spd according to the common attributes of the resource; and based on the user attributes in the spd after the replacement, instantiate the user attribute configuration (parametersvalues), and then obtain the updated orchestration file (such as the final values.yaml), and use the updated orchestration file for parameter orchestration (such as templates for rendering Helm Chart packages).

[0209] It should be understood that the public properties in the spd file that are not replaced according to the resource use the parameter values ​​in the spd file, that is, the parameter values ​​set by the application developer, in the updated orchestration file; while the properties that are not modified in the original orchestration file use the original default values ​​in the application blueprint.

[0210] In the embodiments of the present disclosure, application developers can use Helm Chart to define cloud-native application blueprints and configure operation and maintenance parameters, and can write development configuration files (spd files) for the corresponding cloud-native service instantiations for the applications; operation and maintenance personnel write cloud resource configuration files (resource files) based on the differences in resource scale and operation and maintenance capabilities of different cloud environments; the parameter orchestration method of the embodiments of the present disclosure can use development configuration files (spd files of the above embodiments) and operation and maintenance configuration files (resource files of the above embodiments) to complete parameter orchestration.

[0211] To better understand the parameter orchestration method of the embodiment of the present disclosure, the following describes the parameter orchestration method of the embodiment of the present disclosure in a cloud environment, taking the case of using Helm to describe an application blueprint in the container cloud platform Kubernetes as an example.

[0212] It should be noted that the parameter orchestration method of the embodiment of the present disclosure is not limited to Kubernetes, container cloud platforms, or Helm, but can be used in various scenarios of cloud-native system parameter orchestration deployment in any public, private, or edge cloud platform.

[0213] Figure 6 This is an architectural diagram of the parameter arrangement method provided in an embodiment of the present disclosure.

[0214] exist Figure 6 In the architecture, n1 cloud platforms, multi-cloud environments, and cloud-native application systems are included, where n1 is an integer greater than or equal to 1.

[0215] Each cloud platform offers a variety of technical services and cloud-native applications. These services include at least one of the following: a distributed search and analytics engine (ElasticSearch), file transfer services (FTP / SFTP), real-time search and analytics (Logstash), in-memory data structure storage (Redis), a distributed publish / subscribe messaging system (Kafka), databases, and other technical services. Cloud-native applications include multiple application instances.

[0216] In a multi-cloud environment, operations personnel can use n2 operation and maintenance configuration files (resource files, also called cloud resource configuration files), where n2 is an integer greater than or equal to 1. For example, multiple operation and maintenance configuration files can be used to describe different cloud environment resource scales and operation and maintenance capabilities.

[0217] A cloud-native application system includes multiple applications, such as application 1, application 2, ..., application n3, where n3 is an integer greater than or equal to 1. Each application's configuration file includes a development configuration file (spd) and a cloud-native application blueprint (HelmChart). The Helm Chart includes application resources and a template file directory (templates). The template file directory contains template files for the following resource objects: container packages (pods), loads (Deployments), services (Services), application access portals (Ingresses), volumes (Volumes), and other resource objects (Others).

[0218] It should be noted that the specific parameters in templates and values.yaml can refer to the above Figure 2 The description in , will not be repeated here.

[0219] exist Figure 6 In the cloud native system, the users include two roles, namely application developers and operation and maintenance personnel. As an example, for the role of application developer, they can write business applications, use Helm to package application resource blueprints, specify the application resource blueprint name and version required for this deployment based on the spd file provided in the embodiment of this disclosure, and describe the list of other cloud native instances that the application depends on; use macro functions to assist applications in using technical services within the system or cloud environment, and through the private attribute replacement capability of spd, link specific attributes in the above resources into the application blueprint definition in the form of configuration files, so that cloud native applications can use these capabilities; expose application operation and maintenance parameters to resources through the public attribute replacement capability of spd files, allowing operation and maintenance personnel to modify them through resource files.

[0220] As an example, for the role of operation and maintenance personnel, when the system is actually deployed, they can edit the corresponding resource file according to the different cloud platforms where the cloud-native application system is deployed, and replace the operation and maintenance parameters such as CPU, memory, and number of replicas of each application in the system; based on the operation and maintenance capabilities provided by the platform, the application customization capabilities of the resource file can be used to update the corresponding resources for all applications or specific applications in the system.

[0221] Reference Figure 6 It can be seen that for the problem of coupling of concerns between application developers and operation and maintenance personnel in cloud-native systems, we can use the design idea of ​​separation of concerns and use cloud-native services to instantiate development configuration files (spd) and operation and maintenance configuration files (resource) to separate the concerns of application developers and operation and maintenance personnel (that is, "decoupling"). Application developers only focus on the implementation of business logic, and operation and maintenance personnel focus on how to run applications smoothly. This solves the difficulty of collaboration between different roles in Kubernetes' "All-in-One" approach and simplifies configuration work.

[0222] Figure 7 A schematic diagram of the relationship between the various participants in the parameter arrangement method provided in an embodiment of the present disclosure.

[0223] Reference Figure 7The various participants in the parameter orchestration method may include: application developers 701, application marketers 702, operations and maintenance parties 703, and deployers 704. Application developers 701 include multiple contributors, each of which is responsible for providing a business cloud-native blueprint and a corresponding spd file. Application marketers 702 can be used to provide cloud-native business applications, technical services, and other related applications. Operations and maintenance parties 703 can use operation and maintenance configuration files to tailor / assemble applications, for example, organizing and packaging applications based on user selections. Deployers 704 can parse version packages, read the contents of spd and resource files, organize application dependencies based on spd files, support system-level parameter replacement and customization capabilities implemented through resource files, and complete system version deployment.

[0224] Exemplarily, the deployer 704 may be a package manager based on Helm (version V3). It should be understood that the version of Helm can be selected according to actual needs and is not specifically limited in the present embodiment.

[0225] In some application scenarios, the application developer 701 is used to push the application to the application market 702; the operation and maintenance party 703 is used to obtain the application from the application market 702, and can use the operation and maintenance configuration file to cut / assemble the application, package the application, and form a system version through multiple cloud native applications; the deployer 704 is used to select the operation and maintenance configuration file (resource file) according to the environment scale to replace the application parameters. It can also write the delivery strategy according to the environment operation and maintenance characteristics, provide application parameter replacement capabilities and application customization capabilities, and realize the application of parameter orchestration methods to various scenarios of parameter orchestration of cloud platforms. Figure 7 As shown in the figure, the cloud platform can provide multi-cluster (Multi-Cluster) services of container orchestration (Kubernetes), cloud (Clouds) services, edge computing services (IoT Edge), etc.

[0226] Figure 8 Schematic diagram of the system framework of the parameter arrangement method according to an embodiment of the present disclosure. Figure 8 and Figure 7 Modules with the same number have the same function.

[0227] Reference Figure 8 The system framework also includes: a first writing module 801, a second writing module 802, a first reading module 803, and a second reading module 804. The first writing module 801, also known as the spd writing module, is used to write development configuration files; the second writing module 802, also known as the resource writing module, is used to write operation and maintenance configuration files; the first reading module 803 is used to read development configuration files; and the second reading module 804 is used to read operation and maintenance configuration files.

[0228] In the embodiments of the present disclosure, parameter orchestration is performed based on development configuration files and operation and maintenance configuration files to implement cloud-native application deployment. According to this method, any cloud-native Helm Chart package deployed on Kubernetes can be deployed without any modification under the specifications mentioned in the embodiments of the present disclosure, thereby performing scale-related parameter settings, sharing technical services across applications, and unifying various deployment features; deployment features include, for example: running as a non-root user (root), feature tags (used to specify that the container is deployed on a certain node), and other settings.

[0229] In order to better understand the present disclosure, Figures 9-14 , describes in detail the parameter arrangement method of the exemplary embodiment of the present disclosure.

[0230] Figure 9 A flowchart of editing and developing a configuration file provided in an embodiment of the present disclosure. Figure 9 , editing the development configuration file can include the following steps:

[0231] S901: Initiate cloud native application enhanced configuration operation.

[0232] S902, describe the application blueprint.

[0233] In this step, you can use Helm to describe the application blueprint.

[0234] S903: Define modifiable application operation and maintenance properties as cloud native application blueprint (Helm Chart) template variables.

[0235] In this step, you can set the properties that need to be modified by the operation and maintenance personnel as Helm Chart template variables.

[0236] S904: Define the technical service link parameters required by the application as Helm Chart template variables.

[0237] In this step, you can set the technical service link parameters (secret / configmap) that the application needs to use as Helm Chart template variables.

[0238] S905, define operation and maintenance configuration parameters.

[0239] In this step, the default values ​​of the application operation and maintenance attributes in the above step S903 and the technical service link parameters in the above step S904 are defined in the orchestration file (values.yaml) and can be modified.

[0240] S906, define a cloud native service instantiation configuration file.

[0241] Exemplarily, the cloud native service instantiation configuration file is the development configuration file (spd file) in the embodiment of the present disclosure.

[0242] S907, define application component dependencies in the development configuration file.

[0243] Exemplarily, other applications or services (dependencies) that an application depends on are defined in an spd file.

[0244] S908, define private attribute replacement parameters in the development configuration file, and use macro functions to assist the application in using technical services.

[0245] For example, in the spd file, define the secret / configmap attributes that need to be assisted in the values.yaml file as macro variables, declare the macro variables in the spd private attribute replacement list, set the replace type to secret / configmap, and define the secret attribute name and attribute value source under the variable type (replace type) of the replacement variable. The attribute value source is seamlessly connected to the Kubernetes ApiServer through a macro function. The meaning of "predetermined resource attributes that need to be assisted in the values.yaml file" is described in the above embodiment and will not be repeated here.

[0246] Illustratively, in the embodiment of the present disclosure, when instantiating an application, the variable type (replace type) of the corresponding replacement variable is a field of secret / configmap, and specifically, the corresponding secret / configmap may be generated in the tenant where the application instance is located.

[0247] S909: Define public attribute replacement parameters in the development configuration file and expose them to the application configuration file.

[0248] For example, in the spd file, the parameters that need to be exposed to operation and maintenance personnel in values.yaml are defined as macro variables, and the macro variables are declared in the parameter replacement list of the public property replacement parameter of the spd file, and the replacement variable replace type is set to the default type (default), thereby completing the parameter exposure configuration of the resource configuration file resource by the configuration parameter values.yaml of the application blueprint Helm Chart package.

[0249] Through the above steps S901-S909, application developers can edit the development configuration file. The process of editing the development configuration file can include assisting cloud-native applications in using technical services, describing cloud-native application dependencies and public attribute replacement parameters, and exposing them to the application configuration file.

[0250] Figure 10 A flowchart for defining an operation and maintenance configuration file provided in an embodiment of the present disclosure.

[0251] Reference Figure 10 , the definition of the operation and maintenance configuration file can include the following steps:

[0252] S1001, initiate an operation to define an operation and maintenance configuration file.

[0253] Exemplarily, a definition operation on a resource file, ie, a cloud resource configuration file, is initiated.

[0254] S1002, defining common attributes.

[0255] Exemplarily, common properties in the resource file are configured.

[0256] S1003: Define application attributes.

[0257] For example, the application attribute replacement list of the resource file can be set according to the environment scale, and the application operation and maintenance parameter configuration can be reset.

[0258] S1004, determine whether the current application is the last application in the system; if so, continue to execute below; if not, execute the above step S1003.

[0259] S1005: Set a customized configuration parameter delivery strategy.

[0260] For example, the customized configuration parameter delivery strategy in the resource file can be set according to the differences in the operation and maintenance capabilities of the cloud environment currently required to be deployed.

[0261] Through the above steps S1001-S1005, operation and maintenance personnel can implement cloud-native application attribute replacement and customized capability configuration by defining and editing resource files.

[0262] For ease of understanding, the following Figure 11 , describes the process of replacing cloud native application attributes and customizing capabilities. Figure 11 A schematic diagram of the processing flow for cloud-native application attribute replacement and customization capabilities provided in an embodiment of the present disclosure.

[0263] exist Figure 11In the example, refer to "1) Replacement" to replace the application properties in the spd file through the resource file.

[0264] Specifically, you can declare common property replacement parameters and application property replacement parameters in the resource file. When instantiating a cloud-native application, if the common property replacement parameters in the SPD file have the same macro variable name, you can directly use the macro variable in the resource file to replace them.

[0265] like Figure 11 As shown in "User Attributes (User Values)", the macro variables related to attribute replacement in the spd file can be applied to the user values ​​definition and perform parameter replacement to obtain the user values ​​configuration required for the instantiated application.

[0266] like Figure 11 As shown in "Merged properties (Merged values)", the user values ​​configuration and the default configuration parameter values.yaml in the Cloud Native Helm Chart package are merged. The merging rule is that for properties with the same name, the user values ​​configuration takes precedence. This results in an updated orchestration file (updated values.yaml) for the application resource template in the template folder used to instantiate the Cloud Native Helm Chart package (application blueprint).

[0267] like Figure 11 In the "Rendered Configuration File" in the chart, Helm can use the updated values.yaml to render the application resource template under the Template of the Helm Chart package to form a rendered executable orchestration file (executable yaml resource) that can be used by Kubernetes.

[0268] like Figure 11 As shown in "Post Rendered", Helm can call the post-rendering interface to update the executable layout file.

[0269] exist Figure 11 In the example, refer to "2) Update" to configure the delivery strategy in the resource file and update the executable orchestration file (executable YAML resource) rendered by the Helm instantiation operation. This allows for application customization in the resource, which improves Helm's customization capabilities.

[0270] After the aforementioned "1) replacement" and "2) update" processes, the cloud-native application's resources are finally submitted to Kubernetes, converted and instantiated into specific resource objects (Deployment, Service, etc.). Helm then generates an application instance associated with these resources.

[0271] Figure 12 A flowchart of parameter orchestration of cloud-native applications provided by an exemplary embodiment of the present disclosure.

[0272] Reference Figure 12 In some embodiments, the parameter arrangement method includes the following steps.

[0273] S1201: Initiate application attribute replacement and instantiation operations.

[0274] In this step, the deployer can initiate cloud-native application property replacement, customization, and deployment operations.

[0275] S1202: Process each cloud native application in the system in turn.

[0276] S1203, parsing the private attribute replacement configuration in the development configuration file.

[0277] In this step, the private attribute replacement (replaces private) configuration information in the spd file in the cloud native application is parsed to obtain the private attribute replacement parameters.

[0278] S1204, read the private attribute replacement parameters in sequence.

[0279] Exemplarily, the private attribute replacement parameters are located in the parameter replacement list (replaces) under replaces private in the spd file.

[0280] S1205, determine whether to use the macro function; if yes, continue to execute downward, if not, jump to step S1207.

[0281] S1206, as shown in "Replace Macro Function Expression", the macro function expression in the current predetermined resource attribute is replaced with the specific value of the resource attribute specified by the macro function.

[0282] Exemplarily, the macro function expression in the current replaces is replaced.

[0283] S1207: As indicated by "whether the attribute type is a corresponding type", it is determined whether the attribute type is a type corresponding to the technical service link parameter.

[0284] Exemplarily, it is determined whether the type of the current replaces variable is secret / configmap. If so, the process continues to proceed; if not, the process jumps to step S1209.

[0285] S1208, as shown in “Creating a resource configuration file in the current tenant”, the deployer creates a corresponding resource configuration file in the current application deployment tenant.

[0286] For example, a corresponding Kubernetes resource configuration file secret / configmap is created in the current application deployment tenant.

[0287] S1209, determining whether the private attribute replacement parameters are replaced.

[0288] Exemplarily, it is determined whether the replaces private in the spd file has been processed. If so, the process continues to proceed downwards. If not, the process jumps to step S1204 to continue matching the next replace.

[0289] S1210: The deployer obtains the operation and maintenance configuration file and initiates an application instantiation action.

[0290] For example, the resource file submitted by the operation and maintenance personnel may be obtained.

[0291] S1211, parse the public attribute replacement configuration in the development configuration file.

[0292] Exemplarily, the public properties of the spd file in the cloud native application are parsed and replaced (replaces public) configuration.

[0293] S1212: Parse the common attribute replacement parameters in the operation and maintenance configuration file in sequence.

[0294] Exemplarily, the parameter replacement list under the common attribute (commonParas) in the resource file is read in sequence.

[0295] S1213, configure the public attribute replacement parameters in the development configuration file.

[0296] For example, the parameter replacement list under replaces public in the spd file is matched.

[0297] S1214, determine whether the parameter replacement name is consistent, if yes, continue to execute below, if not, jump to step S1216.

[0298] S1215, as shown in "Replace with public attribute parameters", use the corresponding values ​​in the public attribute replacement parameters in the application attributes to replace the values ​​of the relevant attributes in the development configuration file.

[0299] Exemplarily, the values ​​of the relevant properties in the spd file are replaced with the corresponding values ​​in the commonParas related parameters of the resource file.

[0300] S1216, as indicated by “Has the general attribute replacement parameter been processed?”, determines whether the general attribute replacement parameter in the operation and maintenance configuration file has been processed.

[0301] Exemplarily, it is determined whether the commonParas of the resource file has been processed. If so, the process continues to proceed downwards. If not, the process jumps to step S1212 to continue matching the next replace.

[0302] S1217, read the application attribute replacement parameters in the operation and maintenance configuration file in sequence.

[0303] Exemplarily, the application attribute replacement list (releaseParas) in the resource file is read in sequence to obtain the name and parameter replacement list of the application instance release.

[0304] S1218, matches the application name in the development configuration file.

[0305] Exemplarily, the name of the application instance release in the application attribute replacement parameter is matched with the application name (releaseName) in the spd file.

[0306] S1219, determine whether the instance names are consistent.

[0307] Exemplarily, it is determined whether the name of the application instance (release) in the resource file is consistent with the releaseName defined in the spd file. If yes, the process continues to proceed; if not, the process jumps to step S1223.

[0308] S1220, read the application attribute replacement parameters under the application instance in the operation and maintenance configuration file in sequence.

[0309] For example, the parameter replacement list under the release of the cloud native application instance in the resource file is read in sequence and matched with the parameter replacement list under replaces public in spd.

[0310] S1221, determine whether the parameter replacement name is consistent, if yes, continue to execute below; if not, jump to step S1223.

[0311] S1222, as shown in “Replace with application attribute replacement parameter”, use the value of the application attribute replacement parameter in the operation and maintenance configuration file to replace the value of the relevant attribute in the development configuration file.

[0312] Exemplarily, the corresponding value of the parameter in the resource file is used to replace the value of the relevant attribute in the spd file.

[0313] S1223, determine whether the application attribute replacement parameter processing is completed.

[0314] Exemplarily, determine whether the parameter replacement list under the release of the cloud native application instance has been processed. If so, continue to execute downward; if not, jump to step S1217 to continue matching the next replace.

[0315] S1224, instantiate user attribute configuration.

[0316] For example, the macro variables defined by the parameter replaces under parameters in the spd file are used to instantiate the user values ​​configuration (parameters values).

[0317] S1225: Submit the instantiated user attribute configuration to the package manager (Helm).

[0318] For example, the instantiated parameter values ​​are submitted to Helm.

[0319] S1226: Helm merges the user attribute configuration with the original orchestration file to obtain an updated orchestration file.

[0320] For example, Helm can merge the values ​​with the default values.yaml in the Helm Chart package to obtain a final property configuration file, which is called the final values.yaml file or the updated orchestration file.

[0321] S1227: Generate an executable orchestration file using the updated orchestration file.

[0322] For example, the final values.yaml file is used to render the template of the Helm Chart package to form a YAML resource that can be executed by Kubernetes.

[0323] S1228: Read the policy parameter list in the delivery policy in the operation and maintenance configuration file in sequence.

[0324] Exemplarily, the policy parameter lists (patches) under the delivery policies (policies) in the resource file are used in sequence.

[0325] S1229, as shown in “Parse policy parameters and obtain executable orchestration file”, parse the policy parameters in the policy parameter list and obtain the executable orchestration file corresponding to the target resource from the cloud environment system resources.

[0326] Exemplarily, the patches attribute is parsed, and the Kubernetes executable YAML resource generated in step S1227 is matched through the target resource (target).

[0327] S1230: Determine whether the resource object matches.

[0328] Exemplarily, whether there is a match is determined based on the group, version, type, name and namespace of the resource object. If so, continue to execute below; if not, jump to step S1232.

[0329] S1231: Execute corresponding resource update operations on the target resource.

[0330] Exemplarily, the Helm PostRender interface is called according to the JSON Patch rule to perform a patch operation on the Kubernetes executable YAML resource.

[0331] S1232: Determine whether the executable arrangement file has been processed.

[0332] Exemplarily, it is determined whether the Kubernetes executable YAML resource has been processed. If so, the process continues to proceed; if not, the process jumps to step S1229 to continue matching the next Kubernetes executable YAML resource.

[0333] S1233, as indicated by "Has the policy parameter list been processed?", determines whether the policy parameter list in the delivery policy in the operation and maintenance configuration file has been processed.

[0334] Exemplarily, it is determined whether the patches under the policies attribute in the resource file have been processed. If so, the process continues; if not, the process jumps to step S1228.

[0335] S1234: Submit the executable orchestration file to the cloud native application server to complete the cloud native application instantiation.

[0336] For example, Helm can call kube apply to submit yaml to the Kubernetes ApiServer to complete the cloud native application instantiation action.

[0337] S1235: Determine whether the cloud native application in the system has been processed.

[0338] Exemplarily, if yes, continue to execute downward; if no, jump to step S1202 to continue processing the next cloud native application.

[0339] In the disclosed embodiments, the priority for replacing user attributes (used for values) in the SPD file in the definitions of the various attribute replacement fields described above is: resource application attribute replacement list > resource general attribute configuration > SPD public attribute replacement > SPD private attribute. A higher replacement priority means that the parameter value of the higher-priority replacement parameter prevails; for example, for attributes with the same name, the parameter value of the higher-priority replacement parameter prevails.

[0340] It can be seen from the above steps that the parameter arrangement method of the embodiment of the present disclosure may include the following three processing stages:

[0341] First, use Helm Chart to define the application blueprint and configure operation and maintenance parameters. At the same time, write the corresponding cloud native service instantiation configuration file (spd file) for the application. This processing stage is aimed at the role of application developers.

[0342] Secondly, write operation and maintenance configuration files (resource files) based on the differences in resource scale and operation and maintenance capabilities of different cloud environments. This processing stage targets the operation and maintenance party.

[0343] Then, when the system is instantiated, the deployer first processes the macro functions involved in replacing user values ​​and private attributes in each spd file; then it completes the replacement of spd public attributes according to the resource file, and updates the rendered cloud resource blueprint according to the user delivery policy in the resource file; finally, the deployer submits the Kubernetes executable YAML resources of each application in the system to the Kubernetes ApiServer by calling kube apply through Helm, completing the application instantiation action.

[0344] The following describes the method for parameter orchestration according to an embodiment of the present disclosure, using a development configuration file (cloud native service instantiation configuration file) to assist applications in using technical services through private attribute replacement and macro functions.

[0345] Figure 13 A schematic diagram of a processing flow for using a development configuration file to assist cloud-native applications in using technical services provided in an embodiment of the present disclosure.

[0346] refer to Figure 13In some embodiments, the deployer uses the development configuration file to assist in using the technical service, including the following steps:

[0347] like Figure 13 As shown in "S1301, Technical Service Instance Configuration," use Helm to describe the cloud-native application blueprint, determine the required technical service instances, and configure them in the specific Kubernetes resource template under the template in the Helm Chart package.

[0348] exist Figure 13 As shown in the "Technical Service (pg) Connection Parameters" section of the blueprint template, taking the cloud-native application using a cloud database (PostgreSQL database, hereinafter referred to as the pg database) as a technical service as an example, the application in the blueprint template can mount the Kubernetes configuration file secret to a specific path in the application container. The application obtains the pg database client connection parameters by reading the corresponding fields in the secret at startup.

[0349] For example, the template definition of a Helm Chart package is as follows:

[0350]

[0351] The above description can be used to implement the template definition in the Helm Chart package.

[0352] exist Figure 13 As shown in "Orchestration File (values.yaml)", configure the specific mounting information of the pg secert volume in the orchestration file (values.yaml) of the Helm Chart package as follows:

[0353]

[0354] Exemplarily, the volume type may include at least one of the following: node local (hostPath), persistent data volume (persistentVolumeClaim), sensitive data (secret), and application configuration (configmap).

[0355] like Figure 13 As shown in "S1302, Attribute Value Configuration of Technical Services," configure the technical service pg in the system that the cloud-native application depends on in the development configuration file (spd file). Define the pgsecret name that the application needs to mount as a macro variable in the private attribute replacement. Use replace with type secret to define the attribute name and attribute value source of pg secret.

[0356]

[0357]

[0358] In some embodiments, the process of the deployer processing the auxiliary use technology service definition in the development configuration file is as follows:

[0359] like Figure 13 As shown in "S1303, Create Secret", when the system is instantiated, the deployer creates a secret according to the application dependency definition of the above development configuration file and preferentially deploys the service components that the application depends on.

[0360] like Figure 13 As shown in "S1304, modify the user attribute configuration in the development configuration file", the deployer processes the macro function and replaces the macro function expression in the current private attribute replacement definition with the specific value of the Kubernetes resource attribute specified by the macro function; identifies the private attribute replacement definition type type definition secret, and generates the corresponding Kubernetes configuration file sercet in the application deployment tenant; and processes the private attribute macro variable ${pgSecret} definition, uses the sercet name generated by the application deployment tenant to replace the macro variable ${pgSecret}, and obtains the processed user attribute configuration (user values).

[0361] like Figure 13 As shown in "S1305, deploy using processed user attribute configuration", the deployer uses the processed user values ​​configuration to render the Helm Chart blueprint and complete the application instantiation action.

[0362] In the embodiment of the present disclosure, during the application blueprint writing stage, the components within the system that the application needs to rely on can be defined based on the application developer's own business needs, while enabling the application developer to have the ability to orchestrate the application to use the cloud environment or Kubernetes native resources within the system.

[0363] The following embodiment involves the operator cloudification process. In this embodiment, for the parameter orchestration method of the embodiment of the present disclosure, during the telecom operator cloudification process, the network management system of the same telecom domain needs to be deployed in different user scale scenarios. In this scenario, the operation and maintenance parameters of the application are usually not determined during the development phase. During system deployment, the operation and maintenance personnel need to modify them according to actual needs, or dynamically adjust the operation and maintenance parameters of each business application in the network management system, such as CPU and memory, based on different user scales, such as 600,000, 300,000, and 100,000 users in a cell. These parameters need to be defined in the values.yaml file of the Helm Chart package.

[0364] In this embodiment, a cloud environment is exemplarily shown: the current network management system has cloud native applications A, B, and C. The operation and maintenance personnel select appropriate operation and maintenance configuration files (resources) to replace the CPU, memory, and other operation and maintenance configurations of A, B, and C in the system based on the user scale of the system deployment.

[0365] In this embodiment, the developer uses the development configuration file to define the public attribute configuration process as follows:

[0366] First, use Helm to describe the cloud-native application blueprint. Then, use template variables to configure the operation and maintenance parameters used by the application in the specific Kubernetes resource template in the template directory of the Helm Chart package.

[0367] For example, to configure the CPU and memory parameters for cloud-native application A, the application developer fills in the CPU and memory request statements in the resource fields of each container in the cloud-native application blueprint. The template definition example of the Helm Chart package is as follows:

[0368]

[0369] Next, declare the default values ​​for the resources required by each container in the cloud-native application blueprint in the Helm Chart package's values.yaml file. The key is resources, and under resources, mount the container resource definitions used by each container in each deployment. For example, the resource definitions required by container A in application A are as follows:

[0370]

[0371]

[0372] Next, in the user values ​​configuration of spd, define the operation and maintenance parameters that need to be modified by the resource as macro variables and declare the macro variables in the public property replacement. Use the property replacement with the type default and assign a default value. For example, if the operation and maintenance personnel need to modify the CPU and memory operation and maintenance parameters of container A in application A, the spd example is as follows:

[0373]

[0374]

[0375] In this embodiment, the operation and maintenance personnel can define application configuration attributes in the resource according to the user scale.

[0376] For example, in a large-scale scenario with 600,000 residential communities, operations personnel dynamically adjust the CPU and memory operation parameters of applications A, B, and C in the system through application configuration properties. An example of a cloud-native configuration file is as follows:

[0377]

[0378] For example, if the network management system needs to operate in a community scale of 300,000, the operation and maintenance personnel only need to update the resource to implement the system deployment operation.

[0379] In this embodiment, taking the configuration of CPU and memory operation and maintenance parameters of applications A, B, and C in the system as an example, the cloud native configuration file example is as follows:

[0380]

[0381] In this embodiment, the process of the deployer processing the application attribute replacement in the operation and maintenance configuration file is as follows:

[0382] S41, when the system is instantiated, the application attribute replacement configuration is replaced according to the operation and maintenance configuration file, and the attribute replacement variable definition list under each instance name is sorted according to the application instance name.

[0383] S42: The deployer processes the attribute replacement variables of each application and uses the variables with the same name defined in the operation and maintenance configuration file to replace the attribute replacement variables with the same name in the public attribute replacement of the development configuration file within the cloud native application.

[0384] S43, the deployer processes the macro variable definition of the public attribute in the user attribute, replaces the variable type (type) of the variable according to the attribute, and completes the injection of the variable value.

[0385] In step S44, the deployer uses the user values ​​configured after processing in step S43 to render the Helm Chart blueprint, completing the application instantiation action.

[0386] In this embodiment, operation and maintenance personnel can easily complete the configuration of application operation and maintenance parameters within the system when the system is deployed in different scale scenarios.

[0387] The following example involves deploying on different cloud platforms. Assuming the network management system needs to be deployed on different cloud platforms, common properties of applications within the system, such as image repositories and non-root user role configurations, are not universal across different cloud platforms. Therefore, common application properties cannot be determined during the development phase and must be modified by operations personnel during system deployment based on actual needs. These parameters must be defined in the values.yaml file within the Helm Chart package.

[0388] For example, the operation and maintenance environment is: the current network management system has cloud-native applications A, B, and C. The operation and maintenance personnel complete the image warehouse address configuration operation of the entire system by setting the general attribute replacement parameters of the operation and maintenance configuration file (resource file) according to the specific configuration of the system cloud platform image warehouse.

[0389] In actual application scenarios, a public attribute setting interface can be provided, allowing operation and maintenance personnel to implement one-click setting of public attributes within the system when deploying the system on different platforms.

[0390] For example, the application developer uses the development configuration file to define the public property configuration process as follows:

[0391] First, use Helm to describe a cloud-native application blueprint. Define the image repository used by the application in a specific Kubernetes resource template within the Helm Chart package's template directory using template variables. For example, for cloud-native application A, the application developer configures the image repository information for each container in the "image" field within the cloud-native application blueprint.

[0392] The following is an example of a Helm Chart package template definition:

[0393]

[0394]

[0395] Next, in the user values ​​configuration for spd, define the common properties that need to be modified by the resource as macro variables and declare the macro variables in the public property replacement. Use the property replacement with type default and assign a default value. Taking application A as an example, the spd example is as follows:

[0396]

[0397]

[0398] In this embodiment, the operator defines common configuration attributes in the operation and maintenance configuration file based on the specific information of the image repository in the operator's cloud environment. For example, if the cloud environment image repository address is quay.ocp4.example.com:8443, the operator uses the common configuration attributes to dynamically adjust the image repository information of all applications in the system.

[0399] An example of an operation and maintenance configuration file is as follows:

[0400]

[0401] In this embodiment, the deployer processes the application attribute replacement process in the operation and maintenance configuration file as follows:

[0402] S51, when the system is instantiated, obtain a variable list of common attribute replacement configurations in the operation and maintenance configuration file.

[0403] S52: The deployer processes the attribute replacement variables of each application and uses the attribute replacement variables defined in the general attribute replacement configuration to replace the attribute replacement variables with the same names under the public attribute replacement of the configuration file developed in the cloud native application.

[0404] S53, the deployer processes the public attribute macro variable definition in the user attribute, replaces the variable type according to the attribute, and completes the injection of the variable value.

[0405] In step S54, the deployer uses the user attribute configuration processed in step S53 to render the Helm Chart blueprint, completing the application instantiation action.

[0406] Through the above steps S51-S54, the relevant parameters in the public attributes can be replaced by the application attributes in the operation and maintenance configuration file, and the user attribute configuration is generated according to the parameter value of the replaced public attribute. The Helm Chart blueprint is rendered according to the user attribute configuration to complete the application instantiation.

[0407] In some embodiments, the network management system needs to be deployed on cloud platforms of different operators. Different cloud platforms have different operational characteristics, which application developers cannot determine during the development phase. Furthermore, operational characteristics are often not directly related to the business, but rather assist operations personnel in monitoring and optimizing application operations. When setting cloud platform operational properties, operations personnel must update applications as needed based on actual cloud platform support during system deployment. Unlike property replacement, these parameters do not need to be defined in the values.yaml file of the Helm Chart package.

[0408] In this embodiment, the operation and maintenance environment is as follows: the current network management system has cloud-native applications A, B, and C, and the operator's cloud platform has log collection and operation and maintenance features. The operation and maintenance personnel complete the addition of log collection sidecars for each application in the entire system by setting the delivery policy parameters of the cloud resource configuration file (resource).

[0409] Figure 14 A schematic diagram of the processing process of the delivery strategy provided in an embodiment of the present disclosure.

[0410] like Figure 14 As shown, in some embodiments, the process of delivering a policy may include:

[0411] like Figure 14As shown in "S1401, Describe application blueprints and define development configuration files," application developers use Helm to describe the cloud-native application blueprints for each application (A, B, and C) in the cloud-native system and define development configuration files.

[0412] Figure 14 For examples of application resources, see Figure 6 The description in , will not be repeated here.

[0413] like Figure 14 As shown in "S1402, Define Delivery Strategy," operations personnel define the delivery strategy in resource. Here, for each cloud-native application pod, the log collection container supported by the current cloud platform is updated as a sidecar. The resource example is as follows:

[0414]

[0415] like Figure 14 As shown in "S1403, Generate Resource Instance List", the deployer parses the development configuration files of each application in the system, combines them with the operation and maintenance configuration files submitted by the operation and maintenance personnel to complete attribute replacement and cloud native resource blueprint rendering operations, and converts the resource blueprint into a specific Kubernetes resource instance list.

[0416] like Figure 14 In "S1404, Update Resource Instance List," the deployer parses the delivery policy settings in the operation and maintenance configuration file and updates the specific Kubernetes resource instance lists for each application in the system output in step 3 according to JSON6902, ultimately completing the application deployment on the operator's cloud platform.

[0417] In the disclosed embodiments, operation and maintenance personnel can easily complete customized configuration of application operation and maintenance characteristics within the system based on the system operation and maintenance characteristics, innovatively enabling operation and maintenance personnel to have system-level application customization capabilities.

[0418] According to the parameter orchestration method of the embodiment of the present disclosure, in the field of application orchestration and instantiation in cloud-native scenarios, it can be used to solve problems such as component development involved in the application orchestration field in complex cloud-native application systems, exposure of cloud-native application configuration parameters, dependency management and parameter transfer between cloud-native applications, cross-application use of technical services, and coupling of concerns during system deployment, i.e., application instantiation.

[0419] For example, in the field of telecommunications management system deployment: With the continuous development and iteration of communication technology, traditional telecommunications system deployment solutions are limited by hardware specifications and the lack of uniformity among cloud platform providers, resulting in the inability to uniformly configure system development and operation and maintenance. Application development and deployment at different locations require independent planning and construction (i.e., chimney mode). The method disclosed in this disclosure can better unify the language, that is, application development does not need to focus on application deployment, but only needs to define the operation and maintenance parameters (CPU, memory, number of copies, mirror address, etc.) that are allowed to be adjusted during application deployment. Operation and maintenance personnel uniformly configure according to the actual cloud environment of the operator, and the two roles are decoupled from each other. At the same time, this disclosure can help operation and maintenance personnel quickly complete deployment configuration when deploying systems on different operators.

[0420] For example, in various 5G (fifth-generation mobile communication technology) industry applications: As the scope of 5G applications expands, various application models emerge one after another. Cloud platforms bear the heavy responsibility of supporting various industry customers in defining various industry applications. Different scenarios and applications have different requirements for cloud platform capabilities. The method disclosed in this paper can better define and expose the capabilities provided by the cloud platform, provide customization capabilities during application deployment, and assist in the definition and instantiation of 5G industry applications.

[0421] For example, in assembly-based architecture and assembly-based delivery scenarios, software version integration and delivery have evolved over the years, with increasingly shorter delivery cycles and the emergence of new technologies. Version delivery methods are also evolving in response to user business changes and the current digital transformation of enterprises. The parameter orchestration method disclosed herein utilizes a system assembly approach to parameterize versions in the deployment state. Operations and maintenance personnel can assemble the required business capabilities based on business development needs, conveniently adjusting system business functions and parameters for flexible assembly.

[0422] According to the method of the embodiment of the present disclosure, there is no need to modify the cloud platform when the system is deployed. Native applications build applications around the declarative application programming interface (API) of Kubernetes, without the need for customization and privatization, so that the delivery of complex cloud-native microservice systems can be met at a lower cost and learning cost. The cloud-native service instantiation configuration file, that is, the development configuration file (spd file), is standardized so that different application developers in the system have a unified and standardized definition method. The cloud resource configuration file, that is, the operation and maintenance configuration file (resource file), is standardized to facilitate the operation and maintenance personnel to perform attribute replacement and application customization configuration. The entire process can seamlessly connect to the cloud environment ecological capabilities, such as security, monitoring, continuous integration (CI) CI / continuous delivery (CD), software development framework (GitOps), etc.

[0423] An embodiment of the present disclosure provides a parameter arrangement device. Figure 15 This is a block diagram of a parameter arrangement device provided by an embodiment of the present disclosure. Figure 15 , an embodiment of the present disclosure provides a parameter arrangement device, and the parameter arrangement device 1500 may include the following modules.

[0424] An acquisition module 1510 is configured to acquire user attributes from a development configuration file of a cloud-native application, where the user attributes include public attributes, and the public attributes are used to indicate attributes that are allowed to be modified through the operation and maintenance configuration file during the deployment of the cloud-native application.

[0425] The replacement module 1520 is used to replace the parameter values ​​of the matching public attributes in the user attributes with the parameter values ​​of the application dynamic attributes in the preset operation and maintenance configuration file during the cloud native application deployment process;

[0426] A generating module 1530 is configured to generate a user attribute configuration according to the replaced parameter values ​​of the matching public attributes;

[0427] The updating module 1540 is configured to update the original orchestration file of the cloud native application according to the user attribute configuration to obtain an updated orchestration file.

[0428] In some embodiments, the device also includes: a first setting module, which is used to set the attributes that are allowed to be modified as macro variables in the user attributes of the development configuration file before obtaining the user attributes in the development configuration file of the cloud native application, and declare the macro variables in the public attributes; the macro variables are used to pass the parameter values ​​of the corresponding attributes.

[0429] In this embodiment, when the application dynamic attributes include common attributes, the replacement module 1520, when used to replace the parameter value of the matching public attribute in the user attribute with the parameter value of the application dynamic attribute in the preset operation and maintenance configuration file, is specifically used to: determine the common attribute replacement parameter preset in the common attribute; obtain the first matching attribute in the public attribute as a macro variable; wherein the parameter name of the first matching attribute matches the parameter name in the common attribute replacement parameter; and replace the parameter value of the first matching attribute with the parameter value of the common attribute replacement parameter.

[0430] In some embodiments, when the application dynamic attributes also include application attributes, the replacement module 1520, after being used to replace the parameter value of the first matching attribute with the parameter value of the general attribute replacement parameter, is also used to: determine the application attribute replacement parameter of the application instance preset in the application attribute; determine the second matching attribute in the public attribute as a macro variable, the name of the application instance is the same as the application instance name in the development configuration file, and the parameter name corresponding to the second matching attribute matches the parameter name in the application attribute replacement parameter; use the parameter value of the application attribute replacement parameter to replace the parameter value of the second matching attribute.

[0431] In some embodiments, the development configuration file includes component dependency information, which is used to indicate the service instances in the cloud environment system that the cloud native application depends on; the user attributes also include private attributes, which are used to indicate the attributes of the service instance that are allowed to be replaced.

[0432] In this embodiment, before the replacement module 1520 is used to replace the parameter value of the matching public attribute in the user attribute with the parameter value of the application dynamic attribute in the preset operation and maintenance configuration file, it is also used to: obtain the private attribute replacement parameter preset in the private attribute; wherein the private attribute replacement parameter includes: the parameter name and parameter value source in the predetermined resource attribute of the service instance, the parameter value source is defined as a macro function expression, and the macro function expression is used to indicate: the parameter value of the predetermined resource attribute stored in the cloud environment system resource; through the macro function expression, the parameter value of the predetermined resource attribute is obtained from the cloud environment system resource; the parameter value of the predetermined resource attribute obtained from the cloud environment system resource is used to replace the macro function expression; obtain the resource configuration file created in the cloud native application deployment tenant, the resource configuration file includes the parameter name and corresponding parameter value of the predetermined resource attribute; obtain the third matching attribute in the private attribute as a macro variable, the parameter name corresponding to the third matching attribute matches the parameter name of the predetermined resource attribute; when the variable type of the macro variable corresponds to the attribute type of the predetermined resource attribute, the parameter value of the created predetermined resource attribute is used to replace the parameter value of the third matching attribute.

[0433] In some embodiments, the macro function expression includes input parameter information and query path information; the input parameter information includes: application version number, application type and naming information; when the replacement module 1520 is used to obtain the parameter value of the predetermined resource attribute from the cloud environment system resources through the macro function expression, it is specifically used to: search for the corresponding application resource list from the cloud environment system resources according to the application version number; search for application resources of the same type as the application type from the application resource list; generate query link information according to the application version number, resource name and naming information of the found application resources; query the resource data of the application resource from the cloud native application server through the query link information; use the query path information to query and obtain the parameter value of the predetermined resource attribute under the corresponding path of the resource data as the parameter value of the predetermined resource attribute in the cloud environment system resources.

[0434] In some embodiments, the update module 1540 is specifically configured to merge the user attribute configuration with the original orchestration file to obtain an updated orchestration file; wherein, when the user attribute configuration and the original orchestration file have the same attribute, the parameter value of the corresponding attribute in the updated orchestration file adopts the parameter value of the attribute in the user attribute configuration.

[0435] In some embodiments, the parameter orchestration device further includes: a rendering module, configured to obtain a cloud-native application blueprint corresponding to the original orchestration file after obtaining the updated orchestration file; and generate an executable orchestration file using the updated orchestration file, wherein the executable orchestration file is used to perform orchestration of the cloud-native application.

[0436] In some embodiments, the parameter orchestration device also includes: an update module, which is used to obtain the delivery strategy in the operation and maintenance configuration file after generating the executable orchestration file, and the delivery strategy includes preset policy parameters, and the policy parameters are used to indicate: the target resource and the corresponding resource update operation; obtain the target resource from the cloud environment system resources, and the target resource is: the executable orchestration file resource that matches the target resource; and perform the corresponding resource update operation on the target resource.

[0437] In some embodiments, it also includes: a first receiving module, used to receive input application deployment parameters through a first interactive interface during the cloud native application deployment process, the application deployment parameters include at least one of the following: cloud environment characteristic parameters and application scale attributes; or, a second receiving module, used to receive an execution instruction for a predetermined macro function expression through a second interactive interface, the execution instruction is used to trigger: according to the predetermined macro function expression, obtain the parameter value of the predetermined resource attribute stored in the cloud environment system resource; or, an editing module, used to edit the predetermined operation and maintenance parameters through a third interactive interface, the predetermined operation and maintenance parameters are used to configure the operation and maintenance parameters under different cloud environment scales and operation and maintenance difference scenarios.

[0438] According to the parameter orchestration device of the embodiment of the present disclosure, during the cloud-native application deployment process, the parameter values ​​of the application dynamic attributes in the operation and maintenance configuration file can be used to replace the parameter values ​​of the matching public attributes contained in the user attributes in the development configuration file of the cloud-native application. The replaced parameter values ​​of the matching public attributes are then used to generate a user attribute configuration, and the generated user attribute configuration is used to update the original orchestration file of the cloud-native application to obtain an updated orchestration file. This parameter orchestration method provides operation and maintenance personnel with application customization capabilities, allowing them to adaptively orchestrate the parameters of interest based on the operation and maintenance configuration file when deploying a cloud-native application system.

[0439] According to this device, the attributes that operation and maintenance personnel are concerned about can be replaced by the parameter values ​​of public attributes in the development configuration file. Without changing the original cloud platform, the development configuration of the cloud native application can be "decoupled" according to the focus of the role (operation and maintenance personnel), and the attributes that the operation and maintenance personnel need to pay attention to can be exposed to the operation and maintenance configuration file so that they can be modified by the operation and maintenance personnel when the cloud native application is deployed. In this way, the application can be customized through parameter replacement, so that the operation and maintenance personnel have system-level parameter orchestration capabilities when deploying cloud native applications, solving the problem of poor application customization capabilities in complex cloud native application systems.

[0440] Reference Figure 16 The embodiment of the present disclosure provides a parameter orchestration device (such as a deployer), which includes a memory 1601 and a processor 1602; the memory 1601 stores a computer program that can be executed by the processor, and when the computer program is executed by the processor 1602, any parameter orchestration method of the embodiment of the present disclosure is implemented.

[0441] An embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon. When the computer program is executed by a processor, any parameter arrangement method of the embodiment of the present disclosure is implemented.

[0442] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, which can realize information exchange between the memory and the processor, including but not limited to the data bus (Bus), etc.

[0443] Those skilled in the art will appreciate that all or some of the steps, systems, and functional modules / units in the apparatus disclosed above may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0444] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation.

[0445] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As is well known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; compact disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cassettes, tapes, disk storage or other magnetic storage; any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0446] The present disclosure has disclosed example embodiments, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly indicated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A parameter arrangement method, wherein: include: Obtaining user attributes in a development configuration file of a cloud-native application, where the user attributes include public attributes, and the public attributes are used to indicate attributes that are allowed to be modified through an operation and maintenance configuration file during the deployment of the cloud-native application; During the deployment of the cloud-native application, the parameter values ​​of the application dynamic attributes in the preset operation and maintenance configuration file are used to replace the parameter values ​​of the matching public attributes in the user attributes; Generating a user attribute configuration according to the replaced parameter value of the matching public attribute; An original orchestration file of the cloud native application is updated according to the user attribute configuration to obtain an updated orchestration file.

2. The method according to claim 1, wherein Before obtaining the user attributes in the development configuration file of the cloud native application, the method further includes: setting the attributes that can be modified as macro variables in the user attributes of the development configuration file, and declaring the macro variables in the public attributes; the macro variables are used to transfer parameter values ​​of corresponding attributes; In the case where the application dynamic attributes include common attributes, the use of the parameter values ​​of the application dynamic attributes in the preset operation and maintenance configuration file to replace the parameter values ​​of the matching public attributes in the user attributes includes: Determining a preset universal attribute replacement parameter in the universal attribute; Obtaining a first matching attribute in the public attribute as a macro variable; wherein a parameter name of the first matching attribute matches a parameter name in the general attribute replacement parameter; The parameter value of the general attribute replacement parameter is used to replace the parameter value of the first matching attribute.

3. The method according to claim 2, wherein: In a case where the application dynamic attribute further includes an application attribute, after replacing the parameter value of the first matching attribute with the parameter value of the general attribute replacement parameter, the method further includes: Determine application attribute replacement parameters of the application instance preset in the application attributes; Determining a second matching attribute in the public attribute as a macro variable, the name of the application instance is the same as the application instance name in the development configuration file, and the parameter name corresponding to the second matching attribute matches the parameter name in the application attribute replacement parameter; The parameter value of the second matching attribute is replaced by the parameter value of the application attribute replacement parameter.

4. The method according to claim 1, wherein The development configuration file includes component dependency information, which is used to indicate the service instance in the cloud environment system that the cloud native application depends on; the user attributes also include private attributes, which are used to indicate the attributes of the service instance that are allowed to be replaced; Before replacing the parameter value of the matching public attribute in the user attribute with the parameter value of the application dynamic attribute in the preset operation and maintenance configuration file, the method further includes: Obtaining a private attribute replacement parameter preset in the private attribute; wherein the private attribute replacement parameter includes: a parameter name and a parameter value source in a predetermined resource attribute of the service instance, wherein the parameter value source is defined as a macro function expression, and the macro function expression is used to indicate: a parameter value of the predetermined resource attribute stored in a cloud environment system resource; Obtaining the parameter value of the predetermined resource attribute from the cloud environment system resources through the macro function expression; Replacing the macro function expression with the parameter value of the predetermined resource attribute obtained from the cloud environment system resource; Obtain a resource configuration file created for the cloud-native application deployment tenant, wherein the resource configuration file includes a parameter name and a corresponding parameter value of the predetermined resource attribute; Acquire a third matching attribute as a macro variable in the private attribute, wherein a parameter name corresponding to the third matching attribute matches a parameter name of the predetermined resource attribute; In a case where the variable type of the macro variable corresponds to the attribute type of the predetermined resource attribute, the parameter value of the third matching attribute is replaced by the created parameter value of the predetermined resource attribute.

5. The method according to claim 4, wherein The macro function expression includes input parameter information and query path information; The input parameter information includes: application version number, application type and naming information; the parameter value of the predetermined resource attribute is obtained from the cloud environment system resource through the macro function expression, including: According to the application version number, searching for a corresponding application resource list from the cloud environment system resources; Searching for an application resource of the same type as the application from the application resource list; Generate query link information according to the application version number, resource name and naming information of the found application resource; querying resource data of the application resource from the cloud-native application server through the query link information; The query path information is used to query and obtain the parameter value of the predetermined resource attribute under the path corresponding to the resource data as the parameter value of the predetermined resource attribute in the cloud environment system resource.

6. The method according to claim 1, wherein The updating of the original orchestration file of the cloud native application according to the user attribute configuration to obtain an updated orchestration file includes: The user attribute configuration is merged with the original orchestration file to obtain an updated orchestration file; wherein, when the user attribute configuration and the original orchestration file have the same attributes, the parameter value of the corresponding attribute in the updated orchestration file adopts the parameter value of the attribute in the user attribute configuration.

7. The method according to claim 1 or 6, wherein: After obtaining the updated arrangement file, the method further includes: Obtaining a cloud-native application blueprint corresponding to the original orchestration file; An executable orchestration file is generated using the updated orchestration file, where the executable orchestration file is used to orchestrate the cloud-native application.

8. The method according to claim 1, wherein After generating the executable arrangement file, the method further includes: Obtaining a delivery strategy in the operation and maintenance configuration file, wherein the delivery strategy includes preset strategy parameters, and the strategy parameters are used to indicate: a target resource and a corresponding resource update operation; Acquire the target resource from the cloud environment system resources, where the target resource is: an executable arrangement file resource that matches the target resource; Perform the corresponding resource update operation on the target resource.

9. The method according to claim 1, wherein During the cloud native application deployment process, the method further includes: receiving input application deployment parameters through the first interactive interface, the application deployment parameters including at least one of the following: cloud environment characteristic parameters and application scale attributes; Alternatively, receiving an execution instruction for a predetermined macro function expression through the second interactive interface, the execution instruction is used to trigger: obtaining a parameter value of the predetermined resource attribute stored in the cloud environment system resource according to the predetermined macro function expression; Alternatively, the third interactive interface is used to edit predetermined operation and maintenance parameters, where the predetermined operation and maintenance parameters are used to configure operation and maintenance parameters under different cloud environment scales and operation and maintenance difference scenarios.

10. An electronic device comprising a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements the parameter arrangement method according to any one of claims 1 to 9.

11. A computer-readable medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the method for parameter arrangement according to any one of claims 1 to 9 is implemented.

Images