A method, system and device for generating a container orchestration deployment package and a storage medium

Abstract

The application discloses a container orchestration deployment package generation method, system, device and storage medium, and relates to the technical field of cloud computing.The method comprises the following steps: identifying configuration files and metadata related to deployment from a target source code warehouse according to target source code warehouse information in obtained deployment package generation instructions; converting the configuration files and metadata into a deployment blueprint through static analysis and collaborative analysis of a preset language model; performing virtualization environment adaptation on the deployment blueprint by using available resources and policy constraints corresponding to target virtualization tenant information to obtain an adapted deployment blueprint; and generating an orchestration deployment package corresponding to the adapted deployment blueprint.The application introduces a deployment blueprint as a core intermediate representation, decouples links such as warehouse analysis, environment adaptation and deployment package generation, improves debuggability and expandability, can stably and efficiently automatically generate a high-quality container orchestration deployment package, and realizes automatic delivery with high availability and high adaptability.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method, system, device, and storage medium for generating container orchestration and deployment packages. Background Technology

[0002] With the development of cloud computing technology, cloud-native has become the de facto standard for modern application architecture design and deployment. Based on containerization and Kubernetes (K8s, an open-source container orchestration system) at its core, orchestration and scheduling platforms have greatly improved the agility, portability, and elasticity of application delivery. In private cloud virtualization environments, enterprises are building Kubernetes-based Platform as a Service (PaaS) to uniformly manage their massive application portfolios. Within this ecosystem, Helm serves as the package manager for Kubernetes, and its defined Helm Chart format (a standardized application packaging format for Kubernetes) has become the most widely used method for packaging, distributing, and managing cloud-native applications.

[0003] In related technologies, converting existing applications (especially those not developed in cloud-native environments) into Helm Charts suitable for specific private cloud environments is a complex and error-prone manual task. Although some automation tools exist, these tools are either too simplistic to understand complex application contexts and environmental constraints, lack stability and controllability to meet enterprise user needs, or have poor scalability and universality, making them difficult to maintain and extend. Therefore, how to stably and efficiently automatically generate high-quality container orchestration and deployment packages, achieving automated delivery with high availability, high universality, and high adaptability, is an urgent problem to be solved. Summary of the Invention

[0004] The purpose of this invention is to provide a method, system, device, and computer-readable storage medium for generating container orchestration and deployment packages, so as to stably and efficiently generate high-quality container orchestration and deployment packages automatically, and achieve automated delivery with high availability, high versatility, and high adaptability.

[0005] To address the aforementioned technical problems, this invention provides a method for generating container orchestration and deployment packages, comprising: Based on the target source code repository information in the obtained deployment package generation instructions, the deployment-related configuration files and metadata are identified from the target source code repository; wherein, the deployment package generation instructions include the target source code repository information and the target virtualization tenant information; Through the collaborative analysis of static parsing and a preset language model, the configuration file and metadata are converted into a deployment blueprint; wherein, the deployment blueprint adopts a preset data exchange format, and the deployment blueprint includes at least one of the following: service definition, number of replicas, port, environment variables, volume mount, dependency relationship, probe, resource request and limit, and lifecycle hook; Using the available resources and policy constraints corresponding to the target virtualization tenant information, the deployment blueprint is adapted to the virtualization environment to obtain the adapted deployment blueprint; Generate the orchestration and deployment package corresponding to the adapted deployment blueprint.

[0006] On the other hand, the process of converting the configuration file and metadata into a deployment blueprint through collaborative analysis of static parsing and a preset language model includes: Based on the metadata, a static parser is used to process the structured files and extract baseline service information; wherein, the structured files include the structured files in the configuration file; Based on the metadata, the pre-defined language model is used to infer the unstructured files and obtain the inference result; wherein, the unstructured files include files other than the structured files in the configuration file; The deployment blueprint is constructed based on the baseline service information and the inference results; wherein the baseline service information has a higher priority than the inference results.

[0007] On the other hand, the step of adapting the deployment blueprint to a virtualized environment using the available resources and policy constraints corresponding to the target virtualized tenant information to obtain an adapted deployment blueprint includes: Using the plugin for the loaded target private cloud environment, obtain the available resources and policy constraints corresponding to the target virtualization tenant information; wherein, the target private cloud environment is the private cloud environment corresponding to the target virtualization tenant information; Based on the available resources and the policy constraints, the deployment blueprint is adapted to a virtualization environment to obtain an adapted deployment blueprint.

[0008] On the other hand, the step of identifying deployment-related configuration files and metadata from the target source code repository based on the target source code repository in the obtained deployment package generation instructions includes: Clone the target data from the target source code repository corresponding to the target source code repository information; Identify deployment-related configuration files from the target data; The metadata is obtained by performing deep parsing on the configuration file using a metadata extraction model; wherein the deep parsing includes at least one of document file parsing, application named entity recognition, relation extraction and text summarization, and the metadata extraction model is a pre-trained language model for metadata extraction.

[0009] On the other hand, identifying deployment-related configuration files from the target data includes: If there are files to be partitioned in the configuration file, the master-slave score of each file to be partitioned corresponding to the current type is calculated according to the preset scoring algorithm; wherein, the files to be partitioned are configuration files of the same type, the current type is any type corresponding to at least two configuration files, and the preset scoring algorithm is used to calculate the score based on at least one weighted factor among standard file name matching degree, file path depth, content keywords and service quantity; Based on the master-slave score, determine a master configuration file corresponding to the current type.

[0010] On the other hand, generating the orchestration and deployment package corresponding to the adapted deployment blueprint includes: Using a template engine and an AI-assisted model, an orchestration and deployment package corresponding to the adapted deployment blueprint is generated; wherein, the template engine is used to generate the workload in the orchestration and deployment package using a preset working template corresponding to the deployment blueprint, and the AI-assisted model is used to generate the configuration content in the orchestration and deployment package, and the AI-assisted model is a pre-trained language model used for configuration conversion.

[0011] On the other hand, the AI-assisted model is driven by structured prompts, which include at least one of role definition, task description, input data, and output constraints.

[0012] On the other hand, after generating the orchestration and deployment package corresponding to the adapted deployment blueprint, the method further includes: The orchestrated deployment package is used as the current deployment package, and the current deployment package is verified using an isolated sandbox environment; If the verification is successful, the current deployment package is delivered to obtain the target orchestration deployment package; wherein the delivery process includes at least one of versioning, signing and packaging.

[0013] On the other hand, the verification of the current deployment package using an isolated sandbox environment includes: Perform static verification on the current deployment package and dynamic pre-installation verification in the sandbox environment; If the verification is successful, then proceed with the step of delivering the current deployment package to obtain the target orchestration deployment package.

[0014] On the other hand, after verifying the current deployment package using an isolated sandbox environment, the process also includes: If verification fails, obtain the error message of the verification failure, and use the artificial intelligence repair engine to correct the current deployment package based on the error message to obtain the corrected deployment package; The modified orchestrated deployment package is used as the current deployment package, and the step of verifying the current deployment package using an isolated sandbox environment is executed.

[0015] On the other hand, the step of using an artificial intelligence repair engine to correct the current deployment package based on the error information, and obtaining a corrected orchestrated deployment package, includes: Using the AI ​​repair engine, the target code is corrected based on the error information to obtain the corrected target code; wherein, the target code is the code segment corresponding to the error information, and the AI ​​repair engine includes a pre-trained language model for code repair; Based on the modified target code, the current deployment package is modified to obtain the modified orchestration deployment package.

[0016] On the other hand, before generating the orchestration and deployment package corresponding to the adapted deployment blueprint, the method further includes: The adapted deployment blueprint is pre-rendered to obtain a resource list; Send the resource list to the Open Policy Agent and receive the compliance decision results returned by the Open Policy Agent; If the compliance decision result is compliant, then the step of generating the orchestration and deployment package corresponding to the adapted deployment blueprint is executed; If the compliance decision result is non-compliant, the AI ​​repair engine is used to correct the adapted deployment blueprint based on the non-compliance information returned by the open policy agent, resulting in a corrected deployment blueprint, and an orchestration and deployment package corresponding to the corrected deployment blueprint is generated.

[0017] On the other hand, the static verification of the current deployment package and the dynamic pre-installation verification in the sandbox environment include: During the dynamic pre-installation verification process, it is necessary to detect whether there are any resource naming conflicts. If resource naming conflicts exist, the conflicting resource names will be adjusted, and dynamic pre-installation verification will continue.

[0018] On the other hand, the sandbox environment is created each time the dynamic pre-installation verification is performed, and destroyed after the dynamic pre-installation verification is completed.

[0019] On the other hand, the delivery process of the current deployment package to obtain the target orchestration deployment package includes: Generate a unique semantic version number for the currently deployed package; Package the current deployment package into an Open Container Initiative image format; The current deployment package is digitally signed to obtain the target orchestration deployment package.

[0020] On the other hand, after generating the orchestration and deployment package corresponding to the adapted deployment blueprint, the method further includes: Obtain the runtime data after the orchestration and deployment package is deployed to the application; wherein, the runtime data includes resource consumption; Based on the resource consumption and the resource requests of the adapted deployment blueprint, determine the discrepancy information; Based on the discrepancy information, resource allocation optimization suggestions are generated.

[0021] On the other hand, after generating resource configuration optimization suggestions based on the difference information, the method further includes: When configuring the next deployment blueprint using the preset language model, the resource configuration optimization suggestions are taken as input; and / or, The preset language model is adjusted or retrained using the difference information and the resource configuration optimization suggestions.

[0022] The present invention also provides a system for generating container orchestration and deployment packages, comprising: The repository acquisition module is used to identify deployment-related configuration files and metadata from the target source code repository based on the target source code repository information obtained from the deployment package generation instruction; wherein, the deployment package generation instruction includes the target source code repository information and the target virtualization tenant information; The dependency analysis module is used to convert the configuration file and metadata into a deployment blueprint through static parsing and collaborative analysis with a preset language model. The deployment blueprint adopts a preset data exchange format and includes at least one of the following: service definition, number of replicas, port, environment variables, volume mount, dependency relationship, probe, resource request and limit, and lifecycle hook. The virtualization adaptation module is used to adapt the deployment blueprint to the virtualization environment by utilizing the available resources and policy constraints corresponding to the target virtualization tenant information, and obtain the adapted deployment blueprint. The template generation module is used to generate the orchestration and deployment package corresponding to the adapted deployment blueprint.

[0023] The present invention also provides an apparatus for generating container orchestration and deployment packages, comprising: Memory, used to store computer programs; A processor, used to execute the computer program to implement the steps of the container orchestration deployment package generation method as described above.

[0024] In addition, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the container orchestration deployment package generation method described above.

[0025] The present invention provides a method for generating a container orchestration deployment package, comprising: identifying deployment-related configuration files and metadata from the target source code repository based on the target source code repository information obtained from the deployment package generation instruction; wherein the deployment package generation instruction includes target source code repository information and target virtualization tenant information; converting the configuration files and metadata into a deployment blueprint through co-analysis of static parsing and a preset language model; wherein the deployment blueprint adopts a preset data exchange format and includes at least one of service definition, replica count, port, environment variables, volume mount, dependency relationship, probe, resource request and limit, and lifecycle hook; adapting the deployment blueprint to the virtualization environment using the available resources and policy constraints corresponding to the target virtualization tenant information to obtain an adapted deployment blueprint; and generating an orchestration deployment package corresponding to the adapted deployment blueprint.

[0026] As can be seen, this invention introduces a deployment blueprint as the core intermediate representation, decoupling the repository parsing, environment adaptation, and deployment package generation processes. This allows for subsequent operations based on the deployment blueprint, improving debuggability and scalability. Furthermore, by utilizing the collaborative analysis of static parsing and a pre-defined language model, it deeply understands the context of the entire code repository. Through virtualization environment adaptation of the deployment blueprint to meet the constraints of private cloud virtualization environments, it can stably and efficiently automatically generate high-quality container orchestration deployment packages, achieving automated delivery with high availability, high versatility, and high adaptability. In addition, this invention also provides a container orchestration deployment package generation system, device, and computer-readable storage medium, which also possess the aforementioned beneficial effects. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0028] Figure 1 A flowchart illustrating a method for generating a container orchestration deployment package according to an embodiment of the present invention; Figure 2This is a schematic diagram of the system structure of another method for generating container orchestration and deployment packages provided in an embodiment of the present invention; Figure 3 This is a structural block diagram of a container orchestration and deployment package generation system provided in an embodiment of the present invention; Figure 4 This is a simplified structural diagram of a container orchestration deployment package generation device provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the specific structure of a container orchestration and deployment package generation device provided in an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a method for generating a container orchestration and deployment package according to an embodiment of the present invention. The method may include: Step 101: Based on the target source code repository information in the obtained deployment package generation instructions, identify the deployment-related configuration files and metadata from the target source code repository.

[0031] The deployment package generation instructions include target source code repository information and target virtualization tenant information.

[0032] It is understood that the deployment package generation instruction in this embodiment can be an instruction used to generate a corresponding orchestrated deployment package. The specific content of the deployment package generation instruction can be set by the designer. For example, the deployment package generation instruction can include target source code repository information, such as a source code repository link, to indicate the source code repository used (i.e., the target source code repository). The deployment package generation instruction can also include target virtualization tenant information to represent the virtualization tenant (i.e., the private cloud tenant). For instance, a user can provide a source code repository link (i.e., target source code repository information) and target virtualization tenant information through the Cloud Management Platform (CMP) interface or Command Line Interface (CLI) to trigger the deployment package generation instruction.

[0033] Correspondingly, in this step, the deployment package generation instructions can be used to identify deployment-related configuration files and metadata from the source code repository corresponding to the target source code repository information (i.e., the target source code repository) to obtain a complete and relevant repository context. The specific method for identifying deployment-related configuration files and metadata from the target source code repository information in the deployment package generation instructions can be set by the designer according to the practical scenario and user needs. For example, this step can clone data from the target source code repository (i.e., target data) and preprocess the cloned data to identify all deployment-related configuration files and metadata.

[0034] Furthermore, this embodiment can leverage the natural language understanding (NLU) capabilities of a pre-trained language model to improve the accuracy of metadata recognition. For example, in this step, target data can be cloned from the target source code repository corresponding to the target source code repository information; deployment-related configuration files can be identified from the target data; and a metadata extraction model can be used to perform deep parsing of the configuration files to obtain metadata. Deep parsing includes at least one of document file parsing, application named entity recognition (NER), relation extraction, and text summarization. The metadata extraction model is a pre-trained language model used for metadata extraction. The pre-trained language model can be a pre-trained language model, such as a Large Language Model (LLM).

[0035] Correspondingly, the process of cloning target data from the target source code repository corresponding to the target source code repository information can be configured by the designer. For example, the process can directly clone target data from the target source code repository corresponding to the target source code repository information, such as downloading all branches and full historical commit records since the target source code repository was created. Alternatively, the process can clone target data from the target source code repository corresponding to the target source code repository information according to the target cloning mode. The target cloning mode can be any preset cloning mode, such as the preset cloning mode corresponding to the cloning mode selection information in the deployment package generation instruction, or a preset cloning mode determined according to the data specifications of the target source code repository. Preset cloning modes can include normal cloning mode, shallow cloning mode, and incremental cloning mode. For example, in shallow cloning mode, only the latest commit status or a specified depth can be downloaded, ignoring historical change records. Incremental cloning mode can only pull newly added or modified data since the last synchronization, based on the existing local cache. By setting shallow cloning mode and incremental cloning mode, the data volume of network transmission and disk read / write overhead can be greatly reduced, thereby significantly optimizing the retrieval efficiency of large repositories.

[0036] Furthermore, the process of identifying and deploying relevant configuration files from target data can also include a master-slave identification process for configuration files of the same type. For example, when there are files to be partitioned in the configuration files, the master-slave score of each file to be partitioned corresponding to the current type is calculated according to a preset scoring algorithm. Here, the files to be partitioned are configuration files of the same type, the current type is any type that corresponds to at least two configuration files, and the preset scoring algorithm is used to calculate the score based on at least one weighted factor among standard filename matching degree, file path depth, content keywords, and service quantity. Based on the master-slave score, a master configuration file corresponding to the current type is determined. For example, the configuration file with the highest master-slave score is taken as the master configuration file corresponding to the current type, and other configuration files can be used as auxiliary or overlay files (i.e., slave configuration files) to be used in conjunction with the master configuration file when building the deployment blueprint.

[0037] For example, the method provided in this embodiment can realize a container orchestration deployment package generation system. Its goal is to target private cloud virtualization platforms, such as private clouds built on KVM (Kernel-based Virtual Machine, a virtualization technology), VMware, etc., and their upper-layer cloud management platforms. In a structured workflow, it automatically extracts deployment information (i.e., configuration files and metadata) from the source code repository and generates orchestration deployment packages that conform to the constraints of specific virtualization environments (such as network, storage, and security policies).

[0038] Among them, such as Figure 2 As shown, the above system may include a repository ingestion module, or repository ingestion layer, as the source of data input to ensure the acquisition of complete and relevant repository context. The repository ingestion module may include: a repository cloning submodule, used to clone target data from the target source code repository corresponding to the target source code repository information; the repository cloning submodule can support access to various code version control systems, such as GitHub, GitLab, and Bitbucket, code hosting and collaboration platforms based on the Git (a distributed version control system) protocol; it performs security authentication and cloning operations based on the access token generated in the user-provided deployment package, ensuring access permissions for private repositories; it creates isolated temporary working directories for each commit or tag that needs to be processed to avoid cross-contamination; and it supports incremental cloning and shallow cloning to optimize the pull efficiency of large repositories.

[0039] The repository acquisition module can also include a configuration discovery submodule for identifying deployment-related configuration files from target data. This includes automated scanning of the working directory, based on a predefined and extensible rule base, such as a JSON file (a lightweight data exchange format) containing glob (a file matching pattern) patterns and file type signatures, to identify common deployment configuration files (i.e., deployment-related configuration files), such as: docker-compose.yml (a multi-container definition file), compose.yaml (a multi-container definition file), Dockerfile (a container image build instruction file), Makefile (a configuration management tool file), helm / or chart / directories (existing orchestration deployment packages), kustomize (a custom configuration tool) directory, etc.

[0040] The configuration discovery submodule can also be used to initiate a deterministic scoring mechanism (i.e., a preset scoring algorithm) to select the primary configuration file when multiple configuration files of the same type (i.e., files to be partitioned) are detected. For example, the preset scoring algorithm calculates a score based on the following weighted factors: standard filename matching degree, such as docker-compose.yaml or compose.yaml receiving the highest score (e.g., +10 points); path depth, such as files in the root directory taking precedence over files in deeper directories (e.g., -1 point for each deeper directory); content keywords, such as files containing standard declarations like `version:'3.x'` receiving a higher score (e.g., +5 points); and the number of services, such as the more services defined in the file, the higher the score (e.g., +1 point for each service). The configuration file with the highest total score is selected as the primary configuration file, and the rest are used as auxiliary or overriding files.

[0041] The configuration discovery submodule can also be used to record all unrecognized custom scripts, such as .sh (a file format for a programming language shell) and .py (a file format for a programming language Python) startup scripts, and mark them as pending analysis for subsequent dependency analysis (especially for inference of intent in preset language models).

[0042] The repository acquisition module can also include a metadata extraction submodule, which uses a metadata extraction model (such as LLM) to perform deep parsing of configuration files and obtain metadata. For example, the metadata extraction submodule can use the natural language understanding capabilities of a large language model (LLM) to perform deep parsing (i.e., document file parsing) of README.md or other document files (such as the `docs / ` directory); the LLM can be trained to identify specific entities related to deployment (i.e., application named entity recognition), such as Port: 8080, Database: PostgreSQL, and Cache: Redis; through relation extraction technology, the relationships between entities are understood (e.g., application A depends on database B), and combined with text summarization technology, key information such as "how to run", "default port description", and "required external dependencies" is extracted; this extracted structured information (e.g., in JSON format "{"dependencies":["redis","postgres"],"exposed_ports":

[8080] }") is appended as annotations or metadata to the list of files to be processed, providing richer context for subsequent dependency analysis.

[0043] Step 102: Transform configuration files and metadata into deployment blueprints through collaborative analysis of static parsing and preset language models.

[0044] The deployment blueprint adopts a preset data exchange format and includes at least one of the following: service definition, number of replicas, port, environment variables, volume mount, dependency, probe, resource request and limit, and lifecycle hook.

[0045] It is understood that the preset language model in this embodiment can be a pre-set language model, such as a Large Language Model (LLM). This step, through the collaborative analysis of static analysis and the preset language model (such as LLM), transforms the identified diverse, semi-structured, and even unstructured deployment information (i.e., configuration files and metadata, such as multi-container definition files, container image build instruction files, and documentation files) into a unified, structured deployment blueprint. This deployment blueprint serves as the core intermediate representation, decoupling repository parsing, environment adaptation, and deployment package generation, enabling subsequent operations based on the deployment blueprint, thus improving debuggability and scalability.

[0046] Correspondingly, the deployment blueprint in this embodiment can be a standardized, Kubernetes-oriented intermediate representation, meaning it can be a standard data structure. The specific structure and content of the deployment blueprint in this embodiment can be set by the designer according to practical scenarios and user needs. For example, the deployment blueprint can adopt a preset data exchange format, such as JSON. The deployment blueprint can include at least one of the following: service definition (e.g., service name), number of replicas, port, environment variables, volume mounts, dependencies, probes, resource requests and limits, and lifecycle hooks. For instance, the deployment blueprint can include service definition, number of replicas, port, environment variables, volume mounts, dependencies, probes, resource requests and limits, and lifecycle hooks. For example, the specific structure of a JSON-formatted deployment blueprint can be as follows: { "schemaVersion": "1.0", "mainApplication": "webapp", / / The inferred name of the main application "services": { "webapp": { / / Service name extracted from static parsing "image": "my-app:latest", / / Image obtained through static parsing or inference "replicas": 1, / / Number of replicas "ports": [ { "containerPort": 80, "protocol": "TCP"} / / Port mappings filled in by static parsing or LLM analysis of the Dockerfile ], "env": [ { "name": "DATABASE_URL", "valueFrom": "secret:db-credentials:url"} / / Environment variables extracted by static parsing ], "volumes": [ { "name": "app-data", "mountPath": " / app / data", "subPath": null} / / Statically resolved volume mount ], "probes": { / / Advanced runtime properties for data fusion supplementation: health check probes "liveness": { "httpGet": { "path": " / healthz", "port": 80}, "initialDelaySeconds": 15}, "readiness": { "httpGet": { "path": " / ready", "port": 80}, "initialDelaySeconds": 5} }, "resources": { / / Advanced runtime properties for data fusion supplementation: resource requests and limits "requests": { "cpu": "100m", "memory": "128Mi"}, "limits": { "cpu": "500m", "memory": "512Mi"} }, "lifecycle": { / / Lifecycle hooks (such as pre-installation jobs or initialization commands) filled in after LLM intent recognition. "init": [ { "type": "job", "name": "db-migrate", "command": ["rake", "db:migrate"]} ] } }, "database": { / / Dependency services derived from relation extraction and dependency inference "image": "postgres:13", "isStateful": true, / / Stateful service attribute inferred and identified "volumes": [ { "name": "db-storage", "mountPath": " / var / lib / postgresql / data"} ] } }, "volume_definitions": { / / Abstract storage volume definition, awaiting resource mapping by the subsequent virtualization adaptation layer. "db-storage": { "size": "10Gi", "accessMode": "ReadWriteOnce"} }, "ingress": { / / Network policy and entry point configuration "host": "app.example.com", "path": " / ", "serviceName": "webapp", "servicePort": 80 } }

[0047] It should be noted that the specific method for converting configuration files and metadata into deployment blueprints through the collaborative analysis of static parsing and preset language models in this step can be customized by the designers based on practical scenarios and user needs. For example, this step can use a static parser to process structured files based on metadata and extract baseline service information. Structured files include structured files in the configuration file, such as multi-container definition files (e.g., docker-compose.yaml mentioned above). Based on the metadata, the preset language model is used to infer the results from unstructured files. Unstructured files include files other than structured files in the configuration file, such as unstructured or semi-structured files (e.g., Dockerfile, README documents, and startup scripts). Based on the baseline service information and the inference results, a deployment blueprint is constructed. The baseline service information has a higher priority than the inference results. In other words, in this step, a static parser can be used first to process structured files to extract baseline service information. When information is missing or needs to be obtained from unstructured files, a preset language model (such as LLM) is activated to perform intent inference, entity recognition, and relation extraction. The static parsing results are then fused with the inference results of the preset language model, with the baseline service information obtained from the static parsing having higher priority. The inference results of the preset language model are used to fill in information gaps, infer dependencies, and identify behavioral intents, ultimately generating a complete and unified deployment blueprint. Metadata can provide rich context, and both the static parsing of the static parser and the inference of the preset language model will be analyzed in conjunction with this metadata. In particular, the preset language model will heavily rely on this metadata when inferring missing information or dependencies.

[0048] For example, such as Figure 2As shown, the generation system implemented by the method provided in this embodiment may further include a dependency analysis module, or dependency analysis layer, responsible for converting the original configuration into a structured deployment blueprint. The repository acquisition module may include a service parsing submodule, used to employ a hybrid parsing mode that combines a deterministic static parser with an LLM to ensure the accuracy and coverage of the parsing results. During the parsing process, a high-precision parser is first used to prioritize structured files, such as multi-container definition files (docker-compose). This can extract service names, images, port mappings, environment variables, volumes, and service dependencies (depends_on) with 100% accuracy. These statically parsed results are considered the ground truth. When critical information is missing (e.g., no multi-container definition file) or when it is necessary to infer intent from unstructured files, LLM can be activated. LLM will perform the following tasks: ① Dockerfile parsing, by providing LLM with a prompt similar to the following: "Analyze the following Dockerfile content and return the exposed ports (EXPOSE), default startup command (CMD / ENTRYPOINT), and build parameters (ARG) in JSON format." ① Extract structured information using `[here]`; ② Startup script analysis: Analyze the run.sh script to infer the main application service and its configuration; ③ Data fusion: Fuse the results inferred by LLM with the baseline facts of static parsing. The fusion logic is: static parsing results have the highest priority, and LLM results are used to fill in missing fields. For example, if a port is not defined in docker-compose, the `EXPOSE` port parsed from the Dockerfile by LLM is used.

[0049] The repository acquisition module may also include a dependency graph construction submodule, which uses the parsed results obtained from the fusion to build a deployment blueprint in JSON format.

[0050] The repository acquisition module can also include: a multi-file concatenation submodule, used to analyze the main configuration file and slave configuration files of the same type separately to obtain their respective analysis results; such as supporting shard analysis capabilities for multi-container definition files; for example, a main `docker-compose.yaml` and a `docker-compose.override.yaml` can be parsed separately. It can also be used to merge the analysis results of the main configuration file and slave configuration files of the same type to obtain the complete analysis results corresponding to the main configuration file, such as performing a merge according to the standard override logic of docker-compose (multi-container definition files); for example, for dictionary (mapping) types (such as `environment`), a key is used to merge, with the latter overriding the former; for list types (such as `ports`, `volumes`), a union operation is performed to ensure the integrity of the configuration; and it records which local file path each service definition in the blueprint originally came from, facilitating subsequent template generation layer references to the configuration file.

[0051] The repository collection module can also include a script annotation submodule, used by LLM to perform intent recognition and structuring of instructions in Makefiles, startup scripts, or container image build instruction files. For example, LLM can first classify the commands in the script (i.e., intent classification) to identify whether they belong to predefined categories such as database initialization (e.g., `db:migrate`), dependency installation (e.g., `npm install`), and static file compilation (e.g., `assets:precompile`). For commands classified as executable actions, LLM further extracts their core instructions and parameters. For example, when analyzing the `rake db:migrate` command, LLM will output a structured object: `{"type":"init_job","command":["rake","db:migrate"],"execution_phase":"pre-install"}`. This object is then precisely filled into the `lifecycle.init` field of the corresponding service in the deployment blueprint, ensuring that these dependency steps can be correctly executed as initialization containers or pre-install jobs before the application's main container starts.

[0052] Step 103: Using the available resources and policy constraints corresponding to the target virtualization tenant information, adapt the deployment blueprint to the virtualization environment to obtain the adapted deployment blueprint.

[0053] In this step, the available resources and policy constraints can be the available resources and policy constraints in the virtualization environment (i.e., the target private cloud environment) corresponding to the target virtualization tenant information. This step may also include the process of obtaining the available resources and policy constraints corresponding to the target virtualization tenant information. For example, in this step, a plugin for the loaded target private cloud environment can be used to obtain the available resources and policy constraints corresponding to the target virtualization tenant information; where the target private cloud environment is the private cloud environment corresponding to the target virtualization tenant information. Based on the available resources and policy constraints, the deployment blueprint is adapted to the virtualization environment to obtain the adapted deployment blueprint. In other words, this embodiment can align and constrain a general deployment blueprint with the specific private cloud tenant's virtualization environment (such as resource pool, storage type, network configuration, and security quotas) to achieve resource mapping and policy selection.

[0054] For example, such as Figure 2 As shown, the generation system implemented by the method provided in this embodiment may further include a virtualization adaptation module, or virtualization adaptation layer, used to match application deployment requirements with the actual resource capabilities of the private cloud. This layer is implemented through a pluggable provider abstraction layer. The virtualization adaptation module may include a resource mapping submodule for provider plug-in architecture, such as interacting with the upper-layer cloud management platform or the lower-layer virtualization platform through a unified provider interface, thereby enabling different provider plug-ins for different virtualization environments. The resource mapping submodule can also be used during the adaptation phase to load plugins that match the target tenant's environment. These plugins call the platform's native APIs to obtain the current tenant's real-time context information, including: `getStorageClasses()` to retrieve available storage classes and their performance levels (e.g., `fast-ssd`, `bulk-hdd`); `getAvailableNetworks()` to retrieve available CNI (Container Network Interface) network definitions (e.g., `multus-vlan-net-1`, `sriov-net-2`); and `getTenantQuota()` to retrieve the tenant's compute and storage resource quotas. The resource mapping submodule can also be used to bidirectionally match resource requests abstracted in the deployment blueprint (e.g., `accessMode:ReadWriteOnce` in `volume_definitions`) with the actual resources returned by the plugin, selecting the most suitable `storageClassName` and injecting it into the deployment blueprint, thus achieving blueprint mapping and enrichment.

[0055] The virtualization adaptation module may also include a policy selection submodule, used to inject or modify specific fields of the orchestration platform in the deployment blueprint based on the specific capabilities and global policies of the virtualization environment; automatically select the most suitable storage class based on the read / write mode (e.g., multi-node read / write RWX and single-node read / write RWO) and performance requirements in the deployment blueprint; and automatically select and add network additional definitions (e.g., `k8s.v1.cni.cncf.io / networks` annotation) for applications requiring high performance or specific network isolation to use multiple network interfaces managed by Multus CNI (e.g., SR-IOV hardware passthrough). The policy selection submodule can also be used to set node affinity or taint tolerances to ensure that containers requiring specific hardware (e.g., GPUs) are scheduled to the correct nodes, thus implementing scheduling policy configuration. The strategy selection submodule can also be used to implement advanced strategy injection, such as automatically selecting the correct `ingressClassName` (entry class name, such as `nginx-internal` or `nginx-public`) based on the application's exposed requirements (internal or external) in the blueprint, thus implementing Ingress Class selection; if the platform policy requires all applications to join the service mesh (such as Istio), this module will automatically add the annotations required for Sidecar injection (such as `sidecar.istio.io / inject:"true"`) to the service definition in the blueprint, thus implementing service mesh Sidecar injection; to ensure high availability, for applications with more than 1 replica, it automatically generates PodDisruptionBudget (a type of Kubernetes resource object) resource definition to ensure service stability in scenarios such as node maintenance, thus implementing Pod (container group) distribution budget (PDB).

[0056] The virtualization adaptation module may also include a quota verification submodule. Before generating a deployment package, the system estimates the total resource usage based on the number of replicas and resource requests defined in the blueprint using a simple summation algorithm. This quota verification submodule can also compare the estimated value with the tenant resource quota obtained from the provider plugin. If the quota is exceeded, it can automatically adjust according to preset strategies (e.g., reducing the number of replicas to 1 or proportionally reducing CPU / Memory requests), achieving quota comparison and adjustment, or issuing warnings to prevent the generation of orchestration deployment packages that do not meet the conditions, thus achieving over-quota blocking and alerting.

[0057] The virtualization adaptation module can also include a security compliance submodule for tight integration with the enterprise's unified policy engine (such as OPA) to achieve left-shifted security compliance. For example, the compliance check process might be as follows: A JSON representation of the Kubernetes resource manifest is pre-rendered based on the adapted blueprint; this JSON is used as input to send a verification request to the OPA policy decision point API (e.g., `v1 / data / kubernetes / admission`); OPA evaluates the results based on predefined Rego policies (e.g., disabling privileged containers, restricting image sources, forcibly adding resource restrictions, etc.) and returns a decision result containing `allow:true / false` and `violations` information; if the decision is `allow:false`, the system will parse the `violations` information and attempt to feed it back to the AI ​​repair engine of the verification and self-healing module for correction, or directly terminate the process and report a compliance issue. In other words, after step 103, the adapted deployment blueprint can be pre-rendered to obtain a resource list; the resource list is sent to the open policy agent, and the compliance decision result returned by the open policy agent is received; if the compliance decision result is compliant, then proceed to step 104; if the compliance decision result is non-compliant, then the artificial intelligence repair engine is used to correct the adapted deployment blueprint according to the non-compliance information returned by the open policy agent, to obtain the corrected deployment blueprint, and generate the orchestration and deployment package corresponding to the corrected deployment blueprint.

[0058] The security compliance submodule can also be used to automatically generate the least privilege role-based access control (RBAC) configuration, such as `ServiceAccount`, `Role`, and `RoleBinding`, according to application requirements, to achieve least privilege RBAC generation and avoid using the default or overly privileged `default`ServiceAccount (default service account).

[0059] Step 104: Generate the orchestration and deployment package corresponding to the adapted deployment blueprint.

[0060] In this step, a complete orchestration deployment package (HelmChart) structure, including template files and parameter files, can be built based on the adapted deployment blueprint. The specific method for generating the orchestration deployment package corresponding to the adapted deployment blueprint in this step can be set by the designer. For example, a template engine can be used to generate the orchestration deployment package using preset templates corresponding to the deployment blueprint in the template library. To improve the completeness of the orchestration deployment package, this step can utilize a template engine and an artificial intelligence (AI) assisted model to generate the orchestration deployment package corresponding to the adapted deployment blueprint. The template engine is used to generate the workload in the orchestration deployment package using preset working templates corresponding to the deployment blueprint, while the AI ​​assisted model is used to generate the configuration content in the orchestration deployment package. The AI ​​assisted model is a pre-trained language model, such as a Large Language Model (LLM), used for configuration conversion.

[0061] Correspondingly, in order to reduce the free play of the AI-assisted model and ensure that its generated content meets the requirements of the orchestration and deployment package (such as syntax and structure requirements), the AI-assisted model in this embodiment is driven by structured prompts; wherein, the structured prompts include at least one of role definition, task description, input data and output constraints.

[0062] For example, Figure 2As shown, the generation system implemented by the method provided in this embodiment can also include a template generation module, or template generation layer, used to convert the adapted, data-rich deployment blueprint (i.e., the adapted deployment blueprint) into a specific and complete orchestration deployment package (Helm Chart). The template generation module can include a version control repository; for example, the system can have a built-in versioned template library, such as a template library that conforms to internal best practices. This library not only contains templates for various standard workloads (such as `Deployment`, `StatefulSet`, `Service`, etc.), but more importantly, it contains a `_helpers.tpl` file, which defines general helper functions for generating standard labels, annotations, naming conventions, and security contexts. All templates need to call these helper functions to generate metadata, such as `metadata.labels:{{include"myapp.labels".|nindent4}}`, to ensure that all generated deployment packages follow a unified specification in terms of labels and naming, facilitating subsequent monitoring, logging, and management. The template generation module can automatically select to use the `StatefulSet` template instead of the `Deployment` template based on the `isStateful:true` flag of the service in the deployment blueprint.

[0063] The template generation module can also include a parameter mapping engine, a deterministic transformation engine that recursively traverses the JSON structure of the deployment blueprint and precisely maps its fields to the parameter configuration file (`values.yaml`) of the deployment package. The mapping algorithm used by the parameter mapping engine follows path preservation principles; for example, the value ("100m") at the path `services.webapp.resources.requests.cpu` in the blueprint will be accurately mapped to the location `webapp.resources.requests.cpu` in `values.yaml`. During the mapping process, the engine identifies environment-specific variables and automatically generates parameter file structures that support multiple environments (such as development, testing, or production); for example, it creates `values.yaml` as the base configuration and generates `values-dev.yaml` and `values-prod.yaml` for different environments, utilizing Helm's value file overriding mechanism to achieve differentiated configurations.

[0064] The template generation module can also include an AI-assisted generation submodule for handling non-core but complex configurations, such as converting a complex `nginx.conf` file into a `ConfigMap` (an API object in Kubernetes used to store non-confidential key-value pairs), or generating a complex initialization job based on script annotations, which calls the LLM (i.e., an AI-assisted model) for configuration. In other words, this embodiment does not rely entirely on AI generation, but adopts a strategy of using deterministic templates as the primary method and AI assistance as a secondary method, balancing stability and flexibility. 95% of the content of core workloads (such as `Deployment` and `Service`) is generated from standard templates, ensuring the stability of their structure and best practices. When calling the LLM, the AI-assisted generation submodule can construct a structured hint containing strict instructions to precisely control its output. An example of a structured hint is as follows: { "role": "You are a Kubernetes expert assistant.", / / Role definition, setting the professional identity of the AI-assisted model. "task": "Generate a valid Kubernetes ConfigMap YAML manifest.", / / Task description, explicitly indicating the type of resource to be generated. "input_data": { / / Input data, providing the name and content of the original configuration file to be converted. "filename": "nginx.conf", "content": "server { listen 80; location / { root / usr / share / nginx / html;}}" }, "output_constraints": { / / Output constraints, strictly limiting the format, required fields, and code style of the generated model. "format": "single_yaml_document", / / Constrains the output format to a single-format document. "required_fields": { / / Specified fields and template variables that are required to be included in the generated configuration. "apiVersion": "v1", "kind": "ConfigMap", "metadata.name": "{{ .Release.Name}}-nginx-config", "data": { "nginx.conf": "[content from input_data]" } }, "style_guide": "Use 2 spaces for indentation." / / Specifies that code indentation should be two spaces. } }

[0065] Correspondingly, the AI-assisted generation submodule can call LLM to package the local configuration files (such as `nginx.conf` and `init.sql` scripts) required by the application runtime, which are identified in the repository collection module and dependency analysis module, into the `files / ` directory of the deployment package. It can then reference these files in the `ConfigMap` or `Secret` template through the `.Files.Get` helper function, so that the container can mount and use them at runtime, thus realizing file reference processing. The AI-assisted generation submodule can also determine whether to split the application into a main deployment package (Parent Chart) and sub-deployment packages (Subcharts) based on metadata and heuristic rules in the deployment blueprint, implementing intelligent splitting logic. The splitting trigger conditions can be as follows: when a service in the blueprint is marked with `isExternalDependency:true` (e.g., a standard Redis instance); when it is identified as a common, reusable component (such as a standalone log processing forwarder), it automatically adds a reference to the subchart (specifying the repository alias and version) to the `dependencies` field of the main chart's `Chart.yaml`, and simplifies the configuration of the service in the original blueprint to parameter overriding of the subchart, achieving high application cohesion and low component coupling. When calling the LLM, the AI-assisted generation submodule can construct a structured prompt containing strict instructions to precisely control the LLM output and constrain the AI's free play.

[0066] Furthermore, the method provided in this embodiment may further include an orchestration deployment verification and packaging process after step 103. For example, the orchestration deployment package is used as the current deployment package, and the current deployment package is verified using an isolated sandbox environment; if the verification is successful, the current deployment package is delivered to obtain the target orchestration deployment package; wherein, the delivery process includes at least one of versioning, signing, and packaging.

[0067] Correspondingly, in the event of verification failure, the system can either directly notify the customer or automatically perform repairs. For example, when verification fails, the system can obtain the error information and, based on this information, use an AI-powered repair engine to correct the current deployment package, resulting in a corrected orchestrated deployment package. This corrected orchestrated deployment package is then used as the current deployment package, and the verification process is performed using an isolated sandbox environment.

[0068] The specific method for verifying the current deployment package using an isolated sandbox environment can be configured by the designer. For example, the current deployment package can be statically validated, and a dynamic pre-installation validation can be performed in the sandbox environment. If the validation is successful, the delivery process for the current deployment package is executed to obtain the target orchestration deployment package. For instance, such as... Figure 2 As shown, the generation system implemented by the method provided in this embodiment can also include a validation and self-healing module, or a validation and self-healing layer, used to perform legality checks on the generated deployment package and automatically correct errors. For example, the validation and self-healing layer can call a standard deployment package static validation tool (functionally equivalent to `helmlint`) to check YAML syntax, template variable references, and dependencies; if an error is detected, it may not immediately determine failure, but instead package the error information returned by the validation tool, the file name of the erroneous template, and the line number into a structured repair request and send it to an AI repair engine (such as LLM) dedicated to code repair; the prompts in this request are carefully designed to constrain the behavior of the AI, as shown in the following example: { "role": "You are a Helm chart debugging expert.", / / Role definition, setting your professional identity within the AI ​​repair engine. "context": { / / Provides the context in which the error occurred, including the file path where the error occurred, the specific static validation error message, and the corresponding code snippet. "file": "templates / service.yaml", "lint_error": "[ERROR] templates / service.yaml: line 12: unknown field'targetport' in v1.ServicePort", "code_snippet": " ports:\n - protocol: TCP\nport: 80\n targetport: 8080" }, "instruction": "Fix the error in the provided code_snippet. Only output the corrected YAML snippet. Do not explain the change in natural language. Your output must be valid YAML." / / This fixes the error and explicitly requires the model to output only the corrected code snippet, strictly limiting natural language interpretation and ensuring a valid configuration format is output. }

[0069] After receiving the corrected code snippet from the AI, the verification and self-healing module can verify the scope of the modifications using the `diff` algorithm, then replace the original file content and re-enter the static verification process. After passing static verification, the verification and self-healing module can execute a pre-installation command (equivalent to `helminstall`) in an isolated, temporary sandbox cluster (i.e., a sandbox environment). <release-name>The sandbox cluster is implemented using a lightweight Kubernetes distribution (such as k3d or kind). Each verification task triggers the creation of a brand new, clean cluster, which is immediately destroyed after verification, ensuring a stateless environment and zero resource residue. In other words, the sandbox environment can be created during each dynamic pre-installation verification and destroyed after the verification is complete. The pre-installation process can detect runtime issues that static verification cannot capture, such as Kubernetes API version incompatibility (e.g., `v1beta1`'s Ingress is deprecated in newer clusters), insufficient RBAC permissions, and non-existent service accounts. Similarly, rendering failure errors are fed back to the AI ​​repair engine for correction.

[0070] The AI-powered repair engine can perform a maximum number of repair attempts (e.g., 5) to prevent infinite loops. It meticulously records each repair attempt, generating a structured log containing the following fields: `{"iteration_id":1,"timestamp":"...","validator":"helm_lint","error_message":"...","prompt_to_ai":"...","ai_fix_diff":"...","result":"success"}`. These logs are not only used for issue tracing but also serve as a valuable dataset for continuous model improvement and fine-tuning. If the maximum number of attempts is reached and automatic repair is still not achieved, the system will terminate the process and generate a detailed repair report identifying the unresolved issues for human review.

[0071] The verification and self-healing module can also perform resource conflict detection, such as checking for resource naming conflicts during dynamic pre-installation verification. If a resource naming conflict exists, the conflicting resource names are adjusted, and the dynamic pre-installation verification continues. For example, by querying the API Server of the (sandbox or target) cluster, it checks whether the generated `Ingress` hostname is already in use. If a conflict is detected, the system can automatically adjust it in the parameter file (`values.yaml`) (e.g., adding the version or branch prefix `dev-` before the hostname), or provide explicit warnings and suggestions in the final report.

[0072] Furthermore, the specific method for delivering the current deployment package to obtain the target orchestrated deployment package can be configured by the designer. For example, it could generate a unique semantic version number for the current deployment package; package the current deployment package into an Open Container Initiative (OCI) image format; or digitally sign the current deployment package to obtain the target orchestrated deployment package. For instance, such as... Figure 2 As shown, the generation system implemented by the method provided in this embodiment can also include a packaging and delivery module, or a packaging and delivery layer, used to package, version, and sign the verified deployment package, and push it to a private deployment package repository, while providing metadata for consumption and identification by the upper-layer cloud management platform. The packaging and delivery module may include a version control and signing submodule, which automatically generates a unique semantic version number (e.g., `1.2.3-build.5+git.a1b2c3d`) for each successfully generated deployment package based on the version of the source code repository (e.g., Git Tag) and the generation strategy; populates key metadata such as `appVersion` (from Git Tag) and `kubeVersion` (from the target environment strategy) in the `Chart.yaml` file; and supports packaging Helm Charts into OCI (Open Container Initiative) image format. Before being pushed to the warehouse, industry-standard tools such as Cosign are used to perform keyless digital signatures on the OCI artifact through the enterprise's internal Certificate Authority (CA) or Fulcio public instance to ensure the authenticity and integrity of the delivered item.

[0073] In other words, the process described above, which uses an AI repair engine to correct the current deployment package based on error information, and obtains a corrected orchestrated deployment package, may include: using the AI ​​repair engine to correct the target code based on the error information, and obtaining corrected target code; wherein, the target code is the code segment corresponding to the error information, and the AI ​​repair engine includes a pre-trained language model for code repair; and correcting the current deployment package based on the corrected target code, and obtaining a corrected orchestrated deployment package.

[0074] The packaging and delivery module can also be used to generate dependency indexes. For example, after generating a structure containing subcharts, it can automatically generate a `Chart.lock` file to lock dependency versions. After pushing to a private repository, it automatically triggers the update of the repository's index file (`index.yaml` for traditional chart repositories, but not for OCI repositories), ensuring that the cloud management platform can immediately retrieve the new version.

[0075] The packaging and delivery module can also be used for metadata registration and software catalog integration. For example, it can report the core metadata of the generated deployment package to the Cloud Management Platform (CMP) or integrated software catalogs (such as Backstage.io) via API to complete the registration of key integration points. The reported JSON carrier not only includes the application name and version but also rich information extracted from the deployment blueprint, such as `resourceSummary:{cpuRequest:"500m",memoryRequest:"1Gi"}`, `exposedEndpoints:[{...}]`, and `requiredStorageClasses:["fast-ssd"]`, thus achieving a rich metadata carrier. Correspondingly, the application marketplace of the Cloud Management Platform or the software catalog of Backstage (an open platform for building developer portals) can directly consume this metadata, presenting deployable applications and their resource requirements to end users through a user-friendly graphical interface.

[0076] Correspondingly, the packaging and delivery module can automatically push the Chart's `tgz` package or OCI artifact to one or more target repositories after successful verification, such as the traditional ChartMuseum (a Helm Chart repository) and modern OCI-compatible repositories like Harbor and Artifactory. It supports configuring webhooks to automatically notify downstream systems, such as CI / CD (Continuous Integration / Continuous Delivery) pipelines and developer chat tools, upon successful deployment.

[0077] Furthermore, after step 103 in this embodiment, the runtime data after the orchestration deployment package is deployed can also be obtained; wherein, the runtime data includes resource consumption; based on the resource consumption and the resource requests of the adapted deployment blueprint, the difference information is determined; based on the difference information, resource configuration optimization suggestions are generated.

[0078] Correspondingly, after generating resource configuration optimization suggestions, these suggestions can be used as input when configuring the next deployment blueprint using the preset language model; and / or, the preset language model can be adjusted or retrained using the difference information and resource configuration optimization suggestions to achieve system updates and iterations.

[0079] For example, such as Figure 2 As shown, the generation system implemented by the method provided in this embodiment can also include an integration and evolution module, or integration and evolution layer, for deep integration with the cloud management platform and monitoring system. This enables the triggering of the generation process, continuous feedback on the post-deployment running status, and iterative updates of the analysis model and template library. For example, the integration and evolution module can provide a bidirectional RESTful API (Representational State Transition Style Application Programming Interface). On one hand, the cloud management platform can call this system to trigger generation tasks from Git repository to deployment package on demand for tenants. On the other hand, the integration and evolution module registers the generation results back to the cloud management platform at the delivery layer, automatically creating or updating entries in the application directory of the cloud management platform.

[0080] The integration and evolution module can include a monitoring and feedback submodule, which integrates with a standardized monitoring system (such as Prometheus) after the application is actually deployed. This submodule collects runtime metrics of the application by executing specific PromQL (Prometheus Query Language) queries, such as querying CPU / memory usage: `sum(rate(container_cpu_usage_seconds_total{pod=~"app-."}[5m]))` and `sum(container_memory_working_set_bytes{pod=~"app-."})`. This data is fed back to the dependency analysis layer. The system compares the actual usage with the resource requests in the deployment blueprint. If a long-term deviation is found (e.g., memory usage consistently below 20% of the requested value), the system generates a clear optimization recommendation: "[Recommendation] The memory requests for service 'webapp' can be reduced from 512Mi to 256Mi to improve resource utilization." This recommendation can be automatically adopted in the next generation or submitted for user review.

[0081] The Integration and Evolution module can aggregate the repair logs from the Verification and Self-Healing module and the runtime data from the Monitoring and Feedback module to form a dataset for retraining. The retraining dataset can include an analysis model dataset and a repair model dataset. The analysis model dataset consists of `(source code repository URL, manually corrected optimal deployment blueprint)` data pairs, used to optimize the LLM's ability to understand the code. The repair model dataset consists of `(error information, successfully repaired diff)` data pairs, used to improve the accuracy of the AI ​​repair engine. These datasets are used to periodically retrain or fine-tune the relevant LLM models, continuously enhancing their parsing and repair capabilities. The template library can also be iteratively upgraded based on feedback. The Integration and Evolution module also supports a deployment package version rollback mechanism; when a new version of the deployment package fails to update on the cloud management platform, it can automatically roll back to the previous known stable version.

[0082] Taking a typical multi-service web application as an example, this application includes a frontend service, a backend API service, and a Redis caching service, with its source code hosted in a Git repository. Enterprise users want to automatically package it into a Helm Chart and deploy it to a private cloud PaaS platform built on VMware vSphere. First, application developers within the enterprise access the application automation packaging function area through the web interface of the Cloud Management Platform (CMP). The application developers enter the application's Git repository address, access token, and the target tenant environment for deployment (e.g., production environment - tenant A). Upon receiving the request, CMP calls the API of the development system in this embodiment, triggering a build task.

[0083] The system's repository collection module was activated. The repository cloning module securely cloned the application's latest `main` branch code to an isolated temporary working directory using a token. Subsequently, the configuration discovery module scanned the directory, and its built-in rule base enabled it to quickly identify the following key files: `. / docker-compose.yaml`: Defines the `frontend` and `backend` services; `. / backend / Dockerfile`: Container image build instructions for the `backend` service; `. / README.md`: Project description document; `. / scripts / init-db.sh`: A database initialization script.

[0084] The configuration discovery module, based on its scoring algorithm, designates `docker-compose.yaml` as the primary configuration file. Meanwhile, the metadata extraction module uses a Large Language Model (LLM) to analyze `README.md`, extracting natural language descriptions such as "the application depends on Redis for caching" and "the backend service listens on port 5000 by default," and converting these into structured metadata tags, which are then appended to the file manifest.

[0085] Next, the task enters the core of the system—the dependency analysis module, which uses the service resolution submodule to initiate a hybrid resolution mode. First, the static parser precisely extracts information such as the images, environment variables, and volume mounts of the `frontend` and `backend` services from `docker-compose.yaml` as baseline facts. However, the `redis` service is not defined in `docker-compose.yaml`. At this point, LLM is activated. Combining the metadata extracted from `README.md` in the first step with the analysis of connection strings in the `backend` service code, it infers that the application requires a dependency service named `redis`. Simultaneously, LLM analyzes `. / backend / Dockerfile`, identifies the `EXPOSE5000` instruction, and fills in the missing port information for the `backend` service. Next, the script annotation submodule's LLM analyzes the `. / scripts / init-db.sh` script, identifies its intent as performing database migrations before application startup, and extracts the core commands.

[0086] All this information is gathered by the dependency graph building module to generate the core intermediate representation of this invention—a JSON object of the deployment blueprint. This object clearly describes three services (`frontend`, `backend`, `redis`), where `redis` is marked as a stateful service (`isStateful:true`), and an initialization job pointing to the `init-db.sh` command is added to the lifecycle hooks of the `backend` service.

[0087] The generated deployment blueprint is then passed to the virtualization adaptation module. Since the target environment specified by the task is "Production Environment - Tenant A", the virtualization adaptation module can load the pre-built vSphere provider plugin. This plugin immediately communicates with vSphere and the upper-layer Tanzu platform via API. The resource mapping submodule calls `getStorageClasses()` to obtain the available storage classes for this tenant: `vsphere-fast-ssd` and `vsphere-replicated-hdd`. Based on the `ReadWriteOnce` access mode requirement for persistent volumes by the `redis` service in the blueprint, the module automatically selects `vsphere-fast-ssd` as the `storageClassName`.

[0088] Meanwhile, the policy selection submodule of the virtualization adaptation module automatically adds the `sidecar.istio.io / inject:"true"` annotation to all services according to the platform policy, forcing them to join the service mesh. The security compliance submodule pre-renders the blueprint as a Kubernetes resource and sends it to the OPA policy engine for verification. OPA returns a violation: a `backend` service was detected attempting to run as the root user. This information is logged for subsequent correction. Finally, the quota verification module of the virtualization adaptation module estimates the total CPU and memory required by the blueprint and compares it with the tenant quota obtained from the plugin to confirm that resources are sufficient. A richened and constrained blueprint adapted to the specific vSphere environment is thus generated.

[0089] The adapted deployment blueprint enters the template generation module. The template library management module of the template generation module selects the `Deployment` template for `frontend` and `backend`, and the `StatefulSet` template for `redis`, based on the attributes of each service in the deployment blueprint. The parameter mapping engine deterministically maps all fields in the blueprint (such as image name, number of replicas, resource requests, `vsphere-fast-ssd` storage class, etc.) to the `values.yaml` file of the Helm Chart.

[0090] When processing a complex `nginx.conf` configuration file that needs to be used in a `frontend` container, the AI-assisted template generation module is invoked. The system builds a structured hint, and the LLM instruction converts the file contents into a properly formatted Kubernetes `ConfigMap` YAML manifest. The LLM output is then used directly as a template file in the Chart.

[0091] In addition, the file reference processing module packages the `init-db.sh` script into the Chart's `files / ` directory and references it in the `backend` initialization job template via the `.Files.Get` function.

[0092] The generated Helm Chart is handed over to the verification and self-healing module for closed-loop verification. First, `helmlint` is executed for static verification. The verification passes. Next, the system performs a dynamic pre-run. A lightweight Kubernetes sandbox cluster based on `k3d` is created instantly. The system executes the command `helm install my-app . --dry-run`. The pre-run fails with the error message: ServiceAccount 'default' lacks permissions to create Pods. This is because the OPA policy prohibits the use of the default service account.

[0093] The AI-powered repair engine received this error. Based on the error message and incorporating RBAC best practices learned during training, its LLM generated the YAML fragments needed to create dedicated `ServiceAccount`, `Role`, and `RoleBinding`. These fragments were added to a new template file, and the `Deployment` template was modified to reference the new service account.

[0094] Meanwhile, regarding the "run as root user" issue detected by OPA in the previous step, the AI ​​remediation engine added `securityContext:{runAsUser:1001,runAsGroup:1001}` to the container in the `Deployment` template of the `backend`. The verification and self-healing module performed a second iteration, re-executing `lint` and `dry-run`. This time, all verifications passed. The sandbox cluster was immediately destroyed.

[0095] The verified Chart enters the packaging and delivery module. Based on the Git commit hash, the packaging and delivery module generates a version number `1.0.0-build.1+git.c4a2b1f` for the Chart and updates `Chart.yaml`. Then, it packages the Chart into an OCI image format and digitally signs it using Cosign and an internal enterprise CA.

[0096] The signed OCI artifact is automatically pushed to the enterprise's private Harbor mirror repository. Finally, the metadata registry module of the packaging and delivery module calls the APIs of CMP and the Backstage software catalog to report the metadata of the new application version, including its name, version, access endpoint, and estimated resource consumption. At this point, developers can see this newly created, automatically generated, and deployable application in the CMP application marketplace.

[0097] Finally, after the application was deployed to the production environment, the monitoring and feedback module of the integration and evolution module began to function. It used the Prometheus monitoring system to periodically execute PromQL queries, collecting the actual CPU and memory usage of the `backend` service. A month later, system analysis of historical data revealed that the memory usage of the `backend` service had never exceeded 150Mi, while the initially generated `values.yaml` requested `512Mi`. Based on this, the system generated an optimization suggestion and, the next time the application's packaging task was triggered, prompted the developers to reduce the memory request for the backend service from 512Mi to 256Mi to conserve resources. Simultaneously, this successful case of resource over-provisioning detection and optimization, along with the logs of AI-based RBAC permission fixing, were stored in a dedicated retraining dataset for future fine-tuning of the system's built-in LLM, making it increasingly intelligent with use.

[0098] In this embodiment, the present invention introduces a deployment blueprint as the core intermediate representation, decoupling the repository parsing, environment adaptation, and deployment package generation processes. This enables subsequent operations based on the deployment blueprint, improving debuggability and scalability. Furthermore, by utilizing the collaborative analysis of static parsing and a preset language model, the context of the entire code repository is deeply understood. Through virtualization environment adaptation of the deployment blueprint to meet the constraints of the private cloud virtualization environment, high-quality container orchestration deployment packages can be generated automatically and stably and efficiently, achieving automated delivery with high availability, high versatility, and high adaptability.

[0099] Corresponding to the above method embodiments, this invention also provides a container orchestration and deployment package generation system. The container orchestration and deployment package generation system described below and the container orchestration and deployment package generation method described above can be referred to in correspondence.

[0100] Please refer to Figure 3 , Figure 3 This is a structural block diagram of a container orchestration and deployment package generation system provided in an embodiment of the present invention. The system may include: The repository acquisition module 10 is used to identify the deployment-related configuration files and metadata from the target source code repository based on the target source code repository information in the obtained deployment package generation instructions; wherein, the deployment package generation instructions include target source code repository information and target virtualization tenant information; The dependency analysis module 20 is used to convert configuration files and metadata into deployment blueprints through static parsing and collaborative analysis with a preset language model. The deployment blueprints adopt a preset data exchange format and include at least one of the following: service definition, number of replicas, port, environment variables, volume mount, dependency relationship, probe, resource request and limit, and lifecycle hook. The virtualization adaptation module 30 is used to adapt the deployment blueprint to the virtualization environment by utilizing the available resources and policy constraints corresponding to the target virtualization tenant information, and obtain the adapted deployment blueprint. Template generation module 40 is used to generate orchestration and deployment packages corresponding to the adapted deployment blueprint.

[0101] In some embodiments, the dependency analysis module 20 may include: The static parsing submodule is used to process structured files based on metadata using a static parser to extract baseline service information; the structured files include those in the configuration file. The dynamic reasoning submodule is used to reason about unstructured files based on metadata and a preset language model to obtain the reasoning result; unstructured files include files other than structured files in the configuration file. The construction submodule is used to build a deployment blueprint based on baseline service information and inference results; the baseline service information has a higher priority than the inference results.

[0102] In some embodiments, the virtualization adaptation module 30 may include: The loading submodule is used to obtain the available resources and policy constraints corresponding to the target virtualization tenant information by utilizing the loaded plugin for the target private cloud environment; where the target private cloud environment is the private cloud environment corresponding to the target virtualization tenant information; The adaptation submodule is used to adapt the deployment blueprint to the virtualization environment based on available resources and policy constraints, and obtain the adapted deployment blueprint.

[0103] In some embodiments, the warehouse acquisition module 10 may include: The clone submodule is used to clone target data from the target source code repository corresponding to the target source code repository information; The identification submodule is used to identify deployment-related configuration files from the target data; The parsing submodule is used to perform deep parsing of the configuration file and obtain metadata using the metadata extraction model. The deep parsing includes at least one of document file parsing, application named entity recognition, relation extraction and text summarization. The metadata extraction model is a pre-trained language model for metadata extraction.

[0104] In some embodiments, the identification submodule may include: The scoring unit is used to calculate the master-slave score of each file to be divided according to the preset scoring algorithm if there are files to be divided in the configuration file. The files to be divided are configuration files of the same type, the current type is any type that corresponds to at least two configuration files, and the preset scoring algorithm is used to calculate the score based on at least one weighted factor among standard file name matching degree, file path depth, content keywords and service quantity. The determination unit is used to determine a master configuration file corresponding to the current type based on the master-slave score.

[0105] In some embodiments, the template generation module 40 can be specifically used to generate an orchestration deployment package corresponding to the adapted deployment blueprint using a template engine and an artificial intelligence-assisted model; wherein, the template engine is used to generate the workload in the orchestration deployment package using a preset working template corresponding to the deployment blueprint, and the artificial intelligence-assisted model is used to generate the configuration content in the orchestration deployment package, and the artificial intelligence-assisted model is a pre-trained language model used for configuration conversion.

[0106] In some embodiments, the AI-assisted model is driven by structured prompts, which include at least one of role definition, task description, input data, and output constraints.

[0107] In some embodiments, the system may further include: The verification module is used to verify the orchestrated deployment package as the current deployment package using an isolated sandbox environment; The packaging module is used to perform delivery processing on the current deployment package if the verification is successful, to obtain the target orchestration deployment package; wherein the delivery processing includes at least one of versioning processing, signing processing and packaging processing.

[0108] In some embodiments, the verification module may be specifically used to perform static verification of the current deployment package and dynamic pre-installation verification in a sandbox environment; if the verification is successful, a start signal is sent to the packaging module.

[0109] In some embodiments, the system may further include: The self-healing module is used to obtain the error information of the verification failure if the verification fails, and to use the artificial intelligence repair engine to correct the current deployment package based on the error information, so as to obtain a corrected orchestrated deployment package; the corrected orchestrated deployment package is used as the current deployment package and a start signal is sent to the verification module.

[0110] In some embodiments, the self-healing module may include: The code correction submodule is used to use an artificial intelligence repair engine to correct the target code based on the error information, and obtain the corrected target code. The target code is the code segment corresponding to the error information, and the artificial intelligence repair engine includes a pre-trained language model for code repair. The deployment package correction submodule is used to correct the current deployment package based on the corrected target code, resulting in a corrected orchestrated deployment package.

[0111] In some embodiments, the virtualization adaptation module 30 may further include: The pre-rendering submodule is used to pre-render the adapted deployment blueprint to obtain a resource list; The compliance decision submodule is used to send the resource list to the open policy agent and receive the compliance decision results returned by the open policy agent; if the compliance decision result is compliant, a start signal is sent to the template generation module 40. The repair submodule is used to correct the adapted deployment blueprint if the compliance decision result is non-compliant. It utilizes the artificial intelligence repair engine to correct the non-compliance information returned by the open policy agent, obtains the corrected deployment blueprint, and generates the orchestration and deployment package corresponding to the corrected deployment blueprint.

[0112] In some embodiments, the verification module may include: The conflict detection submodule is used to detect whether there are resource naming conflicts during the dynamic pre-installation verification process. The conflict resolution submodule is used to adjust the names of conflicting resources if there are any naming conflicts, and then continue with the dynamic pre-installation verification.

[0113] In some embodiments, the sandbox environment is created during each dynamic pre-installation verification and destroyed after the dynamic pre-installation verification is completed.

[0114] In some embodiments, the template generation module 40 may include: The version number submodule is used to generate a unique semantic version number for the current deployment package; The packaging submodule is used to package the current deployment package into the Open Container Initiative image format; The signature submodule is used to digitally sign the current deployment package to obtain the target orchestration deployment package.

[0115] In some embodiments, the device further includes: The evolution module is used to acquire runtime data after the orchestration deployment package is deployed to the application; the runtime data includes resource consumption; based on the resource consumption and the resource requests of the adapted deployment blueprint, the module determines the difference information; and based on the difference information, it generates resource configuration optimization suggestions.

[0116] In some embodiments, after generating resource configuration optimization suggestions based on the discrepancy information, the evolution module can also be used to take the resource configuration optimization suggestions as input when configuring the next deployment blueprint using the preset language model; and / or to adjust or retrain the preset language model using the discrepancy information and the resource configuration optimization suggestions.

[0117] In this embodiment, the present invention introduces a deployment blueprint as the core intermediate representation, decoupling the repository parsing, environment adaptation, and deployment package generation processes. This enables subsequent operations based on the deployment blueprint, improving debuggability and scalability. Furthermore, by utilizing the collaborative analysis of static parsing and a preset language model, the context of the entire code repository is deeply understood. Through virtualization environment adaptation of the deployment blueprint to meet the constraints of the private cloud virtualization environment, high-quality container orchestration deployment packages can be generated automatically and stably and efficiently, achieving automated delivery with high availability, high versatility, and high adaptability.

[0118] Corresponding to the above method embodiments, this invention also provides a container orchestration and deployment package generation device. The container orchestration and deployment package generation device described below and the container orchestration and deployment package generation method described above can be referred to each other.

[0119] Please refer to Figure 4 , Figure 4 This is a simplified structural diagram of a container orchestration and deployment package generation device provided in an embodiment of the present invention. The generation device may include: Memory D1 is used to store computer programs; The processor D2 is used to implement the steps of the container orchestration and deployment package generation method provided in the above method embodiments when executing a computer program.

[0120] Accordingly, please refer to Figure 5 , Figure 5 This is a schematic diagram of a container orchestration and deployment package generation device provided in an embodiment of the present invention. The generation device 310 can vary significantly due to different configurations or performance characteristics. It may include one or more processors 322 (e.g., one or more central processing units, CPUs) and a memory 332, and one or more storage media 330 (e.g., one or more mass storage devices) for storing application programs 342 or data 344. The memory 332 and storage media 330 can be temporary or persistent storage. The program stored in the storage media 330 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the host. Furthermore, the processor 322 may be configured to communicate with the storage media 330 and execute the series of instruction operations in the storage media 330 on the generation device 310.

[0121] The generating device 310 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341, such as Linux systems.

[0122] In this embodiment, the generating device 310 can be a server or a computer.

[0123] The steps in the container orchestration deployment package generation method described above can be implemented by the structure of the container orchestration deployment package generation device.

[0124] Corresponding to the above method embodiments, this invention also provides a computer program product. The computer program product described below and the container orchestration deployment package generation method described above can be referred to in correspondence.

[0125] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the container orchestration and deployment package generation method provided in the above-described method embodiments.

[0126] Corresponding to the above method embodiments, this invention also provides a computer-readable storage medium. The computer-readable storage medium described below and the container orchestration deployment package generation method described above can be referred to in correspondence.

[0127] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the container orchestration and deployment package generation method described in the above method embodiments.

[0128] The computer-readable storage medium can specifically be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

[0129] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems, devices, computer program products, and computer-readable storage media disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant details can be found in the method section.

[0130] The foregoing has provided a detailed description of the method, system, device, and computer-readable storage medium for generating container orchestration and deployment packages provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of this invention.

Claims

1. A method for generating container orchestration and deployment packages, characterized in that, include: Based on the target source code repository information in the obtained deployment package generation instructions, the deployment-related configuration files and metadata are identified from the target source code repository; wherein, the deployment package generation instructions include the target source code repository information and the target virtualization tenant information; Through the collaborative analysis of static parsing and a preset language model, the configuration file and metadata are converted into a deployment blueprint; wherein, the deployment blueprint adopts a preset data exchange format, and the deployment blueprint includes at least one of the following: service definition, number of replicas, port, environment variables, volume mount, dependency relationship, probe, resource request and limit, and lifecycle hook; Using the available resources and policy constraints corresponding to the target virtualization tenant information, the deployment blueprint is adapted to the virtualization environment to obtain the adapted deployment blueprint; Generate the orchestration and deployment package corresponding to the adapted deployment blueprint.

2. The method for generating container orchestration and deployment packages according to claim 1, characterized in that, The process of converting the configuration file and metadata into a deployment blueprint through collaborative analysis of static parsing and a preset language model includes: Based on the metadata, a static parser is used to process the structured files and extract baseline service information; wherein, the structured files include the structured files in the configuration file; Based on the metadata, the pre-defined language model is used to infer the unstructured files and obtain the inference result; wherein, the unstructured files include files other than the structured files in the configuration file; The deployment blueprint is constructed based on the baseline service information and the inference results; wherein the baseline service information has a higher priority than the inference results.

3. The method for generating container orchestration and deployment packages according to claim 1, characterized in that, The step of adapting the deployment blueprint to a virtualized environment using the available resources and policy constraints corresponding to the target virtualized tenant information to obtain an adapted deployment blueprint includes: Using the plugin for the loaded target private cloud environment, obtain the available resources and policy constraints corresponding to the target virtualization tenant information; wherein, the target private cloud environment is the private cloud environment corresponding to the target virtualization tenant information; Based on the available resources and the policy constraints, the deployment blueprint is adapted to a virtualization environment to obtain an adapted deployment blueprint.

4. The method for generating container orchestration and deployment packages according to claim 1, characterized in that, The step of generating the target source code repository information from the obtained deployment package instructions, and identifying the deployment-related configuration files and metadata from the target source code repository, includes: Clone the target data from the target source code repository corresponding to the target source code repository information; Identify deployment-related configuration files from the target data; The metadata is obtained by performing deep parsing on the configuration file using a metadata extraction model; wherein the deep parsing includes at least one of document file parsing, application named entity recognition, relation extraction and text summarization, and the metadata extraction model is a pre-trained language model for metadata extraction.

5. The method for generating container orchestration and deployment packages according to claim 4, characterized in that, The step of identifying deployment-related configuration files from the target data includes: If there are files to be partitioned in the configuration file, the master-slave score of each file to be partitioned corresponding to the current type is calculated according to the preset scoring algorithm; wherein, the files to be partitioned are configuration files of the same type, the current type is any type corresponding to at least two configuration files, and the preset scoring algorithm is used to calculate the score based on at least one weighted factor among standard file name matching degree, file path depth, content keywords and service quantity; Based on the master-slave score, determine a master configuration file corresponding to the current type.

6. The method for generating container orchestration and deployment packages according to claim 1, characterized in that, The process of generating the orchestration and deployment package corresponding to the adapted deployment blueprint includes: Using a template engine and an AI-assisted model, an orchestration and deployment package corresponding to the adapted deployment blueprint is generated; wherein, the template engine is used to generate the workload in the orchestration and deployment package using a preset working template corresponding to the deployment blueprint, and the AI-assisted model is used to generate the configuration content in the orchestration and deployment package, and the AI-assisted model is a pre-trained language model used for configuration conversion.

7. The method for generating container orchestration and deployment packages according to claim 6, characterized in that, The AI-assisted model is driven by structured prompts, which include at least one of role definition, task description, input data, and output constraints.

8. The method for generating container orchestration and deployment packages according to claim 1, characterized in that, After generating the orchestration and deployment package corresponding to the adapted deployment blueprint, the process also includes: The orchestrated deployment package is used as the current deployment package, and the current deployment package is verified using an isolated sandbox environment; If the verification is successful, the current deployment package is delivered to obtain the target orchestration deployment package; wherein the delivery process includes at least one of versioning, signing and packaging.

9. The method for generating container orchestration and deployment packages according to claim 8, characterized in that, The verification of the current deployment package using an isolated sandbox environment includes: Perform static verification on the current deployment package and dynamic pre-installation verification in the sandbox environment; If the verification is successful, then proceed with the step of delivering the current deployment package to obtain the target orchestration deployment package.

10. The method for generating container orchestration and deployment packages according to claim 8, characterized in that, After verifying the current deployment package using an isolated sandbox environment, the process also includes: If verification fails, obtain the error message of the verification failure, and use the artificial intelligence repair engine to correct the current deployment package based on the error message to obtain the corrected deployment package; The modified orchestrated deployment package is used as the current deployment package, and the step of verifying the current deployment package using an isolated sandbox environment is executed.

11. The method for generating container orchestration and deployment packages according to claim 10, characterized in that, The step of using an artificial intelligence repair engine to correct the current deployment package based on the error information, resulting in a corrected deployment package, includes: Using the AI ​​repair engine, the target code is corrected based on the error information to obtain the corrected target code; wherein, the target code is the code segment corresponding to the error information, and the AI ​​repair engine includes a pre-trained language model for code repair; Based on the modified target code, the current deployment package is modified to obtain the modified orchestration deployment package.

12. The method for generating container orchestration and deployment packages according to claim 10, characterized in that, Before generating the orchestration and deployment package corresponding to the adapted deployment blueprint, the process also includes: The adapted deployment blueprint is pre-rendered to obtain a resource list; Send the resource list to the Open Policy Agent and receive the compliance decision results returned by the Open Policy Agent; If the compliance decision result is compliant, then the step of generating the orchestration and deployment package corresponding to the adapted deployment blueprint is executed; If the compliance decision result is non-compliant, the AI ​​repair engine is used to correct the adapted deployment blueprint based on the non-compliance information returned by the open policy agent, resulting in a corrected deployment blueprint, and an orchestration and deployment package corresponding to the corrected deployment blueprint is generated.

13. The method for generating container orchestration and deployment packages according to claim 9, characterized in that, The static verification of the current deployment package and the dynamic pre-installation verification in the sandbox environment include: During the dynamic pre-installation verification process, it is necessary to detect whether there are any resource naming conflicts. If resource naming conflicts exist, the conflicting resource names will be adjusted, and dynamic pre-installation verification will continue.

14. The method for generating container orchestration and deployment packages according to claim 9, characterized in that, The sandbox environment is created during each dynamic pre-installation verification and destroyed after the dynamic pre-installation verification is completed.

15. The method for generating container orchestration and deployment packages according to claim 8, characterized in that, The delivery process for the current deployment package to obtain the target orchestration deployment package includes: Generate a unique semantic version number for the currently deployed package; Package the current deployment package into an Open Container Initiative image format; The current deployment package is digitally signed to obtain the target orchestration deployment package.

16. The method for generating a container orchestration deployment package according to any one of claims 1 to 15, characterized in that, After generating the orchestration and deployment package corresponding to the adapted deployment blueprint, the process also includes: Obtain the runtime data after the orchestration and deployment package is deployed to the application; wherein, the runtime data includes resource consumption; Based on the resource consumption and the resource requests of the adapted deployment blueprint, determine the discrepancy information; Based on the discrepancy information, resource allocation optimization suggestions are generated.

17. The method for generating container orchestration and deployment packages according to claim 16, characterized in that, After generating resource configuration optimization suggestions based on the difference information, the process further includes: When configuring the next deployment blueprint using the preset language model, the resource configuration optimization suggestions are taken as input; and / or, The preset language model is adjusted or retrained using the difference information and the resource configuration optimization suggestions.

18. A system for generating container orchestration and deployment packages, characterized in that, include: The repository acquisition module is used to identify deployment-related configuration files and metadata from the target source code repository based on the target source code repository information obtained from the deployment package generation instruction; wherein, the deployment package generation instruction includes the target source code repository information and the target virtualization tenant information; The dependency analysis module is used to convert the configuration file and metadata into a deployment blueprint through static parsing and collaborative analysis with a preset language model. The deployment blueprint adopts a preset data exchange format and includes at least one of the following: service definition, number of replicas, port, environment variables, volume mount, dependency relationship, probe, resource request and limit, and lifecycle hook. The virtualization adaptation module is used to adapt the deployment blueprint to the virtualization environment by utilizing the available resources and policy constraints corresponding to the target virtualization tenant information, and obtain the adapted deployment blueprint. The template generation module is used to generate the orchestration and deployment package corresponding to the adapted deployment blueprint.

19. An apparatus for generating container orchestration and deployment packages, characterized in that, include: Memory, used to store computer programs; A processor, configured to execute the computer program, implement the steps of the method for generating a container orchestration deployment package as described in any one of claims 1 to 17.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method for generating a container orchestration deployment package as described in any one of claims 1 to 17.

Images