Configuration file determination method and device, storage medium and electronic device
Through the hierarchical dependency structure, sub-templates are deployed layer by layer and configuration files are generated, the problems of complex application resource orchestration and sequential deployment of dependencies are solved, and the effective automated deployment and operation of applications are realized.
Patent Information
- Application Number
- CN202210126670.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-02-10
- Publication Date
- 2024-12-31
- Estimated Expiration
- 2042-02-10
AI Technical Summary
The existing technology cannot effectively orchestrate resource for complex applications and cannot deploy application resources in order of service dependencies, resulting in cumbersome orchestration and error-prone.
By obtaining the configuration item parameters of the target application, analyzing the application template files, using the hierarchical dependency structure to deploy sub-templates layer by layer and loading resource files, generating configuration files for operation and maintenance, simplifying the dependency description and realizing the deployment of services in dependency order.
It realizes resource orchestration and automated deployment operation and maintenance of complex applications, simplifies dependency description, ensures that services are deployed in dependency order, and improves deployment efficiency and reliability.
Smart Images

Figure CN114461304B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of cloud computing and container cloud technology, and in particular to container cloud runtime management technology. Specifically, it relates to a configuration file determination method and device, a storage medium, and an electronic device. Background Art
[0002] Kubernetes is a container orchestration platform that implements basic functions such as full lifecycle management of containers, elastic scaling, and operation and maintenance monitoring. It provides a variety of container orchestration objects, such as workload resources such as Deployment, Statefulset, DeamonSet, and Job, as well as encapsulation of a variety of basic configuration resources, such as ConfigMap, Secret, and Service. Kubernetes mainly focuses on the orchestration and scheduling of containers, and manages individual services and components. For users, they are more concerned about the orchestration and runtime management of the entire application, including the combination of multiple containers and services, and the management of their dependencies. Kubernetes needs to use yaml configuration files to define resources. For complex applications, they often contain dozens of services with complex dependencies between services. As the number of services increases, describing an application requires the combination of a large number of kubernetes resources. Using yaml files to describe the resources of multiple services is not only cumbersome, but also prone to errors. At the same time, the yaml resource definition of native Kubernetes does not support the description of service dependencies, and cannot deploy the application's services in the order of dependencies.
[0003] Among the orchestration solutions of related technologies, the most popular one is Helm's resource management solution based on Charts packages. You can define templates for service resource descriptions in Templates, and describe service dependencies in requirements.yaml, which can simplify the templated definition description of applications. However, the helm template syntax definition is complex and difficult to visualize. Although it provides dependency descriptions, it only associates the dependent Charts packages and does not support the processing of service dependencies at runtime, nor can it deploy services in the order of dependencies.
[0004] In view of the above problems, the existing technology is unable to orchestrate resources for complex applications and to deploy application resources in an orderly manner, and no effective solution has been proposed so far. Summary of the invention
[0005] The embodiments of the present invention provide a method and device for determining a configuration file, a storage medium, and an electronic device, so as to at least solve the problems in the prior art that resources for complex applications cannot be orchestrated and application resources cannot be deployed in an orderly manner.
[0006] According to one aspect of an embodiment of the present invention, a method for determining a configuration file is provided, comprising: obtaining configuration item parameters of a target application, and querying a target database according to the configuration item parameters to obtain an application template file of the target application; parsing the application template file to obtain multiple sub-templates included in the application template file and hierarchical information of each sub-template, wherein the hierarchical information of each sub-template is used to indicate the hierarchy of each sub-template in the application template file; deploying each of the multiple sub-templates layer by layer according to the hierarchical information of each sub-template, and loading a corresponding resource file for each deployed sub-template; and determining a configuration file for operating and maintaining the target application according to the loading information of the resource file in each sub-template.
[0007] According to another aspect of an embodiment of the present invention, a method and device for determining a configuration file is also provided, including: an acquisition module, used to acquire configuration item parameters of a target application, and query in a target database according to the configuration item parameters to obtain an application template file of the target application; a parsing module, used to parse the application template file, and obtain multiple sub-templates included in the application template file and hierarchical information of each sub-template, wherein each sub-template; a deployment module, used to deploy each of the multiple sub-templates layer by layer according to the hierarchical information of each sub-template, and load the corresponding resource file for each deployed sub-template; a determination module, used to determine the configuration file used for operating and maintaining the target application according to the loading information of the resource file in each sub-template.
[0008] According to another aspect of the embodiments of the present invention, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute a method in any one of the method embodiments when running.
[0009] According to another aspect of an embodiment of the present invention, there is further provided an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute a method in any one of the above method embodiments through the computer program.
[0010] In an embodiment of the present invention, configuration item parameters of a target application are obtained, and a query is performed in a target database according to the configuration item parameters to obtain an application template file of the target application; the application template file is parsed to obtain multiple sub-templates and hierarchical information of each sub-template included in the application template file, wherein the hierarchical information of each sub-template is used to indicate the hierarchy of each sub-template in the application template file; each of the multiple sub-templates is deployed layer by layer according to the hierarchical information of each sub-template, and a corresponding resource file is loaded for each deployed sub-template; a configuration file for operating and maintaining the target application is determined according to the loading information of the resource file in each sub-template, that is, a hierarchical dependency structure is used to describe the dependency relationship of services in an application, which greatly simplifies the data structure of the dependency description, makes the processing logic of deploying the target application relatively simple, and can conveniently realize the graphical display of the instance topology structure of the target application at runtime, thereby achieving the purpose of resource orchestration for a complex target application, thereby achieving the technical effect of effective and rapid automated deployment and operation of the target application, thereby solving the technical problem that the prior art cannot orchestrate resources for complex applications and orderly deploy application resources. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:
[0012] Figure 1 is a hardware structure block diagram of a computer terminal according to a method for determining a configuration file according to an embodiment of the present invention;
[0013] Figure 2 is a flowchart of a method for determining a configuration file according to an embodiment of the present invention;
[0014] Figure 3 A schematic diagram of the structure of a service template of an optional embodiment of the present invention;
[0015] Figure 4 A schematic diagram of a structure of hierarchical dependency according to an optional embodiment of the present invention;
[0016] Figure 5 is a flowchart of an application deployment method according to an optional embodiment of the present invention;
[0017] Figure 6 It is a schematic diagram of the structure of a device for determining a configuration file according to an embodiment of the present invention. DETAILED DESCRIPTION
[0018] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.
[0019] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0020] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal, a mobile terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 FIG. 1 is a hardware structure block diagram of a computer terminal of a method for determining a configuration file according to an embodiment of the present invention. Figure 1 As shown, the computer terminal 10 may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Optionally, the computer terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. Figure 1 More or fewer components as shown, or with Figure 1 Equivalent functions or comparisons shown Figure 1 A different configuration with more features is shown.
[0021] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for determining the configuration file in the embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0022] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0023] According to one aspect of an embodiment of the present invention, a method for determining a configuration file is provided. Optionally, as an optional implementation, the method for determining a configuration file may be, but is not limited to, applied to: Figure 1 in the environment shown.
[0024] Optionally, in this embodiment, the terminal device may be a terminal device configured with a target client, which may include but is not limited to at least one of the following: a mobile phone (such as an Android phone, an iOS phone, etc.), a laptop, a tablet computer, a PDA, a MID (Mobile Internet Devices), a PAD, a desktop computer, a smart TV, etc. The target client may be a video client, an instant messaging client, a browser client, an education client, etc. The network may include but is not limited to: a wired network, a wireless network, wherein the wired network includes: a local area network, a metropolitan area network and a wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that realize wireless communication. The server may be a single server, or a server cluster consisting of multiple servers, or a cloud server. The above is only an example, and this embodiment does not impose any limitation on this.
[0025] As an optional implementation, Figure 2 As shown, the method for determining the above configuration file includes:
[0026] Step S202, obtaining configuration item parameters of the target application, and querying in the target database according to the configuration item parameters to obtain an application template file of the target application;
[0027] Optionally, the application template file in the target database needs to be predefined. Specifically, the predefined application template consists of template metadata, service template list, configuration input parameter list, and output parameter list. Configuration input parameters are to replace the constantly changing values in the application with variables. During deployment, the combination of application template + configuration items facilitates users to deploy corresponding applications to different environments. The service template list includes multiple sub-templates, each of which consists of template metadata, resource list, configuration input parameter list, and output parameter list. The template metadata is used to indicate the fields that constitute the template framework. For example, the fields may be the template name, template version, the directory to which the template belongs, the template description, and the template tag list.
[0028] Step S204, parsing the application template file to obtain multiple sub-templates included in the application template file and hierarchical information of each sub-template, wherein the hierarchical information of each sub-template is used to indicate that each sub-template loads a corresponding resource file at a hierarchical level of each sub-template in the application template file;
[0029] Step S206, deploying each of the multiple sub-templates layer by layer according to the hierarchical information of each sub-template, and loading corresponding resource files into each of the deployed sub-templates;
[0030] Step S208: determining a configuration file for operating and maintaining the target application according to the loading information of the resource file in each sub-template.
[0031] Through the above steps, the configuration item parameters of the target application are obtained, and the target database is queried according to the configuration item parameters to obtain the application template file of the target application; the application template file is parsed to obtain multiple sub-templates included in the application template file and the hierarchical information of each sub-template, wherein the hierarchical information of each sub-template is used to indicate the hierarchy of each sub-template in the application template file; according to the hierarchical information of each sub-template, each of the multiple sub-templates is deployed layer by layer, and the corresponding resource file is loaded for each deployed sub-template; according to the loading information of the resource file in each sub-template, the configuration file for operating and maintaining the target application is determined, that is, the hierarchical dependency structure is used to describe the dependency relationship of the services in the application, which greatly simplifies the data structure of the dependency description, makes the processing logic of deploying the target application relatively simple, and can conveniently realize the graphical display of the instance topology structure of the target application at runtime, thereby achieving the purpose of resource orchestration for the complex target application, thereby achieving the technical effect of effective and rapid automated deployment and operation of the target application, thereby solving the technical problem that the existing technology cannot orchestrate resources for complex applications and orderly deploy application resources.
[0032] It should be noted that the above-mentioned sub-templates and application template files can be displayed as graphical orchestrations, and the topology view can be displayed by dragging and dropping. Then, when a problem occurs in a sub-template in the application template file, the corresponding sub-template that failed to be enabled can be quickly found, allowing users to be more intuitive when deploying the target application, and to quickly locate the orchestration test before the application goes online based on the dependencies between the layers.
[0033] In an exemplary embodiment, after parsing the application template file to obtain multiple sub-templates included in the application template file and hierarchical information of each sub-template, the method further includes: obtaining an information description of metadata corresponding to each sub-template; and determining attributes of each sub-template based on the information description of metadata corresponding to each sub-template, wherein the attributes of each sub-template are used to indicate a template type of each sub-template, and the template type of each sub-template is used to determine a loading method of a resource file corresponding to each sub-template.
[0034] In an exemplary embodiment, determining the attributes of each sub-template according to the information description of the metadata corresponding to each sub-template includes: when the multiple sub-templates include a first group of sub-templates, and the template type indicated by the attributes of each sub-template in the first group of sub-templates is a service template, determining that the layer-by-layer deployment mode corresponding to each sub-template in the first group of sub-templates is direct deployment; when the multiple sub-templates include a second group of sub-templates, and the template type indicated by the attributes of each sub-template in the second group of sub-templates is a sub-application template, determining that the layer-by-layer deployment mode corresponding to each sub-template in the second group of sub-templates is call deployment, wherein the call deployment is used to indicate a recursive call to other already orchestrated applications in a nested manner.
[0035] In short, due to the different types of sub-templates, different deployment methods are required during deployment. Therefore, it is necessary to determine whether the sub-template is a service template or a sub-application template based on the template metadata information description. If it is a sub-application template, recursive calls are made (that is, other application templates that have been arranged are arranged as components of the application template into the template of the current target application), and the sub-application template is deployed. After the sub-application is deployed, the subsequent process continues. To ensure deployment performance, the nesting level of sub-application templates is limited to 1. If it is a service template, the service template is deployed directly.
[0036] There are multiple ways to deploy the sub-template corresponding to the target application and load the resource files in the above step S206. In an optional embodiment, it can be implemented by the following scheme: according to the hierarchical information of each sub-template, the multiple sub-templates are hierarchically classified to obtain multiple sub-template sets, wherein the sub-templates with the same hierarchy among the multiple sub-templates are classified into a sub-template set, and each sub-template set in the multiple sub-template sets corresponds to a hierarchy; starting from the sub-template set corresponding to the smallest hierarchy, the sub-template sets corresponding to different hierarchies are deployed layer by layer according to the hierarchy order, and after the sub-template set is deployed, the resource files corresponding to the sub-templates in the sub-template set are loaded.
[0037] It is understandable that when deploying multiple sub-templates and loading corresponding resource files, they need to be loaded layer by layer according to the hierarchy to ensure the dependency between different levels, so that corresponding connections are established between the functions of the related target applications, and the dependency between the service template of the previous layer and the service template of the next layer is clarified.
[0038] In an exemplary embodiment, determining a configuration file for operating and maintaining the target application based on the loading information of the resource file in each sub-template includes: when the configuration item parameters of the target application do not include input parameters, obtaining parameter description information corresponding to the loading information of each sub-template, and determining the input parameter variable value of each sub-template according to the parameter description information; replacing the variable placeholder of each sub-template with the input parameter variable value to obtain the configuration file for operating and maintaining the target application; or when the configuration item parameters of the target application include input parameters, determining the input parameter name in the configuration item parameter, matching the input parameter name in a preset parameter library, and obtaining the target input parameter variable value corresponding to the configuration item parameter; replacing the variable placeholder of each sub-template with the target input parameter variable value to obtain the configuration file for operating and maintaining the target application.
[0039] In an exemplary embodiment, the input parameter variable value of each sub-template is determined according to the parameter description information, including: when the input-output relationship is carried in the parameter description information and each sub-template does not belong to the minimum level, obtaining a reference description of each sub-template; wherein the reference description includes: the parameter name contained in the loaded resource file and the output parameters of each sub-template after the resource file is loaded in other levels before the level where each sub-template is currently located; determining the matching result between the target parameter name corresponding to the output parameter of each sub-template after the resource file is loaded in other levels and the parameter name contained in the resource file; when the matching result indicates that the parameter name contained in the resource file has a matching output parameter, using the specific parameter value of the output parameter as the input parameter variable value of each sub-template.
[0040] Optionally, load the resource file of the sub-template, and parse the input-output relationship description from the sub-template input parameter description. The sub-template input parameter sources include: 1) The output parameters of the dependent service in the previous layer are referenced through service.${serviceName}.output.{param} description. 2) The output parameters of the dependent sub-application in the previous layer are referenced through subapp.${appName}.output.{param} description. 3) The input parameters of the application configuration items entered when deploying the application are referenced through app.input.${param}.
[0041] Optionally, when parsing the input-output relationship, the service instance or application instance deployed in the previous layer is searched according to the service name or sub-application name in the reference description, and then the specific value is matched from the output parameter according to the parameter name. If the reference description is an application configuration item input parameter, the specific value is matched directly from the configuration item input parameter according to the parameter name. After obtaining the value (that is, the input parameter variable value), it is used as the input parameter of the sub-template to replace the variable placeholder in the yaml resource file in the sub-template (equivalent to the configuration file in the embodiment of the present invention), thereby completing the rendering of the yaml resource file.
[0042] In an exemplary embodiment, after determining the configuration file for operating and maintaining the target application based on the loading information of the resource file in each sub-template, the method further includes: sending the configuration file to a container orchestration platform, and listening to a workload ready event created by the container orchestration platform based on the configuration file; wherein the workload ready event is used to determine that the status of the corresponding function of the target application is an online status; determining the number of creation of the workload ready events corresponding to the application template file; and when the creation number is greater than the number of the multiple sub-templates, determining that the target application is ready to go online.
[0043] For example, the rendered kubernetes yaml resource object is sent to the container orchestration platform kubernetes, and configuration resources such as volume (object), secret (sensitive information configuration information), configmap (configuration map) are created first, and then workload resources such as deployment (scheduling) or statefulset (stateful set) are created. After all services at this level have completed resource creation, listen to the workload ready (Ready) event of kubernetes for all services at this level. When the ready event of a service is reported, the status of the service instance in the application instance is updated to ready for online, and it is determined whether all services at this level are ready. If not, continue to listen. After the status of all services at this level is ready, the deployment of the next level service template is carried out, and this process is repeated until the deployment of all levels is completed. After the deployment of all levels is completed, the application status is changed to ready for online, and the entire deployment process is completed.
[0044] In order to better understand the technical solutions of the embodiments of the present invention and the optional embodiments, the process of the method for determining the configuration file is explained below with reference to examples, but it is not intended to limit the technical solutions of the embodiments of the present invention.
[0045] As an optional embodiment, a Kubernetes-based application orchestration deployment method and device are provided. The design key points are to use template metadata, template resource list, and custom parameter list to define application templates, and use directed acyclic graphs to define resource dependencies. During deployment, vertices with an out-degree of 0 are cyclically obtained from the directed graph for deployment. After the resources are deployed and executed, the vertices corresponding to the resources are removed from the directed graph to promote the execution of subsequent resources, thereby realizing runtime dependency processing.
[0046] Secondly, the above only implements the graphical display of the topology of the runtime application instance and solves the dependencies of various services in the application. Generally speaking, to simplify the management of various workload resources and configuration resources in complex applications, it is necessary to implement template management similar to helm charts, and organize various yaml files into a file collection by directory. This method uses the directed acyclic graph DAG to describe the dependencies between services, but it is more complicated to describe the yaml resource configuration files of multiple services as DAG structures in the file. It is more difficult to use graphical methods to orchestrate, generate, or parse and display such application templates, and the performance consumption of the program is also more serious.
[0047] Thirdly, a directed acyclic graph is used to describe the service dependencies, which solves the problem of sequential startup of deployed services during application runtime. However, the directed acyclic graph data structure used to describe the service in the application template resource yaml file is relatively complex. The description generated in the template resource yaml file based on the graphical topology structure, or the implementation logic of parsing the template file description into a graphic is complex, which also affects the performance of the program. In runtime management, when deploying application templates to handle dependencies, it is necessary to implement a breadth-first traversal of the graph. The algorithm has a time complexity and space complexity of O(V+E), while the traversal complexity of hierarchical dependencies is O(V), and the algorithm logic implementation is also much simpler. In terms of the time it takes to complete the deployment of the application, the two are actually similar. For applications deployed in dependency order, the entire completion time is calculated based on the time it takes for the last service to start and be ready. The time it takes to complete the deployment of the application can be expressed as:
[0048] t=D×Max[S t ];
[0049] Among them, D represents the maximum dependency depth in the directed acyclic graph structure and the maximum number of levels in the hierarchical dependency structure. For the same application, the two are the same; S t In the directed acyclic graph structure, it represents the maximum ready time of a service in the services with the same dependency depth. In the hierarchical dependency structure, it represents the maximum ready time of a service in the services at the same level. Since the hierarchical dependency structure does not distinguish the specific dependency relationship, the number of services at the same level will be more than that in the directed acyclic graph, but the services at the same level are deployed concurrently. tTherefore, the time required to complete the deployment of the corresponding applications of the two structures is not much different.
[0050] As an optional embodiment, a service orchestration and dependency management method and system based on container cloud technology are also provided. The design point is to configure multiple initialization containers for the services in each application, wherein each initialization container is used to detect whether other management services that have dependencies on the startup of the service can be started normally, and to determine whether the service is started or continues to wait based on the detection results of the associated services, so as to realize the startup of the services in the application in the order of dependencies. However, the main disadvantage of its design is the additional introduction of initialization containers, which increases the complexity. In a service, multiple initialization containers are used to describe the dependencies between services, and it is difficult to use a graphical method to orchestrate, generate, or parse and display such application templates. In terms of runtime management, the dependency processing is realized by waiting for the initialization container. In essence, all service-related resources of the application are sent to kubernetes at one time, but the dependent services are only waiting for the readiness of the initialization container. The topological structure display of the application at runtime is not friendly enough. In addition, the introduction of the initialization container increases the complexity of the description structure, and the resource description file and the graphical conversion are difficult, making it difficult to realize the graphical orchestration of the application, and the topological structure display of the application at runtime is not friendly enough.
[0051] It should be noted that native kubernetes does not support the processing of dependencies between services. Although the helm template implements template management of service resources, it does not support the processing of dependencies between services. All service-related resources under the application are directly sent to kubernetes at one time. However, due to the service startup sequence, some services may fail to start because the dependent services are not ready. In addition, since there is no dependency description, the topology of the runtime application instance cannot be graphically displayed, which makes it inconvenient to manage the runtime status of the application and cannot achieve automatic deployment and operation of the application.
[0052] An optional embodiment of the present invention proposes an application orchestration and deployment solution based on Kubernetes, which uses a hierarchical dependency structure to describe the dependency relationships of services in an application, greatly simplifies the data structure of the dependency description, and converts the graphical description into a template file description, and the template file is parsed into a graphical description, so that the graphical orchestration of the application can be easily realized. For runtime management, the processing logic deployed according to the dependency sequence also becomes relatively simple, and the graphical display of the topological structure of the runtime application instance can be easily realized. For complex applications, application definition and deployment can be realized quickly, and template management of applications and graphical orchestration of templates can be performed. The processing of runtime dependencies is supported during deployment, so that complex applications can be automatically deployed and maintained.
[0053] Optionally, in order to facilitate application resource management and application replication in multiple environments, it is necessary to template the application resources. Figure 3 This is a structural diagram of the service template of an optional embodiment of the present invention; through the application template, resources are reasonably organized to achieve efficient resource management and rapid deployment of applications. Specifically, the application template definition consists of template metadata, service template list, configuration input parameter list, and output parameter list. Configuration input parameters are to replace the constantly changing values in the application with variables. During deployment, the combination of application template + configuration items facilitates users to deploy corresponding applications to different environments. The service template is a basic component of the application template and a basic component of application orchestration. The definition of the service template consists of template metadata, resource list, configuration input parameter list, and output parameter list. The service template is a centralized management of service-related resources.
[0054] Furthermore, the service template encapsulates the YAML description files of the service-related workload resources deployment or statefulset and the YAML description files of the configuration resources volume, secret, configmap, and service into a file collection, and defines the metadata of the service template, replaces the constantly changing values in the service with variables, and defines them as configuration input parameters. During deployment, the program passes the configuration items into the input parameters to complete the service template rendering. The output parameters are variables generated when the service is running, mainly the domain name of the service or the IP address of the pod. These variables can be used as input parameters for subordinate dependent services. The service template achieves relatively independent management by encapsulating and defining resources. As a basic component of application template orchestration, it can easily implement graphical orchestration by dragging and dropping.
[0055] As an optional embodiment, in order to achieve the description of service dependencies and make the description structure as simple as possible, thereby simplifying the topology parsing and generation of application template graphics, a hierarchical dependency structure is designed. Figure 4As shown, it is a structural diagram of hierarchical dependency of an optional embodiment of the present invention. The hierarchical dependency structure mainly layers the service template list according to the depth of the dependency relationship, and the service templates with the same dependency depth are placed in the same layer, which is equivalent to the service template of the upper layer relying on the service template of the lower layer. In this way, the description of the dependency relationship can be realized by only marking the layer to which each service template in the application template belongs. For the description of the input-output relationship of the service template, it is only necessary to associate the output parameter variable of the lower layer dependent service in the input parameter variable of the service template, but the input-output dependency relationship is not used in the topological structure. In this way, although the dependency relationship between specific services is not established in the topological structure of the application template, when deploying, the resources of the service will be issued to kubernetes in the hierarchical order according to the hierarchy of the service template. When the service of the same level is ready, the service of the next level is deployed. Since the service dependent on the service of this layer is ready at this time, there will be no abnormality when starting. Therefore, the sequential deployment of services can still be realized. In addition, the application template supports the nesting of sub-application templates, that is, other application templates that have been arranged are arranged as components of the application template, and the input-output relationship is consistent with the service template.
[0056] As an optional embodiment, after the application template is compiled, it is stored in the application store, and the dependency relationship processing of the deployed application template is implemented in the runtime management. Figure 5 FIG. 1 is a flowchart of an application deployment method according to an optional embodiment of the present invention, and the specific contents are as follows:
[0057] Step 1: When the user enters application configuration item parameters and selects an application template for deployment, the runtime management module queries the application template file from the application store (equivalent to the target database in the embodiment of the present invention) according to the application template name and version number, and parses the application template description information.
[0058] Step 2: When the application template file is queried from the store, obtain the service template hierarchy information in the application template (that is, determine the hierarchy information of each template element in the application template). According to the hierarchy information, first obtain all service templates of the 0th layer. The 0th layer service does not depend on other services and needs to be started first.
[0059] Step 3: Concurrently deploy all templates of the i-th layer and start the asynchronous thread to deploy all services of this layer.
[0060] Step 4: According to the template metadata information description, determine whether the template is a service template or a sub-application template. If it is a sub-application template, make a recursive call to deploy the sub-application template. After the sub-application is deployed, continue the subsequent process. To ensure deployment performance, limit the nesting level of sub-application templates to 1. If it is a service template, deploy the service template.
[0061] Step 5: Load the service template resource file and parse the input-output relationship description from the service template input parameter description. The service template input parameter sources include: 1) The output parameters of the dependent service in the previous layer are referenced through service.${serviceName}.output.{param} description. 2) The output parameters of the dependent sub-application in the previous layer are referenced through subapp.${appName}.output.{param} description. 3) The input parameters of the application configuration items entered when deploying the application are referenced through app.input.${param}.
[0062] Optionally, when parsing the input-output relationship, the service instance or application instance deployed in the previous layer is searched according to the service name or sub-application name in the reference description, and then the specific value is matched from the output parameter according to the parameter name. If the reference description is an application configuration item input parameter, the specific value is matched directly from the configuration item input parameter according to the parameter name. After obtaining the value (that is, the input parameter variable value), it is used as the input parameter of the service template to replace the variable placeholder in the yaml resource file in the service template to complete the rendering of the yaml resource file.
[0063] Step 6: Send the rendered kubernetes yaml resource object to kubernetes, and first create configuration resources such as volume (object), secret (sensitive information configuration information), configmap (configuration map), and then create workload resources such as deployment (scheduling) or statefulset (stateful set).
[0064] Step 7: After all services at this level have completed resource creation, listen to Kubernetes workload readiness events for all services at this level. When a service readiness event is reported, update the status of the service instance in the application instance to ready to go online, and determine whether all services at this level are ready. If not, continue listening.
[0065] Step 8: After all services at this level are ready, deploy the service template of the next level, and repeat this process until all levels are deployed.
[0066] Step 9: After all levels are deployed, change the application status to Ready to go online, and the entire deployment process is completed.
[0067] In summary, through the above process, application runtime management and deployment service dependency processing are realized, the startup order of services in the application is guaranteed, and a simple and intuitive graphical application instance topology structure display is provided to facilitate the management of the entire application status and the status of each service. It can quickly identify which service failure causes the failure of application deployment, and realize automated deployment and operation of the application.
[0068] Through the above embodiments, a relatively simple way to describe the dependency relationship between services in the application is proposed, which can realize the orchestration of application templates by dragging components, solve the complexity of complex application management kubernetes resources, and simplify the user's orchestration of yaml configuration file operations. In runtime management, according to the service dependency relationship, the service resources are sent to kubernetes in order to avoid the failure of service startup due to the service startup sequence problem. And by graphically displaying the application instance topology view, the application deployment is more intuitive, which can quickly locate which service failure in the dependency relationship causes the entire application startup failure, so that users can better understand the status of the application instance, and through a method of application orchestration, the dependency relationship of the service in the application is described through the structure of hierarchical dependency, and the graphical orchestration of the application is realized; hierarchical dependency is layered according to the dependency depth in the specific dependency relationship of the service, and services with the same dependency depth are classified into a unified level, and the processing of the specific dependency relationship of the service is removed during the parsing process. The hierarchical dependency is used to deploy the application template, and the hierarchical dependency in the application template is parsed to complete the deployment of the service in sequence. As well as runtime management based on hierarchical dependency application instances, graphically displaying the topological structure of the application runtime, making the application scenarios more extensive.
[0069] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.
[0070] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present invention.
[0071] According to another aspect of the embodiments of the present invention, a configuration file determination device for implementing the configuration file determination method is also provided. Figure 6 As shown, the device comprises:
[0072] An acquisition module 62 is used to acquire configuration item parameters of a target application, and query a target database according to the configuration item parameters to obtain an application template file of the target application;
[0073] The parsing module 64 is used to parse the application template file to obtain multiple sub-templates included in the application template file and the hierarchical information of each sub-template, wherein each sub-template;
[0074] A deployment module 66, configured to deploy each of the plurality of sub-templates layer by layer according to the hierarchical information of each sub-template, and load a corresponding resource file into each of the deployed sub-templates;
[0075] The determination module 68 is used to determine the configuration file used to operate and maintain the target application according to the loading information of the resource file in each sub-template.
[0076] Through the above-mentioned device, the configuration item parameters of the target application are obtained, and the target database is queried according to the configuration item parameters to obtain the application template file of the target application; the application template file is parsed to obtain multiple sub-templates included in the application template file and the hierarchical information of each sub-template, wherein the hierarchical information of each sub-template is used to indicate the hierarchy of each sub-template in the application template file; according to the hierarchical information of each sub-template, each of the multiple sub-templates is deployed layer by layer, and the corresponding resource file is loaded for each deployed sub-template; according to the loading information of the resource file in each sub-template, the configuration file for operating and maintaining the target application is determined, that is, the hierarchical dependency structure is used to describe the dependency relationship of the service in the application, which greatly simplifies the data structure of the dependency description, makes the processing logic of deploying the target application relatively simple, and can conveniently realize the graphical display of the instance topology structure of the target application at runtime, thereby achieving the purpose of resource orchestration for the complex target application, thereby achieving the technical effect of effective and rapid automatic deployment and operation of the target application, thereby solving the technical problem that the existing technology cannot orchestrate resources for complex applications and orderly deploy application resources.
[0077] It should be noted that the above-mentioned sub-templates and application template files can be displayed as graphical orchestrations, and the topology view can be displayed by dragging and dropping. Then, when a problem occurs in a sub-template in the application template file, the corresponding sub-template that failed to be enabled can be quickly found, allowing users to be more intuitive when deploying the target application, and to quickly locate the orchestration test before the application goes online based on the dependencies between the layers.
[0078] In an exemplary embodiment, the above-mentioned device also includes: a type module, which is used to obtain an information description of the metadata corresponding to each sub-template; and determine the attributes of each sub-template according to the information description of the metadata corresponding to each sub-template, wherein the attributes of each sub-template are used to indicate the template type of each sub-template, and the template type of each sub-template is used to determine the loading method of the resource file corresponding to each sub-template.
[0079] In an exemplary embodiment, the above-mentioned type module is also used to determine that the layer-by-layer deployment mode corresponding to each sub-template in the first group of sub-templates is direct deployment when the multiple sub-templates include a first group of sub-templates and the template type indicated by the attributes of each sub-template in the first group of sub-templates is a service template; and when the multiple sub-templates include a second group of sub-templates and the template type indicated by the attributes of each sub-template in the second group of sub-templates is a sub-application template, determine that the layer-by-layer deployment mode corresponding to each sub-template in the second group of sub-templates is call deployment, wherein the call deployment is used to indicate a recursive call to other already orchestrated applications in a nested manner.
[0080] In short, due to the different types of sub-templates, different deployment methods are required during deployment. Therefore, it is necessary to determine whether the sub-template is a service template or a sub-application template based on the template metadata information description. If it is a sub-application template, recursive calls are made (that is, other application templates that have been arranged are arranged as components of the application template into the template of the current target application), and the sub-application template is deployed. After the sub-application is deployed, the subsequent process continues. To ensure deployment performance, the nesting level of sub-application templates is limited to 1. If it is a service template, the service template is deployed directly.
[0081] Optionally, the above-mentioned deployment module is also used to hierarchically classify the multiple sub-templates according to the hierarchical information of each sub-template to obtain multiple sub-template sets, wherein sub-templates of the same level in the multiple sub-templates are classified into a sub-template set, and each sub-template set in the multiple sub-template sets corresponds to a level; starting from the sub-template set corresponding to the smallest level, the sub-template sets corresponding to different levels are deployed layer by layer according to the hierarchical order, and after the deployment of the sub-template set is completed, the resource files corresponding to the sub-templates in the sub-template set are loaded.
[0082] It is understandable that when deploying multiple sub-templates and loading corresponding resource files, they need to be loaded layer by layer according to the hierarchy to ensure the dependency between different levels, so that corresponding connections are established between the functions of the related target applications, and the dependency between the service template of the previous layer and the service template of the next layer is clarified.
[0083] In an exemplary embodiment, the above-mentioned determination module is also used to obtain parameter description information corresponding to the loading information of each sub-template when the configuration item parameters of the target application do not include input parameters, and determine the input parameter variable value of each sub-template according to the parameter description information; replace the variable placeholder of each sub-template with the input parameter variable value to obtain the configuration file for operating and maintaining the target application; or when the configuration item parameters of the target application include input parameters, determine the input parameter name in the configuration item parameter, match the input parameter name in a preset parameter library, and obtain the target input parameter variable value corresponding to the configuration item parameter; replace the variable placeholder of each sub-template with the target input parameter variable value to obtain the configuration file for operating and maintaining the target application.
[0084] In an exemplary embodiment, the above-mentioned determination module is also used to obtain a reference description of each sub-template when the input-output relationship carried in the parameter description information and each sub-template does not belong to the minimum level; wherein the reference description includes: the parameter name contained in the loaded resource file and the output parameters of each sub-template after the resource files are loaded in other levels before the level where each sub-template is currently located; determine the matching result between the target parameter name corresponding to the output parameter of each sub-template after the resource files are loaded in other levels and the parameter name contained in the resource file; when the matching result indicates that there is a matching output parameter for the parameter name contained in the resource file, use the specific parameter value of the output parameter as the input parameter variable value of each sub-template.
[0085] Optionally, load the resource file of the sub-template, and parse the input-output relationship description from the sub-template input parameter description. The sub-template input parameter sources include: 1) The output parameters of the dependent service in the previous layer are referenced through service.${serviceName}.output.{param} description. 2) The output parameters of the dependent sub-application in the previous layer are referenced through subapp.${appName}.output.{param} description. 3) The input parameters of the application configuration items entered when deploying the application are referenced through app.input.${param}.
[0086] Optionally, when parsing the input-output relationship, the service instance or application instance deployed in the previous layer is searched according to the service name or sub-application name in the reference description, and then the specific value is matched from the output parameter according to the parameter name. If the reference description is an application configuration item input parameter, the specific value is matched directly from the configuration item input parameter according to the parameter name. After obtaining the value (that is, the input parameter variable value), it is used as the input parameter of the sub-template to replace the variable placeholder in the yaml resource file in the sub-template (equivalent to the configuration file in the embodiment of the present invention), thereby completing the rendering of the yaml resource file.
[0087] In an exemplary embodiment, the above-mentioned device also includes: an online module, used to send the configuration file to the container orchestration platform, and listen to the workload ready event created by the container orchestration platform according to the configuration file; wherein the workload ready event is used to determine that the state of the corresponding function of the target application is an online state; determine the number of creation of the workload ready event corresponding to the application template file; when the creation number is greater than the number of the multiple sub-templates, determine that the target application has completed the online readiness.
[0088] For example, the rendered kubernetes yaml resource object is sent to the container orchestration platform kubernetes, and configuration resources such as volume (object), secret (sensitive information configuration information), configmap (configuration map) are created first, and then workload resources such as deployment (scheduling) or statefulset (stateful set) are created. After all services at this level have completed resource creation, listen to the workload ready (Ready) event of kubernetes for all services at this level. When the ready event of a service is reported, the status of the service instance in the application instance is updated to ready for online, and it is determined whether all services at this level are ready. If not, continue to listen. After the status of all services at this level is ready, the deployment of the next level sub-template is carried out, and this process is repeated until the deployment of all levels is completed. After the deployment of all levels is completed, the application status is changed to ready for online, and the entire deployment process is completed.
[0089] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.
[0090] An embodiment of the present invention further provides a storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.
[0091] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:
[0092] S1. Obtain configuration item parameters of a target application, and query a target database according to the configuration item parameters to obtain an application template file of the target application;
[0093] S2. Parse the application template file to obtain multiple sub-templates included in the application template file and hierarchical information of each sub-template, wherein the hierarchical information of each sub-template is used to indicate the hierarchical level of each sub-template in the application template file;
[0094] S3. Deploy each of the multiple sub-templates layer by layer according to the hierarchical information of each sub-template, and load corresponding resource files into each of the deployed sub-templates;
[0095] S4. Determine a configuration file for operating and maintaining the target application according to the loading information of the resource file in each sub-template.
[0096] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store computer programs.
[0097] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.
[0098] An embodiment of the present invention further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.
[0099] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.
[0100] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:
[0101] S1. Obtain configuration item parameters of a target application, and query a target database according to the configuration item parameters to obtain an application template file of the target application;
[0102] S2. Parse the application template file to obtain multiple sub-templates included in the application template file and hierarchical information of each sub-template, wherein the hierarchical information of each sub-template is used to indicate the hierarchical level of each sub-template in the application template file;
[0103] S3. Deploy each of the multiple sub-templates layer by layer according to the hierarchical information of each sub-template, and load corresponding resource files into each of the deployed sub-templates;
[0104] S4. Determine a configuration file for operating and maintaining the target application according to the loading information of the resource file in each sub-template.
[0105] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.
[0106] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.
[0107] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which can be personal computers, servers or network devices, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
[0108] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0109] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.
[0110] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0111] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0112] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.
Claims
1. A method for determining a configuration file, characterized in that: include: Acquire configuration item parameters of the target application, and query in the target database according to the configuration item parameters to obtain an application template file of the target application; Parsing the application template file to obtain multiple sub-templates included in the application template file and hierarchical information of each sub-template, wherein the hierarchical information of each sub-template is used to indicate the hierarchical level of each sub-template in the application template file; Deploy each of the multiple sub-templates layer by layer according to the hierarchical information of each sub-template, and load the corresponding resource file for each deployed sub-template; Determine a configuration file for operating and maintaining the target application according to loading information of the resource file in each sub-template; Among them, the application template file includes at least the following contents: template metadata, service template list, configuration input parameter list, and output parameter list; the template metadata is the field that constitutes the template framework, and the service template list includes multiple sub-templates, and the composition of each sub-template includes: template metadata, resource list, configuration input parameter list, and output parameter list; the configuration input parameters are used to replace the constantly changing values in the target application with variables.
2. The method according to claim 1, characterized in that After parsing the application template file to obtain multiple sub-templates included in the application template file and the hierarchical information of each sub-template, the method further includes: Obtaining information description of metadata corresponding to each sub-template; According to the information description of the metadata corresponding to each sub-template, the attributes of each sub-template are determined, wherein the attributes of each sub-template are used to indicate the template type of each sub-template, and the template type of each sub-template is used to determine the loading method of the resource file corresponding to each sub-template.
3. The method according to claim 2, characterized in that The determining the attribute of each sub-template according to the information description of the metadata corresponding to each sub-template includes: When the multiple sub-templates include a first group of sub-templates, and the template type indicated by the attribute of each sub-template in the first group of sub-templates is a service template, determining that the layer-by-layer deployment mode corresponding to each sub-template in the first group of sub-templates is direct deployment; In a case where the multiple sub-templates include a second group of sub-templates, and the template type indicated by the attributes of each sub-template in the second group of sub-templates is a sub-application template, it is determined that the layer-by-layer deployment mode corresponding to each sub-template in the second group of sub-templates is a call deployment, wherein the call deployment is used to indicate a recursive call to other already orchestrated applications in a nested manner.
4. The method according to claim 1, characterized in that: Deploying each of the multiple sub-templates layer by layer according to the hierarchical information of each sub-template, and loading corresponding resource files for each deployed sub-template, including: According to the level information of each sub-template, the multiple sub-templates are hierarchically classified to obtain multiple sub-template sets, wherein sub-templates with the same level in the multiple sub-templates are classified into one sub-template set, and each sub-template set in the multiple sub-template sets corresponds to one level; Starting from the sub-template set corresponding to the smallest level, the sub-template sets corresponding to different levels are deployed layer by layer according to the level order, and after the sub-template set is deployed, the resource files corresponding to the sub-templates in the sub-template set are loaded.
5. The method according to claim 1, characterized in that: Determining a configuration file for operating and maintaining the target application according to the loading information of the resource file in each sub-template includes: In the case where the configuration item parameters of the target application do not include input parameters, obtaining parameter description information corresponding to the loading information of each sub-template, and determining the input parameter variable value of each sub-template according to the parameter description information; replacing the variable placeholder of each sub-template with the input parameter variable value to obtain the configuration file for operating and maintaining the target application; or In the case where the configuration item parameters of the target application include input parameters, determining the input parameter name in the configuration item parameters, matching the input parameter name in a preset parameter library, and obtaining the target input parameter variable value corresponding to the configuration item parameter; The variable placeholder of each sub-template is replaced by the target input parameter variable value to obtain the configuration file for operating and maintaining the target application.
6. The method according to claim 5, characterized in that Determining the input parameter variable value of each sub-template according to the parameter description information includes: In the case where the input-output relationship is carried in the parameter description information and each sub-template does not belong to the minimum level, a reference description of each sub-template is obtained; wherein the reference description includes: the parameter name contained in the loaded resource file and the output parameters of each sub-template after the resource files are loaded in other levels before the level where each sub-template is currently located; Determine a match result between a target parameter name corresponding to an output parameter of each sub-template after the other levels load the resource file and a parameter name included in the resource file; When the matching result indicates that the parameter name included in the resource file has the matching output parameter, the specific parameter value of the output parameter is used as the input parameter variable value of each sub-template.
7. The method according to claim 1, characterized in that After determining the configuration file for operating and maintaining the target application according to the loading information of the resource file in each sub-template, the method further includes: Sending the configuration file to a container orchestration platform, and monitoring a workload ready event created by the container orchestration platform according to the configuration file; wherein the workload ready event is used to determine that the state of the function corresponding to the target application is an online state; Determining the creation quantity of the workload readiness events corresponding to the application template file; When the creation quantity is greater than the number of the multiple sub-templates, it is determined that the target application is ready to go online.
8. A device for determining a configuration file, characterized in that: include: An acquisition module, used to acquire configuration item parameters of a target application, and query a target database according to the configuration item parameters to obtain an application template file of the target application; A parsing module, used to parse the application template file to obtain multiple sub-templates included in the application template file and hierarchical information of each sub-template, wherein the hierarchical information of each sub-template is used to indicate the hierarchical level of each sub-template in the application template file; A deployment module, configured to deploy each of the plurality of sub-templates layer by layer according to the hierarchical information of each sub-template, and load a corresponding resource file into each of the deployed sub-templates; A determination module, configured to determine a configuration file for operating and maintaining the target application according to loading information of the resource file in each sub-template; Among them, the application template file includes at least the following contents: template metadata, service template list, configuration input parameter list, and output parameter list; the template metadata is the field that constitutes the template framework, and the service template list includes multiple sub-templates, and the composition of each sub-template includes: template metadata, resource list, configuration input parameter list, and output parameter list; the configuration input parameters are used to replace the constantly changing values in the target application with variables.
9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 7 when executed.
10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.
