A container full-automatic construction method, system, electronic device and storage medium

Abstract

The application relates to the field of cloud native technology and discloses a container full-automatic construction method and system, an electronic device and a storage medium. The method comprises the following steps: receiving a business intention described in natural language and performing structural analysis, and outputting an intention parameter; matching a target cloud native constructor, generating business source code and CRD configuration; the CRD configuration comprises image CRD resources and intention CRD resources, and the intention CRD resources are the resourceized carriers of the business intention described in natural language; applying the CRD configuration to a Kubernetes cluster, listening to the changes of the CRD configuration, automatically completing container construction and pushing an image; adopting a fixed structured log protocol to collect construction data, executing a repair operation according to corresponding fault data and outputting a repair result when a preset fault scenario is triggered, automatically updating the business source code and the CRD configuration, triggering a new round of container construction, and realizing a full-link closed loop and full-process automatic intervention without manual intervention.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of cloud-native technology, and in particular to a fully automated container construction method, system, electronic device and storage medium. Background Technology

[0002] With the widespread adoption of cloud-native technologies, Kubernetes (K8s) has become the industry-standard infrastructure for container orchestration and management. Container images, as the core carrier for microservice delivery, directly determine the delivery quality and iteration speed of cloud-native applications based on their build efficiency, standardization, and automation level. Currently, two main technical paths have emerged in the container image building field: one is the traditional build method based on Dockerfiles, and the other is the standardized build method based on Cloud Native Buildpacks (CNBs). The latter, with its advantages such as eliminating the need for manually writing build scripts, natural adaptation to the cloud-native ecosystem, and support for cache reuse and security auditing, is gradually becoming the preferred solution for enterprise-level microservice containerization.

[0003] In the CNB ecosystem, Kpack, as a native image building component for Kubernetes, enables declarative image building, automatic version rebuilding, and clustered management through custom resource definitions (CRDs) such as ClusterBuilder and Image, and has become one of the core tools in the cloud-native building field. Meanwhile, with the rapid development of Large Language Model (LLM) technology, the Vibe Coding paradigm has emerged. It automatically generates business code based on natural language descriptions, significantly lowering the programming threshold and improving development efficiency, and has been widely applied in various code generation scenarios.

[0004] However, the current cloud-native container building and AI (Artificial Intelligence) intent programming technologies are largely disconnected, and existing technologies have failed to achieve deep coupling between the two. This results in numerous pain points in the containerized delivery of cloud-native applications: traditional Dockerfile building methods have high barriers to entry and poor portability, making it difficult to meet clustered management and security compliance requirements; while Kpack supports standardized building, it can only work based on existing Git source code, cannot accept natural language requirements, and does not have the ability to automatically generate business code and build configurations. After a build failure, manual investigation of logs, code modification, and configuration are required, with no automatic repair or iteration capabilities; Vibe Coding can only output business source code and does not have containerization adaptation, Kubernetes orchestration, or automatic generation capabilities for Kpack CRDs. The generated code often does not conform to the Buildpack specification and cannot be directly integrated into the Kpack build process, completely disconnected from the cloud-native delivery chain.

[0005] Furthermore, while existing cloud-native build tools possess some automation capabilities, they require significant manual intervention for configuration, troubleshooting, and optimization, resulting in high barriers to cloud-native deployment, long delivery cycles, and high operational costs. Currently, there is no technology that deeply couples VibeCoding with Kpack, nor does it have a dedicated intent resource carrier or a fixed-rule automatic repair loop. This makes it impossible to achieve fully automated, unattended container builds across the entire chain, leading to fragmented container build processes, cumbersome manual operations, and a lack of automatic repair and iteration capabilities. Summary of the Invention

[0006] The purpose of this invention is to provide at least one fully automated container construction method, system, electronic device, and storage medium, which can at least solve the technical problems of existing methods such as fragmented container construction processes, cumbersome manual operations, and lack of automatic repair and iteration capabilities.

[0007] To address the aforementioned technical problems, at least one embodiment of this application provides a fully automated container construction method, comprising: Receive business intents described in natural language, perform structured parsing, and output intent parameters; The target cloud-native builder is matched according to the intent parameters, and the business source code and CRD configuration are generated using the target cloud-native builder; the CRD configuration includes image CRD resources and intent CRD resources, and the intent CRD resources are the resource carriers of the business intent described in natural language; Apply the CRD configuration to the Kubernetes cluster, listen for changes to the CRD configuration, and automatically build containers and push images. The system uses a fixed structured log protocol to collect and build data. When a preset fault scenario is triggered, it performs repair operations based on the corresponding fault build data and outputs the repair results. The business source code and CRD configuration are automatically updated based on the repair results, triggering a new round of container construction and forming an iterative closed loop.

[0008] At least one embodiment of this application also provides a fully automated container build system, including an intent access module, an intelligent generation engine, a cloud-native build cluster module, and a build reflow and intelligent iteration module; The intent access module is used to: receive business intents described in natural language, perform structured parsing, and output intent parameters; The intelligent generation engine is used to: match a target cloud-native builder according to the intent parameters, and use the target cloud-native builder to generate business source code and CRD configuration; it is also used to: perform repair operations according to the corresponding fault construction data and output the repair results; the CRD configuration includes image CRD resources and intent CRD resources, and the intent CRD resources are the resource carriers of the business intent described in natural language; The cloud-native cluster building module is used to: apply the CRD configuration to the Kubernetes cluster, listen for changes in the CRD configuration, and automatically build containers and push images. The build backflow and intelligent iteration module is used to collect build data using a fixed structured log protocol, backflow the corresponding faulty build data to the intelligent generation engine when a preset fault scenario is triggered, receive the repair results output by the intelligent generation engine, automatically update the business source code and CRD configuration according to the repair results, trigger a new round of container build, and form an iterative closed loop.

[0009] At least one embodiment of this application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described fully automated container construction method.

[0010] At least one embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described fully automated container construction method.

[0011] The fully automated container building method provided in the embodiments of this application realizes a closed-loop process of "intent parsing → adaptation generation → Git push → CRD application → Kpack build → fault return → automatic repair → iterative reconstruction → continuous delivery", which requires no manual intervention throughout the process and automatically triggers incremental build when the business source code or build stack is updated.

[0012] In some optional embodiments, the business intent is structured and parsed according to preset fixed fields, which include programming language, application framework, service port, health check route, running permission level, image repository address, and build stack preferences.

[0013] In some optional embodiments, a target cloud-native builder is matched according to the intent parameters, and the target cloud-native builder is used to generate business source code and CRD configuration, including: A target cloud-native builder is matched by a preset mapping dictionary, which describes the correspondence between technology stacks and cloud-native builders. The target cloud-native builder is used to generate business source code and CRD configuration that conform to the cloud-native build package specification, and the business source code is pushed to the Git repository.

[0014] In some optional embodiments, a fixed structured log protocol is used to collect build data. When a preset fault scenario is triggered, a repair operation is performed based on the corresponding fault build data, and the repair result is output, including: Data is collected and constructed using a fixed structured log protocol; Determine whether a preset fault scenario is triggered, the preset fault scenarios include compilation failure, missing dependencies, and abnormal image push; If triggered, the system will use preset automatic fault repair rules to repair the fault based on the fault data and output the repair results.

[0015] In some optional embodiments, the preset automatic fault repair rules include: Compilation failed: Automatically correct syntax errors and infrastructure defects in the business source code; Dependency Missing: Automatically supplements the project's dependency configuration to match the dependency version requirements of the current build stack; Image push failed: Automatically correct image repository address, repository permission configuration and image tag format.

[0016] In some optional embodiments, the intent access module is used to: perform structured parsing of the business intent according to preset fixed fields, the preset fixed fields including programming language, application framework, service port, health check route, running permission level, image repository address and build stack preference.

[0017] In some optional embodiments, the build reflow and intelligent iteration module is used for: Data is collected and constructed using a fixed structured log protocol; Determine whether a preset fault scenario is triggered, the preset fault scenarios include compilation failure, missing dependencies, and abnormal image push; If triggered, the corresponding fault data is fed back to the intelligent generation engine, which uses preset automatic fault repair rules to repair the fault based on the fault construction data and outputs the repair results. The construction feedback and intelligent iteration module receives the repair results output by the intelligent generation engine and automatically updates the business source code and CRD configuration based on the repair results, triggering a new round of container construction and forming an iterative closed loop. Attached Figure Description

[0018] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0019] Figure 1 This is a flowchart of a fully automated container construction method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the field structure of the intent CRD provided in the embodiments of this application; Figure 3 This is a schematic diagram of a fully automated container building system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the fully automated container building system provided in an embodiment of this application; Figure 5 This is a flowchart of the Vibe Coding intent parsing and generation process provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating the working principle of the Kpack cloud-native build cluster provided in an embodiment of this application; Figure 7 This is a flowchart of the construction log backflow LLM intelligent iteration closed loop provided by an embodiment of this application; Figure 8 This is an Intent CRD+Kpack GitOps management flowchart provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0021] To facilitate understanding of the embodiments of this application, relevant content about cloud-native technology will be introduced first.

[0022] With the widespread adoption of cloud-native technologies, Kubernetes (K8s) has become the industry-standard infrastructure for container orchestration and management. Container images, as the core carrier for microservice delivery, directly determine the delivery quality and iteration speed of cloud-native applications based on their build efficiency, standardization, and automation level. Currently, two main technical paths have emerged in the container image building field: one is the traditional build method based on Dockerfiles, and the other is the standardized build method based on Cloud Native Buildpacks (CNB). The latter, with its advantages such as eliminating the need for manually writing build scripts, natural adaptation to the cloud-native ecosystem, and support for cache reuse and security auditing, is gradually becoming the preferred solution for enterprise-level microservice containerization.

[0023] In the CNB ecosystem, Kpack, as a native image building component for Kubernetes, enables declarative image building, automatic version rebuilding, and clustered management through custom resources (CRDs) such as ClusterBuilder and Image, and has become one of the core tools in the cloud-native building field. Meanwhile, with the rapid development of Large Language Model (LLM) technology, the Vibe Coding paradigm has emerged. It can automatically generate business code based on natural language descriptions, significantly lowering the programming threshold and improving development efficiency, and has been widely applied in various code generation scenarios.

[0024] However, the current cloud-native container building and AI (Artificial Intelligence) intent programming technologies are largely disconnected, and existing technologies have failed to achieve deep coupling between the two. This results in numerous pain points in the containerized delivery of cloud-native applications: traditional Dockerfile building methods have high barriers to entry and poor portability, making it difficult to meet clustered management and security compliance requirements; while Kpack supports standardized building, it can only work based on existing Git source code, cannot accept natural language requirements, and does not have the ability to automatically generate business code and build configurations. After a build failure, manual investigation of logs, code modification, and configuration are required, with no automatic repair or iteration capabilities; Vibe Coding can only output business source code and does not have containerization adaptation, Kubernetes orchestration, or automatic generation capabilities for Kpack CRDs. The generated code often does not conform to the Buildpack specification and cannot be directly integrated into the Kpack build process, completely disconnected from the cloud-native delivery chain.

[0025] Furthermore, while existing cloud-native build tools (such as Tencent Cloud CNB, AWS CodeBuild, GitLab CI / CD, etc.) possess some automated build capabilities, none have achieved a complete closed-loop process of "natural language intent → AI code generation → standardized build → automatic fault repair → continuous iteration." They still require significant manual intervention for configuration, troubleshooting, and optimization, resulting in high barriers to cloud-native deployment, long delivery cycles, and high operational costs. Currently, there is no existing technology that deeply couples Vibe Coding with Kpack, nor is there a dedicated intent resource carrier or a fixed-rule automatic repair closed loop, making it impossible to achieve fully automated, unattended container builds across the entire process.

[0026] Among related technologies, the simple combination of the Kpack build tool and a general AI code generation tool combines Kpack's cloud-native standardized build capabilities with the code generation capabilities of the general Vibe Coding tool. It is currently the mainstream attempt in the industry to realize "AI-assisted cloud-native builds". Its main technical content, implementation principles and operation steps are as follows: The solution mainly consists of two independent modules, which are not deeply coupled and are simply connected through manual operation, as detailed below: 1. General Vibe Coding AI Code Generation Module: Employing mainstream large language models (such as GPT, Claude, etc.), this module allows users to describe business requirements in natural language (e.g., "Java Maven microservice, port 8080, health check interface") and generate corresponding business source code (e.g., Java interface code, configuration files, etc.). Its core principle is to translate user intent into code generation instructions through natural language semantic parsing. Leveraging the code generation capabilities trained by the model, it outputs business code that conforms to basic syntax standards, but it does not adapt to Buildpack specifications or generate any Kubernetes or Kpack-related configuration files. The core characteristics of this module are consistent with existing Vibe Coding technologies; it is unconstrained automated code generation, only capable of source code output, lacking containerization adaptation and configuration generation capabilities.

[0027] 2. Kpack Cloud-Native Build Module: Utilizing official Kpack standard components (including kpack-controller, kpack-webhook, and the Paketo series of ClusterBuilders), deployed on a K8s / K3s cluster, its core principle is to detect Image CRD resource changes through the K8s Event listening mechanism, automatically pull source code from the Git repository, and call the ClusterBuilder and the corresponding Buildpack to complete dependency detection, compilation and packaging, OCI (Open Container Initiative) image generation, and image repository push. This module supports build cache reuse, SBOM material generation, and security scanning. However, its build process relies on manually pre-written Image CRD configurations and can only pull source code already existing in the Git repository. It cannot automatically retrieve AI-generated source code and lacks automatic fault repair capabilities, consistent with the core functionality of existing Kpack v0.17.0 and above.

[0028] The implementation of this solution requires full human intervention and lacks automated closed-loop processing. The specific steps are as follows: 1. Users describe their business requirements in natural language and input them into the general Vibe Coding AI code generation tool to generate business source code (such as Java Maven project code, pom.xml dependency configuration, etc.). 2. Users manually inspect the generated source code and modify any content that does not conform to Buildpack specifications (such as incompatible dependency versions, non-standard directory structure, etc.) to ensure that the source code can be recognized by Buildpack called by Kpack; 3. Users manually push the modified source code to the specified Git repository, locking the branch and revision; 4. Users manually write the Kpack Image CRD configuration file, specifying parameters such as Git repository address, revision version, ClusterBuilder, and image repository address, and manually apply the CRD configuration to the K8s cluster; 5. The Kpack module listens for changes to the Image CRD through K8s Events, automatically pulls the source code from the Git repository, and calls the corresponding ClusterBuilder and Buildpack to complete the image compilation, generation, and push. 6. If the build fails (e.g., compilation error, missing dependency, abnormal image push), the user needs to manually check the Kpack build log to locate the cause of the failure and manually modify the source code, dependency configuration or Image CRD parameters. 7. The user pushes the modified content back to the Git repository, manually triggers Kpack to rebuild, and repeats steps 5-6 until the build is successful; 8. If the source code or build stack needs to be updated later, the user needs to repeat all the above steps to manually complete the source code modification, Git push, CRD update and build trigger.

[0029] This solution merely combines "AI code generation" and "Kpack building," failing to address the disconnect between the two or establish an automated closed loop. Its core shortcomings are as follows, which are also the technical deficiencies that this invention aims to address: 1. Lack of dedicated intent resource carrier: Without a dedicated Intent CRD resource, it is impossible to structure and resource the user's natural language intent, and it is impossible to achieve version control, GitOps synchronization and traceability of intent. User intent is disconnected from build configuration and source code, making it difficult to achieve full-process auditability and version backtracking. 2. Lack of automatic mapping and adaptation mechanism: There is no built-in fixed mapping dictionary for the technology stack and ClusterBuilder. Users need to manually select the ClusterBuilder used for Kpack building. In addition, the source code generated by AI is not adapted to the Buildpack specification, which requires manual modification, increasing the manual operation cost and making it easy to have adaptation errors. 3. Lack of automated closed-loop capability: AI code generation, Git push, Kpack CRD configuration, build fault diagnosis, source code and configuration modification, etc. all require manual intervention. There is no automatic connection and iteration mechanism, and it is impossible to achieve unattended operation of the entire chain of "intent input → automatic generation → automatic build → fault repair → rebuild". 4. Lack of standardized fault feedback and repair mechanism: The lack of a fixed structured log protocol results in messy fault information that cannot be accurately fed back to the AI ​​model; moreover, the absence of preset fault repair rules means that manual troubleshooting and repair are required after a failure, which is inefficient and cannot achieve automatic iterative fault repair. 5. Extremely low module coupling: The Vibe Coding code generation module and the Kpack build module are independent of each other, with no data interaction or collaborative working mechanism. This makes it impossible to produce a technical effect of 1+1>2, and it still does not solve the core pain points of existing technologies, such as excessive manual intervention, low delivery efficiency, and high barriers to cloud-native implementation.

[0030] In summary, the existing technology only achieves a simple superposition of two technologies, and does not solve the defects of fragmented links, cumbersome manual operation, and lack of automatic repair and iteration capabilities.

[0031] To address the technical problems of existing methods, this invention proposes a fully automated container construction method, system, electronic device, and storage medium. It achieves "strong coupling and linkage, full-link automated closed-loop, dedicated Intent CRD management, and fixed-rule fault repair" and other technical means. Through the combination of these technical means, it overcomes the shortcomings of existing technologies, achieving a breakthrough in fully automated cloud-native AI container construction. This solves the defects of existing technologies, such as the disconnect between AI code generation and cloud-native construction, excessive manual intervention, and lack of automated closed-loop, realizing unattended delivery from "natural language intent input → full-link automated construction → automatic fault repair → continuous iteration." The implementation details of this invention are described below for ease of understanding and are not essential for implementing this solution.

[0032] Example 1: The fully automated container construction method of this embodiment can be applied to electronic devices with communication, computing, and data storage capabilities. Its specific process can be as follows: Figure 1 As shown, it includes: Step 101: Receive the business intent described in natural language and perform structured parsing to output intent parameters.

[0033] In the specific implementation, the business intent is structured and parsed according to preset fixed fields, which include programming language, application framework, service port, health check route, running permission level, image repository address and build stack preferences.

[0034] Step 102: Match the target cloud-native builder according to the intent parameters, and use the target cloud-native builder to generate business source code and CRD configuration.

[0035] Specifically, CRD configuration includes image CRD resources and intent CRD resources. Intent CRD resources are resource carriers of business intents described in natural language.

[0036] Step 103: Apply the CRD configuration to the Kubernetes cluster, listen for changes in the CRD configuration, and automatically complete container building and push the image.

[0037] Step 104: Collect and build data using a fixed structured log protocol. When a preset fault scenario is triggered, perform repair operations based on the corresponding fault build data and output the repair results.

[0038] In the specific implementation, a fixed structured log protocol is used to collect build data. When a preset fault scenario is triggered, repair operations are performed based on the corresponding fault build data and the repair results are output. This includes: collecting build data using a fixed structured log protocol; determining whether a preset fault scenario has been triggered, which includes compilation failure, missing dependencies, and abnormal image push; if triggered, using preset automatic fault repair rules, fault repair is performed based on the fault build data and the repair results are output.

[0039] Specifically, the preset automatic fault repair rules include: Compilation failed: Automatically correct syntax errors and infrastructure defects in the business source code; Dependency Missing: Automatically supplements the project's dependency configuration to match the dependency version requirements of the current build stack; Image push failed: Automatically correct image repository address, repository permission configuration and image tag format.

[0040] By pre-setting automatic fault repair rules, fixed repair rules are formulated for three types of pre-set fault scenarios, which can ensure accurate repair without manual intervention.

[0041] Step 105: Automatically update the business source code and CRD configuration based on the repair results, triggering a new round of container construction and forming an iterative closed loop.

[0042] The method in this embodiment parses the business intent described in natural language and outputs intent parameters. It then matches these parameters with a target cloud-native builder to generate business source code, image CRD resources, and intent CRD resources. The method applies the CRD configuration to the Kubernetes cluster, monitors for changes in the CRD configuration, and automatically completes container building and pushes the image. A fixed structured log protocol is used to collect build data. When a preset fault scenario is triggered, repair operations are performed based on the corresponding fault build data. The business source code and CRD configuration are automatically updated based on the repair results, triggering a new round of container building. This forms a closed loop of "intent parsing → adaptation generation → build execution → fault revert → iterative repair," automating container building throughout the entire process without manual intervention.

[0043] In some examples, the field structure of an Intent CRD is as follows: Figure 2 As shown, by using a custom Intent CRD resource as a Kubernetes resource carrier for natural language business intents, version control, GitOps synchronization, and traceability of business intents are achieved. The specific definition of the Intent CRD (which can be directly applied to a Kubernetes cluster) is as follows: apiVersion is fixed at vibe.kpack.io / v1alpha1, kind is fixed at Intent, and the spec field has 10 fixed fields that cannot be added or deleted, ensuring that the intent is structured and standardized. apiVersion: vibe.kpack.io / v1alpha1 kind: Intent metadata: name: app-intent-demo namespace: default spec: rawPrompt: "Java Maven microservice, port 8080, / health health check, non-root, local repository localhost:5000" # User's raw natural language intent language: java # The parsed programming language framework: maven # The parsed application framework port: 8080 # The resolved service port healthPath: / health # Resolved health check route runAsNonRoot: true # Parsed execution permissions (non-root) imageRegistry: localhost:5000 # The resolved image repository address clusterBuilderName: paketo-jammy-tiny # Automatically matched build stack gitRepo: "https: / / github.com / your-username / java-maven-app.git" # The Git repository address for source code push gitRevision: main # Locked Git branch / revision This Intent CRD works in conjunction with the Kpack Image CRD and is incorporated into GitOps management to achieve version consistency from "intent → source code → build configuration", which facilitates traceability and rollback.

[0044] In some embodiments, matching a target cloud-native builder based on intent parameters and generating business source code and CRD configuration using the target cloud-native builder includes: matching the target cloud-native builder ClusterBuilder using a preset mapping dictionary, where the preset mapping dictionary describes the correspondence between the technology stack and the cloud-native builder; generating business source code and CRD configuration adapted to the cloud-native build package specification using the target cloud-native builder, and pushing the business source code to a Git repository. Setting the mapping rules between the technology stack and ClusterBuilder using the preset mapping dictionary fixes the one-to-one correspondence between the technology stack and PaketoClusterBuilder, eliminating the need for manual selection and enabling automatic matching of the optimal build stack.

[0045] The method in this embodiment achieves a closed-loop end-to-end process of "intent parsing → adapter generation → Git push → CRD application → Kpack build → fault rollback → automatic repair → iterative reconstruction → continuous delivery," requiring no manual intervention throughout the entire process. Furthermore, incremental builds are automatically triggered whenever the business source code or build stack is updated. By forming a closed loop around "intent parsing → adapter generation → build execution → fault rollback → iterative repair," and leveraging Intent CRD resources for resource-based intent management, combined with preset mapping rules and fault repair rules, fully automated container construction without manual intervention is achieved.

[0046] Example 2: Another embodiment of this application relates to a fully automated container building system. The implementation details of this fully automated container building system are described below. The following implementation details are provided for ease of understanding and are not essential for implementing this solution. A schematic diagram of the fully automated container building system in this embodiment can be seen as follows: Figure 3 As shown, it includes an intent access module 310, an intelligent generation engine 320, a cloud-native construction cluster module 330, and a construction backflow and intelligent iteration module 340. Each module is strongly coupled and linked according to a fixed time sequence and a fixed data format. The modules work together from top to bottom, while the construction backflow and intelligent iteration module backflows to the intelligent generation engine, forming a closed loop.

[0047] The intent access module 310 is used to: receive business intents described in natural language and perform structured parsing, and output intent parameters. Specifically, it performs structured parsing of the business intents according to preset fixed fields, which include programming language, application framework, service port, health check route, running permission level, image repository address, and build stack preferences.

[0048] The intelligent generation engine 320 is used to: match the target cloud-native builder according to the intent parameters, and use the target cloud-native builder to generate business source code and CRD configuration; it is also used to: perform repair operations based on the corresponding fault construction data and output the repair results; the CRD configuration includes image CRD resources and intent CRD resources, and the intent CRD resources are the resource carriers of business intents described in natural language.

[0049] In some examples, the field structure of an Intent CRD is as follows: Figure 2 As shown, by using a custom Intent CRD resource as a Kubernetes resource carrier for natural language business intents, version control, GitOps synchronization, and traceability of business intents are achieved. The specific definition of the Intent CRD (which can be directly applied to a Kubernetes cluster) is as follows: apiVersion is fixed at vibe.kpack.io / v1alpha1, kind is fixed at Intent, and the spec field has 10 fixed fields that cannot be added or deleted, ensuring that the intent is structured and standardized. apiVersion: vibe.kpack.io / v1alpha1 kind: Intent metadata: name: app-intent-demo namespace: default spec: rawPrompt: "Java Maven microservice, port 8080, / health health check, non-root, local repository localhost:5000" # User's raw natural language intent language: java # The parsed programming language framework: maven # The parsed application framework port: 8080 # The resolved service port healthPath: / health # Resolved health check route runAsNonRoot: true # Parsed execution permissions (non-root) imageRegistry: localhost:5000 # The resolved image repository address clusterBuilderName: paketo-jammy-tiny # Automatically matched build stack gitRepo: "https: / / github.com / your-username / java-maven-app.git" # The Git repository address for source code push gitRevision: main # Locked Git branch / revision This Intent CRD works in conjunction with the Kpack Image CRD and is incorporated into GitOps management to achieve version consistency from "intent → source code → build configuration", which facilitates traceability and rollback.

[0050] In the specific implementation, the target cloud-native builder is matched according to the intent parameters, and the business source code and CRD configuration are generated using the target cloud-native builder. This includes: matching the target cloud-native builder through a preset mapping dictionary, which describes the correspondence between the technology stack and the cloud-native builder; generating business source code and CRD configuration that conform to the cloud-native build package specification using the target cloud-native builder, and pushing the business source code to the Git repository.

[0051] The cloud-native cluster building module 330 is used to: apply CRD configurations to Kubernetes clusters, listen for changes in CRD configurations, automatically build containers, and push images.

[0052] The build backflow and intelligent iteration module 340 is used to collect build data using a fixed structured log protocol. When a preset fault scenario is triggered, the corresponding fault build data is backflowed to the intelligent generation engine 320, and the repair results output by the intelligent generation engine 320 are received. Based on the repair results, the business source code and CRD configuration are automatically updated, triggering a new round of container build, forming an iterative closed loop.

[0053] In the specific implementation, the build reflow and intelligent iteration module 340 is used to: collect build data using a fixed structured log protocol; determine whether a preset fault scenario is triggered, which includes compilation failure, missing dependencies, and image push anomalies; if triggered, the corresponding fault build data is reflowed to the intelligent generation engine 320, so that it can use preset automatic fault repair rules to repair the fault based on the fault build data and output the repair results. The build reflow and intelligent iteration module 340 automatically updates the business source code and CRD configuration based on the repair results, triggering a new round of container build and forming an iterative closed loop.

[0054] Specifically, the preset automatic fault repair rules include: Compilation failed: Automatically correct syntax errors and infrastructure defects in the business source code; Dependency Missing: Automatically supplements the project's dependency configuration to match the dependency version requirements of the current build stack; Image push failed: Automatically correct image repository address, repository permission configuration and image tag format.

[0055] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.

[0056] In some alternative embodiments, the fully automated container build system can implement the fully automated container build method in any of the above embodiments.

[0057] For a detailed implementation of the device in this embodiment, please refer to the foregoing embodiments; this embodiment will not repeat the details here.

[0058] Example 3: Based on the foregoing embodiments, a specific implementation of a fully automated container construction system is provided.

[0059] System architecture such as Figure 4 As shown, the modules work together from top to bottom, while simultaneously constructing a backflow and intelligent iteration module 40 to backflow to the LLM Vibe Coding intelligent generation engine 20, forming a closed loop. The composition, function, and relationship of each module are as follows: 1. Intent Access Module 10: As the system entry point, it supports three input methods: command-line terminal, web interface, and GitOps configuration. It has built-in intent semantic normalization parsing rules. Its core function is to receive users' natural language business intents, perform structured parsing according to seven fixed fields (programming language, application framework, service port, health check route, running permission level, image repository address, and build stack preference), output standardized intent parameters, and pass them to the LLM Vibe Coding intelligent generation engine (i.e., the intelligent generation engine in the aforementioned embodiment). Through fixed field normalization parsing, it ensures that similar needs described in different natural languages ​​can be transformed into structured parameters in a unified format, providing a foundation for subsequent automatic matching and generation.

[0060] 2. LLM Vibe Coding Intelligent Generation Engine 20: As the core generation unit of the system, it connects unidirectionally to the Intent Access Module 10 and bidirectionally to the Build Backflow and Intelligent Iteration Module. It incorporates four core components: an intent parsing unit, a code generation unit, a CRD configuration generation unit, and a preset mapping dictionary. The core function of the LLM Vibe Coding Intelligent Generation Engine 20 is to receive structured intent parameters output by the Intent Access Module 10, match the optimal build stack using the preset mapping dictionary, and generate business source code (pushed to a Git repository), Kpack ImageCRD configuration, and Intent CRD resources that conform to the Cloud Native Buildpacks specification. Simultaneously, it receives fault data pushed by the Build Backflow and Intelligent Iteration Module 40 and performs automatic repair.

[0061] 3. Kpack Cloud-Native Build Cluster Module 30: Deployed on a Kubernetes / K3s cluster, it has a one-way connection with the LLM VibeCoding intelligent generation engine 20 and a one-way connection with the build recycle and intelligent iteration module 40. It has a built-in kpack-controller, kpack-webhook admission component, and pre-configured Paketo series ClusterBuilders (paketo-jammy-tiny, paketo-jammy-full). The core function of Kpack Cloud-Native Build Cluster Module 30 is to detect resource changes of Image CRD and Intent CRD through the native Kubernetes Event listening mechanism, automatically pull business source code from the Git repository, call the corresponding ClusterBuilder and Buildpack to complete dependency detection, compilation and packaging, OCI image generation and image push, and at the same time complete build cache reuse, SBOM material generation, container security vulnerability scanning, and pass the build status and logs to the build recycle and intelligent iteration module 40.

[0062] 4. Build Backflow and Intelligent Iteration Module 40: As the core of the system's closed loop, it is bidirectionally connected to the Kpack cloud-native build cluster module 30 and the LLMVibe Coding intelligent generation engine 20, and has built-in log collection, fault judgment, and data backflow units. The core function of the Build Backflow and Intelligent Iteration Module 40 is to collect the Kpack build status, fault type, build stack information, and error summary using a fixed structured log protocol, and determine whether three preset fault scenarios (compilation failure, missing dependencies, and abnormal image push) have been triggered. If triggered, the structured fault data is backflowed to the LLMVibe Coding intelligent generation engine 20, and the repair results output by the LLMVibe Coding intelligent generation engine 20 are received. The business source code, Intent CRD, and Kpack Image CRD in the Git repository are automatically updated, triggering a new round of build and forming an iterative closed loop. If no fault is triggered, only logs are retained, and no backflow is performed.

[0063] The system core resources defined in this embodiment are as follows: Figure 2 As shown, it includes a custom Intent CRD resource, which serves as a Kubernetes resource carrier for natural language intents, enabling version control, GitOps synchronization, and traceability of intents. Its field structure is as follows: The specific definition of the Intent CRD (which can be directly applied to a Kubernetes cluster) is as follows: apiVersion is fixed at vibe.kpack.io / v1alpha1, kind is fixed at Intent, and the spec field has 10 fixed fields that cannot be added or deleted, ensuring that the intent is structured and standardized. apiVersion: vibe.kpack.io / v1alpha1 kind: Intent metadata: name: app-intent-demo namespace: default spec: rawPrompt: "Java Maven microservice, port 8080, / health health check, non-root, local repository localhost:5000" # User's raw natural language intent language: java # The parsed programming language framework: maven # The parsed application framework port: 8080 # The resolved service port healthPath: / health # Resolved health check route runAsNonRoot: true # Parsed execution permissions (non-root) imageRegistry: localhost:5000 # The resolved image repository address clusterBuilderName: paketo-jammy-tiny # Automatically matched build stack gitRepo: "https: / / github.com / your-username / java-maven-app.git" # The Git repository address for source code push gitRevision: main # Locked Git branch / revision This Intent CRD works in conjunction with the Kpack Image CRD and is incorporated into GitOps management to achieve version consistency from "intent → source code → build configuration", which facilitates traceability and rollback.

[0064] The core rule definitions of the system in this embodiment (the key support for system implementation) are as follows: To achieve end-to-end automation, three core rules are preset and built into the LLM Vibe Coding intelligent generation engine 20 or the build reflow and intelligent iteration module 40, requiring no manual configuration: 1. Technology Stack and ClusterBuilder Mapping Rules (built into the preset mapping dictionary of LLM Vibe Coding intelligent generation engine 20): Fixed one-to-one correspondence between 4 mainstream technology stacks and Paketo ClusterBuilder, no manual selection required, automatically matching the optimal build stack, the specific mapping is as follows: Java Maven → paketo-jammy-tiny; Java Gradle → paketo-jammy-full; Python Flask → paketo-jammy-tiny; Go → paketo-jammy-tiny.

[0065] 2. Structured Reflow Log Protocol (built into the Reflow and Intelligent Iteration Module 40): A fixed JSON format containing only 5 standard fields ensures accurate reflow of fault data and avoids redundancy. The protocol definition is as follows: { "buildStatus": "Failed|Success", # Build status (failed / successful) "errorType": "CompileError|DependencyMissing|PushFailed", # Fault type (only 3 types can trigger a reflow) "buildStack": "paketo-jammy-tiny", # ClusterBuilder used in this build "errorSummary": "Dependency package could not be fetched", # Brief description of the error "imageTag": "localhost:5000 / my-app:latest" # Image tag for this build } 3. Automatic Fault Repair Rules (Built-in LLM Vibe Coding Intelligent Generation Engine 20): Fixed repair rules are formulated for 3 preset fault scenarios to ensure accurate repair without manual intervention: Compilation failure: Automatically corrects syntax errors and infrastructure defects in the business code to ensure that the code conforms to the Buildpack specification; Dependency missing: Automatically completes project dependency configurations (such as pom.xml for Java Maven and requirements.txt for Python) to match the dependency version requirements of the current build stack; Image push failed: Automatically corrects the image repository address, repository permission configuration, and image tag format to ensure compliance with OCI image standards and repository requirements.

[0066] This embodiment provides a fully automated cloud-native AI container build system based on Kpack and Vibe Coding. It comprises four tightly coupled core modules: a natural language intent access module, an LLM Vibe Coding intelligent generation engine, a Kpack cloud-native build cluster module, and a build reflow and intelligent iteration module. Each module operates in a sequential manner: "intent input → parsing → generation → build → reflow → repair," achieving end-to-end automation. The build reflow module only reflows structured data back to the LLM Vibe Coding intelligent generation engine under three preset fault scenarios. A custom Intent CRD resource is used: apiVersion is vibe.kpack.io / v1alpha1, kind is Intent, and the spec field contains 10 fixed structured fields: rawPrompt, language, framework, port, healthPath, runAsNonRoot, imageRegistry, clusterBuilderName, gitRepo, and gitRevision. This is used to implement Kubernetes resourceization, versioning, and GitOps management of natural language intents. The LLM VibeCoding intelligent generation engine performs structured parsing of natural language intents based on seven fixed fields, outputting standardized parameters. It includes a built-in preset mapping dictionary that binds Java Maven, Java Gradle, Python Flask, and Go technology stacks to `paketo-jammy-tiny` and `paketo-jammy-full` respectively, enabling automatic build stack matching. Based on the structured intent parameters, it automatically generates business source code that is Dockerfile-free and conforms to the CloudNative Buildpacks specification. It also automatically generates the `kpack.io / v1alpha2` version Image CRD configuration and the aforementioned dedicated Intent CRD resources, eliminating the need for manual coding. The engine collects build data using a structured log protocol in a fixed JSON format, triggering automatic LLM repair only in three scenarios: compilation failure, missing dependencies, and image push anomalies. LLM corrects business code, dependency configurations, or Kpack CRD parameters according to preset rules, achieving automatic fault repair.

[0067] Example 4: Based on the aforementioned embodiments, a specific implementation method for a fully automated container construction method is provided. This method implements a cloud-native AI container fully automated construction method based on Kpack and Vibe Coding, consisting of 9 steps, each executed in a fixed sequence. Figures 5 to 8 It provides a detailed explanation of the execution conditions, operation content, relationships, and functions of each step.

[0068] Figure 5 This is a flowchart of the Vibe Coding intent parsing and generation process, corresponding to the core steps 1-7 in the method (intent parsing → generation → push → CRD application). Figure 6 This diagram illustrates the working principle of building a Kpack cloud-native cluster, corresponding to step 5 (Kpack automatic build) in the method. Figures 5 to 6 The details are as follows: Step 1: Receive the user's natural language business intent and perform semantic normalization and structured parsing according to seven preset fixed fields.

[0069] Execution conditions: Users enter natural language intents via command line, web interface, or GitOps configuration (no format restrictions, such as "Java Maven microservice, port 8080, / health health check interface, running without root, image pushed to local localhost:5000 repository"). Operation content: After receiving the business intent, the intent access module extracts information from 7 fixed fields through the built-in semantic normalization parsing rules and outputs standardized parameters (such as language:java, framework:maven, port:8080, etc.). Function: To transform unstructured natural language business intents into structured and standardized intent parameters, providing a unified input for subsequent automatic matching and generation.

[0070] Step 2: By automatically matching the corresponding build stack with the technology stack built into the LLM Vibe Coding intelligent generation engine and the ClusterBuilder's preset mapping dictionary, LLM generates business source code, Kpack ImageCRD configuration, and dedicated Intent CRD resources that are compatible with the Buildpack specification.

[0071] Execution conditions: Receive the structured parameters output from step 1; Operation content: The intent parsing unit of the LLM Vibe Coding intelligent generation engine receives structured parameters (intent parameters), queries the built-in mapping dictionary, and matches the corresponding ClusterBuilder (e.g., matching paketo-jammy-tiny for Java Maven); the code generation unit uses the matched ClusterBuilder to generate business source code without Dockerfile and conforming to the Buildpack specification (e.g., a Java Maven project, including the main program, health check interface, and configuration files, ensuring that the directory structure and dependency format meet the Buildpack requirements of paketo-jammy-tiny); the CRD generation unit generates the Image CRD configuration for kpack.io / v1alpha2 (specifying Git repository address, image repository address, ClusterBuilder, and other parameters), and the CRD configuration generation unit generates a dedicated Intent CRD configuration (filling in the 7 types of fields parsed in step 1 and the matched ClusterBuilder, Git repository address, and other information); Function: To automatically generate "intent → source code → build configuration" without the need for manual code writing and CRD configuration, while ensuring that the generated content is compatible with Kpack build requirements.

[0072] Step 3: Automatically push the business source code to the Git repository and lock the branch and revision.

[0073] Execution conditions: Step 2 generates business source code and Intent CRD (which already includes the Git repository address gitRepo and the revision version gitRevision); Operation details: The LLM Vibe Coding intelligent generation engine automatically pushes the generated business source code to the Git repository specified in the Intent CRD via the Git API, locks the branch corresponding to gitRevision (such as the main branch), prohibits manual modification of the source code of this branch, and ensures the consistency between the source code and the intent and build configuration; at the same time, it updates the gitRevision field of the Intent CRD to record the currently pushed source code version; Function: To implement version control of source code, provide a stable source for Kpack to pull source code, and facilitate source code updates and traceability after subsequent fault fixes.

[0074] Step 4: Apply Intent CRD and Kpack Image CRD to the Kubernetes cluster.

[0075] Execution conditions: Step 3 has completed the source code push, and the Intent CRD and Image CRD configurations have been generated; Operation details: The LLM Vibe Coding intelligent generation engine applies Intent CRD and ImageCRD configurations to the K8s / K3s cluster simultaneously via the K8s API. The CRD resources are deployed to the default namespace (which can be modified via the metadata.namespace field of the Intent CRD). After receiving the CRD configuration, the K8s cluster completes resource registration and waits for the Kpack cluster to listen for changes. Function: To encapsulate build configurations and intents into resources, incorporate them into the K8s cluster management, and trigger subsequent Kpack automatic build processes.

[0076] Step 5: The Kpack cluster listens for CRD changes through Kubernetes Events, automatically pulls the source code, calls the corresponding ClusterBuilder to complete the compilation and build, and pushes the OCI image.

[0077] Execution conditions: Step 4 completes the CRD application, and the Kpack cluster (with kpack-controller, kpack-webhook, and Paketo ClusterBuilder deployed) is running; Operation content: Kpack's kpack-controller detects changes to the Image CRD through the native Kubernetes Event listening mechanism and automatically performs the following operations: ① Pull the business source code pushed to the Git repository in step 3 (based on the gitRepo and gitRevision specified by the Image CRD); ② Call the ClusterBuilder matched in step 2 (such as paketo-jammy-tiny), which calls the corresponding Buildpack to complete source code dependency detection, compilation, and packaging; ③ Generate an OCI standard image and push it according to the image repository address (such as localhost:5000) and image tag specified by the Image CRD; ④ Simultaneously enable build cache reuse (to reduce repeated build time), automatically generate an SBOM (Software Bill of Materials) (for security auditing), and perform container security vulnerability scanning (to investigate image security risks). Purpose: To enable standardized and automated building of container images without manual intervention, while meeting security and compliance requirements.

[0078] Step 6: Collect build data according to a fixed structured log protocol, and only revert to LLM in three scenarios: compilation failure, missing dependencies, and abnormal image push.

[0079] Execution condition: Step 5 completes the build (regardless of success or failure); Operation content: The log collection unit of the build reflow and intelligent iteration module collects data such as build status (success / failure), fault type (if it fails, only CompileError, DependencyMissing, and PushFailed are recorded), build stack information, error summary, and image tag according to the preset structured log protocol; the fault judgment unit determines whether the build has triggered the three types of fault scenarios. If it has, the data reflow unit pushes the structured fault data to the LLM Vibe Coding intelligent generation engine; if it has not been triggered (build success or other non-three types of faults), only the log is retained, and no reflow is performed; Function: Accurately screen fault scenarios that need to be repaired, reduce redundant data transmission, ensure that LLM only processes critical faults, and improve repair efficiency.

[0080] Step 7: LLM corrects the business code, dependency configuration, or Kpack image configuration according to the fault type and preset rules.

[0081] Execution conditions: Step 6 triggers three types of fault scenarios, and the LLM Vibe Coding intelligent generation engine receives structured fault data; Operation content: The LLM Vibe Coding intelligent generation engine performs repairs according to the fault type and preset repair rules: ① If it is a compilation failure (errorType: CompileError), it corrects syntax errors and basic structural defects in the business code to ensure that the code conforms to the Buildpack specification; ② If it is a dependency missing (errorType: DependencyMissing), it supplements the project dependency configuration (such as adding missing dependency packages and corresponding versions to pom.xml in Java Maven); ③ If it is an image push failure (errorType: PushFailed), it corrects the image repository address, permission configuration, and image tag format in the Image CRD to ensure that it conforms to the OCI standard and repository requirements; Function: Enables automatic fault repair without manual troubleshooting and modification, providing a foundation for subsequent iterative reconstruction.

[0082] Figure 7 To construct the log reflux LLM intelligent iteration closed-loop flowchart, the corresponding method steps are 8-9 (update after repair → rebuild). Figure 8 This is a flowchart for Intent CRD + Kpack GitOps management, corresponding to the GitOps synchronization steps in steps 3, 4, and 8 of the method. Combined with... Figures 7 to 8 Detailed explanation of steps 8-9: Step 8: Automatically update Git source code, Intent CRD, and Kpack Image CRD, triggering a new build until successful.

[0083] Execution conditions: Step 7 completes fault repair and generates the repaired source code and Image CRD configuration; Operation content: The build reflow and intelligent iteration module receives the repair results output by the LLM Vibe Coding intelligent generation engine and automatically performs the following operations: ① Push the repaired business source code to the Git repository and update the source code of the corresponding branch (keeping gitRevision and Intent CRD consistent); ② Update the relevant fields of the Intent CRD (e.g., after the source code is repaired, if dependency changes are involved, update the framework-related association information); ③ Update the configuration of the Kpack Image CRD (e.g., after fixing the image push failure, update the imageRegistry and imageTag fields); ④ Reapply the updated Intent CRD and Image CRD through the K8s API to trigger a new round of Kpack build; ⑤ Repeat steps 5-8 until the build is successful; Function: Enables automatic iteration after fault repair, forming a closed loop of "build → fault → repair → rebuild", ensuring successful final build without manual triggering.

[0084] Step 9: When the business source code or ClusterBuilder version is updated, Kpack automatically and incrementally rebuilds the image to achieve continuous delivery.

[0085] Execution conditions: After successful build, the user updates the source code in the Git repository (such as business function iteration), or the ClusterBuilder version in the Kpack cluster is updated (such as Paketo version upgrade). Operation details: The Kpack cluster listens for Git source code changes (via the gitRepo associated with the Image CRD) or ClusterBuilder version changes through K8s Events, automatically triggering incremental builds (building only the changed parts and reusing the original cache), generating a new OCI image and pushing it to the image repository without manual intervention; at the same time, it updates the gitRevision field of the Intent CRD to record the latest source code version; Purpose: To achieve continuous delivery and ensure that the image can be automatically updated after the source code or build stack is updated, thus meeting the needs of microservice iteration.

[0086] The beneficial effects that this embodiment can bring are as follows: 1. By using fixed intent semantic normalization parsing rules, it forcibly extracts seven types of structured fields: programming language, application framework, service port, health check route, runtime permission level, image repository address, and build stack preference. This transforms unstructured natural language intents into standardized parameters in a unified format. Simultaneously, it incorporates a pre-defined mapping dictionary to bind four mainstream technology stacks—Java Maven, Java Gradle, Python Flask, and Go—to the Paketo series ClusterBuilders (paketo-jammy-tiny, paketo-jammy-full), achieving automatic matching of the build stack without manual intervention. Compared to general AI code generation tools in related technologies that lack fixed field parsing rules and require manual selection of ClusterBuilders, Kpack solves the pain points of "non-standard intent parsing and build stack matching relying on manual intervention," forming the foundation for achieving end-to-end automation.

[0087] 2. A custom Intent CRD resource is defined, with the apiVersion fixed as vibe.kpack.io / v1alpha1, the kind as Intent, and the spec field fixed to include 10 structured fields such as rawPrompt (original intent), language, framework, and port. This transforms the user's natural language intent into native Kubernetes resources, achieving resource-based, versioned, GitOps-synchronized, and end-to-end traceability of the intent. Existing technologies lack such a custom Intent CRD, only general CRDs or no intent-based resource carrier exist. Therefore, version unification is achieved from "intent → source code → build configuration".

[0088] 3. The tightly coupled design of LLM and Kpack breaks the existing disconnect between AI code generation and Kpack building, achieving strong coupling between the LLM Vibe Coding intelligent generation engine and the Kpack cloud-native build cluster. LLM automatically generates business source code, Kpack Image CRDs, and Intent CRDs that conform to the Cloud Native Buildpacks specification, and automatically pushes the source code to the Git repository and the application CRD to the Kubernetes cluster, requiring no manual intervention. Kpack build status and fault data are automatically fed back to LLM, forming a two-way data interaction. Compared to the simple superposition of two technologies without data interaction and collaborative mechanisms in related technologies, this achieves a seamless connection of "intent input → automatic generation → automatic build," producing a new level of automation beyond the superposition of a single technology.

[0089] 4. A fixed JSON-formatted structured log protocol was designed, containing only five standard fields such as `buildStatus` and `errorType`. Only critical fault information is collected, avoiding redundant data transmission. Simultaneously, three fixed fault trigger conditions are preset: "compilation failure," "missing dependencies," and "image push anomaly." The LLM automatically repairs these faults according to the corresponding rules (code repair for compilation failure, configuration update for missing dependencies, image parameter modification for push failure), without supporting the repair of irrelevant faults, ensuring accurate and efficient repair. Compared to related technologies that lack standardized fault reflow protocols and fixed repair rules, requiring manual troubleshooting and repair after build failures, this approach achieves automatic fault identification, accurate reflow, and intelligent repair, which is the core of achieving closed-loop iteration.

[0090] 5. A closed-loop end-to-end system is constructed, encompassing "Natural Language Intent → Structured Parsing → Source Code / CRD Generation → Git Push → CRD Application → Kpack Build → Fault Revert → Automatic Repair → Update and Rebuild." After fault repair, the Git source code, Intent CRD, and Image CRD are automatically updated, triggering a new build cycle until successful. When the source code or build stack is updated, incremental Kpack rebuilding is automatically triggered, achieving continuous delivery without manual intervention. Compared to related technologies where each step requires manual intervention, this system completely solves the core pain points of existing technologies, namely cumbersome manual operations and low delivery efficiency.

[0091] Example 5: Based on the above embodiments, an application example of a fully automated container build system and method is provided, based on a Java Maven microservice scenario, detailing the specific implementation process of the solution.

[0092] I. Environmental Preparation (Prerequisites) 1. Deploy a K3s cluster (compatible with K8s cluster) to ensure the cluster operates normally and has basic resource scheduling capabilities; 2. Deploy the Kpack cloud-native build cluster module in the K3s cluster: Install kpack-controller (v0.17.0 version) and kpack-webhook, and pre-configure the Paketo series ClusterBuilder (paketo-jammy-tiny, paketo-jammy-full). 3. Deploy the LLM Vibe Coding intelligent generation engine, with built-in technology stack, ClusterBuilder mapping dictionary, and fault repair rules; 4. Prepare a Git repository (such as GitHub or GitLab) and obtain repository API permissions (for LLM automatic push / update of source code). 5. Prepare a local image repository (e.g., localhost:5000), ensuring that the Kpack cluster can access it normally and has image push permissions; 6. Deploy the Natural Language Intent Access Module (supporting web interface input) and the Build Backflow and Intelligent Iteration Module to ensure network connectivity between modules and normal data transmission.

[0093] II. Implementation Steps (Forming a Complete Closed Loop) Step 1: The user enters a natural language intent through the web interface: "Java Maven microservice, port 8080, / health health check interface, run without root, push image to local localhost:5000 repository" (corresponding to...) Figure 4 (User Natural Language Intent Input) Step 2: The intent access module receives the business intent, parses it according to 7 fixed fields, and outputs structured parameters: language:java, framework:maven, port:8080, healthPath: / health, runAsNonRoot:true, imageRegistry:localhost:5000, build stack preference:default (corresponding to...) Figure 5 Steps 1-2 in the process). Step 3: The LLM Vibe Coding intelligent generation engine receives structured parameters, queries the mapping dictionary, and matches ClusterBuilder as paketo-jammy-tiny (corresponding to...). Figure 5 Step 3); Generate Java Maven business source code adapted to the Buildpack specification (including the main program, / health health check interface, pom.xml dependency configuration, no Dockerfile), Kpack Image CRD configuration, and Intent CRD configuration (corresponding to...). Figure 5 Steps 4-5 in the middle). Step 4: The LLM Vibe Coding intelligent generation engine automatically pushes the generated Java source code to the preset Git repository (https: / / github.com / your-username / java-maven-app.git) via the Git API, locks the main branch, and updates the gitRepo and gitRevision fields of the Intent CRD (corresponding to...). Figure 5 Step 6 in the process). Step 5: The LLM Vibe Coding intelligent generation engine applies Intent CRDs and Image CRDs to the K3s cluster via the K8s API (corresponding to...). Figure 5 Step 7 in the middle). Step 6: The kpack-controller in the Kpack cluster listens for CRD changes via Kubernetes Events, automatically pulls the Java source code from the Git repository, calls paketo-jammy-tiny ClusterBuilder and the corresponding Buildpack, completes dependency checks, compilation and packaging, generates the OCI image (localhost:5000 / java-maven-app:latest), pushes it to the local image repository, and simultaneously generates the SBOM bill of materials and performs a security scan (corresponding to...). Figure 6 Steps 1-7 in the process). Step 7: The build reflow and intelligent iteration module collects build data. If a "dependency missing" error occurs (e.g., spring-boot-starter-web dependency is missing in pom.xml), fault data is generated according to the structured log protocol (buildStatus:Failed, errorType:DependencyMissing, buildStack:paketo-jammy-tiny, errorSummary:spring-boot-starter-web dependency missing, imageTag:localhost:5000 / java-maven-app:latest), and then reflowed to the LLM Vibe Coding intelligent generation engine (corresponding to...). Figure 7 (Steps 1-4) Step 8: The LLM Vibe Coding intelligent generation engine automatically supplements the spring-boot-starter-web dependency configuration in pom.xml based on the "dependency missing" fault type (corresponding to...). Figure 7 Step 5 in the process). Step 9: The build reflow and intelligent iteration module automatically pushes the repaired business source code to the Git repository, updates the Intent CRD and Image CRD configurations, reapplies them to the K3s cluster, and triggers a new round of Kpack build (corresponding to...). Figure 7 Steps 6-7 in the middle). Step 10: The Kpack cluster executes the build again. Dependency checks pass, compilation and packaging are successful, an image is generated and pushed to the Git repository, and the build is successful. Step 11: When a user subsequently updates the Java source code in the Git repository (e.g., adding a new interface), the Kpack cluster listens for source code changes, automatically triggers an incremental build, generates a new image, and pushes it, achieving continuous delivery (corresponding to...). Figure 8(Steps 5-6) At the same time, the gitRevision field of the Intent CRD is updated synchronously to achieve version tracking.

[0094] III. Implementation Results Verification After implementation, the effects can be verified through the following methods to ensure that the invention's purpose is achieved: 1. Container image building can be completed solely through natural language intents, eliminating the need for manually writing Dockerfiles, business source code, and Kpack CRD configurations. 2. If three types of preset faults occur during the construction process, the system will automatically repair and rebuild without manual intervention until the construction is successful; 3. Intent CRDs, source code, and Image CRDs are all integrated into GitOps management, allowing for version tracking and configuration rollback via Git repository; 4. The generated image conforms to the OCI standard, includes an SBOM (Bill of Materials), passes a security scan, and meets compliance requirements; 5. When the source code or build stack is updated, incremental builds are automatically triggered to achieve continuous delivery and significantly improve delivery efficiency.

[0095] Example 6: Another embodiment of this application relates to an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods described in the above embodiments.

[0096] In this embodiment, the memory and processor are connected via a bus, which can include any number of interconnected buses and bridges, connecting various circuits of one or more processors and the memory together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be further described in this embodiment. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0097] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0098] Example 7: Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.

[0099] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A fully automated container construction method, characterized in that, include: Receive business intents described in natural language, perform structured parsing, and output intent parameters; The target cloud-native builder is matched according to the intent parameters, and the business source code and CRD configuration are generated using the target cloud-native builder; the CRD configuration includes image CRD resources and intent CRD resources, and the intent CRD resources are the resource carriers of the business intent described in natural language; Apply the CRD configuration to the Kubernetes cluster, listen for changes to the CRD configuration, and automatically build containers and push images. Data is collected and constructed using a fixed structured log protocol. When a preset fault scenario is triggered, repair operations are performed based on the corresponding fault data and the repair results are output. The business source code and CRD configuration are automatically updated based on the repair results, triggering a new round of container construction and forming an iterative closed loop.

2. The fully automated container construction method according to claim 1, characterized in that, The business intent is structured and parsed according to preset fixed fields, which include programming language, application framework, service port, health check route, running permission level, image repository address, and build stack preference.

3. The fully automated container construction method according to claim 1, characterized in that, Match the target cloud-native builder according to the intent parameters, and use the target cloud-native builder to generate business source code and CRD configuration, including: A target cloud-native builder is matched by a preset mapping dictionary, which describes the correspondence between technology stacks and cloud-native builders. The target cloud-native builder is used to generate business source code and CRD configuration that conform to the cloud-native build package specification, and the business source code is pushed to the Git repository.

4. The fully automated container construction method according to claim 1, characterized in that, Data is collected and constructed using a fixed structured log protocol. When a preset fault scenario is triggered, repair operations are performed based on the corresponding fault data, and the repair results are output, including: Data is collected and constructed using a fixed structured log protocol; Determine whether a preset fault scenario is triggered, the preset fault scenarios include compilation failure, missing dependencies, and abnormal image push; If triggered, the system will use preset automatic fault repair rules to repair the fault based on the fault data and output the repair results.

5. The fully automated container construction method according to claim 4, characterized in that, The preset automatic fault repair rules include: Compilation failed: Automatically correct syntax errors and infrastructure defects in the business source code; Dependency Missing: Automatically supplements the project's dependency configuration to match the dependency version requirements of the current build stack; Image push failed: Automatically correct image repository address, repository permission configuration and image tag format.

6. A fully automated container building system, characterized in that, This includes an intent access module, an intelligent generation engine, a cloud-native build cluster module, and a build reflow and intelligent iteration module; The intent access module is used to: receive business intents described in natural language, perform structured parsing, and output intent parameters; The intelligent generation engine is used to: match a target cloud-native builder according to the intent parameters, and use the target cloud-native builder to generate business source code and CRD configuration; it is also used to: perform repair operations according to the corresponding fault data and output the repair results; the CRD configuration includes image CRD resources and intent CRD resources, and the intent CRD resources are the resource carriers of the business intent described in natural language; The cloud-native cluster building module is used to: apply the CRD configuration to the Kubernetes cluster, listen for changes in the CRD configuration, and automatically build containers and push images. The build backflow and intelligent iteration module is used to collect build data using a fixed structured log protocol, backflow the corresponding fault data to the intelligent generation engine when a preset fault scenario is triggered, receive the repair results output by the intelligent generation engine, automatically update the business source code and CRD configuration according to the repair results, trigger a new round of container build, and form an iterative closed loop.

7. The fully automated container construction system according to claim 6, characterized in that, The intent access module is used to: perform structured parsing of the business intent according to preset fixed fields, the preset fixed fields including programming language, application framework, service port, health check route, running permission level, image repository address and build stack preference.

8. The fully automated container construction system according to claim 6, characterized in that, The construction reflow and intelligent iteration module is used for: Data is collected and constructed using a fixed structured log protocol; Determine whether a preset fault scenario is triggered, the preset fault scenarios include compilation failure, missing dependencies, and abnormal image push; If triggered, the corresponding fault data is fed back to the intelligent generation engine, which uses preset automatic fault repair rules to repair the fault based on the fault construction data and outputs the repair results. The construction feedback and intelligent iteration module receives the repair results output by the intelligent generation engine and automatically updates the business source code and CRD configuration based on the repair results, triggering a new round of container construction and forming an iterative closed loop.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the fully automated container construction method as described in any one of claims 1 to 5.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the fully automated container construction method according to any one of claims 1 to 5.

Images