Dockerfile peculiar smell iterative detection and restoration method and system based on large language model

Abstract

The invention discloses a Dockerfile peculiar smell iterative detection and restoration method and system based on a large language model, and the method comprises the steps: obtaining to-be-optimized initial Dockerfile file content inputted by a user, inputting the to-be-optimized initial Dockerfile file content to a peculiar smell detection module for multi-dimensional scanning and analysis, and outputting structured peculiar smell detection information; fusing a predefined natural language instruction framework, an original Docker file to be optimized and structured peculiar smell information output by a peculiar smell detection module in the iteration to generate a cue word; inputting the cue word into a large language model for semantic analysis and code generation, and outputting an optimized Docker file for the current Docker file odor; and carrying out cleaning and key information extraction on the optimized Dockerfile by adopting a method of combining regular expression matching and semantic analysis, generating Dockerfile update content, and feeding back the Dockerfile update content to the peculiar smell detection module to carry out next round of iteration. According to the invention, intelligence and automation from Dockerfile peculiar smell detection to restoration are realized.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of containers, in particular to a Dockerfile smell iterative detection and repair method and system based on a large language model. BACKGROUND

[0002] Docker is a widely used tool in the software industry. It can create a stable and portable container environment on a machine, thereby avoiding a series of problems that may occur when migrating environments between different machines, including missing dependencies, configuration errors, and version incompatibility. This container environment is guided by Dockerfile to build images and run. Dockerfile is composed of a series of instructions. However, due to the lack of sufficient training of the personnel who write Dockerfile, some low-quality Dockerfile appears, thereby building inefficient and unsafe images. This low-quality Dockerfile that deviates from best practices is called "Dockerfile smell".

[0003] At present, in order to detect and eliminate Dockerfile smell, academia and industry have made many efforts, and there are mature technical solutions, mainly including two categories: (1) rule generation method based on data mining, such as Drive tool, which automatically mines common error patterns from a large number of open source projects Dockerfile and converts them into detection rules. (2) static analysis tools based on manually defined rules, such as Hadolint, Dockerfilelint and Dockle. These tools have a large number of rules summarized by domain experts built-in, which can effectively identify various smells and potential risks in Dockerfile through syntax and semantic analysis. In terms of elimination, the existing technical solutions highly depend on the pre-defined elimination rules.

[0004] Since the detection rules can be generated through data mining, their number is much larger than that of the elimination rules, and some smells are complex and difficult to eliminate with rules. Therefore, the current elimination rules of smells only contain common, easy-to-eliminate smells, and are difficult to deal with complex or rare smells. The above existing technical solutions have the following significant defects and limitations: 1. Eliminate the serious lack of rule coverage: The number of rules for detecting odors is much larger than that of elimination rules. It requires huge expert cost to manually write corresponding elimination rules for each detection rule. And the repair of some complex Dockerfile odors requires a deep understanding of the context and semantics of the code, rather than simple text replacement or instruction merging. For example, "determine whether to use COPY instead of ADD" or "optimize instruction order to take advantage of build cache". These complex scenarios are difficult to handle reliably and correctly with limited and fixed rules.

[0005] 2. Limited automation: The existing method mainly stays in the "detection-reporting" stage, and the repair capability is weak. Developers still need to manually read the report and modify the code, which is inefficient. And with the continuous evolution of Docker engine and best practices, the repair rule library needs to be updated and expanded constantly, which brings a continuous burden and cost to the maintenance of the technical solution. SUMMARY

[0006] To solve the above problems, the present application provides a Dockerfile odor iterative detection and repair method and system based on a large language model, and a storage medium, aiming to realize the intelligentization and automation from Dockerfile odor detection to repair.

[0007] According to a first aspect of the embodiments of the present disclosure, a Dockerfile odor iterative detection and repair method based on a large language model is provided, which comprises the following steps: Obtain the user inputted initial Dockerfile file content to be optimized and the preset maximum iteration number parameter; Input the initial Dockerfile content to the odor detection module, which performs multi-dimensional scanning and analysis on the input Dockerfile, and outputs structured odor detection information; Perform logical judgment on the current structured odor detection information. If the odor list in the current detection result is empty set, or the preset maximum iteration number has been reached, the termination condition is triggered, and the final optimized Dockerfile result is outputted; otherwise, the following steps are continued to be executed: Fuse the pre-defined natural language instruction framework, the original Dockerfile to be optimized, and the structured odor information outputted by the odor detection module in this iteration to generate prompt words; Input the prompt words into the large language model for semantic analysis and code generation. Adopt the method combining regular expression matching and semantic analysis to clean and extract information, and finally generate the optimized Dockerfile for the current Dockerfile odor; Feed back the optimized Dockerfile to the odor detection module for the next iteration.

[0008] A further technical solution of the present application is that the odor detection module is constructed based on an open-source static analysis tool Hadolint.

[0009] A further technical solution of the present application is that the structured odor detection information includes an odor type, an odor specific description, and a Dockerfile file line number.

[0010] A further technical solution of the present application is that the specific expression of the prompt word Prompt is: Prompt = Instruct + Dockerfile + Smells, wherein Instruct represents a predefined natural language instruction framework for explicitly defining optimization goals and constraint conditions, Dockerfile represents a Dockerfile to be optimized, and Smells represents structured odor information output by the odor detection module in this iteration.

[0011] According to a second aspect of the embodiments of the present disclosure, a Dockerfile odor iterative detection and repair system based on a large language model is provided, and the system comprises: An initialization and input acquisition module is configured to acquire an initial Dockerfile file content to be optimized input by a user and a preset maximum iteration number parameter; An odor detection module is configured to perform multi-dimensional scanning and analysis on the input Dockerfile, and output structured odor detection information; An iteration termination condition judgment module is configured to perform logical judgment on the current structured odor detection information, and if the odor list in the current detection result is an empty set or the preset maximum iteration number has been reached, a termination condition is triggered, and a final optimized Dockerfile result is output; otherwise, the prompt word construction module, the large language model calling module, and the response analysis and iteration update module are continued to be executed: A prompt word construction module is configured to fuse a predefined natural language instruction framework, a Dockerfile to be optimized, and structured odor information output by the odor detection module in this iteration to generate a prompt word; A large language model calling module is configured to input the prompt word into a large language model for semantic analysis and code generation; A response analysis and iteration update module is configured to perform cleaning and information extraction on the output of the large language model calling module by combining a regular expression matching method and a semantic analysis method, generate an optimized Dockerfile for the odor of the current Dockerfile, and feed back the optimized Dockerfile to the odor detection module for the next iteration.

[0012] A further technical solution of the present application is that the odor detection module is constructed based on an open-source static analysis tool Hadolint.

[0013] A further technical solution of the present application is that the structured odor detection information in the odor detection module includes an odor type, an odor specific description, and a Dockerfile file line number.

[0014] A further technical solution of the present application is that the specific expression of the prompt word Prompt in the prompt word construction module is: Prompt = Instruct + Dockerfile + Smells, wherein Instruct represents a predefined natural language instruction framework for explicitly defining optimization goals and constraint conditions, Dockerfile represents an original Dockerfile to be optimized, and Smells represents structured odor information output by the odor detection module in this iteration.

[0015] According to a third aspect of the embodiments of the present disclosure, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the above-mentioned Dockerfile odor iterative detection and repair method based on a large language model when executing the program.

[0016] According to a fourth aspect of the embodiments of the present disclosure, a non-temporary computer readable storage medium is provided, and the storage medium stores computer instructions, and the instructions are executed by a processor to implement the steps of the above-mentioned Dockerfile odor iterative detection and repair method based on a large language model.

[0017] The Dockerfile odor iterative detection and repair method, system and storage medium based on a large language model provided by the embodiments of the present disclosure have the following beneficial effects compared with the prior art: The understanding and generation capabilities of the large language model are utilized to expand the range of automatic repair, and solve complex and even rare Dockerfile odor problems that have no pre-defined repair rules; Through the iterative optimization mechanism, the thoroughness of the repair process and the high quality of the output results are ensured, and new problems that may be caused by single repair are avoided; The intelligentization and automation from Dockerfile odor detection to repair are realized, the dependence on manual expert rule writing is reduced, and the development efficiency and software quality are improved.

[0018] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0019] The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate embodiments consistent with the application and serve to explain the principles of the application.

[0020] Figure 1 is a flowchart of a method for detecting and repairing Dockerfile odors based on a large language model in embodiments of the application; Figure 2 is a system structure diagram of a method for detecting and repairing Dockerfile odors based on a large language model in embodiments of the application; Figure 3 is a schematic diagram of an electronic device in embodiments of the application. DETAILED DESCRIPTION

[0021] The application will be further described below in conjunction with the drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the application, and not to limit the application. In addition, it should be noted that, for the sake of description, only the relevant parts of the drawings are shown, not all the structures.

[0022] Before discussing the example embodiments in more detail, it is to be understood that some of the example embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts depict the steps in sequential order, many of the steps can be performed in parallel, concurrently or even simultaneously. In addition, the order of the steps can be re-arranged. The steps can be terminated when their operations are completed, but the process can also have additional steps not included in the figure. The process can correspond to methods, functions, procedures, subroutines, subprograms, etc.

[0023] The application fields of the present application include: 1. Software development and DevOps / CI-CD pipeline automation: as an automated quality gate in the continuous integration / continuous deployment (CI / CD) pipeline. Before the automated pipeline builds an image through the Dockerfile, the system described in the present application is automatically called to scan and optimize the Dockerfile, improving the quality of the image from the source; 2. Cloud-native application development and deployment platform: integrated into container orchestration platforms such as Kubernetes and Docker Swarm. When the developer uploads or writes a Dockerfile through the platform, the platform can automatically call the service to provide real-time optimization suggestions or silent optimization, reducing the user's use threshold and improving the overall quality and security of the platform's deployed applications; 3. Software security and compliance audit platform: existing tools such as Trivy, Grype, and Snyk are mainly responsible for "detecting" security vulnerabilities and compliance issues. The present application can be integrated into this, providing an automatic repair solution after detecting odors from the Dockerfile; 4. Code quality platform and IDE plug-in: integrated into integrated development environments (IDEs) such as Visual Studio Code and JetBrains IDEA in the form of a plug-in, providing real-time Dockerfile writing suggestions and "one-click optimization" functions for developers, acting as an intelligent programming assistant to help developers learn and write best practice code. 5. Network target range: in network attack and defense exercises, network security teaching, and other target environments, it is crucial to quickly build target machine base images that meet best practices. The present application can be integrated into the target range management platform to automatically optimize the Dockerfile of the exercise container, ensuring the security (such as using a non-root user, reducing unnecessary exposure) and efficiency (reducing exercise resource consumption) of the target machine environment.

[0024] The present application provides a large language model-based Dockerfile odor iterative detection and repair method, system, and storage medium, as follows: As shown in Figure 1 A large language model-based Dockerfile odor iterative detection and repair method, comprising the following steps: S101. Process initialization and input acquisition: after the process is started, the initial Dockerfile file content to be optimized input by the user and the preset maximum iteration number parameter are acquired; S102. Odor detection stage: input the initial Dockerfile content to the odor detection module, and the odor detection module performs multi-dimensional scanning and analysis on the input Dockerfile, and outputs structured odor detection information, wherein the odor detection module is constructed based on the static analysis tool Hadolint, and the structured odor detection information includes odor type, odor specific description and code line number.

[0025] S103. Iteration termination condition judgment: logically judge the current structured odor detection information, if the odor list in the current detection result is empty set, or the maximum number of iterations has been reached, the termination condition is triggered, and the final optimized Dockerfile result is output in S107; otherwise, the following steps are continued: S104. Prompt word construction stage: fuse the pre-defined natural language instruction framework, the original Dockerfile to be optimized, and the structured odor information output by the odor detection module in this iteration to generate a prompt word.

[0026] Specifically, the specific expression of the prompt word Prompt is: Prompt = Instruct + Dockerfile + Smells, wherein Instruct represents a pre-defined natural language instruction framework, which is used to clearly define optimization goals and constraint conditions, Dockerfile represents a Dockerfile to be optimized, and Smells represents structured odor information output by the odor detection module in this iteration.

[0027] In one specific embodiment, S104 fuses three types of key information to generate an optimization instruction through a pre-defined structured natural language template, and the prompt word template can be formalized as the following structured expression: Prompt = Instruct + Dockerfile + Smells Wherein the definition and examples of each component are as follows: Instruct, a pre-defined natural language instruction framework, is used to clearly define optimization goals and constraint conditions, and exemplary content is: "Please optimize the Dockerfile content based on the following Dockerfile content, and according to the detected odor problems, follow the Docker best practices, and retain the original function integrity, and output the optimized Dockerfile in the form of a code block".

[0028] Dockerfile, the original Dockerfile content to be optimized.

[0029] Smells, structured odor information output by the odor detection module in this iteration.

[0030] By step S104, the context of the object to be optimized can be deeply integrated with the optimization target instruction to generate a prompt word with clear direction.

[0031] S105. Large language model calling stage: input the prompt word into the large language model for semantic analysis and code generation, and output the optimized Dockerfile for the current Dockerfile odor; In specific embodiments, the constructed prompt word is sent to an external large language model server through a preset large language model service interface. The large language model performs semantic analysis and code generation on the input prompt word, and outputs the optimized Dockerfile for the current Dockerfile odor.

[0032] S106. Response analysis and iterative update: using a method combining regular expression matching and semantic analysis, the optimized Dockerfile is cleaned and key information is extracted to generate Dockerfile update content, and the Dockerfile update content is fed back to the odor detection module for the next iteration; In specific embodiments, the response returned by the large language model is a mixed text containing natural language instructions and code content. In this phase, a combination of regular expression matching and semantic analysis is used to clean and extract information from the mixed response. Specifically, first, quickly locate the possible position of the Dockerfile file, preferentially use the matching Markdown code block, regular expression example: (?:dockerfile|Dockerfile|bash|sh)?\s*([\s\S]*?), if not found, try to match the indented code block, regular expression example: (?m)^(\s{4,}|\t+)(.*)$, if both are not matched, the entire response text is taken as the object to be analyzed, and semantic analysis is performed. In semantic analysis, the system maintains a dictionary containing all standard Dockerfile instructions (such as FROM, RUN, COPY, WORKDIR, etc.), and scans the text to be analyzed according to the dictionary to identify text starting with instructions in the dictionary, and extracts the Dockerfile file code block. Finally, remove the inline comments in the file code block to obtain the optimized Dockerfile content, and use the content as the input data for the next iteration.

[0033] In specific embodiments, the system feeds back the updated Dockerfile content to the odor detection module (i.e. returns to step S102), and repeats the closed-loop process of "odor detection-prompt word construction-LLM code generation-response analysis-iterative detection". Each iteration aims to eliminate the current detected odor, and through multiple iterations, the quality of the Dockerfile is gradually improved.

[0034] S107. Output the final optimized Dockerfile result.

[0035] Another embodiment is used to illustrate a large language model-based Dockerfile smell iterative detection and repair system, the system 200 comprises: An initialization and input acquisition module 201 is configured to acquire an initial Dockerfile file content to be optimized input by a user and a preset maximum iteration number parameter. A smell detection module 202 is configured to perform multi-dimensional scanning and analysis on the input Dockerfile, and output structured smell detection information. An iteration termination condition judgment module 203 is configured to perform logical judgment on the current structured smell detection information. If the smell list in the current detection result is empty or the preset maximum iteration number is reached, the termination condition is triggered, and the final optimized Dockerfile result is output. Otherwise, the prompt word construction module, the large language model calling module, and the response analysis and iteration update module are executed: A prompt word construction module 204 is configured to fuse a predefined natural language instruction framework, a Dockerfile to be optimized, and structured smell information output by the smell detection module in the current iteration to generate a prompt word. A large language model calling module 205 is configured to input the prompt word into a large language model for semantic analysis and code generation. A response analysis and iteration update module 206 is configured to perform regular expression matching and semantic analysis on the output of the large language model calling module to clean and extract information, generate an optimized Dockerfile for the current Dockerfile smell, and feed back the optimized Dockerfile to the smell detection module for the next iteration.

[0036] The smell detection module 202 is based on the open source static analysis tool Hadolint.

[0037] The structured smell detection information in the smell detection module 202 includes smell type, smell specific description, and Dockerfile file line number.

[0038] The specific expression of the prompt word Prompt in the prompt word construction module 204 is: Prompt = Instruct + Dockerfile + Smells, wherein Instruct represents a predefined natural language instruction framework for explicitly defining optimization objectives and constraint conditions, Dockerfile represents the original Dockerfile to be optimized, and Smells represents the structured smell information output by the smell detection module in this iteration.

[0039] In addition to the above-mentioned modules, the system 200 can also include other components, however, since these components are irrelevant to the content of the embodiments of the present disclosure, the illustration and description thereof are omitted here.

[0040] The other specific working processes of the large language model-based Dockerfile smell iterative detection and repair system 200 are described with reference to the description of the above-mentioned large language model-based Dockerfile smell iterative detection and repair method embodiments, and will not be repeated here.

[0041] Another embodiment is used to illustrate that the system of the present application can also be implemented by means of Figure 3 the architecture of the computing device shown. Figure 3 The architecture of the computing device is shown. As Figure 3 shown, the computer system 310, the system bus 330, the one or more CPUs 340, the input / output 320, the memory 350, etc. The memory 350 can store various data or files used by the computer processing and / or communication and the program instructions executed by the CPU including the program instructions of the embodiments of the large language model-based Dockerfile smell iterative detection and repair method. Figure 3 The architecture shown is only exemplary, and when implementing different devices, one or more components in Figure 3 may be adjusted according to actual needs. The memory 350 as a kind of computer readable storage medium can be used to store software programs, computer executable programs and modules, such as the program instructions / modules corresponding to the large language model-based Dockerfile smell iterative detection and repair method in the embodiments of the present application (for example, the initialization and input acquisition module 201, the smell detection module 202, the iteration termination condition judgment module 203, the prompt word construction module 204, the large language model calling module 205 and the response analysis and iteration update module 206 in the large language model-based Dockerfile smell iterative detection and repair system 200). The one or more CPUs 340 execute various functional applications and data processing of the system of the present application by running the software programs, instructions and modules stored in the memory 350, that is, implement the above-mentioned large language model-based Dockerfile smell iterative detection and repair method, which includes the following steps: Obtaining the initial Dockerfile file content to be optimized input by a user and a preset maximum iteration number parameter; Inputting the initial Dockerfile content to a smell detection module, wherein the smell detection module performs multi-dimensional scanning and analysis on the input Dockerfile, and outputs structured smell detection information; Performing logical judgment on the current structured smell detection information, if the smell list in the current detection result is an empty set, or the preset maximum iteration number is reached, a termination condition is triggered, and a final optimized Dockerfile result is output; otherwise, the following steps are continuously executed: Fusing a predefined natural language instruction framework, an original Dockerfile to be optimized, and structured smell information output by the smell detection module in this iteration to generate a prompt word; Inputting the prompt word into a large language model for semantic analysis and code generation, performing regular expression matching and semantic analysis in combination to clean and extract information, and finally generating an optimized Dockerfile for the smell of the current Dockerfile; Feeding back the optimized Dockerfile to the smell detection module for the next iteration.

[0042] Of course, the processor of the server provided in the embodiments of the present application is not limited to performing the method operations as described above, but can also perform related operations in the large language model-based Dockerfile smell iterative detection and repair method provided in any embodiment of the present application.

[0043] The memory 350 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, application programs required by at least one function; the data storage area can store data created according to the use of the terminal, etc. In addition, the memory 350 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state memory device. In some examples, the memory 350 can further include a memory remotely arranged with respect to the one or more CPUs 340, which can be connected to the device through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0044] The input / output 320 can be used to receive input digital or character information, and to generate key signal input related to user settings and function control of the device. The input / output 320 can also include a display device such as a display screen.

[0045] The embodiment of the present application also provides a non-temporary computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the large language model-based Dockerfile smell iterative detection and repair method described in the above embodiment. The computer readable storage medium of the embodiment of the present application can adopt any combination of one or more computer readable media. The computer readable medium can be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples (non-exhaustive list) of the computer readable storage medium include: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or apparatus.

[0046] The computer readable signal medium can include a data signal propagated in a baseband or as a part of a carrier wave, in which a computer readable program code is borne. Such a propagated data signal can take on multiple forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium can also be any computer readable medium that is not a storage medium and that can send, propagate or transmit a program for use by or in connection with an instruction execution system, apparatus or device.

[0047] The program code contained on the storage medium can be transmitted in any suitable medium, including but not limited to wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0048] In addition, the other specific working processes of the non-temporary computer readable storage medium are described with reference to the above embodiment of the large language model-based Dockerfile smell iterative detection and repair method, and will not be repeated here.

[0049] In this document, the term "include", "contain" or any other variant thereof is intended to cover non-exclusive inclusion, so that the steps, methods including a series of elements not only include those elements, but also include other elements not explicitly listed, or include elements inherent to such steps, methods.

[0050] The above is further detailed description of the present application in combination with specific preferred embodiments, and cannot be deemed as limitation of the specific implementation of the present application to these descriptions. For those skilled in the art to which the present application belongs, without departing from the concept of the present application, a number of simple deductions or substitutions can be made, and all should be deemed as falling within the protection scope of the present application.

Claims

1. A Dockerfile smell iterative detection and repair method based on a large language model, characterized in that, The method comprises the following steps: Obtaining the initial Dockerfile file content to be optimized input by a user and a preset maximum iteration number parameter; Inputting the initial Dockerfile content into a smell detection module, which performs multi-dimensional scanning and analysis on the input Dockerfile and outputs structured smell detection information; Performing logical judgment on the current structured smell detection information, and if the smell list in the current detection result is an empty set or the preset maximum iteration number has been reached, triggering a termination condition and outputting a final optimized Dockerfile result; otherwise, the following steps are continued to be executed: Fusing a predefined natural language instruction framework, the original Dockerfile to be optimized, and the structured smell information output by the smell detection module in this iteration to generate a prompt word; Inputting the prompt word into a large language model for semantic analysis and code generation, and performing regular expression matching and semantic analysis in combination to clean and extract information, and finally generating an optimized Dockerfile for the smell of the current Dockerfile; Feeding back the optimized Dockerfile to the smell detection module for the next iteration.

2. The Dockerfile smell iterative detection and repair method based on a large language model according to claim 1, characterized in that, The smell detection module is constructed based on the open source static analysis tool Hadolint.

3. The method of claim 1, wherein the method further comprises: The structured smell detection information includes smell type, smell specific description, and Dockerfile file line number.

4. The Dockerfile smell iterative detection and repair method based on a large language model according to claim 1, characterized in that, The specific expression of the prompt word Prompt is: Prompt = Instruct + Dockerfile + Smells, wherein Instruct represents a predefined natural language instruction framework, which is used to clearly define the optimization target and constraint condition, Dockerfile represents the Dockerfile to be optimized, and Smells represents the structured smell information output by the smell detection module in this iteration.

5. A Dockerfile smell iterative detection and repair system based on a large language model, characterized in that, The system comprises: An initialization and input acquisition module for acquiring the initial Dockerfile file content to be optimized input by a user and a preset maximum iteration number parameter; A smell detection module for performing multi-dimensional scanning and analysis on the input Dockerfile and outputting structured smell detection information; An iteration termination condition judgment module for performing logical judgment on the current structured smell detection information, and if the smell list in the current detection result is an empty set or the preset maximum iteration number has been reached, triggering a termination condition and outputting a final optimized Dockerfile result; otherwise, the prompt word construction module, the large language model calling module, and the response analysis and iteration update module are continued to be executed: A prompt word construction module for fusing a predefined natural language instruction framework, the Dockerfile to be optimized, and the structured smell information output by the smell detection module in this iteration to generate a prompt word; A large language model calling module for inputting the prompt word into a large language model for semantic analysis and code generation; In response to the analysis and iterative updating module, a method combining regular expression matching and semantic analysis is used to clean and extract information from the output of the large language model calling module, generate an optimized Dockerfile for the current Dockerfile smell, and feed the optimized Dockerfile back to the smell detection module for the next iteration.

6. The Dockerfile smell iterative detection and repair system based on a large language model according to claim 5, characterized in that, The smell detection module is based on the open source static analysis tool Hadolint.

7. The Dockerfile smell iterative detection and repair system based on a large language model according to claim 5, characterized in that, The structured smell detection information in the smell detection module includes smell type, smell specific description and Dockerfile file line number.

8. The Dockerfile smell iterative detection and repair system based on a large language model of claim 5, wherein, The specific expression of the prompt word Prompt in the prompt word construction module is: Prompt = Instruct + Dockerfile + Smells, wherein Instruct represents a predefined natural language instruction framework for clearly defining optimization goals and constraint conditions, Dockerfile represents the original Dockerfile to be optimized, and Smells represents the structured smell information output by the smell detection module in this iteration.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps of the Dockerfile smell iterative detection and repair method based on the large language model according to any one of claims 1 to 4.

10. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The instructions are executed by the processor to implement the steps of the Dockerfile smell iterative detection and repair method based on the large language model according to any one of claims 1 to 4.

Images