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

Abstract

The application discloses a Dockerfile smell iterative detection and repair method and system based on a large language model, which comprises the following steps: obtaining user inputted initial Dockerfile file content to be optimized and inputting the same to a smell detection module for multidimensional scanning and analysis, and outputting structured smell detection information; 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 outputting an optimized Dockerfile for the current Dockerfile smell; adopting a method combining regular expression matching and semantic analysis to clean and extract key information from the optimized Dockerfile, generating Dockerfile update content, and feeding back the Dockerfile update content to the smell detection module for the next iteration. The application realizes the intelligentization and automation from Dockerfile smell detection to repair.

Description

Technical Field

[0001] This invention relates to the field of container technology, specifically to a method and system for iterative detection and repair of Dockerfile odors based on a large language model. Background Technology

[0002] Docker is a widely used tool in the software industry that creates a stable and portable container environment on a machine, avoiding a range of problems that can arise when migrating environments between different machines, including missing dependencies, configuration errors, and version incompatibility. This container environment is guided by a Dockerfile, which instructs Docker to build and run images. A Dockerfile is a series of instructions. However, due to insufficient training for Dockerfile writers, some low-quality Dockerfiles have emerged, resulting in inefficient and insecure images. These low-quality Dockerfiles that deviate from best practices are known as "Dockerfile smells."

[0003] Currently, academia and industry have made many efforts to detect and eliminate Dockerfile smells, and there are mature technical solutions, mainly including two categories: (1) rule generation methods based on data mining, such as the Drive tool, which automatically mines common error patterns and transforms them into detection rules by analyzing Dockerfiles in massive open-source projects. (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, which can effectively identify various smells and potential risks in Dockerfiles through syntactic and semantic analysis. In terms of elimination, existing technical solutions rely heavily on manually predefined elimination rules.

[0004] Because detection rules can be generated through data mining, their number far exceeds that of elimination rules, and some odors are complex and difficult to eliminate using rule analysis. Therefore, current odor elimination rules only cover common, impactful, and easily eliminated odors, making it difficult to address complex or rare odors.

[0005] The aforementioned existing technical solutions have the following significant defects and limitations:

[0006] 1. Insufficient rule coverage for removal: The number of rules for detecting odors far exceeds the number of rules for removal. Manually writing corresponding removal rules for each detection rule requires significant expert resources. Furthermore, fixing some complex Dockerfile odors requires a deep understanding of the code's context and semantics, rather than simple text replacement or instruction merging. For example, "determining whether to use COPY instead of ADD" or "optimizing instruction order to utilize the build cache" are complex scenarios that are difficult to handle reliably and correctly with limited, fixed rules.

[0007] 2. Limited Automation: Existing methods mainly remain at the "detection-reporting" stage, with weak remediation capabilities. Developers still need to manually read reports and modify code, which is inefficient. Furthermore, with the continuous evolution of Docker engines and best practices, the remediation rule base needs to be constantly updated and expanded, which brings a continuous burden and cost to the maintenance of the technical solution. Summary of the Invention

[0008] To address the aforementioned issues, this invention provides a method, system, and storage medium for iterative detection and repair of Dockerfile odors based on a large language model, aiming to achieve intelligent and automated detection and repair of Dockerfile odors.

[0009] According to a first aspect of the present disclosure, an iterative detection and repair method for Dockerfile odors based on a large language model is provided, the method comprising the following steps:

[0010] Obtain the content of the initial Dockerfile to be optimized and the preset maximum number of iterations parameter input by the user;

[0011] The initial Dockerfile content is input into the odor detection module, which performs multi-dimensional scanning and analysis on the input Dockerfile and outputs structured odor detection information.

[0012] Logically assess the current structured odor detection information. If the odor list in the current detection result is empty, or the preset maximum number of iterations has been reached, trigger the termination condition and output the final optimized Dockerfile result; otherwise, continue with the following steps:

[0013] The predefined natural language instruction framework, the original Dockerfile to be optimized, and the structured odor information output by the odor detection module in this iteration are fused to generate prompt words;

[0014] The prompt words are input into a large language model for semantic parsing and code generation. The output is cleaned and information is extracted using a combination of regular expression matching and semantic analysis. Finally, an optimized Dockerfile is generated to address the current Dockerfile smell.

[0015] The optimized Dockerfile will be fed back to the odor detection module for the next iteration.

[0016] A further technical solution of the present invention is that the odor detection module is built based on the open-source static analysis tool Hadolint.

[0017] A further technical solution of the present invention is that the structured odor detection information includes odor type, specific description of odor, and line number of the Dockerfile.

[0018] A further technical solution of the present invention is as follows: the specific expression of the prompt word Prompt is: Prompt = Instruct + Dockerfile + Smells, where Instruct represents a predefined natural language instruction framework used to clarify the optimization goals and constraints, Dockerfile represents the Dockerfile to be optimized, and Smells represents the structured odor information output by the odor detection module in this iteration.

[0019] According to a second aspect of the present disclosure, a Dockerfile odor iterative detection and repair system based on a large language model is provided, the system comprising:

[0020] The initialization and input acquisition module is used to acquire the content of the initial Dockerfile to be optimized and the preset maximum number of iterations parameter input by the user;

[0021] The odor detection module is used to perform multi-dimensional scanning and analysis on the input Dockerfile and output structured odor detection information.

[0022] The iteration termination condition judgment module is used to logically judge the current structured odor detection information. If the odor list in the current detection result is an empty set, or the preset maximum number of iterations has been 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 parsing and iterative update module continue to be executed.

[0023] The prompt word construction module is used to fuse the predefined natural language instruction framework, the Dockerfile to be optimized, and the structured odor information output by the odor detection module in this iteration to generate prompt words;

[0024] The large language model calling module is used to input prompt words into the large language model for semantic parsing and code generation;

[0025] The response parsing and iterative update module is used to clean and extract information from the output of the large language model calling module by combining regular expression matching and semantic analysis, generate an optimized Dockerfile for the current Dockerfile smell, and feed the optimized Dockerfile back to the smell detection module for the next round of iteration.

[0026] A further technical solution of the present invention is that the odor detection module is built based on the open-source static analysis tool Hadolint.

[0027] A further technical solution of the present invention is as follows: the structured odor detection information in the odor detection module includes odor type, specific description of odor, and line number of the Dockerfile.

[0028] A further technical solution of the present invention is as follows: the specific expression of the prompt word Prompt in the prompt word construction module is: Prompt = Instruct + Dockerfile + Smells, where Instruct represents a predefined natural language instruction framework used to clarify the optimization goal and constraints, Dockerfile represents the original Dockerfile to be optimized, and Smells represents the structured odor information output by the odor detection module in this iteration.

[0029] According to a third aspect of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the above-described iterative detection and repair method for Dockerfile odors based on a large language model.

[0030] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, wherein computer instructions are stored on the storage medium, and when executed by a processor, the instructions implement the steps of the above-described iterative detection and repair method for Dockerfile odors based on a large language model.

[0031] The present disclosure provides an iterative detection and repair method, system, and storage medium for Dockerfile odors based on a large language model, which has the following advantages compared with existing technologies:

[0032] Leveraging the understanding and generation capabilities of large language models, we can expand the scope of automated remediation and address complex or even rare Dockerfile smells that lack predefined remediation rules.

[0033] Through an iterative optimization mechanism, we ensure the thoroughness of the repair process and the high quality of the output results, avoiding new problems that may arise from a single repair.

[0034] This enables intelligent and automated detection and remediation of Dockerfile anomalies, reducing reliance on rules written by human experts and improving development efficiency and software quality.

[0035] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0037] Figure 1 This is a schematic diagram of the iterative detection and repair method for Dockerfile odors based on a large language model in an embodiment of the present invention;

[0038] Figure 2 This is a structural diagram of the Dockerfile odor iterative detection and repair system based on a large language model in this embodiment of the invention;

[0039] Figure 3 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0040] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present invention are shown in the drawings, not the entire structure.

[0041] Before discussing the exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of these steps can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the steps can be rearranged. The process can be terminated when its operation is complete, but may also have additional steps not included in the figures. The process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0042] The application areas of this invention include: 1. Software development and DevOps / CI-CD pipeline automation: As an automated quality gatekeeper in a continuous integration / continuous deployment (CI / CD) pipeline. Before the automated pipeline builds an image using a Dockerfile, the system described in this invention is automatically invoked to scan and optimize the Dockerfile, improving image quality from the source; 2. Cloud-native application development and deployment platform: Integrated into container orchestration platforms such as Kubernetes and Docker Swarm. When developers upload or write Dockerfiles through the platform, the platform can automatically invoke this service to provide real-time optimization suggestions or silent optimization, reducing the user's barrier to entry and improving the overall quality and security of application deployment on the platform; 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. This invention can be integrated into the Dockerfile to provide an automatic repair solution upon detecting Dockerfile-related issues; 4. Code Quality Platform and IDE Plugin: Integrating as a plugin into Integrated Development Environments (IDEs) such as Visual Studio Code and JetBrains IDEA provides developers with real-time Dockerfile writing suggestions and a "one-click optimization" function, acting as an intelligent programming assistant to help developers learn and write best-practice code. 5. Network Range: In network attack and defense drills, network security training, and other target range environments, quickly building target machine base images that conform to best practices is crucial. This invention can be integrated into the range management platform to automatically optimize the Dockerfiles of training containers, ensuring the security (e.g., using non-root users, reducing unnecessary exposure) and efficiency (reducing training resource consumption) of the target machine environment itself.

[0043] The following embodiments are provided for an iterative detection and repair method, system, and storage medium for Dockerfile odors based on a large language model:

[0044] like Figure 1 As shown, an iterative detection and repair method for Dockerfile smells based on a large language model includes the following steps:

[0045] S101. Process Initialization and Input Acquisition: After the process starts, the content of the initial Dockerfile to be optimized and the preset maximum number of iterations parameter are obtained from the user input.

[0046] S102. Odor Detection Stage: The initial Dockerfile content is input into the odor detection module. The odor detection module performs multi-dimensional scanning and analysis on the input Dockerfile and outputs structured odor detection information. The odor detection module is built based on the static analysis tool Hadolint. The structured odor detection information includes odor type, specific description of odor, and the line number of the code where it is located.

[0047] S103. Iteration Termination Condition Judgment: Logically judge the current structured odor detection information. If the odor list in the current detection result is an empty set, or the preset maximum number of iterations has been reached, trigger the termination condition and proceed to S107 to output the final optimized Dockerfile result; otherwise, continue to execute the following steps:

[0048] S104. Prompt word construction stage: The predefined natural language instruction framework, the original Dockerfile to be optimized, and the structured odor information output by the odor detection module in this iteration are fused to generate prompt words.

[0049] Specifically, the expression for the prompt word Prompt is: Prompt = Instruct + Dockerfile + Smells, where Instruct represents a predefined natural language instruction framework used to clarify the optimization goals and constraints, Dockerfile represents the Dockerfile to be optimized, and Smells represents the structured odor information output by the odor detection module in this iteration.

[0050] In one specific embodiment, S104 uses a predefined structured natural language template to fuse three types of key information to generate an optimized instruction. The prompt word template can be formalized into the following structured expression:

[0051] Prompt = Instruct + Dockerfile + Smells

[0052] The definitions and examples of each component are as follows:

[0053] Instruct is a predefined framework of natural language instructions used to specify optimization goals and constraints. An example is: "Based on the following Dockerfile content, optimize it according to Docker best practices to address the detected odor issues, while preserving the integrity of the original functionality. Please output the optimized Dockerfile as a code block."

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

[0055] Smells are the structured odor information output by the odor detection module in this iteration.

[0056] Step S104 allows for the deep integration of the context of the object to be optimized with the optimization target instructions, generating prompts with clear direction.

[0057] S105. Large Language Model Invocation Phase: Input the prompt words into the large language model for semantic parsing and code generation, and output an optimized Dockerfile that addresses the current Dockerfile smells;

[0058] In a specific embodiment, the constructed prompt words are sent to an external large language model server through a preset large language model service interface. The large language model performs semantic parsing and code generation on the input prompt words, and outputs an optimized Dockerfile that addresses the current Dockerfile smell.

[0059] S106. Response Parsing and Iterative Update: A combination of regular expression matching and semantic analysis is used to clean the optimized Dockerfile and extract key information, generating Dockerfile update content, which is then fed back to the odor detection module for the next round of iteration;

[0060] In a specific embodiment, the response returned by the large language model is a mixed text containing natural language descriptions and code content. This stage employs a combination of regular expression matching and semantic analysis to clean and extract information from the mixed response. Specifically, it first quickly locates the possible position of the Dockerfile, prioritizing matching Markdown code blocks. A regular expression example is: (?:dockerfile|Dockerfile|bash|sh)?\s*([\s\S]*?). If no match is found, it attempts to match indented code blocks. A regular expression example is: (?m)^(\s{4,}|\t+)(.*)$. If neither matches, the entire response text is treated as the object to be analyzed for semantic analysis. During semantic analysis, the system maintains a dictionary containing all standard Dockerfile instructions (such as FROM, RUN, COPY, WORKDIR, etc.). The text to be analyzed is scanned according to this dictionary, identifying text starting with instructions from the dictionary to extract the Dockerfile code blocks. Finally, all inline comments within the code blocks of the file are removed to obtain the optimized Dockerfile content, which is then used as input data for the next iteration.

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

[0062] S107. Optimization Result Output: Outputs the final optimized Dockerfile result.

[0063] Another embodiment illustrates an iterative detection and repair system for Dockerfile odors based on a large language model. The system 200 includes:

[0064] The initialization and input acquisition module 201 is used to acquire the content of the initial Dockerfile to be optimized and the preset maximum number of iterations parameter input by the user;

[0065] Odor detection module 202 is used to perform multi-dimensional scanning and analysis on the input Dockerfile and output structured odor detection information;

[0066] The iteration termination condition judgment module 203 is used to perform logical judgment on the current structured odor detection information. If the odor list in the current detection result is an empty set, or the preset maximum number of iterations has been 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 parsing and iterative update module continue to be executed.

[0067] The prompt word construction module 204 is used to fuse the predefined natural language instruction framework, the Dockerfile to be optimized, and the structured odor information output by the odor detection module in this iteration to generate prompt words;

[0068] The large language model calling module 205 is used to input prompt words into the large language model for semantic parsing and code generation;

[0069] The response parsing and iterative update module 206 is used to clean and extract information from the output of the large language model calling module by combining regular expression matching and semantic analysis, generate an optimized Dockerfile for the current Dockerfile smell, and feed the optimized Dockerfile back to the smell detection module for the next round of iteration.

[0070] The odor detection module 202 is built based on the open-source static analysis tool Hadolint.

[0071] The structured odor detection information in the odor detection module 202 includes the odor type, a detailed description of the odor, and the line number of the Dockerfile in which it is located.

[0072] The specific expression of the prompt word Prompt in the prompt word construction module 204 is: Prompt = Instruct + Dockerfile + Smells, where Instruct represents a predefined natural language instruction framework used to clarify the optimization goals and constraints, Dockerfile represents the original Dockerfile to be optimized, and Smells represents the structured odor information output by the odor detection module in this iteration.

[0073] In addition to the modules described above, the system 200 may also include other components; however, since these components are not relevant to the content of this disclosure, their illustrations and descriptions are omitted here.

[0074] The other specific working processes of the Dockerfile odor iterative detection and repair system 200 based on a large language model are described in the above-described embodiment of the Dockerfile odor iterative detection and repair method based on a large language model, and will not be repeated here.

[0075] Another embodiment illustrates that the system of the present invention can also be achieved by means of... Figure 3 The architecture of the computing device shown is used to implement this. Figure 3 The architecture of the computing device is shown. For example... Figure 3 As shown, the computer system 310 includes a system bus 330, one or more CPUs 340, input / output 320, and memory 350. Memory 350 can store various data or files used for computer processing and / or communication, as well as program instructions executed by the CPU, including those described in the embodiment of the iterative detection and repair method for Dockerfile odors based on a large language model. Figure 3 The architecture shown is merely exemplary and should be adjusted according to actual needs when implementing different devices. Figure 3One or more components in the system. The memory 350, as a 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 iterative detection and repair method for Dockerfile odors based on a large language model in this embodiment of the invention (e.g., the initialization and input acquisition module 201, odor detection module 202, iteration termination condition judgment module 203, prompt word construction module 204, large language model calling module 205, and response parsing and iterative update module 206 in the iterative detection and repair system for Dockerfile odors based on a large language model 200). One or more CPUs 340 execute various functional applications and data processing of the system of the present invention by running the software programs, instructions, and modules stored in the memory 350, that is, implementing the above-mentioned iterative detection and repair method for Dockerfile odors based on a large language model, which includes the following steps:

[0076] Obtain the content of the initial Dockerfile to be optimized and the preset maximum number of iterations parameter input by the user;

[0077] The initial Dockerfile content is input into the odor detection module, which performs multi-dimensional scanning and analysis on the input Dockerfile and outputs structured odor detection information.

[0078] Logically assess the current structured odor detection information. If the odor list in the current detection result is empty, or the preset maximum number of iterations has been reached, trigger the termination condition and output the final optimized Dockerfile result; otherwise, continue with the following steps:

[0079] The predefined natural language instruction framework, the original Dockerfile to be optimized, and the structured odor information output by the odor detection module in this iteration are fused to generate prompt words;

[0080] The prompt words are input into a large language model for semantic parsing and code generation. The output is cleaned and information is extracted using a combination of regular expression matching and semantic analysis. Finally, an optimized Dockerfile is generated to address the current Dockerfile smell.

[0081] The optimized Dockerfile will be fed back to the odor detection module for the next iteration.

[0082] Of course, the processor of the server provided in the embodiments of the present invention is not limited to performing the method operations described above, but can also perform related operations in the Dockerfile odor iterative detection and repair method based on a large language model provided in any embodiment of the present invention.

[0083] The memory 350 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on terminal usage. Furthermore, the memory 350 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 350 may further include memory remotely configured relative to one or more CPUs 340, these remote memories being connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

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

[0085] This invention also provides a non-transitory computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements the iterative detection and repair method for Dockerfile odors based on a large language model as described in the above embodiments. The computer-readable storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a 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, apparatus, or device.

[0086] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0087] The program code contained on the storage medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0088] Furthermore, other specific working processes of a non-transitory computer-readable storage medium are described in the above embodiment of the Dockerfile odor iterative detection and repair method based on a large language model, and will not be repeated here.

[0089] In this document, the terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a step or method that comprises a list of elements includes not only those elements but also other elements not expressly listed or inherent to such a step or method.

[0090] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for iterative detection and repair of Dockerfile smells based on a large language model, characterized in that, The method includes the following steps: Get the content of the initial Dockerfile to be optimized and the preset maximum number of iterations parameter input by the user; The initial Dockerfile content is input into the odor detection module, which performs multi-dimensional scanning and analysis on the input initial Dockerfile and outputs structured odor detection information. Logically assess the current structured odor detection information. If the odor list in the current detection result is empty, or the preset maximum number of iterations has been reached, trigger the termination condition and output the final optimized Dockerfile result; otherwise, continue with the following steps: The predefined natural language instruction framework, the initial Dockerfile to be optimized, and the structured odor information output by the odor detection module in this iteration are fused to generate prompt words; The prompt words are input into a large language model for semantic parsing and code generation. The output is cleaned and information is extracted using a combination of regular expression matching and semantic analysis. Finally, an optimized Dockerfile is generated to address the current Dockerfile smell. The optimized Dockerfile will be fed back to the odor detection module for the next iteration. The odor detection module is built based on the open-source static analysis tool Hadolint. The specific expression for the prompt word Prompt is: Prompt = Instruct + Dockerfile + Smells, where Instruct represents a predefined natural language instruction framework used to clarify the optimization goals and constraints, Dockerfile represents the initial Dockerfile to be optimized, and Smells represents the structured odor information output by the odor detection module in this iteration.

2. The method for iterative detection and repair of Dockerfile odors based on a large language model according to claim 1, characterized in that, The structured odor detection information includes the odor type, a detailed description of the odor, and the line number of the Dockerfile in which it is located.

3. A Dockerfile anomaly detection and repair system based on a large language model, characterized in that, The system includes: The initialization and input acquisition module is used to acquire the content of the initial Dockerfile to be optimized and the preset maximum number of iterations parameter input by the user; The odor detection module is used to perform multi-dimensional scanning and analysis on the input initial Dockerfile and output structured odor detection information. The iteration termination condition judgment module is used to logically judge the current structured odor detection information. If the odor list in the current detection result is an empty set, or the preset maximum number of iterations has been 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 parsing and iterative update module continue to be executed. The prompt word construction module is used to fuse the predefined natural language instruction framework, the initial Dockerfile to be optimized, and the structured odor information output by the odor detection module in this iteration to generate prompt words; The large language model calling module is used to input prompt words into the large language model for semantic parsing and code generation; The response parsing and iterative update module is used to clean and extract information from the output of the large language model calling module by combining regular expression matching and semantic analysis, generate an optimized Dockerfile for the current Dockerfile smell, and feed the optimized Dockerfile back to the smell detection module for the next round of iteration; The odor detection module is built based on the open-source static analysis tool Hadolint. The specific expression of the prompt word Prompt in the prompt word construction module is: Prompt = Instruct + Dockerfile + Smells, where Instruct represents a predefined natural language instruction framework used to clarify the optimization goals and constraints, Dockerfile represents the initial Dockerfile to be optimized, and Smells represents the structured odor information output by the odor detection module in this iteration.

4. The Dockerfile Odor Iterative Detection and Repair System Based on a Large Language Model according to claim 3, characterized in that, The structured odor detection information in the odor detection module includes the odor type, a detailed description of the odor, and the line number of the Dockerfile in which it is located.

5. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the Dockerfile odor iterative detection and repair method based on a large language model as described in any one of claims 1 and 2.

6. A non-transitory computer-readable storage medium, wherein computer instructions are stored on the storage medium, characterized in that, When the instruction is executed by the processor, it implements the steps of the Dockerfile odor iterative detection and repair method based on a large language model as described in any one of claims 1 and 2.

Images