Orchestration file generation method and device, equipment, storage medium and product

Abstract

The invention relates to an arrangement file generation method and device, equipment, a storage medium and a product. The method comprises the following steps: displaying a first visual interface, wherein the first visual interface is used for receiving application deployment parameters of a to-be-deployed application input by a user; reading project structure information corresponding to the to-be-deployed application loaded in the integrated development environment; analyzing a configuration file associated with the to-be-deployed application in the project structure information to obtain application configuration data; and calling a preset arrangement file template, filling the application deployment parameters, the project structure information and the application configuration data into the arrangement file template for rendering, and generating a target arrangement file of the to-be-deployed application. By adopting the method, the generation efficiency of the arrangement file can be improved.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a method, apparatus, device, storage medium, and product for generating and arranging files. Background Technology

[0002] With the widespread adoption of cloud-native architectures, Kubernetes (K8s) has become the de facto standard in container orchestration and the mainstream platform for enterprises to deploy and manage microservice applications. In the Kubernetes platform, application deployment primarily relies on a series of orchestration files in YAML (YAML Ain't Markup Language) format, written strictly according to syntax rules. These files define aspects such as the application's container image, network, storage, and configuration. Their complex structure and numerous configuration items place high demands on the technical capabilities of development and operations personnel.

[0003] Currently, cloud-native configuration file generation primarily relies on command-line interfaces (CLI), visual management platforms, and continuous integration / continuous deployment (CI / CD) toolchains. However, all of these methods are separated from the development process. Developers frequently switch between writing business code and generating deployment configurations, making manual operations prone to errors and inefficient. This has become a key technical bottleneck hindering the agility of cloud-native development processes. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, device, storage medium, and product for generating layout documents that can improve generation efficiency in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for generating arrangement files, applied to an integrated development environment for an application to be deployed. The method includes:

[0006] Display a first visualization interface, which is used to receive application deployment parameters of the application to be deployed input by the user;

[0007] Read the project structure information corresponding to the application to be deployed that is loaded in the integrated development environment;

[0008] The configuration file associated with the application to be deployed in the project structure information is parsed to obtain the application configuration data;

[0009] The preset orchestration file template is invoked, and the application deployment parameters, project structure information, and application configuration data are filled into the orchestration file template for rendering to generate the target orchestration file of the application to be deployed.

[0010] In one embodiment, the step of calling a preset orchestration file template, filling the application deployment parameters, the project structure information, and the application configuration data into the orchestration file template for rendering, and generating the target orchestration file for the application to be deployed includes:

[0011] The application deployment parameters, project structure information, and application configuration data are populated into the preset orchestration file template for rendering, thereby generating the initial orchestration file for the application to be deployed.

[0012] The trained large language model is invoked to verify the compliance of the initial orchestration file based on the application deployment parameters, the project structure information, the application configuration data, and preset prompt words, and a first verification result is obtained; the first verification result includes error information that needs to be forcibly corrected;

[0013] Based on the first verification result, the initial layout file is adjusted to obtain the target layout file.

[0014] In one embodiment, the verification of the compliance of the initial orchestration file to obtain a first verification result includes:

[0015] The system identifies whether the characters in the application name and namespace in the application deployment parameters conform to a preset naming convention, and obtains a first identification result.

[0016] The second identification result is obtained by identifying whether the port number in the application deployment parameters is within a valid range and whether the protocol is an allowed type.

[0017] The third identification result is obtained by identifying whether the variable name format of the environment variable in the application deployment parameters conforms to the predetermined specification and whether the value is not empty;

[0018] The fourth identification result is obtained by identifying whether the number of replicas in the application deployment parameters meets the minimum requirement.

[0019] The fifth identification result is obtained by identifying whether the application name in the application deployment parameters is consistent with the application name defined in the application configuration data.

[0020] The first verification result is obtained by combining the first identification result, the second identification result, the third identification result, the fourth identification result, and the fifth identification result.

[0021] In one embodiment, the method further includes:

[0022] The large language model is invoked to verify the rationality of the initial arrangement file based on the application deployment parameters, the project structure information, the application configuration data, and preset prompt words, resulting in a second verification result; the second verification result includes optional optimization information.

[0023] The step of adjusting the initial layout file based on the first verification result to obtain the target layout file includes:

[0024] The initial layout file is adjusted by combining the first verification result and the second verification result to obtain the target layout file.

[0025] In one embodiment, the step of verifying the rationality of the initial arrangement file to obtain a second verification result includes:

[0026] Based on a predefined deployment environment strategy, an adaptive analysis is performed on the number of replicas in the application deployment parameters to obtain the first analysis result;

[0027] Determine whether the application configuration data includes configuration items that meet the characteristics of sensitive information to obtain a second analysis result;

[0028] Determine whether there is a definition conflict or duplication between the port defined in the application deployment parameters and the service port declared in the application configuration data, and obtain the third analysis result;

[0029] The second verification result is generated by combining the first analysis result, the second analysis result, and the third analysis result.

[0030] In one embodiment, parsing the configuration file associated with the application to be deployed in the project structure information to obtain application configuration data includes:

[0031] Obtain multiple configuration files associated with the application to be deployed from the project structure information;

[0032] Display a second visualization interface, which provides mounting options and mounting type options for multiple configuration files;

[0033] In response to the selection operation for the determined mount option and the mount type option, the application configuration data is obtained by combining the determined mount configuration file and the corresponding mount type.

[0034] Secondly, this application also provides an orchestration document generation apparatus for use in an integrated development environment for an application to be deployed, the apparatus comprising:

[0035] The display module is used to display a first visualization interface, which is used to receive application deployment parameters of the application to be deployed input by the user.

[0036] The reading module is used to read the project structure information corresponding to the application to be deployed loaded in the integrated development environment.

[0037] The configuration module is used to parse the configuration file associated with the application to be deployed in the project structure information to obtain application configuration data;

[0038] The generation module is used to call a preset orchestration file template, fill the application deployment parameters, the project structure information and the application configuration data into the orchestration file template for rendering, and generate the target orchestration file of the application to be deployed.

[0039] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the file generation method provided in the first aspect of this application.

[0040] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the file generation method provided in the first aspect of this application.

[0041] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the file generation method provided in the first aspect of this application.

[0042] The aforementioned orchestration file generation method, apparatus, device, storage medium, and product display a first visual interface via an IEDA plugin. This first visual interface receives application deployment parameters of the application to be deployed input by the user. The IEDA plugin reads the project structure information corresponding to the application to be deployed loaded in the integrated development environment (IDE). The IEDA plugin parses the configuration file associated with the application to be deployed within the project structure information to obtain application configuration data. The IEDA plugin then calls a preset orchestration file template, filling the template with the application deployment parameters, project structure information, and application configuration data for rendering, thus generating the target orchestration file for the application to be deployed. This application deeply integrates the orchestration file generation process into the developer's IDE. Specifically, it achieves multi-source data acquisition and template-based rendering mechanisms through plugins within the IDE, significantly reducing the complexity and error rate of manually writing orchestration files. It not only automatically extracts key information from the development context (project structure, application configuration), avoiding frequent switching and repetitive information entry between different tools and environments, but also ensures the standardization and consistency of orchestration files through template-based generation. This improves the efficiency of cloud-native application deployment while guaranteeing the quality and maintainability of Infrastructure as Code (IaaS). Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a flowchart illustrating a method for generating arrangement files in one embodiment;

[0045] Figure 2 This is a flowchart illustrating the file generation method in another embodiment;

[0046] Figure 3 This is a flowchart illustrating the process of obtaining the target orchestration file in one embodiment;

[0047] Figure 4 This is a flowchart illustrating the process of obtaining the target orchestration file in another embodiment;

[0048] Figure 5 This is a structural block diagram of a document generation apparatus in one embodiment;

[0049] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0052] Currently, the generation and management of cloud-native configuration files primarily utilize command-line tools (CLI), visual management platforms, and automated generation via CI / CD. However, these current methods for generating Kubernetes orchestration files have several limitations.

[0053] First, using command-line tools relies on command-line parameters, which is inflexible. While they can operate independently of a Kubernetes cluster, the generated templates have limited functionality, are simple in content, lack template capabilities, and do not support the automatic generation of combined resources. Some command-line tools require users to memorize a large number of command parameters or learn specific template syntax, resulting in a steep learning curve and difficulty in meeting the configuration requirements of complex applications.

[0054] Secondly, while visual management platforms provide graphical interfaces, their functionality is insufficient. The generated orchestration files are often not in the native Kubernetes format, resulting in poor portability and strong platform dependencies. They are all bound to their respective platforms or frameworks, with the main function being cluster management and orchestration file generation being just an additional function. Their capabilities are not deep enough to meet the needs of templated systems, and the generated orchestration files are not pure native Kubernetes YAML, resulting in poor portability.

[0055] Furthermore, continuous integration or continuous deployment (CI / CD) toolchains themselves do not have the ability to generate orchestration files; they still require calling command-line tools via scripts, which is cumbersome and lacks template capabilities. Configurations are scattered throughout scripts, and orchestration files for different environments need to be manually distinguished, making unified reuse difficult and upgrades and environment migration challenging. This method relies on an additional continuous integration environment and is not suitable for on-the-spot generation during local development.

[0056] All of the above methods are separated from the development process, making it impossible to identify project engineering information, parse application configurations, and automatically generate mount types, and the generation efficiency of orchestration files is low.

[0057] To improve generation efficiency, this application provides a method for generating arrangement files, which can be applied to the integrated development environment (IDE) of the application to be deployed. The IDE (Integrated Development Environment) refers to the application provided by IDEA, which typically includes tools such as a code editor, compiler, debugger, and graphical user interface.

[0058] In some embodiments, developers perform application coding, debugging, and project management within the integrated development environment (IDE). This application extends the functionality of the IDE by integrating dedicated plugins, enabling developers to deploy and configure cloud-native applications without switching working contexts. These dedicated plugins can refer to software modules installed and running within the IDE, used to extend its native functionality to support Kubernetes orchestration file generation. These plugins interact with developers through a graphical user interface and can access and manipulate currently loaded project objects and the file system within the IDE.

[0059] In some embodiments, the plugin will provide dedicated function entry points, configuration panels, and operation buttons in the user interface of the integrated development environment, and will be able to access metadata such as module information, dependencies, and configuration files of the current project in the background, providing a data foundation for subsequent orchestration file generation.

[0060] In some embodiments, the plugin is installed in the integrated development environment. After the plugin is installed, the plugin settings option is selected in the IDEA settings to set the layout template directory. The directory can contain multiple layout templates. When generating layout files, the user can select the layout template. In addition, custom layout templates can be placed in this directory for extension.

[0061] In one exemplary embodiment, such as Figure 1 As shown, a method for generating orchestration files is provided. Taking the application of this method to an integrated development environment (IDE) of an application to be deployed as an example, the method includes the following steps 102 to 108. Wherein:

[0062] Step 102: Display the first visualization interface, which is used to receive application deployment parameters of the application to be deployed input by the user.

[0063] The first visual interface can refer to the user interaction page provided by plugins in the integrated development environment (IDE) for receiving and configuring the parameters required for the application to run in the Kubernetes cluster. Application deployment parameters can refer to the core configuration set that defines the application's runtime state in Kubernetes, which includes at least the application name, namespace, number of replicas, port mappings, and environment variables.

[0064] For example, when a developer activates the plugin functionality in the integrated development environment (IDE), the plugin renders and displays a graphical configuration window that includes form controls such as input fields, dropdown lists, and checkboxes. Through this window, the developer inputs or selects various parameters required for application deployment, such as specifying the application's unique identifier in the cluster (appName), target namespace, number of replicas, and container port and protocol. The plugin collects all parameters entered by the user in this interface and encapsulates them into a structured data model.

[0065] Step 104: Read the project structure information corresponding to the application to be deployed loaded in the integrated development environment.

[0066] Among them, project structure information can refer to the metadata inherent in the software project corresponding to the application to be deployed developed in the integrated development environment, which describes its engineering organization and build artifacts. It may include module name, project path, build artifact name and version number, etc.

[0067] For example, the plugin calls the application programming interface provided by the integrated development environment to scan and parse currently active projects. The plugin obtains information such as the project's root directory path, the names and physical paths of each module, and the name and storage location of the deployment package (such as a JAR file) generated after the build process, and organizes the above information into a structured engineering data model.

[0068] Step 106: Parse the configuration files associated with the application to be deployed in the project structure information to obtain the application configuration data.

[0069] In this context, a configuration file can refer to a specific file (such as application.yml or properties files) located in the project structure information and used to define the application's runtime behavior. Application configuration data can refer to a collection of configuration items organized in key-value pairs, obtained by parsing the configuration file.

[0070] For example, the plugin locates a specific configuration file in the project resource directory based on the identified project structure information. The plugin reads the raw content of the configuration file and parses it according to its format specifications (such as YAML or Properties), converting the file content into structured configuration objects or text blocks to form an application configuration data model.

[0071] Step 108: Call the preset orchestration file template, fill the application deployment parameters, project structure information and application configuration data into the orchestration file template for rendering, and generate the target orchestration file of the application to be deployed.

[0072] The orchestration file template can refer to a predefined template file that contains Kubernetes resource description syntax and dynamic placeholders. The target orchestration file can refer to a YAML format file that conforms to Kubernetes specifications and can be directly used for application deployment after being rendered by the template engine.

[0073] For example, a plugin loads a preset orchestration file template based on user selection or preset rules. The template engine matches and replaces the placeholders in the template with the data model obtained in steps 102, 104, and 106 to generate multiple target orchestration files. The target orchestration files can be directly output to a specified directory of the project or displayed to the user for preview and further editing.

[0074] In the above-described orchestration file generation method, a first visualization interface is displayed through an IEDA plugin. This first visualization interface is used to receive application deployment parameters of the application to be deployed input by the user. The IEDA plugin reads the project structure information corresponding to the application to be deployed loaded in the integrated development environment. The IEDA plugin parses the configuration file associated with the application to be deployed in the project structure information to obtain application configuration data. The IEDA plugin calls a preset orchestration file template, and fills the application deployment parameters, project structure information, and application configuration data into the orchestration file template for rendering, generating the target orchestration file of the application to be deployed. This embodiment of the application deeply integrates the orchestration file generation process into the developer's integrated development environment. Specifically, it can realize multi-source data collection and templated rendering mechanism through plugins in the integrated development environment, which can significantly reduce the complexity and error rate of manual writing of orchestration files. It not only realizes the automatic extraction of key information from the development context (project structure, application configuration), avoiding frequent switching and repeated information entry between different tools and environments, but also ensures the standardization and consistency of orchestration files through templated generation. Thus, while improving the deployment efficiency of cloud-native applications, it ensures the quality and maintainability of infrastructure as code.

[0075] In one exemplary embodiment, such as Figure 2As shown, a method for generating an arrangement file is provided, including steps 202 to 214, wherein:

[0076] Step 202: In response to the installation and setup operations for the IDEA plugin, complete the installation and setup of the IDEA plugin.

[0077] In this process, you need to install the plugin in IDEA. Once the plugin is installed, find the plugin settings option in IDEA settings and set the layout template directory. The directory can contain multiple layout templates. When generating layout files, users can select the layout template. In addition, custom layout templates can be placed in this directory for extension.

[0078] Step 204: Display the first visualization interface through the plugin. This first visualization interface is used to receive application deployment parameters of the application to be deployed input by the user.

[0079] For example, in response to a user's action of opening the first visualization interface in the IDEA plugin, the first visualization interface is displayed through the IDEA plugin. The user enters relevant information about the application to be deployed in Kubernetes within this visualization interface, such as appName, namespace, replicas, ports (port, targetPort, protocol), envs (environment variables: name, value), and labels (custom labels, key, value). This data is stored in JSON format and uniformly encapsulated in the viewModel of the data model, which can be represented as:

[0080] .

[0081] Step 206: Read the project structure information corresponding to the application to be deployed loaded in the integrated development environment through the plugin.

[0082] For example, the plugin automatically scans and reads the project information loaded by IDEA, such as modelName (module name), modelPath (module path), jarName (jar name), jarPath (jar path), and projectVersion (project version). This data is stored in JSON format and uniformly encapsulated in the projectModel of the data model, which can be represented as:

[0083] .

[0084] Step 208: Use the plugin to parse the configuration file associated with the application to be deployed in the project structure information to obtain the application configuration data.

[0085] In one possible implementation, the integrated development environment (IDE) can obtain multiple configuration files associated with the application to be deployed from the project structure information via a plugin. The plugin then displays a second visual interface, providing options for determining the mount point and mount type for these configuration files. Responding to selections for these options, the plugin combines the selected configuration files and their corresponding mount types to obtain the application configuration data. For example, the visual interface could display a list of configuration files by name, allowing the user to choose whether to mount them. If mounting is selected, the user can choose between a ConfigMap and a Secret mount type.

[0086] For example, the plugin can automatically parse application configuration files in the project, such as application.yml or .properties files. The configuration file name is used as the key, the content is converted into text form as the value, and the data is stored in JSON format and uniformly encapsulated in the applicationModel of the data model, which can be represented as follows;

[0087] .

[0088] Step 210: By calling the preset orchestration file template through the plugin, the application deployment parameters, project structure information and application configuration data are filled into the orchestration file template for rendering, and the initial orchestration file of the application to be deployed is generated.

[0089] For example, you can choose the orchestration template built into the plugin or the extended orchestration template in step 202. The orchestration template predefines the template files required by Kubernetes, such as Dockerfile.ftl, Deployment.ftl, Service.ftl, ConfigMap.ftl, Secret.ftl, etc.

[0090] In this embodiment of the application, placeholders (such as ${appName}, ${namespace}, ${jarName}) are used in the template file to represent the content that needs to be dynamically rendered. Clicking the "Generate" button uses the FreeMarker template engine to render the data model obtained in steps 204, 206, and 208 into the template file, forming a complete orchestration file content. For extended orchestration templates, the data required for rendering the template file can be obtained from the data model.

[0091] The following describes how to render the Dockerfile.ftl file.

[0092] Render the code snippets to be rendered in the Dockerfile.ftl file according to the Dockerfile specification. For example, add a JAR file: ADD . / target / ${jarName} / ${modelName} / ; expose ports: get the ports array of viewModel and convert it into Dockerfile port exposure instructions one by one. The port exposure instructions can be represented as: EXPOSE ${targetPort1} ${targetPort2}; set the working directory: WORKDIR ${appName}; start command: ENTRYPOINT ["java", "-Dfile.encoding=utf-8", "-jar", " / ${appName} / ${jarName}"].

[0093] After rendering, a complete Dockerfile is generated, named Dockerfile, and displayed in the visualization interface.

[0094] The following describes how to render the Deployment.ftl file.

[0095] According to the Kubernetes Deployment orchestration file specification, the code snippets to be rendered in the Deployment.ftl file are rendered. For example, resource name: app: ${appName}-deployment; namespace: namespace: ${namespace}; replicas: replicas: ${replicas}; environment variables: obtain the envs array of the viewModel and convert each item to the env field content in the Deployment specification, which can be represented as:

[0096] .

[0097] For example, regarding labels: Retrieving the `labels` array from the `viewModel` and converting each item to the `labels` field content in the Deployment specification can be represented as:

[0098] .

[0099] After rendering, the complete Deployment content is generated and named ${appName}-deployment.yaml, and displayed in the visualization interface.

[0100] The following describes the rendering of the Service.ftl file.

[0101] According to the Kubernetes Service orchestration specification, the code snippets that need to be rendered in the Service.ftl file are rendered. For example, resource name: app: ${appName}-service, namespace: namespace: ${namespace}, port: obtain the ports array of the viewModel and convert each item into the ports field content in the Service specification, which can be represented as follows:

[0102] .

[0103] After rendering, the complete Service content is generated and named ${appName}-service.yaml, which is then displayed in the visualization interface.

[0104] The following describes how to render the ConfigMap.ftl file.

[0105] If the mount type selected in step 4 is ConfigMap, then the code snippets to be rendered in the ConfigMap.ftl file will be rendered according to the Kubernetes ConfigMap orchestration specification. For example, resource name: app: ${appName}-configMap, namespace: namespace: ${namespace}, data tag: retrieve the corresponding configuration in applicationModel and convert it into the data field content in the ConfigMap specification, which can be represented as:

[0106] .

[0107] After rendering, a complete ConfigMap is generated and named ${appName}-configMap.yaml, which is then displayed in the visualization interface.

[0108] The following describes how to render the Secret.ftl file.

[0109] If the mount type selected in step 4 is Secret, then the code snippets to be rendered in the Secret.ftl file will be rendered according to the Kubernetes Secret orchestration file specification. For example, resource name: app: ${appName}-secret, namespace: namespace: ${namespace}, stringData tag: retrieve the corresponding configuration in applicationModel and convert it into the stringData field content in the Secret specification, which can be represented as:

[0110] .

[0111] After rendering, the complete Secret content is generated and named ${appName}-secret.yaml, and displayed in the visualization interface.

[0112] Step 212: The initial orchestration file is validated by calling the trained large language model through the plugin, and the target orchestration file is determined based on the validation results.

[0113] Step 214: Export the target orchestration file to the preset directory using the plugin.

[0114] For example, based on the verification result of step 212, the content of the initial orchestration file is adjusted on the editing page. After the modification is completed, the target orchestration file is obtained. Click the "Export Target Orchestration File" button, and the plugin obtains the modelPath from the data model, places the rendered target orchestration file in the modelPath / ks8 directory, and submits it to the entire project management.

[0115] In this embodiment, by constructing an end-to-end automated process from plugin initialization, parameter collection, project parsing to template rendering and AI verification, the generation process of Kubernetes orchestration files can be deeply integrated into the development environment. This not only lowers the user's operational threshold through visual interaction, but also ensures the standardization and integrity of orchestration files through automatic collection of multi-source data and templated rendering. Furthermore, the introduction of an AI-assisted verification mechanism effectively improves the reliability of the output results and the compliance with best practices. Thus, while significantly improving the deployment efficiency of cloud-native applications, it comprehensively ensures the quality and maintainability of infrastructure code.

[0116] It is understood that the process of implementing step 212 is not unique. This embodiment of the application can call a trained large language model to verify the initial arrangement file based on application deployment parameters, project structure information, application configuration data, and preset prompts.

[0117] For example, the initial orchestration files generated in step 210 can be displayed in a list on the visual interface. Clicking on each orchestration file allows for direct previewing and editing within IDEA. In editing mode, the data models obtained in steps 204, 206, and 208 can be input into the large AI model via a plugin, and assisted analysis and verification can be performed according to predefined prompts.

[0118] In one exemplary embodiment, such as Figure 3 As shown, step 212 includes steps 302 and 304. Wherein:

[0119] Step 302: Call the trained large language model to verify the compliance of the initial orchestration file based on application deployment parameters, project structure information, application configuration data and preset prompt words, and obtain the first verification result.

[0120] The first verification result includes error information that needs to be forcibly corrected.

[0121] Step 304: Adjust the initial layout file based on the first verification result to obtain the target layout file.

[0122] For example, compliance verification prompts can be used to check the compliance of the initial orchestration file. This can be built into the plugin logic, with the large language model responsible for interpretation or prompting.

[0123] In one possible implementation, a plugin calls a large language model to identify whether the characters in the application name and namespace in the application deployment parameters conform to the preset naming conventions, thus obtaining a first identification result; it identifies whether the port number in the application deployment parameters is within a valid range and whether the protocol is an allowed type, thus obtaining a second identification result; it identifies whether the variable name format of the environment variables in the application deployment parameters conforms to the predetermined conventions and whether the value is not empty, thus obtaining a third identification result; it identifies whether the number of replicas in the application deployment parameters meets the minimum quantity requirement, thus obtaining a fourth identification result; it identifies whether the application name in the application deployment parameters is consistent with the application name defined in the application configuration data, thus obtaining a fifth identification result; and it combines the first, second, third, fourth, and fifth identification results to obtain a first verification result.

[0124] For example, naming convention validation: appName must conform to the specification "^[a-z0-9]([-a-z0-9]*[a-z0-9])?$" (K8s naming convention); namespace is the same as above, avoiding uppercase letters and special characters; port validation: port and targetPort must be integers between 1 and 65535, and protocol only allows TCP or UDP; environment variable validation: name must be uppercase letters with underscores (^[A-Z_][A-Z0-9_]*$), and value must not be empty; replica count validation: replicas >= 1, and replicas >= 2 is recommended for production environments; configuration consistency validation: spring.application.name must be consistent with appName, and server.port cannot conflict with the defined container port.

[0125] In this embodiment, by introducing an automated verification mechanism based on a large language model and pre-setting compliance check rules covering multiple dimensions such as naming conventions, port validity, environment variable formats, replica count thresholds, and configuration consistency, the system can systematically identify configuration errors and specification deviations in the initial orchestration file. This method not only achieves intelligent review of orchestration file compliance, effectively preventing deployment failures or runtime anomalies caused by configuration errors, but also significantly improves the quality and reliability of orchestration files by providing precise correction guidance, thus providing a solid guarantee for the stable deployment and operation of cloud-native applications.

[0126] In one exemplary embodiment, such as Figure 4 As shown, step 212 includes steps 402 and 404. Wherein:

[0127] Step 402: Invoke the large language model to verify the rationality of the initial arrangement file based on application deployment parameters, project structure information, application configuration data, and preset prompt words, and obtain the second verification result.

[0128] The second verification result includes optional optimization information.

[0129] In one possible implementation, a plugin invokes a large language model to perform adaptive analysis on the number of replicas in the application deployment parameters based on a predefined deployment environment strategy, resulting in a first analysis result; it then determines whether the application configuration data includes configuration items that meet the characteristics of sensitive information, resulting in a second analysis result; it further determines whether there is a definition conflict or duplication between the ports defined in the application deployment parameters and the service ports declared in the application configuration data, resulting in a third analysis result; and finally, it combines the first, second, and third analysis results to generate a second verification result.

[0130] For example, the rationality of the initial arrangement file can be verified by analyzing optimization prompts, which can be built into the plugin logic. The large language model is responsible for providing optimization suggestions or risk warnings.

[0131] For example, user form data (viewModel of the data model), application configuration (applicationModel of the data model), and project information (projectModel of the data model) are input into the large language model, which then performs the following tasks: validates whether the format conforms to YAML syntax, validates whether all fields conform to Kubernetes specifications, checks whether appName and spring.application.name are consistent, checks whether the port definition is reasonable (whether it conflicts with server.port or is duplicated), provides optimization suggestions for the number of replicas (dev suggests 1, test suggests 1-2, prod suggests 2+), checks whether the environment variable naming conforms to the specifications, and prompts for potentially sensitive information (such as unencrypted passwords), and outputs an error list and optimization suggestions.

[0132] For example, the output format of a large language model may include discovered errors (which must be fixed), potential risks or optimization suggestions (which can be optionally fixed), and AI-provided automatic optimization results, such as:

[0133] .

[0134] Step 404: Combine the first verification result and the second verification result to adjust the initial layout file and obtain the target layout file.

[0135] In this embodiment, an intelligent analysis and optimization mechanism based on a large language model is introduced to perform environment adaptability analysis, security risk detection, and resource configuration conflict checks on orchestration file configurations. This systematically identifies potential performance bottlenecks, security vulnerabilities, and configuration inconsistencies. This method not only upgrades capabilities from compliance verification to intelligent optimization but also provides targeted configuration suggestions based on different deployment environments. This significantly improves the rationality, security, and resource utilization efficiency of orchestration files, providing intelligent quality assurance for the stable operation of the production environment.

[0136] The above embodiments have the following beneficial effects:

[0137] (1) Plugins can be integrated into IDEA, allowing developers to complete code writing and file generation in the same environment, reducing tool switching.

[0138] (2) Automatically identify project information: read module name, package name, project path, running parameters, etc.

[0139] (3) Parse application configuration: Supports parsing application configuration files application.yml / .properties, and can selectively map application configuration files to ConfigMap or Secret orchestration files.

[0140] (4) Visualization and echoing: Users can input necessary parameters through a visual interface without writing layout files or understanding various template syntaxes. The layout files can be exported and edited again.

[0141] (5) AI-assisted analysis and verification: Automatically detect the compliance of the orchestration files and whether the resource settings are reasonable, and provide best practice suggestions (such as probe configuration, resource limits, and security policies).

[0142] (6) Lightweight: It does not depend on a platform, is easy to install and use, can run independently, and is not strongly bound to CI / CD or clusters.

[0143] (7) Extensibility: It can be built into templates according to enterprise needs, flexibly adapt to internal specifications, support the generation of orchestration files for multi-language and multi-framework applications, and adapt to different scenarios.

[0144] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0145] Based on the same inventive concept, this application also provides an apparatus for implementing the above-described method for generating layout documents. The solution provided by this apparatus is similar to the solution described in the above method; therefore, the specific limitations in one or more embodiments of the layout document generation apparatus provided below can be found in the limitations of the layout document generation method described above, and will not be repeated here.

[0146] In one exemplary embodiment, such as Figure 5 As shown, a file arrangement and generation apparatus is provided, including: a display module 502, a reading module 504, a configuration module 506, and a generation module 508, wherein:

[0147] The display module is used to display a first visualization interface, which is used to receive application deployment parameters of the application to be deployed input by the user.

[0148] The reading module is used to read the project structure information corresponding to the application to be deployed, which is loaded in the integrated development environment.

[0149] The configuration module is used to parse the configuration file associated with the application to be deployed in the project structure information to obtain application configuration data.

[0150] The generation module is used to call a preset orchestration file template, fill the application deployment parameters, the project structure information and the application configuration data into the orchestration file template for rendering, and generate the target orchestration file of the application to be deployed.

[0151] Each module in the aforementioned document generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0152] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a file generation method.

[0153] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0154] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the arrangement file generation method provided in the first aspect of the present application.

[0155] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the arrangement file generation method provided in the first aspect of the embodiments of this application.

[0156] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the arrangement file generation method provided in the first aspect of the embodiments of this application.

[0157] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0158] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0159] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0160] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for generating formatted documents, characterized in that, The method, applied to an integrated development environment (IDE) for an application to be deployed, includes: Display a first visualization interface, which is used to receive application deployment parameters of the application to be deployed input by the user; Read the project structure information corresponding to the application to be deployed that is loaded in the integrated development environment; The configuration file associated with the application to be deployed in the project structure information is parsed to obtain the application configuration data; The preset orchestration file template is invoked, and the application deployment parameters, project structure information, and application configuration data are filled into the orchestration file template for rendering to generate the target orchestration file of the application to be deployed.

2. The method according to claim 1, characterized in that, The process of calling a preset orchestration file template, filling the application deployment parameters, project structure information, and application configuration data into the orchestration file template for rendering, and generating the target orchestration file for the application to be deployed includes: Call the preset orchestration file template, fill the application deployment parameters, the project structure information and the application configuration data into the orchestration file template for rendering, and generate the initial orchestration file of the application to be deployed; The trained large language model is invoked to verify the compliance of the initial orchestration file based on the application deployment parameters, the project structure information, the application configuration data, and preset prompt words, and a first verification result is obtained; the first verification result includes error information that needs to be forcibly corrected; Based on the first verification result, the initial layout file is adjusted to obtain the target layout file.

3. The method according to claim 2, characterized in that, The verification of the compliance of the initial arrangement file to obtain a first verification result includes: The system identifies whether the characters in the application name and namespace in the application deployment parameters conform to a preset naming convention, and obtains a first identification result. The second identification result is obtained by identifying whether the port number in the application deployment parameters is within a valid range and whether the protocol is an allowed type. The third identification result is obtained by identifying whether the variable name format of the environment variable in the application deployment parameters conforms to the predetermined specification and whether the value is not empty; The fourth identification result is obtained by identifying whether the number of replicas in the application deployment parameters meets the minimum requirement. The fifth identification result is obtained by identifying whether the application name in the application deployment parameters is consistent with the application name defined in the application configuration data. The first verification result is obtained by combining the first identification result, the second identification result, the third identification result, the fourth identification result, and the fifth identification result.

4. The method according to claim 2, characterized in that, The method further includes: The large language model is invoked to verify the rationality of the initial arrangement file based on the application deployment parameters, the project structure information, the application configuration data, and preset prompt words, resulting in a second verification result; the second verification result includes optional optimization information. The step of adjusting the initial layout file based on the first verification result to obtain the target layout file includes: The initial layout file is adjusted by combining the first verification result and the second verification result to obtain the target layout file.

5. The method according to claim 4, characterized in that, The step of verifying the rationality of the initial arrangement file to obtain a second verification result includes: Based on a predefined deployment environment strategy, an adaptive analysis is performed on the number of replicas in the application deployment parameters to obtain the first analysis result; Determine whether the application configuration data includes configuration items that meet the characteristics of sensitive information to obtain a second analysis result; Determine whether there is a definition conflict or duplication between the port defined in the application deployment parameters and the service port declared in the application configuration data, and obtain the third analysis result; The second verification result is generated by combining the first analysis result, the second analysis result, and the third analysis result.

6. The method according to any one of claims 1 to 4, characterized in that, The step of parsing the configuration file associated with the application to be deployed in the project structure information to obtain application configuration data includes: Obtain multiple configuration files associated with the application to be deployed from the project structure information; Display a second visualization interface, which provides mounting options and mounting type options for multiple configuration files; In response to the selection operation for the determined mount option and the mount type option, the application configuration data is obtained by combining the determined mount configuration file and the corresponding mount type.

7. A document formatting and generation device, characterized in that, An integrated development environment (IDE) for use with an application to be deployed, the apparatus comprising: The display module is used to display a first visualization interface, which is used to receive application deployment parameters of the application to be deployed input by the user. The reading module is used to read the project structure information corresponding to the application to be deployed loaded in the integrated development environment. The configuration module is used to parse the configuration file associated with the application to be deployed in the project structure information to obtain application configuration data; The generation module is used to call a preset orchestration file template, fill the application deployment parameters, the project structure information and the application configuration data into the orchestration file template for rendering, and generate the target orchestration file of the application to be deployed.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images