Method and device for automatically generating Helm script

Abstract

The invention relates to the technical field of software engineering, in particular to a method and a device for automatically generating a Helm script, which are characterized in that a Velocity template engine is utilized to extract all deployment configuration information related to an application from corresponding. Vm files, dynamic elements of the application are implanted and marked, and the Velocity template engine is called to generate a Helm script file corresponding to a final module. Compared with the prior art, the method has the advantages that the problems of low efficiency, high error rate, difficulty in maintenance and the like caused by manual writing of Helm Chart in the application deployment process in the Kubernetes environment can be solved, and meanwhile, the requirement of quickly, accurately and flexibly performing application deployment is met.

Description

Technical Field

[0001] The present invention relates to the technical field of software engineering, and specifically provides a method and device for automatically generating Helm scripts. Background Art

[0002] Helm script generation technology refers to the process of automatically generating and managing scripts or configuration files required for Kubernetes application deployment using the Helm tool in a Kubernetes environment. Helm is a package management tool for Kubernetes that allows users to create, package, publish, and manage Kubernetes applications through predefined Helm Charts.

[0003] Helm script generation technology mainly relies on the concept of Helm Charts. A Helm Chart is a way to package Kubernetes resources, which contains all Kubernetes configuration files and dependencies required for deploying an application. By defining a Helm Chart, users can describe the structure of the application, the required resources, and configuration information, and package this information into a reusable template.

[0004] During the Helm script generation process, users first create or obtain a template for a Helm Chart. This template usually contains the basic structure of the application and some configurable parameters. Users can customize the template according to their needs, such as setting resource limits, environment variables, storage configurations, etc. Once the customization is complete, users can use the Helm command-line tool to generate specific Kubernetes deployment scripts.

[0005] The advantage of Helm script generation technology is that it simplifies the deployment process of Kubernetes applications. By automatically generating scripts, users do not need to manually write a large number of Kubernetes configuration files, reducing the possibility of errors and improving the efficiency and consistency of deployment. In addition, Helm also supports version control, and users can easily upgrade, roll back, etc. the Charts to better manage the lifecycle of the application. Helm is a Kubernetes package management tool that uses a packaging format called Helm Chart to define, install, and upgrade Kubernetes applications. Helm itself does not provide a direct way to write scripts, but interacts with the Kubernetes cluster through a command-line tool (helm CLI) to perform operations such as installation, upgrade, rollback, etc.

[0006] During the use of Helm, users usually write or modify the YAML files of Helm Charts to define Kubernetes resources and their configurations. These YAML files can be regarded as scripts describing the structure of Kubernetes applications, but they are not traditional script files (such as bash or Python scripts).

[0007] Helm scripts play an important role in the deployment and management of Kubernetes applications, but there are also some problems and challenges. For users who are not familiar with Helm, it takes a certain amount of time and effort to learn and understand the working principle, Chart structure, and best practices of Helm. In addition, the configuration and deployment process of Helm may be relatively complex, especially for large and complex Kubernetes applications.

[0008] The following are the main types of commonly used Helm script generation tools:

[0009] 1. Helm CLI: The command-line interface (CLI) tool of Helm is the most direct and commonly used Helm script generation tool. Through the Helm CLI, users can create new Helm Charts, edit the templates and value files in the Charts, and install, upgrade, and delete Kubernetes applications. The Helm CLI provides a simple and powerful way to manage the lifecycle of Kubernetes applications.

[0010] 2. Kompose: Kompose is an open-source tool that can convert Docker Compose files or Kubernetes YAML files into Helm Charts or other Kubernetes resources. This is very useful for users who already have Docker Compose files or Kubernetes YAML files and want to convert them into Helm Charts.

[0011] 3. Kubeconform: Kubeconform is also an open-source tool that is mainly used to verify whether Kubernetes YAML files conform to the specifications of the Kubernetes API. In addition, it can also convert Kubernetes YAML files into Helm Charts. While ensuring the compliance of YAML files, Kubeconform also provides the function of converting them into Helm Charts, making it more convenient for users to manage Kubernetes resources.

[0012] Currently, all commonly used Helm script generation tools need to generate from a deployed Kubernetes instance or from existing Docker Compose files and Kubernetes YAML files. However, deploying a new Kubernetes instance or writing a YAML file often takes a lot of time and effort.

[0013] Therefore, we need a new method that can not only simplify the deployment process of Kubernetes applications, eliminating the need for developers to manually write a large number of Helm scripts, but also reduce the likelihood of errors, improve the deployment efficiency, and ensure consistency. Summary of the Invention

[0014] In view of the deficiencies of the above-mentioned existing technologies, the present invention provides a practical method for automatically generating Helm scripts.

[0015] A further technical task of the present invention is to provide a device for automatically generating Helm scripts with reasonable design, safety, and applicability.

[0016] The technical solution adopted by the present invention to solve its technical problems is as follows:

[0017] A method for automatically generating Helm scripts uses the Velocity template engine to extract all the configuration information related to the deployment of an application into corresponding.vm files, implant elements marked with the dynamics of the application itself, and then call the Velocity template engine to generate the Helm script file corresponding to the final module.

[0018] Furthermore, it has the following steps:

[0019] S1. Define a standardized application deployment information model;

[0020] S2. Define the.vm template files related to the standardized Chart;

[0021] S3. Maintain the application deployment information;

[0022] S4. Parse and verify the application deployment information;

[0023] S5. Fill the application deployment information into the.vm template files;

[0024] S6. Generate the HelmChart script according to the template files;

[0025] S7. Verify and publish the HelmChart script.

[0026] Further, in step S1, according to the application deployment scenario, define the application deployment information model, including the environment variables env used by the application, the port number port of the application, the service name service exposed by the application, the storage mapping volumn used by the application, the user permissions security of the application, the Docker image image used by the application, and the resource configuration resource used by the application; the model is finally stored in the database in the form of a table, and each model attribute is stored in json form.

[0027] Further, in step S2, for each yaml file in the HelmChart package, define a corresponding.vm template file. Among them, values.yaml, Chart.yaml, deployment.yaml, ingress.yaml, service.yaml, configmap.yaml, and secret.yaml correspond to values.vm, chart.vm, deployment.vm, ingress.vm, service.vm, configmap.vm, and secret.vm files respectively;

[0028] For the fixed part in each.vm file, copy the format and content of the fixed part. For dynamic elements, use the ${} method to specially mark the specific form as: ${deployConfig.XX};

[0029] Among them, XX is an attribute in AppDeployDTO; all the above.vm files are stored in the src\main\resources\template directory.

[0030] Further, in step S3, the visualization interface maintains the relevant information of the application deployment information model defined in step S1, stores it in the data in JSON form through the front-end and back-end code. If the model fails to meet the application deployment requirements, add or modify the model, synchronize the modified code and synchronize it to the database.

[0031] Further, in step S4, read the application deployment information maintained in step S3 from the database, convert it from JSON form to AppDeployDTO through the back-end code. The attributes in JSON correspond to the attributes in DTO. After converting to DTO, perform legal verification on each attribute through the HelmChartCliUtil.lint method;

[0032] If the verification fails, return a failure message through the back-end;

[0033] If the verification is successful, proceed to step S5.

[0034] Further, in step S5, the converted AppDeployDTO calls the HelmChartGeneratorUtil.generate method through the backend code to fill the application deployment information into the.vm template file defined in step S2;

[0035] The rules for filling the.vm file are as follows:

[0036] In HelmChartGeneratorUtil.generate, the attributes of AppDeployDTO are injected into the template engine in the form of the Context attributes of the Velocity template engine, and the dynamic content of the application deployment information in the template is marked by ${deployConfig.XX} in the.vm template file;

[0037] Among them, XX is the attribute in AppDeployDTO, and deployConfig is the name of the instance of AppDeployDTO specified in HelmChartGeneratorUtil.generate.

[0038] Further, in step S6, for the template file filled in step S5, the java implementation of HelmCLi is called through the backend, and HelmChartCliUtil.packageIt packages the yaml file into a HelmChart script, which includes values.yaml, Chart.yaml, and a templates folder. The templates folder contains _helpers.tpl, deployment.yaml, ingress.yaml, service.yaml, configmap.yaml, and secret.yaml;

[0039] The final format of the script is a.tgz type compressed package.

[0040] Further, in step S7, through the backend code, the HelmChart compressed package generated in step S5 is read, verified, and published. HelmChartCLiUtil.install is called for verification, and HelmChartCLiUtil.push is called for publishing. The underlying is the api implementation of the Helm command.

[0041] An apparatus for automatically generating a Helm script includes: at least one memory and at least one processor;

[0042] The at least one memory is used to store machine-readable programs;

[0043] The at least one processor is used to call the machine-readable program to execute a method for automatically generating Helm scripts.

[0044] Compared with the prior art, a method and device for automatically generating Helm scripts according to the present invention have the following outstanding beneficial effects:

[0045] The present invention solves the problems of low efficiency, error-proneness, and difficulty in maintenance caused by manually writing Helm Charts during the application deployment process in the Kubernetes environment, and at the same time meets the requirements of rapid, accurate, and flexible application deployment. It realizes a high degree of automation, reduces manual intervention, and improves the deployment efficiency. It supports custom templates and logic processing, can flexibly handle various complex deployment requirements, and is easy to expand to support new functions and requirements.

[0046] (1) Through automated information parsing, template filling, and script verification, errors caused by human factors are greatly reduced.

[0047] (2) The generated Helm Chart script is closely associated with the deployment information of the application, making it easy to maintain and update.

[0048] (3) It helps to promote unified deployment practices within a team or organization and improve the standardization of the deployment process. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0050] FIG. Figure 1 is a flowchart of a method for automatically generating Helm scripts;

[0051] FIG. Figure 2 is a block diagram of the input and output of a method for automatically generating Helm scripts;

[0052] FIG. Figure 3 is a block diagram of a system for automatically generating Helm scripts. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0053] To enable those skilled in the art to better understand the solution of the present invention, the present invention will be further described in detail below in conjunction with specific embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0054] The following gives an optimal embodiment:

[0055] Embodiment 1:

[0056] As Figure 1 shown, a method for automatically generating a Helm script in this embodiment uses the Velocity template engine to extract all the configuration information to be deployed involved in an application into a corresponding.vm file, implant elements marked with the dynamics of the application itself, and call the Velocity template engine to generate a Helm script file corresponding to the final module.

[0057] As Figure 1 shown, specifically as follows:

[0058] S1. Define a standardized application deployment information model;

[0059] According to the deployment scenario of the application, define the application deployment information model, including the environment variables (env) used by the application, the port number (port) of the application, the service name (service) exposed by the application, the storage mapping (volumn) used by the application, the user permissions (security) of the application, the Docker image (image) used by the application, and the resource configuration (resource) used by the application. The model is finally stored in the database in the form of a table. Each model attribute is stored in json form.

[0060] S2. Define the.vm template file involved in the standardized Chart;

[0061] For each yaml file in the HelmChart package, a corresponding.vm template file is defined. Among them, values.yaml, Chart.yaml, deployment.yaml, ingress.yaml, service.yaml, configmap.yaml, and secret.yaml correspond to values.vm, chart.vm, deployment.vm, ingress.vm, service.vm, configmap.vm, and secret.vm files respectively. In this embodiment, for the fixed part in each.vm file, the format and content of the fixed part are copied in, and for the dynamic elements, they are specially marked in the form of ${}, specifically: ${deployConfig.XX};

[0062] where XX is an attribute in AppDeployDTO; all the above.vm files are stored in the src\main\resources\template directory.

[0063] S3. Maintain application deployment information;

[0064] Maintain the relevant information of the application deployment information model defined in step S1 through the visual interface, and store it in the data in JSON form through the front-end and back-end codes.

[0065] If the model fails to meet the application deployment requirements, add or modify the model, synchronously modify the code and synchronize it to the database.

[0066] S4. Parse and verify application deployment information;

[0067] Read the application deployment information maintained in step S3 from the database, and convert it from JSON form to AppDeployDTO through the back-end code. The attributes in JSON correspond to the attributes in DTO, including env, port, context, volumn, valueFrom, repo, image, etc.

[0068] After converting to DTO, perform legal verification on each attribute through the HelmChartCliUtil.lint method. If the verification fails, return a failure message through the back-end;

[0069] If the verification is successful, proceed to step S5.

[0070] S5. Fill the application deployment information into the.vm template file;

[0071] Such as Figure 2As shown in the figure, for the converted AppDeployDTO in step S4, the application deployment information is filled into the.vm template file defined in step S2 by calling the HelmChartGeneratorUtil.generate method through the backend code.

[0072] The rules for filling the.vm file are as follows:

[0073] In HelmChartGeneratorUtil.generate, the attributes of AppDeployDTO are injected into the template engine in the form of Context attributes of the Velocity template engine, and the dynamic content of the application deployment information in the template is marked by ${deployConfig.XX} in the.vm template file;

[0074] Among them, XX is the attribute in AppDeployDTO, and deployConfig is the name of the instance of AppDeployDTO specified in HelmChartGeneratorUtil.generate.

[0075] S6. Generate a HelmChart script according to the template file;

[0076] For the template file filled in step S5, through the Java implementation of HelmCLi called by the backend, HelmChartCliUtil.packageIt, the yaml file is packaged into a HelmChart script, and the script contains values.yaml, Chart.yaml, and the templates folder;

[0077] The templates folder contains _helpers.tpl, deployment.yaml, ingress.yaml, service.yaml, configmap.yaml, and secret.yaml.

[0078] The final format of the script is a.tgz type compressed package.

[0079] S7. Verify and publish the HelmChart script;

[0080] Through the backend code, the HelmChart compressed package generated in step S5 is read, verified, and published; call HelmChartCLiUtil.install for verification and call HelmChartCLiUtil.push for publishing, and the underlying is the api implementation of the Helm command.

[0081] During use, the user inputs or uploads the deployment information of the application through methods such as a graphical user interface (GUI), command-line interface (CLI), or API interface. This information includes but is not limited to application metadata, service configurations, resource requests and limits, environment variables, storage configurations, etc.

[0082] After the system receives the deployment information, it first performs format verification to ensure the integrity and correctness of the information. Subsequently, the parser will parse this information and extract the key data used to generate the Helm Chart.

[0083] Based on the type, version of the application, or a template specified by the user, the system selects an appropriate Helm Chart template from the template library. Then, the parsed deployment information is filled into the corresponding positions in the template to generate a preliminary Helm Chart script.

[0084] After generating the preliminary Helm Chart script, the system may need to perform some logical processing, such as conditional judgment, loop traversal, dependency handling, etc., to ensure that the generated script can accurately reflect the deployment requirements of the application. At the same time, the system will also optimize the generated script to improve its readability and execution efficiency.

[0085] The generated and optimized Helm Chart script will go through a strict verification process to ensure that it complies with the specifications and requirements of Helm. After passing the verification, the system outputs the script to the user, and the user can directly use these scripts to deploy or upgrade the application in the Kubernetes environment.

[0086] Among them, the system supports automatically generating Helm Chart templates and deployment scripts adapted to different environments according to the specific requirements of different environments (such as development, testing, production).

[0087] When generating the Helm Chart template, the system can automatically identify and handle the dependencies between applications to ensure the correct configuration and deployment of dependencies.

[0088] The system supports managing the configuration information of the application through Kubernetes resources such as ConfigMap and Secrets to ensure the security of sensitive information and the flexibility of the configuration.

[0089] In the generated Helm Chart template, the system can integrate an elastic scaling mechanism to automatically adjust resource allocation according to the load situation of the application, realizing dynamic expansion and contraction of the application.

[0090] Example 2:

[0091] Such as Figure 3As shown in the figure, a system for automatically generating Helm scripts in this embodiment has a management period for maintaining environment variable information, system resource information, access information, storage mapping information, resource configuration information, and template information used for generating scripts involved in application deployment. The specific modules are as follows:

[0092] Variable management module: Maintain the environment variables used in application deployment;

[0093] Resource management module: Maintain information such as the number of CPU cores and memory usage used in application deployment;

[0094] Certificate management module: Maintain various certificates required for application operation;

[0095] Service management module: Maintain information such as the context during application operation and the exposed port numbers;

[0096] Storage management module: Maintain the host directory and configuration mapping information used in application operation;

[0097] Template management module: Maintain the.vm template files used for generating Helm scripts.

[0098] During the running period, it is used to fill the application deployment information into the defined template to generate a Helm deployment script and verify the release. The specific modules are as follows:

[0099] Template selection module: Select the.vm template maintained during the management period;

[0100] Template generation module: Fill the application deployment information maintained during the management period into the selected.vm template to generate a HelmChart file.

[0101] Template verification module: Package the generated HelmChart file into a script and verify the release.

[0102] Example 3:

[0103] An apparatus for automatically generating Helm scripts in this embodiment includes at least one memory and at least one processor;

[0104] Memory, for storing machine-readable programs;

[0105] Processor, for calling the machine-readable program to execute a method for automatically generating Helm scripts.

[0106] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or the processor can also be any conventional processor, etc.

[0107] The memory can be used to store computer programs and / or modules. The processor realizes various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by calling the data stored in the memory. The memory mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function, etc.; the data storage area can store data created according to the use of the terminal, etc. In addition, the memory can also include high-speed random access memory, and can also include non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash memory card, at least one magnetic disk storage period, a flash memory device, or other volatile solid-state storage devices.

[0108] The above specific embodiments are only specific cases of the present invention. The patent protection scope of the present invention includes but is not limited to the above specific embodiments. Any technical solution that conforms to the technical solutions described in the above specific embodiments of the present invention and any appropriate changes or substitutions made by those of ordinary skill in the art shall fall within the patent protection scope of the present invention.

[0109] Although the embodiments of the present invention have been shown and described, it will be understood by those of ordinary skill in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for automatically generating a Helm script, characterized in that: Using the Velocity template engine, all the deployment configuration information involved in an application is extracted from the corresponding .vm file, the dynamic elements of the application itself are implanted in the tag, and the Velocity template engine is called to generate the Helm script file corresponding to the final module.

2. A method for automatically generating a Helm script according to claim 1, characterized in that: The steps are as follows: S1. Define a standardized application deployment information model; S2. Define the .vm template file involved in the standardized Chart; S3. Maintain application deployment information; S4, application deployment information analysis and verification; S5. Fill the application deployment information into the .vm template file; S6. Generate HelmChart script according to the template file; S7. Verify and publish the HelmChart script.

3. A method for automatically generating a Helm script according to claim 2, characterized in that: In step S1, according to the deployment scenario of the application, the deployment information model of the application is defined, including the environment variable env used by the application, the port number port of the application, the service name service exposed by the application, the storage mapping volume used by the application, the user permission security of the application, the Docker image image used by the application, and the resource configuration resource used by the application; the model is finally stored in the database in the form of a table, and each model attribute is stored in the form of json.

4. A method for automatically generating a Helm script according to claim 3, characterized in that: In step S2, for each yaml file in the HelmChart package, a .vm template file is defined corresponding to it, where values.yaml, Chart.yaml, deployment.yaml, ingress.yaml, service.yaml, configmap.yaml, and secret.yaml correspond to values.vm, chart.vm, deployment.vm, ingress.vm, service.vm, configmap.vm, and secret.vm files respectively; For the fixed part of each .vm file, copy the format and content of the fixed part, and use ${} to specially mark the dynamic elements. The specific form is: ${deployConfig.XX}; Among them, XX is the property in AppDeployDTO; all the above .vm files are stored in the src\main\resources\template directory.

5. A method for automatically generating a Helm script according to claim 4, characterized in that: In step S3, the visual interface maintains the relevant information of the application deployment information model defined in step S1, and stores it in the data in JSON format through the front-end and back-end codes. If the model fails to meet the application deployment requirements, the model is added or modified, and the code is modified synchronously and synchronized to the database.

6. A method for automatically generating a Helm script according to claim 5, characterized in that: In step S4, the application deployment information maintained in step S3 is read from the database and converted from JSON to AppDeployDTO through the backend code. The attributes in JSON correspond to the attributes in DTO. After conversion to DTO, the legality of each attribute is checked through the HelmChartCliUtil.lint method. If the verification fails, the failure information will be returned through the backend; If the verification is successful, proceed to step S5.

7. A method for automatically generating a Helm script according to claim 6, characterized in that: In step S5, the converted AppDeployDTO calls the HelmChartGeneratorUtil.generate method through the backend code to fill the application deployment information into the .vm template file defined in step S2; The rules for filling the .vm file are as follows: In HelmChartGeneratorUtil.generate, inject the properties of AppDeployDTO into the template engine as the Context property of the Velocity template engine, and use ${deployConfig.XX} to mark the dynamic content of the application deployment information in the template in the .vm template file; Where XX is the property in AppDeployDTO, and deployConfig is the name of the instance of AppDeployDTO specified in HelmChartGeneratorUtil.generate.

8. A method for automatically generating a Helm script according to claim 7, characterized in that: In step S6, for the template file filled in step S5, the backend calls the Java implementation of HelmCLi, and HelmChartCliUtil.packageIt packages the yaml file into a HelmChart script. The script contains values.yaml, Chart.yaml, and templates folders. The templates folder contains _helpers.tpl, deployment.yaml, ingress.yaml, service.yaml, configmap.yaml, and secret.yaml. The final format of the script is a .tgz type compressed package.

9. A method for automatically generating a Helm script according to claim 8, characterized in that: In step S7, the HelmChart compressed package generated in step S5 is read, verified and published through the backend code, HelmChartCLiUtil.install is called for verification, and HelmChartCLiUtil.push is called for publishing. The underlying layer is the API implementation of the Helm command.

10. A device for automatically generating a Helm script, characterized in that: include: at least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to call the machine-readable program to execute the method according to any one of claims 1 to 9.

Images