Generation method and device of containerized application arrangement engine, equipment and storage medium

Abstract

The invention belongs to the technical field of artificial intelligence, and discloses a generation method, device and equipment of a containerized application orchestration engine and a storage medium, and the method comprises the steps: creating a declarative application model which describes the overall configuration and deployment requirements of a containerized application; based on the application model, an automatic assembly line from code construction to environment deployment is triggered and executed through a unified arrangement engine, safety strategies are integrated in the automatic assembly line, and safety check and compliance verification are automatically executed; in response to a change event of the Git warehouse, synchronizing the application model to a plurality of target computing clusters based on a GitOps principle; and collecting execution data of the automatic assembly line and the production environment runtime indexes, and associating the execution data of the automatic assembly line to generate delivery efficiency measurement and release decision support. According to the method, the problems of inconsistent deployment process, lack of security compliance verification, difficulty in multi-cluster state synchronization and lack of data support for delivery efficiency in containerized application deployment are solved.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence technology and is applied in the fields of fintech and healthcare. In particular, it relates to a method, apparatus, device and storage medium for generating a containerized application orchestration engine. Background Technology

[0002] With the increasing adoption of containerization and microservice architectures, more and more enterprises are using container orchestration platforms such as Kubernetes to deploy and manage applications. However, in practice, the entire process from code submission to production deployment still presents many challenges. Traditional deployment methods typically rely on manual operations or scattered automated scripts, lacking a unified, declarative application definition and management mechanism. This leads to inconsistent and inefficient deployment processes, and makes it difficult to achieve consistency and repeatability across multiple environments or clusters.

[0003] Furthermore, existing solutions often lack systematic security policy integration and automated compliance verification mechanisms in continuous integration and continuous deployment processes, making them prone to introducing security vulnerabilities or configuration risks. Simultaneously, the lack of automated response mechanisms for Git change events hinders automated multi-cluster synchronization based on GitOps, causing application releases to rely on manual intervention, resulting in slow response times and a high risk of errors. On the other hand, existing systems typically lack the ability to collect and analyze data across the entire lifecycle from build to runtime, failing to effectively correlate pipeline execution data with production environment metrics. This makes it difficult to quantify delivery performance, and release decisions lack data support, impacting overall R&D and operational efficiency and application quality. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for generating a containerized application orchestration engine, in order to solve the problems of inconsistent deployment processes, lack of security and compliance verification, difficulty in synchronizing the states of multiple clusters, and lack of data support for delivery performance in the existing containerized application deployment process.

[0005] In a first aspect, the present invention provides a method for generating a containerized application orchestration engine, comprising: Create a declarative application model that describes the overall configuration and deployment requirements of the containerized application; Based on the application model, an automated pipeline from code building to environment deployment is triggered and executed through a unified orchestration engine. Security policies are integrated into the automated pipeline to automatically perform security checks and compliance verifications. In response to changes in the Git repository, the application model is synchronized to multiple target computing clusters based on GitOps principles; Collect execution data from the automated production line and runtime metrics in the production environment, and correlate the execution data from the automated production line to generate delivery performance metrics and release decision support.

[0006] Secondly, the present invention provides an apparatus for generating a containerized application orchestration engine, characterized in that it comprises: The model creation module is used to create declarative application models, which describe the overall configuration and deployment requirements of containerized applications. An execution module is used to trigger and execute an automated pipeline from code building to environment deployment based on the application model through a unified orchestration engine, wherein security policies are integrated into the automated pipeline to automatically perform security checks and compliance verifications. The synchronization module is used to respond to changes in the Git repository and synchronize the application model to multiple target computing clusters based on GitOps principles. The generation module is used to collect the execution data of the automated pipeline and the runtime indicators of the production environment, and associate the execution data of the automated pipeline to generate delivery performance metrics and release decision support.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for generating a containerized application orchestration engine.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described method for generating a containerized application orchestration engine.

[0009] The solution implemented by the above-mentioned containerized application orchestration engine generation method, device, equipment, and storage medium uniformly describes the overall configuration and deployment requirements of containerized applications by creating a declarative application model. Based on this model, an automated pipeline from code building to environment deployment is triggered and executed through a unified orchestration engine. Security policies are integrated to automatically perform security checks and compliance verifications. Furthermore, in response to Git repository change events, the application model is automatically synchronized to multiple target computing clusters based on GitOps principles. At the same time, pipeline execution data and production environment runtime indicators are collected and correlated to generate delivery performance metrics and release decision support, realizing full-process automation, standardization, and observability of containerized application deployment. This solution systematically addresses the inconsistencies and inefficiencies in traditional deployment processes caused by excessive manual intervention and fragmented scripts. Through built-in security compliance checks and automatic blocking mechanisms, it effectively prevents vulnerabilities and configuration risks from spreading to the production environment. Leveraging GitOps, it achieves reliable and auditable automatic synchronization of states across multiple clusters, significantly improving release reliability. Finally, based on end-to-end data correlation analysis, it provides quantitative evidence for improving R&D efficiency and making release decisions, comprehensively supporting the agile, secure, and efficient delivery of enterprise-level applications.

[0010] Furthermore, the core reason for the weak security protection in the deployment process of related technologies is the lag in security checks, their disconnect from the deployment process, and their reliance on manual triggering. This solution, however, integrates security policies into an automated pipeline, performs static application security testing during the code building phase, triggers container vulnerability scanning after image building, and executes infrastructure compliance checks before deployment. It also configures an automatic blocking mechanism for security policy violations. This shift-left security and automated verification design transforms discrete, passive manual security reviews into a proactive, continuous protection system throughout the CI / CD process, fundamentally preventing insecure code, images, or configurations from entering the production environment. In highly regulated industries such as finance and healthcare, this mechanism ensures that application deployments continuously comply with industry security standards and compliance requirements, significantly reducing business risks and audit failure probabilities caused by non-compliant deployment content.

[0011] Furthermore, the core issue hindering multi-cluster application state management and addressing delivery performance bottlenecks in related technologies lies in the lack of a unified control plane that uses a declarative model as a single trusted source and connects development and runtime data. This solution explicitly uses a declarative application model as a benchmark, monitoring Git repository changes and driving automatic synchronization of multi-cluster states based on GitOps principles. This ensures that the actual cluster state always aligns with the version-defined expected state, enabling reliable reproducibility of the deployment process and version rollback. Simultaneously, by collecting and analyzing end-to-end data from build to runtime, it quantifies and calculates key DevOps metrics such as deployment frequency, change failure rate, and average recovery time. This data is then used to train a release decision model and generate release health reports, enabling teams to accurately pinpoint bottlenecks, predict release risks, and continuously optimize processes. This dual mechanism of automated GitOps synchronization and data-driven decision-making not only solves the application state drift problem in multi-cluster environments but also fills the performance measurement gap between deployment activities and business value delivery, providing organizations with a practical and feasible technical path to improve R&D and operational efficiency.

[0012] In summary, this solution can address the issues in existing containerized application deployment processes, such as inconsistent deployment processes, lack of security and compliance verification, difficulties in synchronizing the states of multiple clusters, and lack of data support for delivery efficiency. Attached Figure Description

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

[0014] Figure 1 This is a flowchart illustrating a method for generating a containerized application orchestration engine according to an embodiment of the present invention.

[0015] Figure 2 yes Figure 1 A flowchart of step S110.

[0016] Figure 3 yes Figure 1 A flowchart of step S120.

[0017] Figure 4 yes Figure 1 Another flowchart of step S120.

[0018] Figure 5 yes Figure 1 A flowchart of step S130.

[0019] Figure 6 yes Figure 1 A flowchart of step S140.

[0020] Figure 7 yes Figure 1 Another flowchart of step S140.

[0021] Figure 8 This is a schematic diagram of a device for generating a containerized application orchestration engine in one embodiment of the present invention.

[0022] Figure 9 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention.

[0023] Figure 10 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0024] 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, not all, of the embodiments of the present invention. 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.

[0025] Please see Figure 1 As shown in the flowchart, this embodiment of the invention provides a method for generating a containerized application orchestration engine, which includes the following steps.

[0026] Step S110: Create a declarative application model that describes the overall configuration and deployment requirements of the containerized application.

[0027] It should be noted that the creation of the declarative application model in step S110 is a core modeling process based on the Infrastructure as Code (IaC) concept, and its design goals are deeply aligned with the application deployment needs of different industries. In the fintech field, applications such as trading systems and risk control services have extremely high requirements for deployment consistency, security, and auditability. This modeling process lays the foundation for the automated deployment of financial-grade applications by standardizing the description of code sources, build parameters, container configurations, and deployment strategies such as replication strategies and resource quotas. In the healthcare field, applications such as electronic medical record systems and medical image processing platforms involve complex multi-component coordination and sensitive data processing. The modeling process ensures that healthcare application deployments comply with industry security standards by unifying and standardizing service exposure methods, resource constraints, and other elements.

[0028] In some embodiments of the present invention, such as Figure 2 As shown, step S110 includes the following steps: Step S111: Parse the application definition file and extract the code repository address, build parameters, and container image configuration; Step S112: Read the deployment strategy description, including the number of replicas, resource limits, and service exposure methods; Step S113: Generate a versioned application model instance and associate it with code commit records and build artifacts; Step S114: Verify the completeness and compliance of the application model, and output a standardized application description object.

[0029] Specifically, in step S111, the process of parsing the application definition file uses a file parser to identify configuration files of specific formats (such as YAML, JSON, etc.) and extract key deployment elements from them. In the fintech field, when parsing the definition file for a high-frequency trading system, it accurately extracts its dedicated code repository branch, low-latency build parameters, and security-hardened base image configuration; in the healthcare field, when processing the definition file for a medical imaging AI platform, it extracts the code repository address containing sensitive data annotations, GPU-accelerated build flags, and container image versions that conform to medical standards.

[0030] Specifically, in step S112, the deployment strategy description is read based on a strategy parsing engine, which converts natural language or structured strategies into executable deployment constraints. In the fintech field, for core payment systems, the strategy description explicitly specifies a high number of replicas across multiple regions to ensure business continuity, sets strict CPU / memory resource limits to prevent resource contention, and defines service exposure via internal load balancers rather than the public internet to ensure network security. In the healthcare field, for online consultation services, the strategy may specify a replica strategy that scales elastically based on outpatient volume, define high memory resource limits to meet image processing requirements, and configure service exposure via an API gateway with integrated authentication mechanisms to protect patient privacy.

[0031] Specifically, in step S113, the generation of versioned instances is accomplished through a model instantiation engine. This engine creates a unique version identifier for each application model and establishes an immutable association with the specific code commit hash value in a version control system (such as Git) and the build artifacts generated by a continuous integration system (such as the Docker image Digest). In the fintech field, the generated model instance is associated with a specific commit that has undergone code review and security scanning, as well as the corresponding built image that has passed financial compliance verification, ensuring that deployment traceability meets audit requirements. In the healthcare field, the model instance is associated with a code commit containing clinical logic updates, as well as the built image artifact that conforms to medical device software standards, ensuring the traceability of the medical software deployment process.

[0032] Specifically, in step S114, the verification process is executed through a rules engine that incorporates integrity check rules (such as mandatory field validation and dependency checks) and an industry compliance rule base. In the fintech field, compliance verification checks whether resource constraints meet the requirements of the financial industry's information system security level protection system and whether service exposure methods comply with financial network security regulations. In the healthcare field, it verifies whether data storage configuration meets the management requirements of HIPAA or the Personal Information Protection Law for patient health information and whether the mirror source complies with medical software traceability standards. Upon successful verification, a standardized, machine-readable application description object (such as an ApplicationConfiguration object conforming to the OAM specification) is output, providing reliable input for subsequent automated orchestration.

[0033] Understandably, the standardized process of creating declarative application models, compared to traditional script-based or manually configured application deployment methods, achieves precise and unambiguous expression of deployment intent and ensures versioned management and audit trails for deployment definitions. In the fintech field, this mechanism is crucial for building stable, compliant, and highly available financial service systems. It ensures that every application change, from code submission to build artifacts and deployment strategy, is fully recorded and correlated, greatly simplifying the complexity of troubleshooting, version rollback, and compliance verification. This standardized description method based on declarative models provides a unified management abstraction for complex deployment topologies commonly found in the financial industry (such as in-city active-active deployments and off-site disaster recovery), significantly improving the reliability and repeatability of the deployment process. After completing the creation and verification of the application model, a solid foundation is laid for achieving a secure and efficient automated application delivery pipeline. For example, during the upgrade of a securities trading system, this standardized application description object can automatically drive the entire process from code compilation and security scanning to multi-environment deployment, ensuring strict consistency between the production environment and the expected state, meeting the financial industry's requirements for high reliability, high security, and strong auditability in the deployment process. In the healthcare field, this modeling mechanism provides technical support for deploying application systems involving sensitive health data, enabling medical institutions to manage the lifecycle of applications in a standardized and auditable manner, just like managing medical assets, effectively supporting the construction of smart hospitals and the digital transformation of medical services.

[0034] Step S120: Based on the application model, an automated pipeline from code building to environment deployment is triggered and executed through a unified orchestration engine, wherein security policies are integrated into the automated pipeline to automatically perform security checks and compliance verifications.

[0035] It should be noted that the unified orchestration engine execution in step S120 is the core implementation mechanism for continuous delivery driven by a declarative application model, and its scheduling logic is closely aligned with the application delivery quality requirements of different industries. In the fintech field, the delivery process of critical business applications such as payment systems and core transaction platforms requires extremely high reliability and security. This execution process ensures the delivery quality of financial-grade applications by building a complete task dependency topology, integrating multi-layered security verification, and intelligent fault recovery mechanisms. In the healthcare field, the delivery of medical applications such as clinical decision support systems and patient management platforms involves strict compliance reviews. The execution process ensures that the deployment of medical software complies with industry regulatory standards through systematic task scheduling and full-process status monitoring.

[0036] In some embodiments of the present invention, such as Figure 3 As shown, step S120 includes the following steps: Step S121: parse the task dependencies in the application model and construct a task execution topology graph; Step S122: Schedule the sequence of tasks for code compilation, image building, security scanning, and deployment testing; Step S123: Monitor the task execution status and trigger a retry or rollback mechanism when the task fails. Step S124: Coordinate the workload of multiple execution nodes to ensure the high efficiency of task execution.

[0037] Specifically, in step S121, resolving task dependencies is achieved through a dependency analysis engine. This engine constructs a task execution topology represented by a directed acyclic graph based on the build phases, test requirements, and deployment order defined in the application model. In the fintech field, for the deployment of risk control engines, dependency analysis identifies a strict order where static code scanning must be completed before unit testing, security compliance verification must be performed immediately after image building, and production environment deployment must wait for all test phases to pass. In the healthcare field, for the updated deployment of medical imaging AI models, a dependency relationship is established where data preprocessing must be performed before model training, model validation must be performed after training, and clinical environment deployment must undergo medical regulatory approval, ensuring that the delivery process complies with medical software lifecycle management standards.

[0038] Specifically, in step S122, task scheduling is executed through a distributed task scheduler, which intelligently allocates tasks at each stage based on the task topology and worker node status. In the fintech field, the scheduler prioritizes allocating high-performance nodes for low-latency compilation tasks of the trading system, allocates compliant computing environments for image building tasks involving sensitive data processing, and ensures that security scanning tasks use the latest vulnerability library versions. In the healthcare field, dedicated GPU computing resources are configured for scheduling medical data processing tasks, isolated execution environments are allocated for testing tasks involving patient privacy, and all security verification tasks comply with medical data security standards such as HIPAA.

[0039] Specifically, in step S123, status monitoring is implemented through a real-time monitoring system that tracks the execution progress, resource consumption, and exit status of each task. In the fintech field, when an integration test of the payment gateway fails, the system automatically rolls back to the previous stable version of the image and notifies the operations team to intervene. In the healthcare field, when a patient data encryption and verification task fails, the system immediately halts the deployment process, automatically rolls back all executed changes, and generates a detailed event report for the healthcare information security team to audit.

[0040] Specifically, in step S124, workload coordination is achieved through a load balancer, which intelligently schedules tasks based on the real-time resource utilization, network conditions, and task priorities of each node. In the fintech field, load coordination ensures that compilation tasks of the core trading system receive priority access to resources, while balancing concurrent build requests from multiple development teams to avoid resource contention. In the healthcare field, it ensures that emergency system update tasks receive the highest scheduling priority, while rationally allocating resource requirements for medical image processing and routine business systems to ensure the continuity of critical medical services.

[0041] Understandably, the automated pipeline execution mechanism of the unified orchestration engine, compared to traditional manually triggered and decentralized deployment methods, achieves standardization, automation, and observability in the application delivery process. In the fintech field, this mechanism is crucial for ensuring the stable operation and compliant delivery of financial systems. Through precise task dependency management, intelligent scheduling strategies, and multi-layered security verification, it ensures that every application change undergoes a complete quality check, significantly reducing business risks caused by deployment issues. This automated execution framework based on unified orchestration provides strong support for the complex multi-environment and multi-region deployment scenarios in the financial industry, significantly improving delivery efficiency and quality consistency. After the automated pipeline execution is completed, a reliable foundation is laid for subsequent GitOps-based multi-cluster synchronization and end-to-end data collection. For example, when releasing a core bank system version, the automated pipeline driven by this orchestration engine can achieve standardized operations throughout the entire process from code submission to production environment deployment, ensuring that each step undergoes rigorous security checks and compliance verification, meeting the financial industry's high reliability, high security, and strong compliance requirements for application delivery. In the healthcare field, this execution mechanism provides technical assurance for the secure deployment of medical software, enabling medical institutions to manage the software delivery process in a standardized and traceable manner, just like managing medical equipment, effectively supporting the safe and reliable operation of smart healthcare construction and digital medical services.

[0042] In some embodiments of the present invention, such as Figure 4 As shown, step S120 further includes the following steps: Step S125: Integrate static application security testing during the code building phase to detect code security vulnerabilities; Step S126: Trigger container vulnerability scanning after image building to verify image security; Step S127: Perform an infrastructure compliance check before deployment to ensure the environment complies with the security policy; Step S128: Configure an automatic blocking mechanism for security policy violations to prevent insecure deployment. Specifically, in step S125, static application security testing integrates the SAST tool to perform in-depth scanning and analysis of the source code before compilation. In the fintech field, for the codebase of core trading systems, the SAST tool focuses on detecting potential SQL injection, buffer overflows, and encryption algorithm implementation defects to prevent attackers from exploiting vulnerabilities to steal funds or data. In the healthcare field, for application code that processes patient health information, it rigorously scans for unauthorized data access paths and whether sensitive information may be recorded in logs to ensure compliance with HIPAA's security control requirements for protected health information.

[0043] Specifically, in step S126, container vulnerability scanning involves calling image scanning tools to perform layered scanning of the built container image based on vulnerability databases such as CVE. In the fintech field, for Docker images hosting online banking services, the scan rigorously checks whether their base image contains high-risk vulnerabilities and verifies whether they comply with financial industry security baselines, such as not running as a root user. In the healthcare field, for images used for medical image analysis, the scan focuses on whether their dependent third-party libraries contain known vulnerabilities and verifies whether their configuration avoids unnecessary network port exposure to prevent unauthorized access to medical data at the container level.

[0044] Specifically, in step S127, the infrastructure compliance check uses a policy-as-code tool to define security policies as executable rules and verify the target computing cluster or cloud environment. In the fintech field, before deploying payment services, it is mandatory to check whether the target namespace has network policy isolation enabled and whether secrets are stored encrypted to ensure compliance with the PCI DSS payment card industry data security standard. In the healthcare field, before deploying electronic medical record applications, it verifies whether the Persistent Volume is configured with encryption and whether the Pod security standard is set to restricted mode, thereby meeting the data integrity and reliability requirements of regulations such as GxP.

[0045] Specifically, in step S128, the automatic blocking mechanism is implemented by setting quality gates in the CI / CD pipeline. When any security detection or compliance check stage fails, the pipeline will automatically stop and be marked as failed. In the fintech field, if the image of the core accounting system is found to contain a critical-level vulnerability, the pipeline will automatically abort the deployment process and immediately notify the security operations team to prevent versions with known high-risk vulnerabilities from entering the production environment. In the healthcare field, if when deploying services for medical device data interfaces, it is found that the target cluster does not have node-level disk encryption enabled, the pipeline will automatically block the deployment and generate a compliance audit event to ensure that only deployments that fully comply with medical data security specifications can be executed.

[0046] It should be noted that the multi-layered security verification and automatic blocking mechanisms integrated into the automated pipeline constitute the key technological implementation of "security shift left" and "continuous compliance." In highly regulated industries such as finance and healthcare, this design seamlessly embeds the traditionally lagging and independent security review process into every critical stage of application delivery. Through automated security capabilities, it achieves full-stack risk control over code, images, and infrastructure, fundamentally improving the inherent security level of application delivery and providing a solid foundation for business continuity and data security.

[0047] Step S130: In response to the change event of the Git repository, the application model is synchronized to multiple target computing clusters based on GitOps principles.

[0048] It should be noted that GitOps synchronization in step S130 is the core mechanism for achieving continuous synchronization of declarative infrastructure. Its design philosophy is deeply aligned with the stringent requirements of various industries for deployment consistency, auditability, and automated operation and maintenance. In the fintech field, multi-cluster deployment scenarios such as core trading systems and risk control platforms require absolute configuration consistency and rapid fault recovery capabilities. This synchronization mechanism ensures that any configuration changes undergo version control and approval processes by using Git as the sole trusted source. In the healthcare field, distributed deployment scenarios such as regional medical collaboration platforms and hierarchical diagnosis and treatment systems have mandatory requirements for configuration standardization and traceability. This mechanism ensures the consistency and reliability of medical services across different institutions through automated state synchronization.

[0049] In some embodiments of the present invention, such as Figure 5 As shown, step S130 includes the following steps: Step S131: Listen for change events of application model files in the Git repository; Step S132: Compare the current state of the cluster with the target state of the Git repository; Step S133: Generate synchronization operation instructions to deploy the application changes to the target cluster; Step S134: Verify the deployment results and ensure that the cluster state is consistent with the Git definition.

[0050] Specifically, in step S131, monitoring change events is implemented through Git Webhook or a timed polling mechanism. When events such as commits or merges of application model files (such as kustomization.yaml or helm values ​​files) are detected, a synchronization process is immediately triggered. In the fintech field, when monitoring changes to application models for cross-border payment systems, the source branch of the triggering event is strictly verified to ensure that only changes that have undergone sufficient testing and compliance approval can enter the production environment. In the healthcare field, when monitoring changes to the configuration of regional medical information platforms, the focus is on monitoring merge requests initiated by authorized operations and maintenance personnel with accompanying clinical change review records to prevent unauthorized configuration modifications from affecting the quality of medical services.

[0051] Specifically, in step S132, the state comparison is performed by a difference analysis engine. This engine obtains the actual state of the running resources in each target computing cluster (e.g., a Kubernetes cluster) in real time and compares it item by item with the expected state defined in Git. In the fintech field, when comparing the state of a securities trading system in multiple data center clusters, it accurately identifies whether key resources such as the number of Deployment replicas, Service configuration, and ResourceQuota have drifted, ensuring the consistency of business disaster recovery capabilities and resource configuration. In the healthcare field, when comparing the state of patient service applications in multiple hospital clusters, it meticulously checks the business parameters in the ConfigMap, the network isolation rules of the NetworkPolicy, etc., to ensure a high degree of consistency between service policies and security baselines in each hospital area.

[0052] Specifically, in step S133, the generation of synchronization instructions is accomplished by the instruction generation module. This module automatically generates specific operation instructions such as `kubectl apply`, `patch`, or `helm upgrade` based on the state difference analysis results. In the fintech field, to ensure the high availability of financial systems, a blue-green deployment strategy is adopted when generating instructions. A new version environment is created first, and traffic switching tests are conducted, rather than directly overwriting the original production environment. In the healthcare field, to meet the stability requirements of healthcare system upgrades, a batch rolling update strategy is adopted when generating instructions. Priority is given to updating some clusters during non-core business periods, and full synchronization is performed only after verification, minimizing the impact on clinical services.

[0053] Specifically, in step S134, result verification is performed by a state verifier. After the synchronization operation is completed, the verifier retrieves the actual state of the cluster again and performs an eventual consistency check with the expected state in Git. In the fintech field, when verifying the deployment results of a payment gateway, it strictly checks whether all Pods are in the Ready state, whether the Service Endpoints are normal, and performs automated smoke tests to verify the integrity of business functions. In the healthcare field, when verifying the deployment results of an electronic medical record application, it checks whether key medical data interface services are accessible, whether data persistent volumes are correctly mounted, and may trigger pre-built health check interfaces to ensure that core diagnosis and treatment processes are not affected.

[0054] Understandably, the aforementioned GitOps-based automated multi-cluster synchronization mechanism, compared to traditional deployment methods relying on manual script execution or single management platforms for push notifications, achieves versioning, auditability, and self-healing capabilities for infrastructure status. In the fintech sector, this mechanism is irreplaceable for meeting the audit requirements of financial regulatory agencies and ensuring configuration consistency of critical business systems under complex distributed architectures. It clearly records the change history of all infrastructure in the Git commit log, achieving complete traceability of the change process. In the healthcare sector, this mechanism provides the technological foundation for standardized deployment and collaborative operation and maintenance of cross-institutional healthcare applications, ensuring that any modification to the healthcare system configuration leaves a trace, much like a change to a medical record, greatly enhancing the transparency and reliability of healthcare IT governance. After synchronizing and verifying the cluster status, it provides an accurate and consistent environmental foundation for subsequent end-to-end data collection and performance measurement. For example, during cross-regional disaster recovery drills in banks, this GitOps synchronization mechanism can quickly and accurately reproduce the complete application stack from the production center to the disaster recovery center with a single click, automatically completing consistency checks to ensure the effectiveness of the disaster recovery system. When regional medical centers distribute a unified health management platform to their subordinate community health institutions, this mechanism ensures that the application configuration and version of all institutions are strictly synchronized, thus guaranteeing the standardization and homogenization of regional medical and health services.

[0055] Step S140: Collect the execution data of the automated production line and the runtime indicators of the production environment, and associate the execution data of the automated production line to generate delivery performance metrics and release decision support.

[0056] It should be noted that the data collection and correlation analysis in step S140 is a core component of achieving digital operation of R&D and maintenance. Its design goals are closely related to the monitoring needs of different industries for delivery quality and system stability. In the fintech field, key applications such as high-frequency trading systems and online banking require extreme performance and rapid fault location capabilities. This data collection and analysis mechanism provides data support for the stable operation of financial systems by establishing end-to-end observability from code submission to production operation. In the healthcare field, medical applications such as emergency medical systems and telemedicine platforms have strict requirements for service availability and response timeliness. This mechanism provides a basis for decision-making on the continuity and quality assurance of medical services by correlating delivery process and operational status data.

[0057] In some embodiments of the present invention, such as Figure 6 As shown, step S140 includes the following steps: Step S141: Collect data on the build time, test pass rate, and deployment success rate of the automated pipeline from code building to environment deployment; Step S142: Monitor the application performance indicators, error rate, and resource usage of the automated production line; Step S143: Establish the data acquisition pipeline of the automated production line to uniformly store and process monitoring data; Step S144: Associate pipeline events with runtime metrics to build a full-link tracing system.

[0058] Specifically, in step S141, data collection is achieved through monitoring agents integrated into each stage of the pipeline. These agents automatically capture key performance indicators. In the fintech field, when collecting pipeline data from the payment core system, the system precisely records code compilation time, security scan duration, and the success rate of cross-data center deployment, providing quantitative data for optimizing the delivery efficiency of the financial system. In the healthcare field, when collecting pipeline data from the medical image processing platform, the system focuses on the execution time of model training tasks, the pass rate of medical data validation, and the deployment success rate to the medical private network, ensuring that the delivery process of medical AI applications meets clinical timeliness requirements.

[0059] Specifically, in step S142, runtime monitoring is implemented through a monitoring component deployed in the target computing cluster (e.g., a Kubernetes cluster) to continuously collect application performance data. In the fintech field, when monitoring the runtime metrics of a stock trading system, API interface response latency, order processing error rate, and CPU / memory resource consumption are closely tracked to ensure stable system performance under high concurrency scenarios. In the healthcare field, when monitoring the runtime status of an electronic medical record query service, the focus is on medical record loading time, query failure frequency, and database connection pool usage to ensure that medical staff can quickly and reliably access patient information.

[0060] Specifically, in step S143, the data pipeline is built through a streaming processing platform to aggregate, clean, and standardize dispersed pipeline events and runtime metrics. In the fintech field, the established unified data platform integrates data from multiple systems such as Jenkins, GitLab, and Prometheus to form a complete delivery performance view, supporting financial regulatory audit requirements. In the healthcare field, the built data pipeline integrates monitoring information from tools such as Azure DevOps, Jira, and Grafana to establish an operational data warehouse that conforms to healthcare IT standards, supporting quality management and continuous improvement in healthcare institutions.

[0061] Specifically, in step S144, end-to-end tracing is implemented through a distributed tracing system, establishing a complete traceability chain from code submission to production operation for each application version. In the fintech field, the constructed tracing system can correlate specific code submissions with online transaction latency fluctuations, accurately pinpointing code changes that cause performance regressions and facilitating rapid fault diagnosis. In the healthcare field, the established tracing chain can correlate medical algorithm updates with changes in clinical diagnostic accuracy, providing data support for the iterative optimization of medical AI models while meeting the lifecycle traceability requirements of medical device software.

[0062] Understandably, the aforementioned end-to-end data collection and correlation analysis mechanism, compared to traditional isolated monitoring and manual attribution methods, enables deeper insights and intelligent decision-making regarding application delivery and operational status. In the fintech sector, this mechanism is crucial for building a data-driven R&D and operations system. It allows teams to assess delivery performance and predict release risks based on objective data rather than experience-based judgment, significantly improving the stability and iteration efficiency of financial systems. This end-to-end data correlation method provides strong support for problem localization and performance optimization in the complex distributed architecture of the financial industry, enabling visualized analysis from code changes to business impacts. In the healthcare sector, this mechanism provides a scientific basis for continuous quality improvement of medical applications, enabling medical institutions to systematically monitor the entire software delivery process, ensuring that medical information systems meet functional requirements while continuously adhering to performance, security, and reliability standards. Completing end-to-end data collection and correlation analysis lays a solid data foundation for generating accurate delivery performance metrics and release decision support. For example, after the release of a core bank system version, this data correlation analysis mechanism can quickly identify database connection pool anomalies caused by specific code changes and automatically generate root cause analysis reports, significantly shortening the mean time to repair faults. During the upgrade of a medical imaging cloud platform, this mechanism helps the team identify deployment process bottlenecks, optimize resource allocation strategies, and ensure the stable and efficient delivery of medical AI services across different medical institutions.

[0063] In some embodiments of the present invention, such as Figure 7 As shown, step 140 also includes the following steps: Step S145: Calculate deployment frequency, change failure rate, and average recovery time metrics; Step S146: Analyze the trend of performance metrics during the release process; Step S147: Train a release decision model based on historical data to predict release risks; Step S148: Generate and publish a health report to provide optimization suggestions for subsequent releases.

[0064] Specifically, in step S145, the metric calculation is automatically executed through a predefined metrics analysis engine, which performs quantitative evaluation based on collected pipeline execution data and runtime anomaly information. In the fintech field, when calculating the deployment frequency of the credit card core system, the number of successful releases in the production environment each week is precisely counted; when analyzing change failure rates, online incidents caused by code defects or configuration errors are correlated with the total number of releases; and the average recovery time is calculated by statistically analyzing the time from the occurrence of a failure to the complete recovery of the system, providing key indicators for improving financial business continuity. In the healthcare field, when calculating the deployment frequency of hospital information systems, planned updates and emergency patch releases are distinguished; when analyzing change failure rates, the focus is on deployment anomalies affecting clinical business processes; and the average recovery time is calculated by strictly monitoring the time from system anomaly to the restoration of medical services to ensure compliance with medical service quality requirements.

[0065] Specifically, in step S146, trend analysis is implemented using time series analysis algorithms to perform longitudinal comparisons and pattern recognition of key performance indicators. In the fintech field, when analyzing the performance trends of mobile banking applications before and after release, the focus is on the changing patterns of transaction response time, the stability of concurrent processing capabilities, and the growth trend of system resource utilization after release, providing a basis for capacity planning. In the healthcare field, when analyzing the performance trends during version updates of medical image storage systems, close attention is paid to the stability of image upload and download speeds, fluctuations in database query performance, and the system's resource consumption patterns during peak patient visit periods, ensuring the reliability and responsiveness of medical data services.

[0066] Specifically, in step S147, risk prediction is achieved through a machine learning model. This model uses historical release data, code change characteristics, and system environment indicators as training features. In the fintech field, the trained risk prediction model comprehensively considers factors such as code complexity, test coverage, and changes in dependent services to predict the probability of potential risks associated with the release of the payment gateway and provides confidence scores for specific risk types (such as performance degradation and functional abnormalities). In the healthcare field, the constructed decision-making model focuses on analyzing characteristics such as changes in medical data formats, compliance inspection results, and clinical test coverage to predict the potential impact of the electronic medical record system release on the diagnosis and treatment process, providing quantitative support for the release decisions of healthcare IT departments.

[0067] Specifically, in step S148, report generation is achieved through an automated reporting engine that integrates various indicator data, trend analysis results, and risk prediction information. In the fintech field, the generated release health report will include the DORA indicator performance of this release, a comparative analysis with historical releases, the identified major bottlenecks, and targeted improvement suggestions, such as "optimize integration testing strategies to reduce pre-release preparation time by 40%." In the healthcare field, the report will focus on showcasing the impact assessment of the release process on clinical services, the complete results of compliance checks, and provide optimization suggestions tailored to the characteristics of healthcare work, such as "recommend adjusting the database change deployment time to off-peak hours."

[0068] It should be noted that the aforementioned delivery performance measurement and release decision support mechanism transforms the traditional experience-based release decision-making process into a data-driven scientific decision-making system. In fields such as finance and healthcare, where system stability requirements are extremely high, this mechanism, through systematic indicator calculation, trend analysis, risk prediction, and optimization suggestion generation, constructs a complete post-release evaluation and continuous improvement closed loop. This significantly enhances the organization's process improvement capabilities and risk control level, providing strong data support for business continuity and service reliability.

[0069] In summary, the solution implemented in this embodiment of the invention can solve the problems of inconsistent deployment processes, lack of security and compliance verification, difficulty in synchronizing the states of multiple clusters, and lack of data support for delivery efficiency in the existing containerized application deployment process.

[0070] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention. Software tools or components not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0071] In one embodiment, an apparatus for generating a containerized application orchestration engine is provided, which corresponds one-to-one with the containerized application orchestration engine generation method in the above embodiments. For example... Figure 8 As shown, the generation device of this containerized application orchestration engine includes a model creation module 810, an execution module 820, a synchronization module 830, and a generation module 840. Detailed descriptions of each functional module are as follows: The model creation module 810 is used to create a declarative application model, which describes the overall configuration and deployment requirements of the containerized application. The execution module 820 is used to trigger and execute an automated pipeline from code building to environment deployment through a unified orchestration engine based on the application model, wherein a security policy is integrated into the automated pipeline to automatically perform security checks and compliance verifications. The synchronization module 830 is used to respond to changes in the Git repository and synchronize the application model to multiple target computing clusters based on GitOps principles. The generation module 840 is used to collect the execution data of the automated pipeline and the runtime indicators of the production environment, and associate the execution data of the automated pipeline to generate delivery performance metrics and release decision support.

[0072] In one embodiment, the model creation module 810 is specifically used for: Parse the application definition file to extract the code repository address, build parameters, and container image configuration; Read the deployment strategy description, including the number of replicas, resource limits, and service exposure methods; Generate versioned application model instances, and associate them with code commit records and build artifacts; Verify the completeness and compliance of the application model, and output a standardized application description object.

[0073] In one embodiment, the execution module 820 is specifically used for: Analyze the task dependencies in the application model and construct a task execution topology graph; Schedule a sequence of tasks including code compilation, image building, security scanning, and deployment testing; Monitor the task execution status and trigger a retry or rollback mechanism when a task fails; Coordinate the workload of multiple execution nodes to ensure efficient task execution.

[0074] In one embodiment, the execution module 820 is further configured to: Integrate static application security testing during the code build phase to detect code security vulnerabilities; Trigger a container vulnerability scan after image building to verify image security; Perform infrastructure compliance checks before deployment to ensure the environment complies with security policies; Configure an automatic blocking mechanism for security policy violations to prevent insecure deployments.

[0075] In one embodiment, the synchronization module 830 is specifically used for: Listen for change events of application model files in the Git repository; Compare the current state of the cluster with the target state of the Git repository; Generate synchronization operation instructions to deploy application changes to the target cluster; Verify the deployment results to ensure that the cluster state is consistent with the Git definition.

[0076] In one embodiment, the generation module 840 is specifically used for: Collect data on build time, test pass rate, and deployment success rate of the automated pipeline from code building to environment deployment; Monitor the application performance metrics, error rate, and resource usage of the automated production line; Establish a data acquisition pipeline for the automated production line to uniformly store and process monitoring data; Correlate pipeline events with runtime metrics to build a full-chain tracing system.

[0077] In one embodiment, the generation module 840 is further configured to: Calculate deployment frequency, change failure rate, and average recovery time metrics; Analyze the trends in performance metrics during the release process; A release decision-making model is trained based on historical data to predict release risks; Generate and publish a health report to provide optimization suggestions for subsequent releases.

[0078] This invention provides a solution for a containerized application orchestration engine generation device. It creates a declarative application model to uniformly describe the overall configuration and deployment requirements of containerized applications. Based on this model, a unified orchestration engine triggers and executes an automated pipeline from code building to environment deployment. Security policies are integrated to automatically perform security checks and compliance verifications. Furthermore, it responds to Git repository change events and automatically synchronizes the application model to multiple target computing clusters based on GitOps principles. Simultaneously, it collects pipeline execution data and production environment runtime metrics, correlates them to generate delivery performance metrics and release decision support, achieving full-process automation, standardization, and observability of containerized application deployment. This solution systematically solves the problems of inconsistency and inefficiency caused by excessive manual intervention and scattered scripts in traditional deployment processes. Through built-in security and compliance checks and automatic blocking mechanisms, it effectively prevents vulnerabilities and configuration risks from spreading to the production environment. By leveraging GitOps to achieve reliable and auditable automatic synchronization of states across multiple clusters, it significantly improves release reliability. Finally, relying on full-link data correlation analysis, it provides quantitative evidence for R&D efficiency improvement and release decisions, fully supporting the agile, secure, and efficient delivery of enterprise-level applications.

[0079] Furthermore, the core reason for the weak security protection in the deployment process of related technologies is the lag in security checks, their disconnect from the deployment process, and their reliance on manual triggering. This solution, however, integrates security policies into an automated pipeline, performs static application security testing during the code building phase, triggers container vulnerability scanning after image building, and executes infrastructure compliance checks before deployment. It also configures an automatic blocking mechanism for security policy violations. This shift-left security and automated verification design transforms discrete, passive manual security reviews into a proactive, continuous protection system throughout the CI / CD process, fundamentally preventing insecure code, images, or configurations from entering the production environment. In highly regulated industries such as finance and healthcare, this mechanism ensures that application deployments continuously comply with industry security standards and compliance requirements, significantly reducing business risks and audit failure probabilities caused by non-compliant deployment content.

[0080] Furthermore, the core issue hindering multi-cluster application state management and addressing delivery performance bottlenecks in related technologies lies in the lack of a unified control plane that uses a declarative model as a single trusted source and connects development and runtime data. This solution explicitly uses a declarative application model as a benchmark, monitoring Git repository changes and driving automatic synchronization of multi-cluster states based on GitOps principles. This ensures that the actual cluster state always aligns with the version-defined expected state, enabling reliable reproducibility of the deployment process and version rollback. Simultaneously, by collecting and analyzing end-to-end data from build to runtime, it quantifies and calculates key DevOps metrics such as deployment frequency, change failure rate, and average recovery time. This data is then used to train a release decision model and generate release health reports, enabling teams to accurately pinpoint bottlenecks, predict release risks, and continuously optimize processes. This dual mechanism of automated GitOps synchronization and data-driven decision-making not only solves the application state drift problem in multi-cluster environments but also fills the performance measurement gap between deployment activities and business value delivery, providing organizations with a practical and feasible technical path to improve R&D and operational efficiency.

[0081] In summary, the solution implemented by the above-mentioned containerized application orchestration engine generation method can solve the problems of inconsistent deployment processes, lack of security and compliance verification, difficulty in synchronizing the states of multiple clusters, and lack of data support for delivery efficiency in the existing containerized application deployment process.

[0082] Specific limitations regarding the generation apparatus for the containerized application orchestration engine can be found in the limitations on the generation method of the containerized application orchestration engine described above, and will not be repeated here. Each module in the aforementioned generation apparatus for the containerized application orchestration engine can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0083] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements a recommended method for an optimal strategy, representing the functions or steps on the server side.

[0084] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 10 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements a recommended method for an optimal strategy, representing client-side functions or steps.

[0085] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Create a declarative application model that describes the overall configuration and deployment requirements of the containerized application; Based on the application model, an automated pipeline from code building to environment deployment is triggered and executed through a unified orchestration engine. Security policies are integrated into the automated pipeline to automatically perform security checks and compliance verifications. In response to changes in the Git repository, the application model is synchronized to multiple target computing clusters based on GitOps principles; Collect execution data from the automated production line and runtime metrics in the production environment, and correlate the execution data from the automated production line to generate delivery performance metrics and release decision support.

[0086] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Create a declarative application model that describes the overall configuration and deployment requirements of the containerized application; Based on the application model, an automated pipeline from code building to environment deployment is triggered and executed through a unified orchestration engine. Security policies are integrated into the automated pipeline to automatically perform security checks and compliance verifications. In response to changes in the Git repository, the application model is synchronized to multiple target computing clusters based on GitOps principles; Collect execution data from the automated production line and runtime metrics in the production environment, and correlate the execution data from the automated production line to generate delivery performance metrics and release decision support.

[0087] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0088] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0090] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for generating a containerized application orchestration engine, characterized in that, include: Create a declarative application model that describes the overall configuration and deployment requirements of the containerized application; Based on the application model, an automated pipeline from code building to environment deployment is triggered and executed through a unified orchestration engine. Security policies are integrated into the automated pipeline to automatically perform security checks and compliance verifications. In response to changes in the Git repository, the application model is synchronized to multiple target computing clusters based on GitOps principles; Collect execution data from the automated production line and runtime metrics in the production environment, and correlate the execution data from the automated production line to generate delivery performance metrics and release decision support.

2. The method for generating a containerized application orchestration engine according to claim 1, characterized in that, The creation of a declarative application model includes: Parse the application definition file to extract the code repository address, build parameters, and container image configuration; Read the deployment strategy description, including the number of replicas, resource limits, and service exposure methods; Generate versioned application model instances, and associate them with code commit records and build artifacts; Verify the completeness and compliance of the application model, and output a standardized application description object.

3. The method for generating a containerized application orchestration engine according to claim 1, characterized in that, The automated pipeline, triggered and executed by a unified orchestration engine based on the application model, from code building to environment deployment, includes: Analyze the task dependencies in the application model and construct a task execution topology graph; Schedule a sequence of tasks including code compilation, image building, security scanning, and deployment testing; Monitor the task execution status and trigger a retry or rollback mechanism when a task fails; Coordinate the workload of multiple execution nodes to ensure efficient task execution.

4. The method for generating a containerized application orchestration engine according to claim 1, characterized in that, The integration of security policies into the automated pipeline to automatically perform security checks and compliance verifications includes: Integrate static application security testing during the code build phase to detect code security vulnerabilities; Trigger a container vulnerability scan after image building to verify image security; Perform infrastructure compliance checks before deployment to ensure the environment complies with security policies; Configure an automatic blocking mechanism for security policy violations to prevent insecure deployments.

5. The method for generating a containerized application orchestration engine according to claim 1, characterized in that, The response to Git repository change events, based on GitOps principles, synchronizes the application model to multiple target computing clusters, including: Listen for change events of application model files in the Git repository; Compare the current state of the cluster with the target state of the Git repository; Generate synchronization operation instructions to deploy application changes to the target cluster; Verify the deployment results to ensure that the cluster state is consistent with the Git definition.

6. The method for generating a containerized application orchestration engine according to claim 1, characterized in that, The collection of execution data and production environment runtime metrics from the automated production line includes: Collect data on build time, test pass rate, and deployment success rate of the automated pipeline from code building to environment deployment; Monitor the application performance metrics, error rate, and resource usage of the automated production line; Establish a data acquisition pipeline for the automated production line to uniformly store and process monitoring data; Correlate pipeline events with runtime metrics to build a full-chain tracing system.

7. The method for generating a containerized application orchestration engine according to claim 1, characterized in that, The generation of delivery performance metrics and release decision support based on the execution data associated with the automated pipeline includes: Calculate deployment frequency, change failure rate, and average recovery time metrics; Analyze the trends in performance metrics during the release process; A release decision-making model is trained based on historical data to predict release risks; Generate and publish a health report to provide optimization suggestions for subsequent releases.

8. An apparatus for generating a containerized application orchestration engine, characterized in that, include: The model creation module is used to create declarative application models, which describe the overall configuration and deployment requirements of containerized applications. An execution module is used to trigger and execute an automated pipeline from code building to environment deployment based on the application model through a unified orchestration engine, wherein security policies are integrated into the automated pipeline to automatically perform security checks and compliance verifications. The synchronization module is used to respond to changes in the Git repository and synchronize the application model to multiple target computing clusters based on GitOps principles. The generation module is used to collect the execution data of the automated pipeline and the runtime indicators of the production environment, and associate the execution data of the automated pipeline to generate delivery performance metrics and release decision support.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method for generating a containerized application orchestration engine as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for generating a containerized application orchestration engine as described in any one of claims 1 to 7.

Images