A method and system for containerized application orchestration with dual-mode delivery

Abstract

The application relates to the field of cloud computing, and provides a dual-mode delivery containerized application arrangement method and system. The method comprises the following steps: defining a description file based on a unified application description model and a single declarative specification definition topology structure, deepening and combining original configuration parameters to obtain arrangement configuration parameters after the configuration parameters are configured to a basic layer, an environment layer and a delivery mode layer of a containerized application according to the priority of each layer, converting description data structure and arrangement configuration parameters according to a target delivery mode, executing a public product generation path for generating a public product and a private product generation path for generating a private offline package product in parallel in the same construction, and encapsulating a monitoring component stack corresponding to the target delivery mode for observation after version consistency verification is passed by performing service corresponding image summarization. The application declares the configuration difference of the two delivery modes in the same description file, ensures that the configurations of the two delivery modes are always derived from the same input source, and eliminates the problem of dual-mode configuration fragmentation.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and in particular to a dual-mode delivery method and system for containerized application orchestration. Background Technology

[0002] With the rapid development of cloud computing and container technologies, the delivery models for containerized applications are becoming increasingly diversified. In the actual operation of enterprise-level software products, the same containerized application often needs to support both public cloud deployment and private on-premises deployment. Public cloud deployment, such as SaaS cloud deployment, is typically based on the Kubernetes (K8s) container orchestration platform for parameterized deployment management; private on-premises deployment is based on Docker (a container engine) container orchestration tools, deployed in an integrated solution in the customer's local environment.

[0003] The deployment of these two delivery modes is maintained by two independent file systems, which lack a structured association and synchronization mechanism. There are fundamental differences in orchestration engine, configuration management, deployment process and operation and maintenance monitoring, which leads to configuration drift, version inconsistency and verification difficulties in containerized applications. The deployment settings of the two delivery modes are set up with independent pipelines, resulting in pipeline duplication and fragmentation. The application stack encapsulation of the two delivery modes is inconsistent, and the application stack encapsulation of the private delivery is chaotic. Summary of the Invention

[0004] This application provides a dual-mode delivery method and system for containerized application orchestration, which solves the problems in the prior art where public and private delivery modes are described independently, lacking correlation in orchestration engine, configuration management, deployment process and operation and maintenance monitoring, causing configuration drift, version inconsistency and verification difficulties during containerized application.

[0005] The first aspect of this application provides a dual-mode delivery method for containerized application orchestration, the method comprising: Based on the unified application description model, a description file is generated by defining the topology structure using a single declarative specification. The description file uses conditional fields to mark the configuration information of the target delivery mode, which includes public delivery mode and private delivery mode. The original configuration parameters are read from the description file, and the base layer, environment layer and delivery mode layer of the containerized application are configured according to the priority of each layer. Then, a hierarchical deep merge is performed to obtain the orchestration configuration parameters. Based on the target delivery mode, the conditional fields in the description file are filtered to obtain the description data structure. In the public delivery mode, the description data structure and the orchestration configuration parameters are converted into a directory structure that generates a directory and environment overlay files. In the private delivery mode, the description data structure and the orchestration configuration parameters are converted into an orchestration file, an environment variable file, and a reverse proxy configuration file. A continuous integration and continuous delivery pipeline is built to perform code checkout, image building, parallel generation of dual-mode artifacts, version consistency verification, and artifact release. In the same build, the public artifact generation path and the private artifact generation path are executed in parallel. When the version consistency verification of the image digest corresponding to each service in the public artifact and the private offline package artifact passes, the public artifact and the private offline package artifact are released. Otherwise, the build is aborted and an error report is generated. Encapsulate the public product and the private offline package product; Based on a unified structured log format, a naming convention-based indicator system, and alarm rule definitions, the monitoring component stack corresponding to the target delivery mode is observed.

[0006] Optionally, a description file is generated based on the input source of the unified application description model, which defines the topology and dual-mode orchestration using a single declarative specification. The description file is then updated by annotating the configuration information of the target delivery mode using conditional fields, including: The service definition list, network policy definition, and configuration layer reference of the containerized application are written in YAML specification to generate the description file. The service definition list includes service components, dependencies, resource requirements, configuration parameters, health check policies, and storage volume declarations. The network policy definition includes ingress traffic rules for external traffic to the application service and inter-service communication rules for network access permissions between services within the application. The configuration layer reference includes configuration files pointing to the base layer, configuration files mapping each deployment environment to the environment layer, and configuration files mapping each delivery mode to the corresponding delivery mode layer. A conditional field is introduced to annotate the configuration information of the target delivery mode in the same description file to update the description file; when the configuration information is effective in both public and private delivery modes, the field value of the conditional field is all; when the configuration information is effective only in public delivery mode, the field value of the conditional field is saas; and when the configuration information is effective only in private delivery mode, the field value of the conditional field is privatized. The four-level verification process, consisting of data structure verification, dependency verification, resource constraint verification, and conditional field verification, is executed sequentially.

[0007] Optionally, the step involves reading the original configuration parameters from the description file, configuring the base layer, environment layer, and delivery mode layer of the containerized application according to the priority of each layer, and performing hierarchical deep merging to obtain orchestration configuration parameters, including: Configure the base layer according to the service image tags, default resource quotas, default environment variables, default number of replicas, and default health check parameters of each service in the description file. Configure the environment layer according to the database, external service address, log level, number of replicas and resource quota corresponding to each environment in the description file; Configure the delivery mode layer according to the configuration information corresponding to the public delivery mode and the configuration information corresponding to the private delivery mode in the description file; Based on the merging strategy corresponding to the data types, a hierarchical deep merging algorithm is executed on the base layer, the environment layer, and the delivery mode layer in order of low priority to high priority to obtain the final configuration parameters. The merging formula in the deep merging algorithm is: , Among them, base_config is the configuration parameter for the base layer, env_config is the configuration parameter for the environment layer, mode_config is the configuration parameter for the delivery mode layer, and final config is the final configuration parameter.

[0008] Optionally, the merging strategy includes: When the data type is a scalar value, the higher priority value overrides the lower priority value; When the data type is a list value, use a higher priority list instead of a lower priority list; When the data type is a dictionary value, iterate through all keys in the high-priority dictionary. If the key does not exist in the low-priority dictionary, add the key to the high-priority dictionary. If the key exists in the low-priority dictionary and the dictionary types are the same, perform a recursive deep merge. If the key exists in the low-priority dictionary and the dictionary types are different, handle the conflict resolution strategy. Optionally, the conflict resolution strategy includes: when the value types of the same configuration key are inconsistent in the high-priority layer and the low-priority layer, overwriting the value of the low-priority layer with the value of the high-priority layer; when the same configuration key is an empty string in the high-priority layer, using the empty string as the result of the merging strategy; when the same configuration key is a special marker in the high-priority layer, deleting the key in the result of the merging strategy. Optionally, the conflict resolution strategy further includes: generating a merge audit log when the configuration key is overridden, added, or set to null. The merge audit log includes the conflicting key path, the value and type of the key at the low priority level, the value and type of the key at the high priority level, the value and type of the key in the result of the merge strategy, and field operation identifiers, including overridden, added, conflict_resolved, deleted, and unchanged.

[0009] Optionally, a description data structure is obtained by filtering the conditional fields in the description file according to the target delivery mode, including: S311, Traverse the data structure of the description file to obtain the current field; S312, determine whether the current field contains the when_mode annotation. If it exists, execute S313. Otherwise, retain the current field value and treat the when_mode annotation of the field value as all. S313, determine if the character after when_mode is all or corresponds to the target delivery mode. If so, retain the current field value and execute step S314. Otherwise, filter the current field value and execute S316. S314. Determine whether the current field satisfies value-level conditionalization. If yes, extract the value corresponding to the target delivery mode to replace the conditionalization structure and execute step S315. Otherwise, execute step S316. S315, Determine if the character after when_mode in the target delivery mode is declared. If yes, output the field value of the target delivery mode and execute S316. If no, output the default value and execute S316. S316, process the next field, until all fields corresponding to the description file have been processed, and finally output the filtered description data structure.

[0010] Optionally, in public delivery mode, the description data structure and orchestration configuration parameters are converted into a directory structure that generates directories and environment overlay files, including: The values.yaml generation process includes extracting global-level configurable parameters from the data structure description and orchestration configuration parameters as global parameters; iterating through the spec.services list describing the data structure; extracting and generating corresponding parameter blocks for each service definition according to the rules of image parameterization, replica number parameterization, resource quota parameterization, environment variable parameterization, health check parameterization, and storage volume parameterization; comparing the environment layer configuration parameters with the default values.yaml key by key, and only writing the key-value pairs that differ to the environment overwrite file. Template rendering involves converting service definitions in the data structure into parameterized Kubernetes resource template files. Kubernetes resource templates include Deployment templates, Service templates, ConfigMap templates, Ingress templates, and helper function templates. Chart structure assembly includes generating a Chart.yaml metadata file, assembling the directory structure, standardizing template file naming, and outputting the directory structure when the chart integrity check passes; otherwise, generating a structured error report and aborting the conversion.

[0011] Optionally, in private delivery mode, the description data structure and the orchestration configuration parameters are converted into orchestration files, environment variable files, and reverse proxy configuration files, including: The docker-compose.yml orchestration file is generated using the docker-compose.yml generation algorithm; The .env environment variable file is generated using an environment variable mapping algorithm; The Nginx reverse proxy configuration file is generated using a network configuration algorithm; Perform a compose file validation. If the validation passes, output the docker-compose.yml orchestration file, the .env environment variable file, and the Nginx reverse proxy configuration file. Otherwise, generate a structured error report and abort the conversion.

[0012] Optionally, the code detection includes: According to the checkout strategy corresponding to the triggering method, the application code is checked out from the Git repository, the version number is extracted from the application code, the build metadata is generated after the version number is determined, and the build metadata is written to the build file build-metadata.json in the workspace in JSON format; The triggering methods include tag triggering, branch triggering, and manual triggering. The version number is extracted from the Git tag name in the application code, or the version number is calculated based on the branch name and the most recent Git tag.

[0013] Optionally, the image building includes: The base path and build context corresponding to the service definition are read from the description file. A container image is compiled and generated based on the build context and base path corresponding to each service definition. An image tag for the container image is generated by short hash encoding according to the version number of each service definition and the build metadata. The container image is pushed to the image repository. An image digest is obtained by calculating the hash value based on the image content of the container image. The image digest is recorded in the build file.

[0014] Optionally, the parallel generation of the dual-mode products includes: Based on the container image and the image digest, the public artifact generation path and the private artifact generation path are executed in parallel during the same build. In the public artifact generation path corresponding to the public delivery mode, the image reference in the directory structure is updated according to the image tag and image summary, the updated directory structure is packaged to obtain the public artifact, the public artifact is pushed to the public repository, and the repository address and version information of the public repository are updated to the build file. In the private artifact generation path corresponding to the private delivery mode, the locally exported container image is compressed to obtain an image package, and the orchestration file, the environment variable file, the reverse proxy configuration file, the image package deployment script, and the database migration script are assembled into a private offline package artifact.

[0015] Optionally, the version consistency check includes: A public image reference mapping table is constructed based on the image repository address, image tag, and image digest of each service extracted from the public artifacts. A private image reference mapping table is constructed based on the field values ​​of each service extracted from the private offline package artifacts and the image digest in the construction metadata. The image digest belongs to the binary content corresponding to the container image of the service, and the image digest is a SHA256 hash value calculated based on the image content. A verification result is generated by comparing the public mirror reference mapping table with the private mirror reference mapping table for each service. The verification result includes the service name, public side mirror reference information and mirror digest, private side mirror reference information and mirror digest information, and the type of mirror inconsistency. When the verification result indicates that the verification is successful, a JSON-formatted error report is generated. The version list includes the build version number, build number, build timestamp, image repository address, image name for each service, image tag for each service, image summary for each service, public artifacts, private offline package artifacts, and verification result. When the verification result indicates failure, the construction of the continuous integration and continuous delivery pipeline is stopped, intermediate artifacts are exported, a structured error report is generated, and the error report is sent to the client corresponding to the service when all service comparisons are completed. The error report includes a list of inconsistent services and a summary of the corresponding service image.

[0016] Optionally, the private offline package artifact is encapsulated, including: The application service component, reverse proxy component, database component, monitoring panel component, and log collection component are integrated and packaged into a single offline deployment package; Export the container images of all services from the build environment as archive files to generate offline image packages; During the initial deployment, an offline deployment initialization is performed, which includes verifying the integrity of the installation package, loading the image, generating the configuration, starting the service in the order of dependencies, performing a health check, and outputting a deployment result report. When a version upgrade command exists in the private offline package artifact, the corresponding incremental image update, configuration migration, database migration, and service rollback and restart are executed. When a component in the private offline package fails to start, a corresponding retry strategy is used to diagnose the fault based on the health status of the dependent components.

[0017] Optionally, the monitoring component stack corresponding to the observation target delivery mode includes: In the public delivery mode, metrics are monitored through Prometheus monitoring and Grafana visualization panel, link tracing is performed through observable analytics backend and application probes, logs are collected through the lightweight log collector of the daemon set and Loki, and logs are queried through Grafana visualization panel and Loki logging system, realizing a full-stack monitoring solution for Kubernetes environment to observe resource objects. In private delivery mode, metrics are monitored through in-application metric endpoints and the Grafana visualization panel, trace links are performed by associating trace_id in application logs, logs are collected through a lightweight log collector and local file storage, and logs are queried through the Grafana visualization panel and local log file browsing component, thus realizing a lightweight solution for observing resource objects in the Docker Compose environment.

[0018] A second aspect of this application provides a dual-mode delivery containerized application orchestration system, the system comprising: The description module, located in the description layer, is used to define the topology and input sources of the dual-mode orchestration engine based on a unified application description model using a single declarative specification. It generates description files by annotating the configuration information of the target delivery mode through conditional fields. The configuration layering module, located in the transformation layer, is used to read the original configuration parameters according to the description file, configure the base layer, environment layer and delivery mode layer according to the priority of each layer, perform hierarchical deep merging, and generate orchestration configuration parameters. A dual-mode orchestration engine, located in the transformation layer, is used to filter the conditional fields in the description file according to the target delivery mode to obtain the description data structure. In public mode, the description data structure and the orchestration configuration parameters are converted into a directory structure that generates a directory and environment overlay files. In private delivery mode, the description data structure and the orchestration configuration parameters are converted into an orchestration file, an environment variable file, and a reverse proxy configuration file. The dual-mode build pipeline, located in the build layer, is used to build a unified continuous integration and continuous delivery pipeline. It sequentially executes code checkout, image building, parallel generation of dual-mode artifacts, version consistency verification, and artifact release. In the same build, it executes the public artifact generation path that generates public artifacts and the private artifact generation path that generates private offline package artifacts in parallel. The version consistency checker, which belongs to the dual-mode build pipeline, is used to publish the public product and the private offline package product when the version consistency check of the image digest corresponding to each service in the public product and the private offline package product passes; otherwise, the build is stopped and an error report is generated. A wrapper, located in the encapsulation layer, is used to encapsulate the public product and the private offline package product; The unified observable adapter, located in the observation layer, is used to monitor the stack of components corresponding to the observation target delivery mode, based on a unified structured log format, naming conventions, indicator system, and alarm rule definition.

[0019] This application includes at least one of the following beneficial technical effects: 1. Based on a unified application description model, the complete topology of the application is defined by a single declarative YAML specification. Through a conditional field annotation mechanism, the configuration differences between the two delivery modes are declared in the same description file, avoiding configuration drift, version inconsistency and verification difficulties caused by two independent descriptions, and strengthening the structured association and synchronization mechanism.

[0020] 2. A four-level validation process, consisting of data structure verification, dependency verification, resource constraint verification, and conditional field verification, automatically converts the description file into both Kubernetes Helm Chart and Docker Compose orchestration configurations by the dual-mode orchestration engine after passing the four-level validation. This ensures that the configurations for both delivery modes always derive from the same input source. This application fundamentally eliminates the problems of dual-mode configuration fragmentation and configuration drift, reducing configuration maintenance workload by approximately 50%, and ensuring configuration consistency across delivery modes through a unified validation mechanism. This differs from existing technologies that maintain independent orchestration configurations for the two delivery modes.

[0021] 3. Based on the description file and original configuration parameters, a three-layer configuration model of base layer, environment layer, and delivery mode layer is configured. Deep merging is performed according to the priority rule of delivery mode layer > environment layer > base layer, achieving structured layered management of configuration. Differentiated merging strategies are adopted for scalar values, list values, and dictionary values, and audit logs are generated during the merging process to record each overridden key and its source layer. This allows for centralized maintenance of common configurations and on-demand overriding of differential configurations, significantly reducing the complexity of configuration management in multi-environment, multi-mode scenarios. This differs from existing technologies where configuration parameters lack structured management between two delivery modes.

[0022] 4. A dual-mode pipeline for continuous integration and continuous delivery was constructed. From the same codebase and the same build, through code checkout, image building, parallel generation of dual-mode artifacts, version consistency verification, and artifact release, public artifacts (such as Helm Chart artifacts) and private offline package artifacts (such as Docker Compose offline package artifacts) are produced simultaneously. During the image building phase, the SHA256 hash value of each service image is recorded as an image digest. The version consistency between the public artifact and the private offline package artifact is determined by the image digest corresponding to each service. If they are consistent, they are released; otherwise, the dual-mode pipeline is aborted. This application establishes a complete traceability link from code submission to dual-mode artifacts, ensuring binary consistency of dual-mode artifacts from the build source, eliminating the risk of version inconsistency caused by independent build pipelines, and achieving full-link version traceability. This differs from existing technologies that maintain two independent build pipelines for two delivery modes.

[0023] 5. Supports standardized automatic packaging of private offline package artifacts. The application service, Nginx reverse proxy component, PostgreSQL database component, Grafana monitoring panel component, and Fluent-bit log collection component are packaged into a single offline deployment package. A dependency-aware service startup orchestration mechanism is introduced into the offline deployment process (e.g., starting the service database component → application service → reverse proxy component → monitoring panel component in dependency topology order). Downstream services are started only after health checks confirm the readiness of dependent components. All service container images are exported from the build environment to obtain offline image packages, supporting standardized upgrade mechanisms for incremental image updates, configuration migration, database migration, and service rollback. When a component fails to start, a corresponding retry strategy is used for fault diagnosis based on the health status of dependent components—if a dependency is not ready, it waits and retryes (maximum 300 seconds); if the component itself fails, it exponentially backs off retrying (maximum 3 times). After all retry failures, a diagnostic report containing the failed component, dependency status, and log summary is generated. This application transforms private delivery from customized development to a standardized process, significantly reducing delivery cycle and implementation costs, and improving the reliability of offline deployment through a dependency-aware intelligent deployment mechanism. Unlike existing technologies where proprietary encapsulation relies on extensive custom development.

[0024] 6. Based on a unified JSON structured log format and a unified metric naming system conforming to Prometheus naming conventions, logs and metrics in both environments have the same data structure. Semantic equivalence of alarm triggering conditions is achieved through unified YAML-formatted alarm rule definitions. Consistency in observability capabilities between public and private offline package artifacts is ensured through unified data formats and alarm rules. A full-stack solution of Grafana + SkyWalking + Fluent-bit + Loki is adopted in the Kubernetes environment, while a lightweight solution of Grafana + Fluent-bit + application-built-in metric endpoints is used in the Docker Compose environment. This application addresses the lack of observability capabilities in private delivery scenarios, enabling operations teams to monitor and troubleshoot applications under both delivery modes in a unified manner, significantly improving operational efficiency and service quality in private environments. This differs from existing technologies that suffer from a severe lack of observability capabilities in private environments. Attached Figure Description

[0025] Figure 1 This is a flowchart of a dual-mode delivery containerized application orchestration method provided in the first embodiment of this application; Figure 2 yes Figure 1 Flowchart for step 10; Figure 3 yes Figure 1 Flowchart for step 20; Figure 4 yes Figure 1 Flowchart for step 30; Figure 5 yes Figure 4 Flowchart for step 31; Figure 6 yes Figure 4 Flowchart for step 32; Figure 7 yes Figure 4 Flowchart for step 33; Figure 8 yes Figure 1 Flowchart for step 40; Figure 9 yes Figure 8 Flowchart for step 42; Figure 10 yes Figure 8 Flowchart for step 43 in the public delivery mode; Figure 11 yes Figure 8 Flowchart of step 43 in the private delivery mode; Figure 12 yes Figure 8 Flowchart for step 44; Figure 13 yes Figure 8 Flowchart for step 45; Figure 14 yes Figure 1 The flowchart for encapsulating the private offline package in step 50; Figure 15 This is a schematic diagram of a containerized application orchestration system for dual-mode delivery provided in the second embodiment of this application.

[0026] Explanation of reference numerals in the attached figures: 70. Containerized Application Orchestration System; 71. Description Module; 72. Configuration Layering Module; 721. Base Layer; 722. Environment Layer; 723. Delivery Mode Layer; 73. Dual-Mode Orchestration Engine; 74. Dual-Mode Build Pipeline; 741. Code Checkout Unit; 742. Image Build Unit; 743. Public Product Generation Unit; 744. Private Product Generation Unit; 745. Version Consistency Verifier; 746. Release Unit; 75. Wrapper; 76. Unified Observable Adapter. Detailed Implementation

[0027] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the scope of the application.

[0028] In the following description, numerous specific details are set forth for illustrative purposes in order to provide a thorough understanding of the inventive concept. As part of this specification, some of the accompanying drawings of this disclosure are block diagrams illustrating structures and devices to avoid complicating the disclosed principles. For clarity, not all features of the actual embodiment need to be described. Unless expressly defined, the terms “a,” “an,” and “the” are not intended to refer to a singular entity, but rather to include general categories whose specific examples may be used for illustration. Thus, the use of the terms “a” or “an” can mean any number of at least one, including “a,” “one or more,” “at least one,” and “one or more.” The term “or” means any of the options and any combination of the options, including all options unless the options are expressly indicated to be mutually exclusive. The phrase “at least one of” when combined with a list of items refers to a single item in the list or any combination of items in the list. The phrase does not require all of the listed items unless expressly defined as such.

[0029] The first embodiment of this application provides a containerized application orchestration method with dual-mode delivery. By standardizing the complete topology structure and input source of dual-mode orchestration through a unified application description model, it declares the configuration differences between public and private delivery modes, avoids configuration drift, version inconsistency and verification difficulties caused by two independent descriptions, and strengthens the structured association and synchronization mechanism.

[0030] A dual-mode delivery method for containerized application orchestration, referenced Figure 1 As shown, it includes: Step 10: Based on the unified application description model, a description file is generated by defining the topology structure using a single declarative specification. The description file uses conditional fields to annotate the configuration information of the target delivery mode.

[0031] Specifically, the target delivery modes include public delivery mode and private delivery mode. The topology of the containerized application, written using the Unified Application Descriptor (UAD) specification, declares the configuration differences between public and private delivery modes through conditional field annotations in the same description file.

[0032] In one example, the implementation of step 10 is referenced. Figure 2 As shown, it includes: Step 11: Write the service definition list, network policy definition, and configuration layer references for the containerized application using the YAML specification, and generate the description file.

[0033] The Unified Application Description Model (UAD) is defined in YAML format and uses a declarative data structure to describe the complete topology of a containerized application. The top-level structure of the UAD includes API version and type declarations, application metadata, and application specification definitions. The specific top-level structure of the UAD is as follows: API version and type declarations include the version number apiVersion and the version type kind. Application metadata includes basic application identification information metadata, a unique application name identifier (also known as application name identifier) ​​name in the entire orchestration system, a semantic version number using semantic versioning specifications version, and application description information description. Application specification definitions are reflected in the spec section. Application specification definitions include a list of service definitions services, network policy definitions networks, and configuration layer references config_layers. Configuration layer references include configuration files pointing to the base layer 721 (also known as the base layer configuration file path) base, configuration files mapping each deployment environment to the environment layer 722 (also known as the environment layer configuration file mapping) environments, and configuration files mapping each delivery mode to the corresponding delivery mode layer 723 (also known as the delivery mode layer configuration file mapping) modes.

[0034] The service definition list describes complete information about each individual service in the containerized reference. The service definition list includes service composition, dependencies, resource requirements, configuration parameters, health check policies, and storage volume declarations.

[0035] The service consists of a base identifier (name), an image reference (image), a shared replica count configuration (default) for dual delivery modes, and a replica count configuration (when_mode) for single delivery modes. The `name` field of the base identifier serves as a unique identifier for the service within the containerized application; the `image` field of the image reference specifies the container image used by the service, employing a complete image reference format to ensure clarity and traceability of the image source; the `default` field of the shared replica count configuration for dual delivery modes defines the default number of replicas shared by all delivery modes; the `when_mode` field of the single delivery mode replica count configuration allows for differentiated replica counts for different delivery modes. For example, "when_mode:saas:3" indicates that a web service in SaaS mode requires 3 replicas to support high concurrency access, while "when_mode:privatized:1" indicates that a privately-hosted web service requires 1 replica to meet the load requirements of a single-client scenario. If the target mode is not declared in `when_mode`, the `default` value is used as the replica count for that target mode.

[0036] Dependencies define the startup order and readiness conditions between services. The `service` field references another service name defined in the UAD, and the `condition` field specifies the state the dependent service needs to reach. The value of the `condition` field is either `healthy` or `started`. `healthy` means the dependent service must pass a health check before starting the current service, while `started` means the dependent service can start immediately (without waiting for a health check). For example: Resource requirements include the CPU and memory resource quotas, the requested values ​​(minimum reserved resources) `requests`, and the memory limits (maximum usable resources) `limits`. The requested values ​​represent the minimum resources the scheduler reserves for this service, and the limits represent the maximum resources the service can use. The format of resource requirements follows the Kubernetes resource representation specification. In the UAD verification process, resource constraint verification will check that the requested values ​​do not exceed the limits, ensuring the logical correctness of the resource configuration. An example of how resource requirements are represented is as follows: Configuration parameters include port mappings for two transport protocols and environment variables that support conditional field annotations. Port mappings define the network port configuration for the service. Each port mapping contains four attributes: port name, container_port (internal container port), service_port (external service port), and transport protocol. Environment variables define the source of direct values ​​(value), external references (value_from), and conditional declarations (when_mode). The value field specifies the string value of the environment variable. The value_from field points to the configuration item in the ConfigMap or Secret via a reference path. The when_mode field indicates the delivery mode to which this environment variable applies. The when_mode field can take the values ​​SaaS (SaaS only), privateized (private only), or all (all modes, the default). Example of port mappings and environment variables: The health check strategy defines the liveness and readiness detection strategies for services, supporting probe types such as HTTP probes, TCP probes, and Exec probes. HTTP probes send HTTP GET requests to specified ports and paths, determining the service's health status based on the response status code. A response status code in the range of 200-399 indicates a healthy service; otherwise, it's considered unhealthy. TCP probes attempt to establish a TCP connection to a specified port, determining the service's health status based on the success of the connection. Exec probes execute specified commands within the container, determining the service's health status based on the command's exit code. An exit code of 0 indicates a healthy service; otherwise, it's unhealthy. Examples of health check strategies include: A storage volume declaration defines the persistent configuration required by the service, including the volume name identifier (name), the mount path (mount_path) within the container, the required storage capacity (size), and the storage class corresponding to the target delivery mode (storage_class). In SaaS mode, the storage class provided by the cloud storage service is typically used, such as efs-sc for AWS EFS; in private mode, a local storage path, such as local-path, is used. An example of a storage volume declaration is as follows: Step 12: Introduce conditional fields to annotate the configuration information of the target delivery mode in the same description file to update the description file.

[0037] The conditional field `when_mode` has a value of `all` when the configuration information is effective in both public and private delivery modes; a value of `saas` when the configuration information is effective only in public delivery mode; and a value of `privatized` when the configuration information is effective only in private delivery mode. The values ​​of the conditional field `when_mode` under each semantic are shown in the table below: This step introduces conditional field annotations that support three application modes: value-level conditionalization, existence-level conditionalization, and structure-level conditionalization. Value-level conditionalization means that the same field takes different values ​​in different delivery modes, such as the replica count scenario; existence-level conditionalization means that a configuration item exists only in a specific delivery mode, such as the environment variable scenario; structure-level conditionalization means that a subfield of a composite structure takes different values ​​in different delivery modes, such as the network configuration scenario.

[0038] Step 13 involves sequentially executing a four-level verification process consisting of data structure verification, dependency verification, resource constraint verification, and conditional field verification.

[0039] In the four-level verification process, the next level of verification can only proceed after the previous level of verification passes. If any level of verification fails, the verification process is terminated and a structured error report is generated.

[0040] Data structure validation, also known as schema validation, is used to verify whether the structure of a YAML file conforms to the UAD JSONSchema definition. Validation includes: validation of the existence of required fields, field type validation, version format validation, and enumeration value validation. For the validation of required fields, it verifies that the four required fields apiVersion, kind, metadata, and spec all exist; that the name and version fields in metadata exist and are not empty; and that the spec.services list contains at least one service definition. In the field type validation, the value type of each field is verified to be consistent with the JSON Schema definition. Specifically, `name` and `image` are string types, `replicas.default` is a positive integer type, `resources.requests.cpu` and `resources.limits.cpu` are strings conforming to the Kubernetes resource quantity format, `resources.requests.memory` and `resources.limits.memory` are strings conforming to the binary unit format, `ports[].container_port` and `ports[].service_port` are integers in the range of 1-65535, and `health_check.type` is an enumeration value. In the version format validation, the `apiVersion` field value is verified to be the currently supported version, and the `metadata.version` field value is verified to conform to the semantic versioning specification. During enumeration value validation, all enumeration type fields are verified to be within the allowed value range. Specifically, `health_check.type` only allows `http`, `tcp`, and `exec`; `ports[].protocol` only allows `TCP` and `UDP`; and `dependencies[].condition` only allows `healthy` and `started`. When data structure validation fails, the generated structured error report includes: error type, error location, expected description, and actual value. Error types include missing fields, type mismatch, format errors, and invalid enumeration values. The error location is a YAML path.

[0041] Dependency validation, after schema validation passes, verifies the correctness and completeness of service dependencies. Validation includes: dependency existence verification, circular dependency detection, and self-dependency verification. In dependency existence verification, the dependencies list in each service definition is traversed to verify that each referenced dependency service name has a corresponding service definition in the UAD's spec.services list. If it doesn't exist, the structured error report includes a "dependency service not defined" error, specifying the referrer's service name, the non-existent referenced service name, and the reference location. In circular dependency detection, all service dependencies are constructed as a directed graph, with each service as a node and each dependency as a directed edge. The directed edges point from the dependent to the dependent. A depth-first search algorithm is used to traverse the directed graph to detect cycles. If a cycle exists, the structured error report includes a "circular dependency" error, listing the complete service chain forming the cycle (e.g., A→B→C→A), ensuring that the dependencies form a directed acyclic graph, allowing subsequent dependency topology sorting and service startup order orchestration to execute correctly. In the self-dependency check, it checks whether there is a service that depends on itself. If so, the structured error report will include a "self-dependency" error, for example, the dependencies list will contain the name of the service itself.

[0042] Resource constraint validation verifies the logical correctness of resource configurations after dependency validation passes. Specific validation content includes: resource request and limit relationship validation, port conflict detection, and storage volume name uniqueness validation. In resource request and limit relationship validation, the resource quantity string in the `resources` field of each service definition is parsed into a uniform numerical unit for comparison, verifying that `requests.cpu ≤ limits.cpu` and `requests.memory ≤ limits.memory` are true. In port conflict detection, it checks for duplicate `container_port` or `service_port` under the same protocol within the same service, and for conflicts in `service_port` under the same protocol across services. This allows for early detection of port conflicts during the validation phase, preventing service startup failures or network traffic routing errors. In storage volume name uniqueness validation, it checks for duplicate volume names in the `volumes` list within the same service, and for conflicts in volume names across services. When multiple services reference volumes with the same name, their configurations must be consistent.

[0043] Conditional field validation verifies the correctness of the `when_mode` conditional annotation after resource constraint validation has passed. Specific validation content includes: `when_mode` value validity validation, conditional field type consistency validation, and conditional coverage integrity validation. In the `when_mode` value validity validation, it verifies that all `when_mode` fields must have only one of three values: `saas`, `privatized`, or `all`. Any other value is considered invalid, and the structured error report includes a "conditional annotation value invalid" error. In the conditional field type consistency validation, when the same field declares different values ​​using `when_mode` under different delivery modes, it verifies that the value type under each mode is consistent with the field's base type. This early detection during the validation phase avoids type inconsistencies that could lead to type errors during the conversion phase. In the conditional coverage integrity validation, when a field uses the `when_mode` conditional annotation but does not provide a default value, it verifies that the field provides a value for at least both `saas` and `privatized` modes, ensuring that the field has a definite value available under any delivery mode. If only one mode provides a value and there is no default value, the structured error report includes a "conditional coverage incomplete" warning.

[0044] Step 10 defines the complete topology of the containerized application using declarative YAML specifications. It unifies service definitions, dependencies, resource requirements, configuration parameters, health checks, and storage volume declarations into a single description file, eliminating the configuration fragmentation problem caused by independent maintenance of dual-mode configurations. When adding a service, modifying port mappings, adjusting resource quotas, or changing health check policies, only one modification is needed in the description file. The dual-mode orchestration engine 73 automatically synchronizes the changes to both Kubernetes and Docker Compose orchestration configurations, fundamentally eliminating the possibility of configuration fragmentation and configuration drift. Configuration drift refers to the situation where, under the dual-mode independent configuration management method, modifications to the two sets of configurations are typically completed by different personnel at different times. When one set is updated while the other is missed, the configurations of the two delivery modes gradually deviate. As the application iteration cycle progresses, this deviation accumulates, leading to unpredictable differences in application behavior under the two delivery modes.

[0045] Based on a unified configuration management system with a single declarative description, a conditional field `when_mode` is introduced to mark specific configuration differences between public and private delivery modes. This ensures that the configurations of the two delivery modes are derived from the same input source, achieving a management model of "unified declaration of common configurations and conditional annotation of different configurations". This avoids the synchronization complexity and consistency risks caused by maintaining two independent description files, while retaining precise control over the specific configurations of the delivery mode.

[0046] Before the description file enters the transformation process, a four-level verification process consisting of schema verification, dependency verification, resource constraint verification, and conditional field verification comprehensively verifies the structural correctness and semantic consistency of the description. This enables the detection of configuration errors during the verification phase, preventing erroneous configurations from flowing into the build and deployment stages and causing higher repair costs. Furthermore, the structured error report generated during the verification phase provides precise error locations and cause descriptions, assisting developers in quickly locating and correcting problems.

[0047] By defining standardized mapping rules from description files to Kubernetes resource objects and Docker Compose resource objects, it ensures that each service defined in the description file has a complete correspondence in the orchestration formats corresponding to both delivery modes, without omitting any service definitions, port mappings, resource quotas, health checks, or storage volume declarations. This standardization makes the transformation process predictable and auditable, eliminating configuration omissions and inconsistencies caused by human error when manually writing orchestration configurations.

[0048] Step 20: Read the original configuration parameters from the description file, configure the base layer, environment layer and delivery mode layer of the containerized application according to the priority of each layer, and perform hierarchical deep merging to obtain the orchestration configuration parameters.

[0049] Specifically, application configurations in containerized applications are divided into three layers, each responsible for different configuration strategies. A hierarchical merging strategy generates the final orchestration configuration parameters. The original configuration parameters are used to determine the dimensions of configuration changes. These dimensions are then divided into three orthogonal dimensions: "environment-independent basic configuration" in the base layer (721), "environment-related differential configuration" in the environment layer (722), and "delivery mode-related differential configuration" in the delivery mode layer (723). This ensures that configuration changes in each dimension do not interfere with each other, reducing the complexity of configuration management.

[0050] In one example, refer to Figure 3 As shown, the implementation of step 20 includes: Step 21: Configure the base layer according to the service image tags of each service, the default resource quotas of each service, the general environment variables required for each service to run, the default number of replicas of each service, and the default health check parameters of each service in the description file.

[0051] The base layer 721 contains default configurations shared across all environments and delivery modes. The configuration file is located at `config / base.yaml`, and its content defines general configuration parameters applicable to any deployment scenario. In base layer 721, the service image tag is the default image tag for each service; the default resource quota is the default CPU and resource quota for each service, suitable for development and testing environments; the default environment variables are general environment variables required for each service to run, such as log level, application name, and default timeout; the default health check parameters are the default interval, timeout, and number of retries for health checks; and the default replica count is the default number of replicas for each service, typically 1.

[0052] Step 22: Configure the environment layer according to the database, external service address, log level, number of replicas and resource quota corresponding to each environment in the description file.

[0053] Environment layer 722 contains overlay configurations for specific deployment environments, adapting to the differentiated needs of different environments. The configuration file path is config / env / {environment}.yaml, where {environment} is the environment identifier. Environments include internal development environment (alpha), daily build environment (nightly), quality assurance environment (qa), pre-release environment (staging), production environment (production), and US region environment (us). In environment layer 722, environment-specific database connections connect to different database instances, such as the development environment connecting to the development database and the production environment connecting to the production database. External service addresses connect to different external service endpoints, such as message queue addresses, caching service addresses, and third-party API addresses. Log levels are debug levels for easy debugging in development environments and warn levels for reducing log volume in production environments. The number of replicas is the minimum number required in development environments and the number of replicas required to support high-volume development in production environments. Resource quotas are the minimum amount of resources required to save costs in development environments and the amount of resources required to ensure performance in production environments.

[0054] Step 23: Configure the delivery mode layer according to the configuration information corresponding to the public delivery mode and the configuration information corresponding to the private delivery mode in the description file.

[0055] The delivery mode layer 723 includes unique configurations for public or private delivery, used to adapt to the differentiated requirements of different delivery modes. The configuration file path is config / mode / {mode}.yaml, where {mode} is the delivery mode identifier, with a value of saas or privateized.

[0056] Step 24: Based on the merging strategy corresponding to the data type, perform a hierarchical deep merging algorithm on the base layer, environment layer, and delivery mode layer in order of low priority to high priority to obtain the final orchestration configuration parameters.

[0057] Different data types employ different merging strategies, including scalar value merging strategy, list value merging strategy, and dictionary value merging strategy.

[0058] The scalar value merging strategy is as follows: when the same configuration key is a scalar value (string, number, boolean) in both the high-priority layer and the low-priority layer, the value in the high-priority layer directly overwrites the value in the low-priority layer. For example, if the base layer 721 defines logLevel: "info" and the environment layer 722 defines logLevel: "warn", then the merging result will use the environment layer 722 to overwrite the base layer 721, and the merging result will be logLevel: "warn".

[0059] The list value merging strategy is as follows: when the same configuration key is a list value in both the high-priority layer and the low-priority layer, the list in the high-priority layer completely replaces the list in the low-priority layer (non-appendage merging). For example, if the base layer 721 defines a port list [80, 8080] and the environment layer 722 defines a port list [443, 8443], using the append strategy would result in [80, 8080, 443, 8443], which may lead to port conflicts; using the replacement strategy, the [443, 8443] from the environment layer 722 is used directly, with clear semantics.

[0060] The dictionary value merging strategy is as follows: when the same configuration key is a dictionary value (nested object) in both the high-priority and low-priority levels, a recursive deep merging is performed. Specifically: iterate through all keys in the high-priority dictionary; if the key does not exist in the low-priority dictionary, add the key from the high-priority dictionary; if the key exists in the low-priority dictionary and the dictionary type is the same, perform a recursive deep merging; if the key exists in the low-priority dictionary and the dictionary type is different, handle the conflict resolution strategy.

[0061] In one example, the pseudocode for recursive depth merging is: In one example, if a key in a high-priority dictionary also exists in a low-priority dictionary and the dictionary types are different, the conflict resolution strategy is as follows: When the value types of the same configuration key are inconsistent in the high-priority layer and the low-priority layer (i.e., type inconsistency conflict), the value in the high-priority layer will overwrite the value in the low-priority layer, and a merged audit log will be generated.

[0062] When the same configuration key is null or an empty string in a higher priority level (i.e., a null value conflict), the empty string is used as the result of the merge strategy. In the merge result, the value of that key is null or an empty string (instead of retaining the value in the lower priority level), and a merge audit log is generated. Explicit clearing of configuration items defined in lower priority levels is supported.

[0063] When the same configuration key is marked with the special flag __DELETE__ (i.e., a key deletion semantic conflict) in a high-priority layer, the key is deleted in the result of the merge strategy, and a merge audit log is generated. This allows high-priority layers to explicitly remove configuration items defined in low-priority layers, suitable for scenarios where certain configurations should not exist in a specific environment or delivery mode.

[0064] In one example, a merge audit log is generated for each configuration key that is overridden, added, or causes a conflict. The merge audit log includes the conflicting key path, the key's value and type at the low-priority level, the key's value and type at the high-priority level, the key's value and type in relation to the merge strategy's result, and field operation identifiers, including overridden, added, conflict_resolved, deleted, and unchanged. The merge audit log records the conflicting key path, the value and type at the low-priority level, the value and type at the high-priority level, and the final value and its source level, providing complete traceability of the configuration merge process. This allows operations personnel to accurately understand the source level and overriding history of each value in the final configuration, facilitating the investigation and auditing of configuration issues. The `action` field in each record of the merge audit log identifies the operation type, as shown in the table below: Step 30: Filter the conditional fields in the description file according to the target delivery mode to obtain the description data structure. In the public delivery mode, convert the description data structure and orchestration configuration parameters into a directory structure that generates a directory and environment overlay files. In the private delivery mode, convert the description data structure and orchestration configuration parameters into an orchestration file, an environment variable file, and a reverse proxy configuration file.

[0065] Specifically, the process receives the description file and the orchestration configuration parameters merged in step 20, performs conditional field filtering on the description file to obtain the description data structure, and converts the same description data structure input into two orchestration configurations: Kubernetes HelmChart and Docker Compose. During the conversion process, the three-layer configuration merging mechanism from step 20 is introduced to generate the final configuration using deterministic priority rules and conflict resolution strategies. At the same time, a complete merge audit log is output to achieve traceability and auditability of the configuration conversion process.

[0066] In one example, reference Figure 4 As shown, the specific implementation of step 30 includes: Step 31: Filter the conditional fields in the description file according to the target delivery mode to obtain the description data structure.

[0067] For specific implementation details of step 31, please refer to [link / reference]. Figure 5 As shown, the process includes: S311, traversing the data structure of the description file to obtain the current field; S312, determining whether the current field contains the when_mode annotation. If it exists, proceed to S313; otherwise, retain the current field value and treat the when_mode annotation of the field value as all; S313, determining whether the character after when_mode corresponds to the target delivery mode or is all. If yes, retain the current field value and proceed to step S314; otherwise, filter the current field value and proceed to S316; S314, determining whether the current field satisfies value-level conditionalization. If yes, extract the value corresponding to the target delivery mode to replace the conditionalization structure and proceed to step S315; otherwise, proceed to S316; S315, determining whether the character after when_mode in the target delivery mode is declared. If yes, output the field value of the target delivery mode and proceed to S316; otherwise, output the default value and proceed to S316; S316, processing the next field and returning to S312, until all fields corresponding to the description file have been processed, and finally outputting the filtered description data structure.

[0068] Step 32: In public delivery mode, the description data structure and orchestration configuration parameters are converted into a directory structure that generates directories and environment overlay files.

[0069] Step 32 relies on a Helm Chart converter to transform the description file (passed four-level verification in step 10) and the orchestration configuration parameters output in step 20 into a complete Helm Chart directory structure. (See reference) Figure 6 As shown, the implementation of step 32 includes: S321, generating values.yaml; S322, template rendering; S333, assembling the Chart structure.

[0070] S321, values.yaml generation includes: global parameter extraction, service-level parameter extraction, and environment coverage file generation.

[0071] Global parameter extraction involves extracting global-level configurable parameters from the description data structure and orchestration configuration parameters, and writing these global parameters into the top-level structure of values.yaml. These configurable parameters include the application name, namespace, global image repository address, and global image pull strategy. The priority of the global parameter values ​​is that the key-value pairs of the orchestration configuration parameters are higher than the default values ​​in the description data structure.

[0072] Service-level parameter extraction involves iterating through the `spec.services` list describing the data structure and generating a corresponding parameter block for each service definition. Parameters within these blocks are extracted according to rules for image parameterization, replica count parameterization, resource quota parameterization, environment variable parameterization, health check parameterization, and storage volume parameterization. Each service's parameter block is written to the service parameter area of ​​`values.yaml` using the service name as the key. Image parameterization splits the service's `image` field into two independent parameters: `repository` (repository address + image name) and `tag` (image tag). This allows for independent overriding of the image tag in different environments without affecting the repository address; for example, `repository:tag`, where a colon serves as the separator. Replica count parameterization extracts the value corresponding to the target delivery mode (`when_mode.saas`) from the service's `replicas` field as the `replicaCount` parameter. If `when_mode.saas` is not declared, the default value is used. For resource quota parameterization, the service's `resources` field is completely extracted into a `resources` parameter block, keeping the structures of `requests` and `limits` unchanged. For environment variable parameterization, environment variables in the service's `env` field with `when_mode` set to `saas` or `all` are extracted into an `env` parameter list; environment variables with `when_mode: privatized` are filtered out in this step. For health check parameterization, the service's `health_check` field is extracted into a `healthCheck` parameter block, containing probe type, path, port, and time parameters. For storage volume parameterization, the service's `volumes` field is extracted into a `persistence` parameter block, and the value of `storage_class.when_mode.saas` is extracted into a `storageClass` parameter.

[0073] When generating the environment override file, the environment layer 722 configuration parameters are compared key-by-key with the default values.yaml, and only the key-value pairs that differ are written to the environment override file values-{env}.yaml. The environment layer 722 configuration parameters contain override values ​​that differ from the default values.yaml; for example, values-production.yaml might contain production-specific replica counts, resource quotas, and log levels. Ensure that the environment override file is minimized to avoid maintenance burdens caused by redundant configurations.

[0074] S322, Template Rendering, includes: Deployment template generation, Service template generation, ConfigMap template generation, Ingress template generation, and helper function template generation. Module rendering is used to convert service definitions in descriptive data structures into parameterized Kubernetes resource template files.

[0075] Deployment template generation involves iterating through the fields of the service definition in the description data structure and converting each field into Helm template syntax according to the mapping rules from UAD to Kubernetes resource objects. This includes metadata templateting, replica count templateting, and container specification templateting. Specifically, the service name in metadata templateting is generated using helper functions defined in `_helpers.tpl`, and the tags include the application name, service name, version number, and Helm management tags. The replica count in replica count modularization references parameters in `values.yaml`. In container specification templateting, the container image, resource quotas, port, environment variables, and health checks are all referenced through parameters in `values.yaml`.

[0076] When generating a Service template, the ports in the data structure are mapped to the port configuration of the Kubernetes Service, with service_port mapped to port and container_port mapped to targetPort.

[0077] When generating a ConfigMap template, non-sensitive environment variables defined by direct values ​​in the data structure are extracted into the ConfigMap template. The data part of the ConfigMap is referenced through the values.yaml parameter, realizing centralized management and versioning of environment variables.

[0078] Ingress template generation converts the ingress traffic rules (networks.ingress, when_mode: saas) in the data structure into an Ingress-Nginx resource template. The Ingress domain name and TLS configuration are obtained from the orchestration configuration parameters.

[0079] The helper function template generation process automatically generates the _helpers.tpl file, which contains template helper functions that can be reused in the Helm Chart, based on the application metadata describing the data structure.

[0080] S323, Chart structure assembly includes: generating the Chart.yaml metadata file, assembling the directory structure, standardizing template file naming, and verifying chart integrity. The files generated in the preceding steps are assembled into a complete directory structure conforming to the HelmChart specification.

[0081] Generating the Chart.yaml metadata file involves extracting the application name, version number, and description information from the metadata describing the data structure. The `version` field represents the Chart's own version number, and the `appVersion` field represents the application's version number. Both are extracted from the `metadata.version` field of the data structure, ensuring consistency between the Chart version and the application version. Assembling the directory structure involves organizing all generated files into a directory structure according to the HelmChart specification. Standardizing template file naming ensures that template files are named in the format `{resource-type}-{service-name}.yaml`, guaranteeing a clear and traceable correspondence between template files and service definitions. Chart integrity verification confirms that the Chart.yaml file exists and contains the necessary fields, the values.yaml file exists and has correct YAML syntax, each service in the `templates` directory has at least a corresponding Deployment and Service template, and all values ​​parameters referenced in template files are defined in values.yaml. If all these conditions are met, the verification fails, a structured error report is generated, and the conversion is aborted.

[0082] Step 33: In private delivery mode, the description data structure and orchestration configuration parameters are converted into orchestration files, environment variable files, and reverse proxy configuration files.

[0083] Convert the data structure and orchestration configuration parameters into a docker-compose.yml orchestration file, a .env environment variable file, and an Nginx reverse proxy configuration file. (See reference.) Figure 7 As shown, the implementation of step 33 includes: S331, generating a docker-compose.yml orchestration file using the docker-compose.yml generation algorithm; S332, generating an .env environment variable file using the environment variable mapping algorithm; S333, generating an Nginx reverse proxy configuration file using the network configuration algorithm; S334, verifying the compose file.

[0084] S331 generates the docker-compose.yml orchestration file using the docker-compose.yml generation algorithm, including: generating the Compose header, generating service definitions, and generating top-level resource declarations. Generating the Compose header involves creating a header for the docker-compose.yml file to declare the Compose version, for example, version: "3.8", meaning the Compose file uses version 3.8. This supports resource constraints (deploy.resources), health checks (healthcheck), and dependency conditions via the depend_on condition syntax, satisfying the mapping requirements of all fields in the UAD. Generating service definitions involves iterating through the list of service definitions describing the data structure, using service names as keys for Compose services (basic identifier conversion), mapping image references directly to image attributes (image conversion), converting Kubernetes format resource values ​​to Compose format (resource quota conversion), converting port definitions to a Compose list of ports (port mapping), converting probe types to the Compose `healthcheck.test` command (health check conversion), converting dependencies to the Compose `depends_on` configuration (storage volume mapping), and mapping `condition: healthy` to `condition` (service dependency mapping). Generating top-level resource declarations involves iterating through the `volumes` field in the service definitions, extracting all unique volume names, generating a top-level declaration for each volume, and extracting network names from the `networks` definition, which by default uses the bridge driver.

[0085] S332, generates the .env environment variable file through an environment variable mapping algorithm, including: mapping environment variable definitions in the descriptive data structure to Compose-recognizable environment variable configurations. The mapping methods include: environment variables defined through the `value` field are directly written to the Compose service's `environment` list, in the format `{NAME}={VALUE}`; environment variables referenced through the `value_from` field in a ConfigMap or Secret are searched for in private mode from orchestration configuration parameters, and the reference is expanded to obtain the direct value or written to the .env file; only environment variables with `when_mode: privatized` and `when_mode: all` are retained, while those with `when_mode: saas` are filtered out; sensitive configuration parameters (such as database passwords, API keys, etc.) and configuration parameters expanded from reference values ​​are written to the .env file, which the Compose service references through `env_file`.

[0086] S333 generates an Nginx reverse proxy configuration file using a network configuration algorithm, including: converting network policies describing data structures into Docker Compose network definitions and Nginx reverse proxy configurations. Specific steps include: extracting network names from the networks definition, generating a top-level Compose networks declaration, creating a bridge-type internal application network, and enabling communication between services via Docker's internal DNS resolution of service names; extracting routing rules from the ingress traffic rules `networks.ingress` and `when_mode: privatized` describing the data structure, mapping the ingress rules to Nginx location blocks, mapping the target server name to the upstream address of `proxy_pass`, and generating the Nginx reverse proxy configuration file; injecting the Nginx reverse proxy service definition into `docker-compose.yml`, during which port mapping of the Nginx service maps ports 80 and 443 of the host machine to the Nginx container, and mounting the generated `nginx.conf` configuration file via volumes.

[0087] S334, compose file verification, including: confirming the correctness of the YAML syntax in the compose file and the consistency of each service reference in the compose file. If yes, output the docker-compose.yml orchestration file, .env environment variable file, and Nginx reverse proxy configuration file. If not, the verification is deemed to have failed, a structured error report is generated, and the conversion is aborted.

[0088] Step 40: Build a continuous integration and continuous delivery pipeline to perform code checkout, image building, parallel generation of dual-mode artifacts, version consistency verification, and artifact release. In the same build, the public artifact generation path and the private artifact generation path are executed in parallel to obtain public artifacts and private offline package artifacts. When the version consistency verification passes, the public artifacts and private offline package artifacts are released.

[0089] Specifically, the continuous integration and continuous delivery pipeline (i.e., CI / CD pipeline) is a dual-mode pipeline that integrates code checkout, image building, parallel generation of dual-mode artifacts, version consistency verification, and artifact release into a single automated process through a five-stage pipeline design. This eliminates the engineering redundancy of maintaining two independent build pipelines from the source of the build process, and ensures that the image binary content of each service in the public artifacts and private offline package artifacts is completely consistent through an image digest-based version consistency verification mechanism.

[0090] In one example, the dual-mode pipeline is implemented based on Jenkins Pipeline (declarative pipeline), using Jenkinsfile to define the complete build logic of the pipeline. Jenkins, as the pipeline's execution engine, provides the following core capabilities: declarative pipeline syntax supports the definition of staged build steps; the parallel directive supports the parallel generation of dual-mode artifacts; the post block supports error reporting and notifications when a build fails; credential management supports secure access to image repositories, chart repositories, and artifact storage; and build parameterization supports specifying the target environment and delivery mode through parameters.

[0091] In one example, reference Figure 8 As shown, the implementation of step 40 includes: Step 41, code checkout.

[0092] Based on the checkout strategy corresponding to the triggering method, the application code is checked out from the Git repository, the version number is extracted from the application code, the build metadata is generated after the version number is determined, and the build metadata is written to the build file build-metadata.json in the workspace in JSON format.

[0093] Based on the checkout strategy corresponding to the triggering method, the application code is checked out from the Git repository. Triggering methods include tag-triggered, branch-triggered, and manual triggering. The version number is extracted from the Git tag name in the application code, or calculated based on the branch name and the most recent Git tag. Tag-triggered builds are automatically triggered when a new version tag (e.g., v1.2.3) is created in the Git repository. The corresponding checkout strategy is to check out the code snapshot corresponding to that tag. Tag-triggered builds are suitable for official release scenarios, and the version number is directly extracted from the tag name. Branch-triggered builds are automatically triggered when code is pushed to a specified branch (e.g., main, release / *). The corresponding checkout strategy is to check out the latest commit of that branch. Branch-triggered builds are suitable for continuous integration scenarios, and the version number is automatically generated based on the branch name and commit history. Manual triggering is when operations personnel manually trigger a build through the Jenkins interface. The corresponding checkout strategy is to specify a target branch or tag. Manual triggering is suitable for emergency fixes or special version release scenarios.

[0094] Extracting the version number from application code uses Semantic Versioning, with the format MAJOR.MINOR.PATCH (e.g., 1.2.3). In one example, the version number is determined by extracting it from the Git tag name, which is in the format v{MAJOR}.{MINOR}.{PATCH} (e.g., v1.2.3). Removing the prefix 'v' yields version number 1.2.3. In another example, the version number is automatically calculated based on the branch name and the most recent Git tag. If the current commit is N commits away from the most recent version tag, the version number is {most recent tag version}-{N}-g{commit_short} (e.g., 1.2.3-5-gabcdef1), representing the 5th commit since version 1.2.3.

[0095] After the version number is determined, build metadata is generated. The pipeline then writes this build metadata in JSON format to the `build-metadata.json` file in the workspace. Subsequent stages append image summaries, artifact information, and validation results to this file, ultimately forming a complete version manifest. For example, the build metadata generated by the pipeline includes the following information: Step 42, image building.

[0096] This step (42) builds the application's container image based on the Dockerfile. A self-built base image is used as the foundation for the application image, rather than directly using a third-party base image from a public image repository, ensuring consistency of the underlying environment. The self-built base image is maintained centrally by the infrastructure team, with regular updates to security patches and dependency versions, ensuring all application images are built on a security-audited base environment. Image tags use the format {registry} / {repo}:{version}-{commit_short}, where {registry} represents the image repository address, {repo} represents the image repository name, {version} represents the semantic version number, and {commit_short} represents the first 7 characters of the Git commit hash from the build metadata. The version number allows operations personnel to quickly identify the image version, and the short hash provides precise code-level traceability. When troubleshooting issues with a specific version, the corresponding code commit can be directly located from the image tag, achieving precise traceability from image to code.

[0097] The types of base images, image tags, and applicable scenarios are shown in the table below: refer to Figure 9 As shown, the specific implementation of step 42 includes: S421, read the base path and build context corresponding to the service definition from the description file, and compile and generate a container image based on the build context and base path corresponding to each service definition.

[0098] The system iterates through the service list in the description files to obtain all service definitions that need to be built into images, determining the Dockerfile path and build context for each service. For each service, the `docker build` command is executed, specifying the Dockerfile path, build context, and image tag, to build the container image. During this process, the version number and build metadata are passed in via `--build-arg`, enabling the application to obtain its own version information at runtime.

[0099] S422 generates an image tag for the container image using short hash encoding based on the version number and build metadata defined for each service, and pushes the container image to the image repository.

[0100] Based on the image repository address, image repository name, semantic version number, and the first 7 characters of the Git commit hash from the build metadata (in the format {registry} / {repo}:{version}-{commit_short}), the container image is pushed to the image repository after the container image build is complete. In one example, ECR login credentials are obtained via the AWS CLI before pushing; the container image is pushed to the image repository when the credentials are verified.

[0101] S423: Calculate the hash value of the image content based on the container image to obtain the image digest, and record the image digest in the build file.

[0102] After the image push is complete, the dual-mode pipeline retrieves the SHA256 hash value of each service image from the image repository to obtain an image digest, and records the image digest in the `images` field of the build metadata in the build file. The command to retrieve the image digest is: The image summary is recorded in the build file as follows: Identical image content will inevitably produce the same digest value; any slight change in the image content will result in a completely different digest value. Therefore, the image digest is the only reliable basis for determining whether two images contain the same binary content. This step S423 records the image digest during the image building phase to ensure that the verification benchmark for version consistency verification in subsequent step 44 comes from the same building process.

[0103] Step 43: Parallel generation of dual-mode products.

[0104] Two artifact generation paths are executed in parallel within the same build: a public artifact generation path and a private artifact generation path. The Jenkins Pipeline's parallel command executes these two paths concurrently without blocking each other, thus reducing the total build time to the longer of the two paths.

[0105] refer to Figure 10 As shown, in the public delivery mode, the public product generation path is enabled, specifically including: S431: The Helm Chart converter of the dual-mode orchestration engine is invoked to obtain the directory structure. The mirror references in the directory structure are updated based on the mirror tags and mirror summaries. Ensure that the mirror tags applied in the directory structure are consistent with the mirror tags produced by this build.

[0106] In step S432, the `helm package` command is executed on the directory structure (i.e., the Helm Chart directory) to package the directory structure into a .tgz archive file, resulting in a public artifact. At this point, the packaging command sets the Chart version number and the application version number. After packaging, a file named `{app-name}-{version}.tgz` (e.g., `myapp-1.2.3.tgz`) is generated in the `. / artifacts / helm / ` directory.

[0107] S433 pushes public artifacts to the public repository and updates the address and version information of the public repository to the build file.

[0108] The public artifact is pushed to the Helm Chart repository. The push command uses the appropriate push method based on the Chart repository type (e.g., ChartMuseum, Harbor, or OCI-compatible repository). For example, the push command for a compatible repository is: `helm push . / artifacts / helm / ${APP_NAME}-${VERSION}.tgz oci: / / ${CHART_REGISTRY} / ${APP_NAME}`. After the push is complete, the address and version information of the public repository (i.e., the Chart repository) are recorded and updated in the build metadata of the build file.

[0109] refer to Figure 11 As shown, in private delivery mode, enabling private artifact generation paths specifically includes: S434 calls the Compose converter of the dual-mode orchestration engine to obtain the docker-compose.yml orchestration file, .env environment variable file, and Nginx reverse proxy configuration file, and updates the image references in the docker-compose.yml orchestration file according to the image tags and image digests.

[0110] S435 exports container images of all services from the local Docker environment and compresses the container images to obtain image packages.

[0111] Export all service images generated from this build from the local Docker environment as a tar archive. This archive contains the complete file system content and metadata of the images; the archive itself is the container image. The export command uses a pipe to directly pass the container images to gzip for compression, resulting in an image package. The compressed image package is 40%-60% smaller than the original size. Compression significantly reduces the bandwidth requirements and storage costs for offline transmission.

[0112] S436, calculate the SHA256 hash value of the image package and write it to the checksums.sha256 file.

[0113] The image package is subjected to SHA256 hashing to calculate the file's hash value, which is then written to the checksums.sha256 file. In this application, the SHA256 hash value is also called the image checksum and serves as the image digest.

[0114] When deploying the private offline package artifact, the SHA256 of the private offline package is recalculated to obtain the deployment hash value. If the deployment hash value matches the hash value recorded in the file (i.e., the hash value written in step 436), the private offline deployment package file is determined to be complete and the next deployment step can be executed; otherwise, the offline deployment package is determined to be corrupted and the deployment is interrupted.

[0115] S437 assembles orchestration files, environment variable files, reverse proxy configuration files, image package deployment scripts, and database migration scripts into a private offline package artifact.

[0116] This package assembles the docker-compose.yml file, the .env template, the Nginx configuration, the Grafana pre-configured dashboard, deployment scripts (install.sh, upgrade.sh, rollback.sh, health-check.sh, diagnosis.sh), database migration scripts, and the image archive into a complete offline installer. The directory structure of the offline installer is as follows: To facilitate transmission and distribution, the directory structure of the offline installation package is compressed and packaged into a single tar.gz archive file as a proprietary offline package artifact, specifically as follows: Step 44, version consistency verification.

[0117] The core objective of version consistency verification is to ensure that the container images of service applications in public artifacts (such as Helm Chart artifacts) and private offline package artifacts (such as Docker Compose artifacts) contain identical binary content. In existing technologies, although the container images used in the two delivery modes may bear the same version tag, the actual image content (binary layer) may differ due to differences in build time, build environment, or build parameters. This step 44 uses a binary consistency verification mechanism based on image digest (SHA256 digest) to ensure that identical container images are running in both modes. The verification mechanism intervenes from the build stage, intercepting any possible version inconsistencies before artifact release, thus eliminating behavioral differences between SaaS and private environments caused by different artifact image content in the two modes.

[0118] refer to Figure 12 As shown, the version consistency check in step 44 includes: S441. Based on the image repository address, image tag, and image summary of each service extracted from the public artifacts, construct a public image reference mapping table.

[0119] Parse the values.yaml file from the Helm Chart artifact generated in step 43, extract the image repository address image.repository, image tag image.tag, and image digest image.digest for each service, and construct the Helm-side image reference mapping table digest_helm as the public image reference mapping table. The public image reference mapping table is as follows: S442, construct a private image reference mapping table based on the field values ​​of each service in the extracted private offline package artifacts and the image digest in the build metadata.

[0120] Parse the docker-compose.yml file from the Docker Compose artifacts generated in step 43, extract the image field value for each service, obtain the corresponding image digest (image.digest) from the build metadata (build-metadata.json), and construct the Compose-side image reference mapping table (digest_compose) as a private image reference mapping table. The private image reference mapping table is as follows: S443, compare the public image reference mapping table with the private image reference mapping table for each service and generate the verification result.

[0121] Iterate through all services defined in the description file, and perform a digest comparison between the public and private image reference maps for each service. The code for the digest comparison is as follows: The verification result is generated based on the abstract comparison results. The data structure of the verification result is as follows: When the image digest in the Helm Chart artifact is exactly the same as the image digest in the Docker Compose artifact, the verification result will show "passed" as true and "mismatches" as an empty list.

[0122] S444: When the verification result indicates that the product has passed, execute the product release.

[0123] After the version consistency check passes, the pipeline proceeds to the product release stage in step 45, whereby the dual-mode products are sent to their respective product repositories, generating a complete version list Build Manifest as a traceability record for this build.

[0124] S445: When the verification result indicates failure, and all service comparisons are completed, the construction of the dual-mode pipeline is stopped, intermediate products are exported, a structured error report is generated, and the error report is sent to the client corresponding to the service.

[0125] When the version consistency check result indicates that the image digest of any service is inconsistent between the Helm Chart artifact and the Docker Compose artifact, the current dual-mode pipeline build is immediately stopped. Specifically, the pipeline will not stop immediately after detecting the first inconsistency, but will continue to complete the comparison of all services to collect complete inconsistency information. If any inconsistency exists after all services are compared, the pipeline will be stopped and the artifact release in step 45 will not be executed.

[0126] When the pipeline is aborted, a structured error report is generated simultaneously, relevant personnel are notified, and the build site is preserved. The error report is generated in JSON format, and the mismatches list within it details information for each inconsistent service, including: service name, image reference in the Helm Chart (helm_image), image digest in the Helm Chart (helm_digest), image reference in Docker Compose (compose_image), image digest in Docker Compose (compose_digest), and inconsistency type (mismatch_type). Relevant personnel are notified via Jenkins' notification mechanism, sending the error report to the build manager and operations team to ensure that version inconsistencies are detected and addressed promptly. Preserving the build site means that after the build is aborted, the pipeline retains all intermediate artifacts and log files in the workspace, facilitating subsequent investigation into the root cause of the inconsistency.

[0127] Step 45, Product Release.

[0128] During the product release phase, the dual-mode products are released to their respective product repositories, and a complete version list is generated.

[0129] For public artifacts, refer to S433 and push the Helm Chart artifact to the Chart repository for Kubernetes deployment in SaaS environments. After deployment, operations personnel can use the `helm install` or `helm upgrade` commands to pull the specified version of the Chart from the Chart repository for deployment. For private offline package artifacts, push them to artifact storage (such as AWS S3, Nexus Repository, or other artifact management systems) for private customer delivery. Upload the checksums.sha256 file of the private offline package artifact during deployment to facilitate verification of its integrity upon receipt.

[0130] The version manifest uses JSON format to record complete build information, establishing a complete traceability chain from code submission to dual-mode artifacts. (Reference) Figure 13 As shown, the process of generating the version manifest includes: S451 reads the version number, build number, Git commit information, build timestamp, and image summary records from the build-metadata.json file as the basic data for the version manifest; S452 extracts the chart name, version, and repository address from the Helm Chart artifact, and extracts the file name, SHA256 checksum, file size, and storage address from the DockerCompose artifact; S453, embed the version consistency check result into the consistency_check field of the version manifest; S454, serialize into a formatted JSON file to obtain the version list.

[0131] A JSON-formatted version manifest is written to the build file as part of the build record. Alternatively, it can be written to the root directory of the Compose offline package for delivery to private clients along with the private offline package artifacts, or stored independently. Compared to existing technologies where the version traceability chain from code submission to final deployment artifacts is independent in both delivery modes, and lacks a unified version manifest to link Helm Chart artifacts and Docker Compose artifacts to the same build, this example embeds the version manifest into the runtime environment during deployment. This allows operations personnel to query the application version running in any environment and its build source at any time, avoiding situations where version inconsistencies are only discovered after deployment or even after customers report issues, increasing repair costs. The embedding method of the version manifest varies depending on the delivery mode.

[0132] For public delivery mode, ConfigMap resource objects are embedded in the cluster within the Kubernetes environment. When generating public artifacts, a ConfigMap named `{app-name}-build-manifest` is automatically created, storing the JSON content of the version manifest in the ConfigMap's `data` field. Key information from the version manifest (version number, Git commit, build timestamp) is also injected into each application container via environment variables, enabling the application to obtain its own version information at runtime and expose it to health check endpoints or version query APIs. Operations personnel can query the application version currently running in the environment using the command: `kubectl get configmap myapp-build-manifest -nproduction -o jsonpath='{.data.manifest\.json}' | jq .`.

[0133] For private delivery mode, the manifest.json file is stored in the root directory of the private offline deployment package and mounted to a specified path inside the application container via a Docker volume. Alternatively, key information from the manifest is injected into the container's environment variables via a .env file. This allows the initial deployment script to extract information such as the version number, Git commit timestamps, and build timestamps from manifest.json and write them to the environment variables when generating the .env file.

[0134] Operations and maintenance personnel can query the application versions running in any environment and their build sources at any time, supporting cross-environment version list comparison to confirm whether different environments are running the same version of the application. As shown in the table below, the version list contains the following core information: The product release adopts an atomic strategy. The release of Helm Chart and Docker Compose products is treated as a whole operation. If the release of either product fails, the released product will be rolled back to ensure that there is no inconsistent state where only one product is released while the other product is missing.

[0135] Step 50: Encapsulate public products and private offline package products.

[0136] Specifically, the encapsulation of public artifacts is already widely used in this field and will not be elaborated further here. Encapsulating private offline package artifacts uses a private encapsulator, which is an integrated encapsulation from application services to infrastructure components. Through a standardized offline image package generation process, service startup orchestration based on dependency topology, dependency-aware intelligent retry strategy, and incremental version upgrade mechanism, private delivery is transformed from customized development into a standardized, repeatable, and automated engineering process, which significantly improves the reliability of offline deployment, the security of upgrades, and the efficiency of troubleshooting.

[0137] refer to Figure 14 As shown, the encapsulated private offline package artifacts include: Step 51: Integrate the application service component, reverse proxy component, database component, monitoring panel component, and log collection component into a single offline deployment package.

[0138] The private wrapper encapsulates the following five types of components into a single offline deployment package, forming a complete application runtime environment. This ensures that the private client environment does not depend on any external network resources (image repositories, package managers, CDNs, etc.). All runtime dependencies are included within the offline deployment package, achieving fully autonomous offline operation. The relationship between component categories, component names, and container image sources is shown in the table below: Application services include all business services defined in the spec.services list of the description file, including container image references, resource requirements, port mappings, environment variables, health check configurations, and service dependencies. During the encapsulation process, the private wrapper reads the image application and summary information for each application service from the build-metadata.json file to ensure that the encapsulated image is consistent with the binary image produced by the dual-mode pipeline.

[0139] The reverse proxy encapsulation is suitable for SSL termination, handling SSL / TLS handshakes and encryption / decryption operations for HTTPS connections, converting encrypted external requests into plaintext internal requests and forwarding them to backend application services; it is also suitable for route distribution, generating routing rules based on the ingress rules in the network policy of the description file, and distributing traffic to the corresponding backend application services; and it is also suitable for static resource services, providing static file services to application services containing frontend static resources, reducing the request pressure on backend services. The self-built base image registry.example.com / base / nginx:latest used by the reverse proxy encapsulation is maintained uniformly by the infrastructure team.

[0140] The database encapsulation uses a self-built PostgreSQL base image. This base image includes built-in SQL scripts for database creation, user permission configuration, and initial schema creation, which are automatically executed upon the container's first startup. The base image also comes pre-configured with postgresql.conf settings optimized for private deployments, including parameters such as connection pool size, shared buffer, and WAL log configuration, adapting to the resource characteristics of small to medium-sized deployment environments. Furthermore, the PostgreSQL data directory ( / var / lib / postgresql / data) is mounted to the host machine via a Docker named volume, ensuring data integrity during container restarts or upgrades. Database encapsulation is optimally performed during service startup.

[0141] The monitoring panel is encapsulated using a pre-configuration method. It automatically loads predefined data sources and monitoring panels when the container starts, eliminating the need for manual configuration by operations and maintenance personnel. It features pre-configured data sources and pre-configured dashboards.

[0142] Log collection is encapsulated, collecting logs from all containers and processing and storing them in a unified format. This includes: log input configuration, log parsing and formatting, and log output configuration. Log input configuration involves Fluent-bit collecting standard output and standard error logs from all containers via the Docker log driver. Log parsing and formatting involves parsing the raw logs into a unified JSON structured format, containing five standard fields: timestamp, level, service, trace_id, and message, consistent with the log format specification defined by the unified observability adapter. Log output configuration involves outputting the processed logs to a specified directory on the local file system (e.g., / var / log / app / ), rotating log files by service name and date for easy viewing and archiving by operations personnel.

[0143] The uniformity of log format is reflected in the uniformity of field definitions, log format across the technology stack, and log format consistency across environments. The field definitions in the uniform JSON structured log structure are shown in the table below: The log format is unified across the technology stack. JSON structured log output is achieved through Logback's JSON encoder (logstash-logback-encoder), Winston's JSON formatter, or structlog's JSON renderer.

[0144] Cross-environment log format unification is achieved by defining a unified log format JSON schema. The application's log output is validated in the CI / CD pipeline to ensure that the log output of all services conforms to the unified format specification. Fluent-bit is used to use the same JSON log parser configuration in both environments to achieve unified log parser configuration and ensure consistent parsing results for log fields.

[0145] Step 52: Export the container images of all services from the build environment as archive files to generate offline image packages.

[0146] Using Docker's `docker save` command, all file system layers, configuration metadata, and tag information of the specified image are exported as a tar archive stream. This stream is then piped to gzip for compression, directly generating a compressed archive file, which serves as the offline image package. This avoids the generation of large, uncompressed tar files that consume disk space. The pipelined execution of the `docker save` command prevents the creation of uncompressed intermediate files on disk. Furthermore, the output stream of `docker save` is directly used as the input stream for gzip, with data streaming in memory. Disk I / O only occurs during the final compressed file write stage. For large image packages of several gigabytes in size, this significantly reduces disk space usage and I / O wait time.

[0147] After compression, the SHA256 checksum of the generated image archive is calculated and written to the checksums.sha256 file. Once the readability of the checksums.sha256 file is verified, the offline image archive is output.

[0148] Step 53: Perform offline deployment initialization during the initial deployment.

[0149] Offline deployment initialization involves the private packager executing a standardized sequence of operations for the first deployment in the customer's environment, strictly automated by the installation script `install.sh`. Offline deployment initialization includes package integrity verification, image loading, configuration generation, service startup in dependency order, health checks, and outputting a deployment result report. Package integrity verification is achieved by comparing the actual SHA256 checksum of the compressed image package with the expected value recorded in the `checksums.sha256` file. Image loading, after successful package integrity verification, loads the archive files from the offline image package into the local Docker environment using the `docker load` command, which reads the tar format image archive and restores all file system layers and metadata of the image to the local Docker image storage. Configuration generation starts from the `.env.template` template file and combines it with the environment parameters provided by the customer (database password, domain name, port, etc.) to generate the final `.env` environment variable file. Variable references in `docker-compose.yml` (${VAR_NAME}) are replaced with environment variables to generate the final Docker Compose orchestration configuration. When services are started in dependency order, the dependent components start first, and the dependent components start only after the health checks of the dependent components have passed, ensuring that all dependencies of each service are ready when it starts. Health checks are performed one by one using the health-check.sh script to check the health status of each service. Health checks include port connectivity, HTTP interface response, and critical functional availability. A deployment report is output after all health checks have passed, showing the running status, access address, and version information of each service.

[0150] In one example, if an image layer already exists locally during image loading (e.g., the base image layer loaded during previous version deployments), that layer's loading is skipped, and only newly added or modified layers are loaded, thus speeding up the image loading process. During configuration generation, the template file contains default values ​​and explanatory comments for all configurable parameters; customers only need to modify the parameters they wish to customize. When starting services according to dependency order, the standard startup order is as follows: Step 54: Upgrade the offline image package version through incremental image updates, configuration migrations, database migrations, and server rolling restarts.

[0151] Incremental updates involve the upgrade script extracting image summaries for each service from both the new version's manifest.json and the current running version's manifest, comparing them one by one to determine which service images have changed. It then compares the new version's manifest with the previous version's, performing a `docker save` export only for services with different summaries, generating a smaller incremental image archive, images-incremental.tar.gz. In the customer environment, the upgrade script performs SHA256 verification on the incremental image archive and then loads the changed image using `docker load`.

[0152] During configuration migration, the upgrade script compares the new version's `.env.template` file with the current version's `.env` file, identifying configuration changes such as added, deleted, modified, and unchanged parameters. For unchanged and deleted parameters, the upgrade script automatically performs the migration operation without manual intervention. For added and modified parameters, the upgrade script marks the parameters requiring confirmation with comments in the migrated `.env` file and outputs prompts to the console to guide operations personnel in checking and confirming. When the new version introduces incompatible configuration changes (such as parameter renaming, parameter type changes, parameter semantic changes, etc.), the upgrade script cannot complete the migration automatically and is explicitly listed in the new version's upgrade documentation `UPGRADE_NOTES.md`. When the upgrade script detects incompatible changes, it pauses execution, outputs a list of incompatible changes and manual handling guidelines, and continues execution after confirmation by operations personnel.

[0153] Database migration involves using versioned SQL scripts to evolve the PostgreSQL database schema from the current version to a new version. Each schema change corresponds to an SQL migration script with an incrementing number. These migration scripts are stored in the `migrations / sql / ` directory of the offline deployment package, using the naming format `V{serial number}__{description}.sql` (e.g., `V001__init_schema.sql`, `V002__add_indexes.sql`), with the serial numbers strictly incrementing. Before executing the migration, the upgrade script queries the `schema_migrations` table in the database to determine the current database schema version and executes only migration scripts with serial numbers greater than the current version. If any SQL statement in the script fails, the entire transaction is automatically rolled back to ensure the database is not in an inconsistent state due to partial migration. If a migration fails, the upgrade script outputs the name of the failed script and an error message, and terminates the execution of subsequent migration scripts.

[0154] The server performs a rolling restart. Before performing any changes, the upgrade script automatically backs up the complete state of the current version, including configuration file backups, version manifest backups, and database backups. When the rollback script rollback.sh is executed, it rolls back to the stable state of the previous version.

[0155] The upgrade process is automated by the upgrade script upgrade.sh. Each step in the upgrade process can be rolled back independently. If any step fails, it will automatically trigger a rollback to the stable state of the previous version, ensuring that the upgrade operation will not cause the system to be in an unusable intermediate state.

[0156] Step 55: When a component in the private offline package fails to start, the corresponding retry strategy is used to diagnose the fault based on the health status of the dependent components.

[0157] Unlike traditional fixed-delay retries or simple retry counting, the retry strategy in step 55 is based on differentiated processing of the dependency graph between services. When a component fails to start, the health status of its dependent components is first analyzed, and different retry strategies are adopted according to the different dependency statuses. Finally, after all retries have failed, a diagnostic report containing complete context information is generated to help operations and maintenance personnel quickly locate the root cause of the problem.

[0158] When a dependent component of a failed component fails a health check (status is unhealthy or starting), the failure is determined to be a cascading failure caused by an unready dependency. The retry strategy enters a waiting mode, polling the health status of dependent components at fixed intervals (default 10 seconds) until all dependent components pass health checks, at which point the failed component is restarted. A maximum waiting time is set (default 300 seconds, or 5 minutes). If the maximum waiting time is exceeded, the dependent component is considered to have failed to start, the waiting process terminates, and the diagnostic report generation process begins.

[0159] If all dependent components of a failed component have passed health checks (status is healthy), but the component itself still fails to start, the failure is determined to be due to an internal component fault (such as configuration errors, port conflicts, insufficient resources, etc.). In this case, the retry strategy implements exponential backoff retries: the first retry waits 10 seconds, the second retrieval waits 20 seconds, and the third retrieval waits 40 seconds. A maximum of 3 retries are performed, with the component's health status rechecked before each retry. After all 3 retries fail, the retrieval process terminates and enters the diagnostic report generation process.

[0160] When all retry strategies fail, the private wrapper automatically generates a structured diagnostic report containing complete contextual information of the failed component, helping operations and maintenance personnel to quickly locate the root cause of the problem.

[0161] The diagnostic report is generated by the diagnostic script (diagnose.sh) and includes information on failed components, the status of dependent components, a log summary, and troubleshooting suggestions. Failed component information includes the name of the component that failed to start, the failure time, the failure type (dependency wait timeout or failure to retry itself), and the number of retries. Dependency component status includes the current health status, runtime, and port connectivity of each dependent component of the failed component. The log summary extracts the most recent log output from the failed component (the last 50 lines by default), containing standard output and standard error information to help operations personnel quickly review error messages. Troubleshooting suggestions are automatically generated based on the failure type and key error information in the logs. In one example, the diagnostic report is output in JSON format to the file . / diagnostics / report-{timestamp}.json, while a key information summary is also output to the console in a human-readable format.

[0162] Step 60: Based on a unified structured log format, a naming convention-based indicator system, and alarm rule definitions, observe the monitoring component stack corresponding to the target delivery mode.

[0163] Specifically, since the log parsing and formatting in step 50 parses the raw logs into a unified JSON structured format consistent with the log format specification defined in the unified observability adapter in step 60, the log formats of public and private offline package products are identical, achieving a unified structured log format. This ensures that observations under both delivery modes can use the same log query and analysis methods. During the delivery of the monitoring component stack corresponding to the observation target, a consistent indicator system with the same naming conventions under both delivery modes is adopted to achieve unified indicator naming and ensure consistent monitoring under both delivery modes. Consistent alarm rules are defined under both delivery modes to achieve alarm rule adaptation and ensure that the same alarm logic is triggered consistently in both environments. Therefore, step 60 provides consistent monitoring, logging, and alarm capabilities during observation, solving the problem of severe lack of observability capabilities in private delivery scenarios in existing technologies.

[0164] In one example, the Unified Observable Adapter 76 provides consistent monitoring, logging, and alerting capabilities across both Kubernetes (SaaS) and Docker Compose (private) delivery models, through a unified design across the following four dimensions, as shown in the table below: The unified observability adapter architecture consists of three layers: The definition layer defines observability specifications common to all delivery modes, including unified log format specifications, unified metric naming specifications, and unified alerting rule definitions. These specifications are stored in the application code repository in YAML format. The adaptation layer converts the unified specifications from the definition layer into specific configurations for the corresponding platform based on the target delivery mode. Specifically, the Kubernetes adapter converts the unified specifications into native Kubernetes observability configurations (Grafana Alert Rules, Fluent-bit DaemonSet configurations, SkyWalking Agent configurations, etc.), and the Docker Compose adapter converts the unified specifications into observability configurations for the Docker Compose environment (Grafana pre-configured dashboards, Fluent-bit local collection configurations, local alerting scripts, etc.). The execution layer is the actual stack of observability components running in the target environment. Specifically, the execution layer for the Kubernetes environment includes four components: Grafana, SkyWalking, Fluent-bit, and Loki; the execution layer for the Docker Compose environment includes three components: Grafana, Fluent-bit, and application-built-in metric endpoints.

[0165] In one example, a unified metric naming convention is defined, adhering to the Prometheus naming convention. This ensures that all application services expose metrics with the same names in both Kubernetes and Docker Compose delivery modes, guaranteeing that monitoring dashboards and alerting rules are compatible in both environments without requiring different dashboard configurations and alerting rules for different environments. The unified metric naming format is: {app}_{component}_{metric}_{unit}, and the meanings of each component are shown in the table below: The metrics that the monitoring system can capture, read, and collect include HTTP request metrics, database connection metrics, JVM metrics (Java services), and application health metrics.

[0166] The monitoring types, tags, and descriptions for HTTP request metrics are shown in the table below: The monitoring types, tags, and descriptions for database connection metrics are shown in the table below: The monitoring types, labels, and descriptions for JVM metrics (Java service) are shown in the table below: The monitoring types, labels, and descriptions for applying health indicators are shown in the table below; To ensure consistency of metrics, a metric registry and metric naming validation are used. The metric registry defines the name, type, tag, and description of all core metrics, serving as the authoritative benchmark for metric naming, and is stored in the application code repository. Metric naming validation, performed in the CI / CD pipeline, validates the names of the metric endpoints exposed by the application, ensuring that all metric names conform to a unified naming convention and are defined in the metric registry. If validation fails, a warning report is generated, prompting developers to correct the metric names.

[0167] In one example, alarm rule adaptation is achieved by defining unified alarm rules in YAML format. Each rule includes an alarm name, trigger condition, duration, severity level, and notification method. Unified alarm rule definitions are the foundation for consistent alarm capabilities across delivery modes, and are converted into the corresponding platform's alarm configuration by the unified observability adapter based on the target delivery mode. The meanings of the fields in a unified alarm rule are as follows: In a Kubernetes environment, the unified observability adapter converts unified alert rule definitions into Grafana Alert Rules. Grafana Alert Rules utilize Grafana's built-in alerting engine to perform rule evaluation and notification sending, supporting multiple notification channels (email, webhook, Slack, PagerDuty, etc.). In a DockerCompose environment, since it does not rely on Grafana's alerting engine (to reduce resource overhead and configuration complexity), the unified observability adapter converts unified alert rule definitions into local alert scripts. Local alert scripts periodically check application metric endpoints and compare them with thresholds, sending notifications via email or webhook when alerts are triggered.

[0168] After unified alert rules are converted into Grafana Alert Rules for the Kubernetes environment and local alert scripts for the Docker Compose environment, the alert triggering conditions of both remain semantically equivalent. Semantic equivalence is reflected in the following three dimensions: metric name equivalence, threshold equivalence, and duration equivalence. In the metric name equivalence dimension, both transformation outputs reference the same metric name (following the unified metric naming convention), ensuring that the alert rules evaluate the same metric object. In the threshold equivalence dimension, both transformation outputs use the same alert threshold and comparison operators. In the duration equivalence dimension, both transformation outputs use the same alert duration requirement. Semantic equivalence is verified as follows: For each unified alert rule, the metric name, threshold, and duration parameters are extracted from both the Grafana Alert Rules and the local alert script, and a triplet equivalence comparison (metric, threshold, duration)_grafana == (metric, threshold, duration)_script is performed to ensure that the two transformation outputs are completely consistent in terms of alert triggering conditions.

[0169] In one example, under public delivery mode, metrics are monitored using Prometheus and the Grafana visualization panel, tracing is performed using the observability analytics backend SkyWalking OAP and the application probe SkyWalking Agent, logs are collected using the lightweight log collectors Fluent-bit and Loki from the daemon set, and log queries are performed using the Grafana visualization panel and the Loki logging system, thus achieving a full-stack monitoring solution for observing resource objects in the Kubernetes environment.

[0170] For the Grafana visualization panel, pre-configured application overview templates, service details panels, infrastructure panels, and log query panels are provided. The application overview panel displays the operational status, including the health status of each service, request volume (QPS), response time, error rate, and resource utilization. This application-level global view facilitates quick identification of abnormal services. The service details panel displays detailed operational metrics for individual services, including HTTP request status code distribution, response time histogram, active connections, thread pool utilization, database connection pool status, and JVM memory usage. The infrastructure panel displays the operational status of the Kubernetes cluster and infrastructure components. The log query panel integrates a logical Loki data source, providing structured log query and browsing capabilities. It supports log filtering by service name, log level, time range, and keywords, and also supports linking cross-service logs for the same request using trace_id.

[0171] The observable analytics backend, SkyWalking OAP, is deployed in a Kubernetes cluster as a Deployment. The OAP Server receives trace, segment, and span data reported by each service agent, performs topology analysis, performance statistics, and anomaly detection, and stores the analysis results in backend storage (Elasticsearch or BanyanDB).

[0172] For the application probe SkyWalking Agent, automatic injection is achieved through the Kubernetes Init Container mechanism. The Init Container executes before the application container starts, copying the SkyWalking Agent JAR file to the shared volume. The application container loads the Agent via the JVM parameter `-javaagent`, enabling automatic collection of trace data. The SkyWalking Agent generates a unique `trace_id` for each request and injects it into the application's log context. The application's output JSON structured logs contain this `trace_id` field, allowing operations personnel to simultaneously view trace data and related log records in Grafana using the `trace_id`, enabling correlation analysis of metrics, traces, and logs.

[0173] The lightweight log collector Fluent-bit is deployed as a DaemonSet on each node of the cluster. It is responsible for collecting the standard output (stdout) and standard error (stderr) logs of all containers on that node and forwarding the logs to Loki for persistent storage. Fluent-bit reads log files from the container log directory ( / var / log / containers / ) of the Kubernetes node, uses the tail input plugin to support real-time tracing and resuming interrupted log entries, and automatically appends Kubernetes metadata (Pod name, namespace, container name, tags, etc.) to each log record to enrich the log's context. The processed logs are then forwarded to the write endpoint via HTTP.

[0174] Loki receives log data forwarded by Fluent-bit and serves as the log storage and query backend for Kubernetes environments. Loki provides efficient log persistence and query capabilities, achieving a good balance between storage efficiency and query performance. Loki uses object storage (such as AWS S3) as the persistent log data backend, supporting long-term storage of large-scale log data. Log data is stored in time-sharing chunks, with each chunk containing log records within a specific time range and corresponding tag indexes. Loki provides the LogQL query language, supporting flexible queries based on tags and log content. Log retrieval using LogQL is also supported through Grafana's log query dashboard. Loki also allows configuring log data retention periods, automatically cleaning up log data exceeding the retention period to balance storage costs and historical log query needs.

[0175] In the public delivery model, the division of responsibilities among the components is shown in the table below: In another example, in a private delivery mode, metrics are monitored via in-application metric endpoints and the Grafana visualization dashboard; trace tracing is performed by associating trace_ids in application logs; logs are collected using the lightweight log collector Fluent-bit and local file storage; and log queries are performed using the Grafana visualization dashboard and a local log file browsing component. This provides core observability capabilities with minimal resource overhead in a resource-constrained private environment, while maintaining consistent metric collection and log formats with the Kubernetes environment, ensuring that the operations team can monitor and troubleshoot applications in both delivery modes in a unified manner.

[0176] For the Grafana visualization panel in the Docker Compose environment, the data source configuration is pre-configured in the config / grafana / provisioning / datasources / directory of the offline deployment package, and the monitoring panel configuration is pre-configured in the config / grafana / dashboards / directory of the offline deployment package. The monitoring panel includes the same four types of panels as the Kubernetes environment (application overview, service details, infrastructure, and log query). The metric query statements in the monitoring panel use the metric names defined in the unified metric naming convention.

[0177] Fluent-bit, a lightweight log collector driven by Docker logs, reads JSON-formatted log files from containers via the mounted Docker log directory ( / var / lib / docker / containers / ). These log files are stored on the local file system and are rotated by date, generating a new log file daily while retaining the most recent 30 days of log data. Log rotation is achieved through Fluent-bit's file output plugin in conjunction with the host machine's logrotate tool. Notably, Fluent-bit is configured consistently in both Docker Compose and Kubernetes environments, using the same JSON log parser to ensure consistent log fields, the same filtering rules to ensure identical metadata field structure in both environments, and the same time format to ensure cross-environment time alignment. The only difference lies in the output target and input source.

[0178] For application-built-in metric endpoints, Prometheus-formatted metric data is directly exposed through these endpoints for Grafana to pull and display. The specification for metric endpoints is that each application service exposes Prometheus-formatted metric data on the ` / metrics` path on a specified port. If the application's technology stack is Java (SpringBoot), the metric endpoint is implemented using Spring Boot Actuator and Micrometer; if the application's technology stack is Node.js (Express), the metric endpoint is implemented using the `prom-client` middleware; and if the application's technology stack is Python (Flask / FastAPI), the metric endpoint is implemented using the `prometheus_client` middleware. The application service exposes the metric endpoints via `ports` mappings in `docker-compose.yml`, and Grafana accesses these metric endpoints directly through the Docker Compose internal network.

[0179] The table below illustrates the differences between observing a Docker Compose environment in a private delivery mode and observing a Kubernetes environment in a public delivery mode: In summary, this embodiment has the following beneficial effects: Regarding application description, compared to existing technologies that use two independent configurations to describe SaaS and private delivery modes respectively, it is difficult to determine whether a production issue is caused by application code or configuration differences. Each application change requires repeated modification, testing, and verification across both configuration systems, leading to an exponential increase in the complexity of synchronous maintenance of the two configurations. Furthermore, independent configurations cannot automatically detect inconsistencies between the two modes during configuration changes. This embodiment proposes a unified application description model that defines the complete application topology using a single declarative YAML specification. Through a conditional field annotation mechanism (when_mode), it declares the configuration differences between SaaS and private delivery modes in the same description file, avoiding the maintenance of two independent descriptions. This fundamentally eliminates the problems of dual-mode configuration fragmentation and configuration drift, reducing configuration maintenance workload by approximately 50%, and ensuring configuration consistency across delivery modes through a unified verification mechanism.

[0180] Regarding the arrangement of configuration parameters, compared with the lack of structured management of configuration parameters between the two delivery modes in the existing technology, this embodiment proposes a three-layer configuration layering model of basic layer 721, environment layer 722, and delivery mode layer 723, which realizes structured layered management of configuration, enabling centralized maintenance of common configurations and on-demand coverage of differential configurations, significantly reducing the complexity of configuration management in multi-environment and multi-mode scenarios.

[0181] Regarding dual-mode pipelines, compared to existing technologies that use two separate CI / CD build and deployment pipelines for Kubernetes Helm Charts and Docker Compose, which independently execute steps such as code checkout, image building, artifact packaging, and release, this implementation constructs a unified dual-mode build pipeline 74 based on Jenkins. This pipeline simultaneously produces HelmChart artifacts and Docker Compose offline package artifacts from the same codebase and in the same build. After the dual-mode artifacts are generated, the version consistency checker 745 automatically compares the image digest referenced in the Helm Chart with the image digest in the Docker Compose artifact to ensure that the dual-mode output artifact versions are consistent. This ensures the binary consistency of the dual-mode artifacts from the build source, eliminates the risk of version inconsistency caused by independent builds, and achieves full-link version traceability.

[0182] In terms of dual-mode encapsulation, compared with existing technologies, there is a lack of standardized methods and tools to encapsulate the application stack into an integrated solution that can be deployed offline. The encapsulation process needs to be adjusted accordingly every time the application architecture changes or a new service is added. When using simple delayed waiting or fixed sequence startup, there is a lack of a dependency-aware startup orchestration mechanism based on health checks. Operations such as image updates, configuration migrations, and database migrations usually need to be performed manually. There is a lack of incremental update and automatic rollback capabilities, and a lack of a systematic integrity verification mechanism. During deployment, it is impossible to reliably detect whether the package content is complete and has not been tampered with. This embodiment encapsulates application services, Nginx reverse proxy, PostgreSQL database, Grafana monitoring panel, and Fluent-bit log collection components into a single Docker Compose package for offline deployment. It proposes a standardized private encapsulator, transforming private delivery from customized development to a standardized process, significantly reducing delivery cycle and implementation costs. Services are started in the order of dependency topology (database → application service → reverse proxy → monitoring component), and downstream services are started only after health checks confirm the readiness of dependent components. This introduces a dependency-aware service startup orchestration mechanism into the offline deployment process, improving the reliability of offline deployment through a dependency-aware intelligent deployment mechanism. It supports a standardized upgrade mechanism for incremental image updates, configuration migration, database migration, and one-click rollback. When a component fails to start, an intelligent retry strategy is executed—if a dependency is not ready, it waits and retryes (maximum 300 seconds); if the component itself fails, it exponentially backs off retrying (maximum 3 times). After all retry failures, a diagnostic report containing the failed component, dependency status, and log summary is generated, implementing an integrity verification mechanism to help operations personnel quickly locate the root cause of the problem.

[0183] In terms of dual-mode observation, compared with existing technologies, the mature observability solutions in the Kubernetes environment (Grafana + SkyWalking + Fluent-bit + Loki) cannot be directly reused in the Docker Compose private environment. This results in a serious lack of observability capabilities in the private delivery scenario, making it impossible to grasp the application's running status and resource usage in real time. In the private environment, logs are only written to local files, which does not support structured storage and querying. The private deployment solution does not include tracing capabilities, making it difficult to conduct distributed problem investigation through inter-service call links. The dual-mode alarm rules are defined and maintained independently, which does not support cross-platform adaptation and has high maintenance costs. Application fault investigation in the private environment mainly relies on manual login to the server to check logs and container status, which makes the fault location cycle long. This embodiment defines a unified JSON structured log format (including standard fields such as timestamp, level, service, trace_id, and message) and a unified metric naming system that follows the Prometheus naming convention. This ensures that logs and metrics have the same data structure in both environments. Through unified YAML format alert rules, the unified observable adapter 76 converts them into Grafana Alert Rules for the Kubernetes environment and local alert scripts for the Docker Compose environment, respectively. This ensures the semantic equivalence of alert triggering conditions, enabling the operations team to monitor and troubleshoot applications in both delivery modes in a unified manner. This significantly improves the operational efficiency and service quality of the private environment.

[0184] The steps described above are only for clarity. In practice, they can be combined into one step or some steps can be broken down into multiple steps. As long as they involve the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, as long as they do not change the core design of the algorithm and process, are also within the scope of protection of this patent.

[0185] The second embodiment of this application provides a containerized application orchestration system with dual-mode delivery, referencing... Figure 15 As shown, the containerized application orchestration system 70 includes: The description module 71, located in the description layer, is used to define the topology and input sources of the dual-mode orchestration engine 73 based on a unified application description model using a single declarative specification. It generates a description file by annotating the configuration information of the target delivery mode through conditional fields. The configuration layer module 72, located in the transformation layer, is used to read the original configuration parameters according to the description file, configure the base layer 721, environment layer 722 and delivery mode layer 723 according to the priority of each layer, perform hierarchical deep merging, and generate orchestration configuration parameters. The dual-mode orchestration engine 73, located in the transformation layer, is used to filter conditional fields in the description file according to the target delivery mode to obtain the description data structure. In public mode, it converts the description data structure and orchestration configuration parameters into a directory structure that generates a directory and environment overlay files. In private delivery mode, it converts the description data structure and orchestration configuration parameters into orchestration files, environment variable files and reverse proxy configuration files. The dual-mode build pipeline 74, located in the build layer, is used to build a unified CI / CD pipeline. It sequentially executes code checkout, image building, parallel generation of dual-mode artifacts, version consistency verification, and artifact release. In the same build, it executes the public artifact generation path (which generates public artifacts) and the private artifact generation path (which generates private offline package artifacts) in parallel. The dual-mode build pipeline 74 includes a code checkout unit 741 that performs code checkout, an image building unit 742 that performs image building, a public artifact generation unit 743 that performs the public artifact generation path, a private artifact generation unit 744 that performs the private artifact generation path, a version consistency verifier 745 that performs version consistency verification, and a release unit 746 that performs artifact release after the version consistency verification is passed. Version consistency checker 745, belonging to dual-mode build pipeline 74, is used to publish public and private offline package products when the version consistency check of the image digest corresponding to each service in public and private offline package products passes; otherwise, the build is aborted and an error report is generated. The encapsulator 75, located in the encapsulation layer, includes a public encapsulator and a private encapsulator. The public encapsulator is used to encapsulate public products, and the private encapsulator is used to encapsulate private offline package products. The Unified Observable Adapter 76, located in the observation layer, is used to observe the monitoring component stack corresponding to the target delivery mode based on a unified structured log format, naming convention, indicator system, and alarm rule definition.

[0186] Other implementation details and working methods of the dual-mode delivery containerized application orchestration system 70 disclosed in this application are the same as or similar to the dual-mode delivery containerized application orchestration method described above, and will not be repeated here.

[0187] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A containerized application orchestration method with dual-mode delivery, characterized in that, The method includes: Based on the unified application description model, a description file is generated by defining the topology structure using a single declarative specification. The description file uses conditional fields to mark the configuration information of the target delivery mode, which includes public delivery mode and private delivery mode. The original configuration parameters are read from the description file, and the base layer, environment layer and delivery mode layer of the containerized application are configured according to the priority of each layer. Then, a hierarchical deep merge is performed to obtain the orchestration configuration parameters. Based on the target delivery mode, the conditional fields in the description file are filtered to obtain the description data structure. In the public delivery mode, the description data structure and the orchestration configuration parameters are converted into a directory structure that generates a directory and environment overlay files. In the private delivery mode, the description data structure and the orchestration configuration parameters are converted into an orchestration file, an environment variable file, and a reverse proxy configuration file. A continuous integration and continuous delivery pipeline is built to perform code checkout, image building, parallel generation of dual-mode artifacts, version consistency verification, and artifact release. In the same build, the public artifact generation path and the private artifact generation path are executed in parallel. When the version consistency verification of the image digest corresponding to each service in the public artifact and the private offline package artifact passes, the public artifact and the private offline package artifact are released. Otherwise, the build is aborted and an error report is generated. Encapsulate the public product and the private offline package product; Based on a unified structured log format, a naming convention-based indicator system, and alarm rule definitions, the monitoring component stack corresponding to the target delivery mode is observed.

2. The method according to claim 1, characterized in that, Based on a unified application description model, a description file is generated by defining the topology structure using a single declarative specification. Configuration information for the target delivery mode is annotated with conditional fields to update the description file, including: The service definition list, network policy definition, and configuration layer references for the containerized application are written using the YAML specification to generate the description file. The service definition list includes service components, dependencies, resource requirements, configuration parameters, health check policies, and storage volume declarations. The network policy definition includes ingress traffic rules for external traffic reaching the application service and inter-service communication rules for network access permissions between services within the application. The configuration layer references include configuration files pointing to the base layer, configuration files mapping each deployment environment to the environment layer, and configuration files mapping each delivery mode to the corresponding delivery mode layer. A conditional field is introduced to annotate the configuration information of the target delivery mode in the same description file to update the description file; when the configuration information is effective in both public and private delivery modes, the field value of the conditional field is all; when the configuration information is effective only in public delivery mode, the field value of the conditional field is saas; and when the configuration information is effective only in private delivery mode, the field value of the conditional field is privatized. The four-level verification process, consisting of data structure verification, dependency verification, resource constraint verification, and conditional field verification, is executed sequentially.

3. The method according to claim 1, characterized in that, The process involves reading the original configuration parameters from the description file, configuring the base layer, environment layer, and delivery mode layer of the containerized application according to the priority of each layer, and performing hierarchical deep merging to obtain orchestration configuration parameters, including: Configure the base layer according to the service image tags, default resource quotas, default environment variables, default number of replicas, and default health check parameters of each service in the description file. Configure the environment layer according to the database, external service address, log level, number of replicas and resource quota corresponding to each environment in the description file; Configure the delivery mode layer according to the configuration information corresponding to the public delivery mode and the configuration information corresponding to the private delivery mode in the description file; Based on the merging strategy corresponding to the data types, a hierarchical deep merging algorithm is executed on the base layer, the environment layer, and the delivery mode layer in order of low priority to high priority to obtain the final configuration parameters. The merging formula in the deep merging algorithm is: ， Among them, base_config is the configuration parameter for the base layer, env_config is the configuration parameter for the environment layer, mode_config is the configuration parameter for the delivery mode layer, and final config is the final configuration parameter; The merger strategy includes: When the data type is a scalar value, the higher priority value overrides the lower priority value; When the data type is a list value, use a higher priority list instead of a lower priority list; When the data type is a dictionary value, iterate through all keys in the high-priority dictionary. If the key does not exist in the low-priority dictionary, add the key to the high-priority dictionary. If the key exists in the low-priority dictionary and the dictionary types are the same, perform a recursive deep merge. If the key exists in the low-priority dictionary and the dictionary types are different, handle the conflict resolution strategy. The conflict resolution strategies include: when the value types of the same configuration key are inconsistent in the high-priority layer and the low-priority layer, the value in the high-priority layer overwrites the value in the low-priority layer; when the same configuration key is an empty string in the high-priority layer, the empty string is used as the result of the merging strategy; when the same configuration key is a special marker delete in the high-priority layer, the key is deleted in the result of the merging strategy. The conflict resolution strategy further includes generating a merge audit log when the configuration key is overridden, added, or set to null. The merge audit log includes the conflicting key path, the value and type of the key at the low priority level, the value and type of the key at the high priority level, the value and type of the key in the result of the merge strategy, and field operation identifiers, including overridden, added, conflict_resolved, deleted, and unchanged.

4. The method according to claim 3, characterized in that, The description data structure is obtained by filtering the conditional fields in the description file according to the target delivery mode, including: S311, Traverse the data structure of the description file to obtain the current field; S312, determine whether the current field contains the when_mode annotation. If it exists, execute S313. Otherwise, retain the current field value and treat the when_mode annotation of the field value as all. S313, determine if the character after when_mode is all or corresponds to the target delivery mode. If so, retain the current field value and execute step S314. Otherwise, filter the current field value and execute S316. S314. Determine whether the current field satisfies value-level conditionalization. If yes, extract the value corresponding to the target delivery mode to replace the conditionalization structure and execute step S315. Otherwise, execute step S316. S315, Determine if the character after when_mode in the target delivery mode is declared. If yes, output the field value of the target delivery mode and execute S316. If no, output the default value and execute S316. S316, process the next field, until all fields corresponding to the description file have been processed, and finally output the filtered description data structure; In the public delivery model, the description data structure and orchestration configuration parameters are converted into a directory structure that generates directories and environment overlay files, including: The values.yaml generation process includes extracting global-level configurable parameters from the data structure description and orchestration configuration parameters as global parameters; iterating through the spec.services list describing the data structure; extracting and generating corresponding parameter blocks for each service definition according to the rules of image parameterization, replica number parameterization, resource quota parameterization, environment variable parameterization, health check parameterization, and storage volume parameterization; comparing the environment layer configuration parameters with the default values.yaml key by key, and only writing the key-value pairs that differ to the environment overwrite file. Template rendering involves converting service definitions in the data structure into parameterized Kubernetes resource template files. Kubernetes resource templates include Deployment templates, Service templates, ConfigMap templates, Ingress templates, and helper function templates. Chart structure assembly includes generating a Chart.yaml metadata file, assembling the directory structure, standardizing template file naming, and outputting the directory structure when the chart integrity check passes; otherwise, generating a structured error report and aborting the conversion. In private delivery mode, the description data structure and the orchestration configuration parameters are converted into orchestration files, environment variable files, and reverse proxy configuration files, including: The docker-compose.yml orchestration file is generated using the docker-compose.yml generation algorithm; The .env environment variable file is generated using an environment variable mapping algorithm; The Nginx reverse proxy configuration file is generated using a network configuration algorithm; Perform a compose file validation. If the validation passes, output the docker-compose.yml orchestration file, the .env environment variable file, and the Nginx reverse proxy configuration file. Otherwise, generate a structured error report and abort the conversion.

5. The method according to claim 1, characterized in that, The code detection includes: According to the checkout strategy corresponding to the triggering method, the application code is checked out from the Git repository, the version number is extracted from the application code, the build metadata is generated after the version number is determined, and the build metadata is written to the build file build-metadata.json in the workspace in JSON format; The triggering methods include tag triggering, branch triggering, and manual triggering. The version number is extracted from the Git tag name in the application code, or the version number is calculated based on the branch name and the most recent Git tag. The image construction includes: The base path and build context corresponding to the service definition are read from the description file. A container image is compiled and generated based on the build context and base path corresponding to each service definition. An image tag for the container image is generated by short hash encoding according to the version number of each service definition and the build metadata. The container image is pushed to the image repository. An image digest is obtained by calculating the hash value based on the image content of the container image. The image digest is recorded in the build file.

6. The method according to claim 1, characterized in that, The parallel generation of the dual-mode products includes: Based on the container image and the image digest, the public artifact generation path and the private artifact generation path are executed in parallel during the same build. In the public artifact generation path corresponding to the public delivery mode, the image reference in the directory structure is updated according to the image tag and image summary, the updated directory structure is packaged to obtain the public artifact, the public artifact is pushed to the public repository, and the repository address and version information of the public repository are updated to the build file. In the private artifact generation path corresponding to the private delivery mode, the locally exported container image is compressed to obtain an image package, and the orchestration file, the environment variable file, the reverse proxy configuration file, the image package deployment script, and the database migration script are assembled into a private offline package artifact.

7. The method according to claim 1, characterized in that, The version consistency check includes: A public image reference mapping table is constructed based on the image repository address, image tag, and image digest of each service extracted from the public artifacts. A private image reference mapping table is constructed based on the field values ​​of each service extracted from the private offline package artifacts and the image digest in the construction metadata. The image digest belongs to the binary content corresponding to the container image of the service, and the image digest is a SHA256 hash value calculated based on the image content. A verification result is generated by comparing the public mirror reference mapping table with the private mirror reference mapping table for each service. The verification result includes the service name, public side mirror reference information and mirror digest, private side mirror reference information and mirror digest information, and the type of mirror inconsistency. When the verification result indicates that the verification is successful, an error report in JSON format is generated. The version list includes the build version number, build number, build timestamp, image repository address, image name of each service, image tag of each service, image summary of each service, public artifacts, private offline package artifacts, and verification result. When the verification result indicates failure, the construction of the continuous integration and continuous delivery pipeline is stopped, intermediate artifacts are exported, a structured error report is generated, and the error report is sent to the client corresponding to the service when all service comparisons are completed. The error report includes a list of inconsistent services and a summary of the corresponding service image.

8. The method according to claim 1, characterized in that, Encapsulating the private offline package artifact includes: The application service component, reverse proxy component, database component, monitoring panel component, and log collection component are integrated and packaged into a single offline deployment package; Export the container images of all services from the build environment as archive files to generate offline image packages; During the initial deployment, an offline deployment initialization is performed, which includes verifying the integrity of the installation package, loading the image, generating the configuration, starting the service in the order of dependencies, performing a health check, and outputting a deployment result report. When a version upgrade command exists in the private offline package artifact, the corresponding incremental image update, configuration migration, database migration, and service rollback and restart are executed. When a component in the private offline package fails to start, a corresponding retry strategy is used to diagnose the fault based on the health status of the dependent components.

9. The method according to claim 1, characterized in that, The monitoring component stack corresponding to the target delivery mode includes: In the public delivery mode, metrics are monitored through Prometheus monitoring and Grafana visualization panel, link tracing is performed through observable analytics backend and application probes, logs are collected through the lightweight log collector of the daemon set and Loki, and logs are queried through Grafana visualization panel and Loki logging system, realizing a full-stack monitoring solution for Kubernetes environment to observe resource objects. In private delivery mode, metrics are monitored through in-application metric endpoints and the Grafana visualization panel, trace links are performed by associating trace_id in application logs, logs are collected through a lightweight log collector and local file storage, and logs are queried through the Grafana visualization panel and local log file browsing component, thus realizing a lightweight solution for observing resource objects in the DockerCompose environment.

10. A containerized application orchestration system with dual-mode delivery, characterized in that, The system includes: The description module, located in the description layer, is used to define the topology and input sources of the dual-mode orchestration engine based on a unified application description model using a single declarative specification. It generates description files by annotating the configuration information of the target delivery mode through conditional fields. The configuration layering module, located in the transformation layer, is used to read the original configuration parameters according to the description file, configure the base layer, environment layer and delivery mode layer according to the priority of each layer, perform hierarchical deep merging, and generate orchestration configuration parameters. A dual-mode orchestration engine, located in the transformation layer, is used to filter the conditional fields in the description file according to the target delivery mode to obtain the description data structure. In public mode, the description data structure and the orchestration configuration parameters are converted into a directory structure that generates a directory and environment overlay files. In private delivery mode, the description data structure and the orchestration configuration parameters are converted into an orchestration file, an environment variable file, and a reverse proxy configuration file. The dual-mode build pipeline, located in the build layer, is used to build a unified continuous integration and continuous delivery pipeline. It sequentially executes code checkout, image building, parallel generation of dual-mode artifacts, version consistency verification, and artifact release. In the same build, it executes the public artifact generation path that generates public artifacts and the private artifact generation path that generates private offline package artifacts in parallel. The version consistency checker, which belongs to the dual-mode build pipeline, is used to publish the public product and the private offline package product when the version consistency check of the image digest corresponding to each service in the public product and the private offline package product passes; otherwise, the build is stopped and an error report is generated. A wrapper, located in the encapsulation layer, is used to encapsulate the public product and the private offline package product; The unified observable adapter, located in the observation layer, is used to monitor the stack of components corresponding to the observation target delivery mode, based on a unified structured log format, naming conventions, indicator system, and alarm rule definition.

Images