Hybrid cloud environment-oriented dynamic dual-state deployment management method and system

Abstract

The invention provides a dynamic dual-state deployment management method and system for a hybrid cloud environment, belongs to the technical field of cloud computing and edge computing fusion deployment, and aims to solve the problems that deployment of a large cloud platform and an all-in-one machine platform needs multi-branch maintenance, scripts are manually changed, and separate deployment packages are easy to select mistakenly. In the construction stage, a pre-compiling engine scans a condition compiling instruction in an SQL and configuration template, environment exclusive resources are generated according to platform types, and resource hash and deployment package fingerprints are calculated; in the deployment stage, a dynamic arbiter judges a target environment according to the priorities of forced configuration, Kubernetes node tags, hardware fingerprints and default values, and loads matching configuration and pre-compiling resources; and the consistency verification module executes matching verification of the template hash, the resource hash and the runtime hash, and gives an alarm and stops or returns in case of abnormality. Uniform delivery, reliable deployment and traceable rollback are realized by only loading applicable functions in different environments through the same deployment package and combining version migration and security isolation.

Description

A dynamic dual-state deployment management method and system for hybrid cloud environments Technical Field

[0001] This invention belongs to the field of cloud computing and edge computing convergence deployment technology, and in particular relates to a dynamic dual-state deployment management method and system for hybrid cloud environments. Background Technology

[0002] In government and enterprise software systems, a common deployment pattern is the coexistence of a large cloud platform in the cloud and a local integrated machine platform. On the one hand, there is a need for elastic scaling in the cloud, and on the other hand, there is a need for local data residency and local processing. The deployment management of existing hybrid cloud environments usually adopts methods such as maintaining multiple branches independently, manually adapting scripts before deployment, or compiling and separating deployment packages for different environments: for example, maintaining two sets of code or branches, one for cloud and one for local, in the code repository, or manually replacing the environment identifiers in the SQL script and configuration file before deployment, and then manually selecting the deployment package corresponding to the environment for installation.

[0003] The above approach is prone to the following problems in practice: First, multiple branches or code repositories lead to repetitive development and synchronization difficulties, easily resulting in version inconsistencies, merge conflicts, and version drift. Second, SQL scripts and static configurations are difficult to process dynamically during deployment or runtime, still relying on manual intervention in advance, which lacks flexibility. Third, each update requires separate packaging and manual verification of environment compatibility, significantly lengthening the deployment cycle. Fourth, there are differences in functional logic between cloud computing and integrated machines, and direct upgrades may lead to the loss of customized functions or abnormalities in standard functions, making it difficult to switch, upgrade, or migrate directly between versions. Fifth, storing multiple copies of code and configurations for the same function results in resource waste.

[0004] Therefore, a deployment management solution is needed that can automatically identify the target runtime platform, automatically generate or load platform-matching resources, and perform consistency verification of the deployment package version and runtime configuration, under the premise of a unified code repository and unified deployment package, in order to reduce human error and improve upgrade compatibility. Summary of the Invention

[0005] In view of this, the present invention aims to propose a dynamic dual-state deployment management method and system for hybrid cloud environments, so as to at least solve one of the problems in the background art.

[0006] To achieve the above objectives, the technical solution of the present invention is implemented as follows: A dynamic dual-state deployment management method for hybrid cloud environments, wherein the hybrid cloud environment includes a cloud platform and an all-in-one platform, comprising: S1, obtaining the platform type variable platType, resource path, and placeholder parameters defined in the deployment description file; S2, performing pre-compilation on the template resources to be released during the build phase, identifying the conditional compilation instructions embedded in the template resources, generating a corresponding set of target resource files according to the platType or its candidate values, and calculating a resource hash for the set of target resource files; S3, encapsulating the set of target resource files, the resource hash, and fingerprint information into a deployment package, wherein the fingerprint information includes at least a platform type identifier, a version number, and a build identifier; S4, determining the target running platform type by a dynamic environment arbitrator according to a preset priority during the deployment phase, wherein the priority is, in order, forced configuration, Kubernetes node label, hardware fingerprint, and default value; S5, loading the configuration and target resource file set matching the target running platform type at runtime, and calculating the runtime hash; S6, performing a consistency check based on the runtime hash and the resource hash, continuing deployment if the check passes, and outputting an alarm and stopping or rolling back the deployment if the check fails.

[0007] Furthermore, the template resources include at least one or more of SQL scripts, YAML resource manifests, and application static configuration files, and the pre-compilation scans the template resources file by file to extract conditional compilation instructions and placeholder parameters.

[0008] Furthermore, the conditional compilation directive includes a condition start marker and a condition end marker. The condition start marker is used to express a Boolean condition related to platType. The pre-compilation retains the corresponding code block when the condition is met, and deletes or comments the corresponding code block when the condition is not met.

[0009] Furthermore, the pre-compilation generates at least two sets of target resource files according to different values ​​of platType, and outputs the target resources corresponding to different values ​​to mutually isolated resource paths or directory levels, so that the same deployment package contains resource versions that can be selected for different platform types.

[0010] Furthermore, the fingerprint information is output with the deployment package in the form of a manifest file. The manifest file records at least the platform type identifier, version number, build time, and hash digest of the target resource file set to support deployment package version tracing and rollback location.

[0011] Furthermore, when determining the target running platform type, the dynamic environment arbitrator: if a forced configuration is detected, it directly uses the platType specified by the forced configuration; if no forced configuration is detected, it reads the Kubernetes node label and obtains the platType based on the label value mapping; if the node label is not matched, it collects the hardware fingerprint and obtains the platType based on the hardware fingerprint feature matching; if none of the above matches, it uses the preset default platType.

[0012] Furthermore, the consistency verification includes at least three levels of hash verification: calculating template hashes for template resources during the build phase; calculating resource hashes for the target resource file set after pre-compilation; and calculating runtime hashes for the runtime-loaded configuration and target resources during the deployment phase, and then matching and verifying the runtime hashes with the resource hashes.

[0013] Furthermore, the method also includes version migration processing: when switching or migrating between the cloud platform and the all-in-one machine platform, the configuration items and database change scripts are converted according to preset mapping rules, and the conversion includes at least the adaptation of field addition, deletion or differential initialization logic.

[0014] Furthermore, this solution discloses a dynamic dual-state deployment management system for hybrid cloud environments, including: a dual-state pre-compilation engine, used to parse conditional compilation instructions in template resources during the build phase and generate a set of target resource files corresponding to different platTypes; a dynamic environment arbitrator, used to determine the target running platform type during the deployment phase based on the priority of forced configuration, Kubernetes node tags, hardware fingerprints, and default values; a consistency verification module, used to perform matching verification between the resource hashes obtained from pre-compilation and the runtime hashes; and a fingerprint marking module, used to generate and output a deployment package fingerprint list containing platform type identifiers and version information.

[0015] Furthermore, it also includes a resource isolation and security control module, which is used to isolate and store sensitive configurations according to platform type, enable local encrypted storage under the appliance platform, and restrict access permissions for configurations of different platform types based on Kubernetes RBAC.

[0016] Compared with existing technologies, the dynamic dual-state deployment management method and system for hybrid cloud environments described in this invention have the following advantages: (1) This invention enables a single codebase to be reused and adapted to multiple environments through variable injection and dynamic template pre-compilation, reducing the burden of branch management and synchronous updates, and lowering the risk of version drift; (2) This invention generates environment-specific resources and solidifies resource hashes during the build phase, and verifies the matching between runtime loading configuration and pre-compiled resources during the deployment phase, avoiding version mismatch and abnormal deployment caused by selecting the wrong package, changing the wrong configuration, or tampering with resources; (3) The dynamic environment arbitrator of this invention can determine the environment type according to the priority strategy, and supports forced configuration and Kubernetes node tags. (4) This invention generates a unique fingerprint for each deployment package and records information such as environment type, version number and compilation time, making the problem version location and rollback more direct and reducing the investigation time; (5) In this invention, the same deployment package only loads applicable functions in different environments, reducing upgrade conflicts; and can provide version migration tools to support configuration conversion between big cloud and all-in-one machine, such as conversion of differences such as SQL field addition and deletion, improving the operability of cross-environment upgrade and migration; (6) The sensitive configuration of this invention can be stored in isolation according to environment. Local encrypted storage can be enabled in the all-in-one machine environment, and the configuration access permissions of different environments can be restricted through Kubernetes RBAC to reduce the risk of unauthorized access and misuse. Attached Figure Description

[0017] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 is a schematic flowchart of the method described in an embodiment of the invention. Detailed Implementation

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0019] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0020] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0021] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] Example 1: System Overall Structure and Module Composition This invention can be implemented as a dynamic dual-state deployment management system, including at least a dual-state pre-compilation engine, a dynamic environment arbitrator, a consistency verification module, and a fingerprint tagging module. The dual-state pre-compilation engine parses conditional compilation instructions in template resources during the build phase, generates a set of target resource files corresponding to different platform types, and outputs a deployment package with fingerprint tags. The dynamic environment arbitrator automatically determines the target environment type during the deployment phase. The consistency verification module verifies the hash matching between pre-compiled resources and runtime configurations before deployment to prevent version mismatches. The fingerprint tagging module records information such as environment type, version number, and compilation time to support problem localization and rollback.

[0023] Optionally, the system may also include a resource isolation and security control module for isolating sensitive configurations by environment, enabling local encrypted storage in an all-in-one machine environment, and implementing permission constraints in conjunction with Kubernetes RBAC; it may also include an automation toolchain integration module to work with CI / CD tools and provide CLI tools for developers to perform local pre-compilation verification.

[0024] Example 2: Method Flow and Key Data Objects 1) Configuration Phase: Define the environment variable platType and resource path in the YAML resource manifest or deployment description file. platType is used to identify the target running platform type. For example, cloud represents a large cloud platform and local represents an all-in-one machine platform. At the same time, configure the template path of static resources such as target SQL scripts and YAML configuration files.

[0025] 2) Compilation Phase and Pre-compilation Generation: The dual-state pre-compilation engine scans template files, identifies conditional compilation directives embedded in SQL scripts and configuration files, generates environment-specific SQL and configuration file versions according to platType, and outputs the deployment package. To avoid hard-coded dependencies, platform type placeholders or conditional tags can be used in the template to express differentiated logic, such as automatically generating environment-adaptive versions through conditional tags.

[0026] 3) Deployment phase and dynamic loading: The dynamic environment arbiter reads platType from ConfigMap or runtime environment variables, or automatically identifies the target environment by combining Kubernetes node tags, hardware fingerprints and other information. Then it loads the configuration and pre-compiled resources that match the target environment and enables the corresponding functional modules as needed.

[0027] 4) Consistency verification and blocking control: Before and after deployment, hash verification is performed on pre-compiled resources and runtime configuration. If a mismatch is found between the runtime loaded configuration and the pre-compiled resources, an alarm is output and the deployment is stopped or a rollback is triggered to reduce failures caused by incorrect environment selection, resource replacement or version mixing.

[0028] 5) Fingerprint and version tracking: Generate a unique fingerprint file for the deployment package, such as recording the environment type, version number, compilation time, etc. in the form of a manifest, for subsequent quick location of problematic versions and accurate rollback.

[0029] Example 3: Conditional Compilation Directives and SQL Differentiation Logic. To express differentiated logic for different environments in static resources, this invention embeds environment-sensitive conditional compilation directives in SQL scripts or configuration files. For example, a conditional block like "#[IF platType = 'cloud']" controls whether a certain piece of code is retained in different environments. The pre-compilation engine parses the conditional blocks during the build phase to generate the final SQL script for the corresponding environment, thereby achieving differentiated deployment without maintaining multiple sets of scripts.

[0030] Furthermore, to ensure that the SQL script executes differentiated logic on demand at runtime, conditional branches related to platType can be introduced into the SQL. For example, when platType is cloud, the preset logic related to cloud_config is called, and when platType is local, the preset logic related to local_config is called. This way, the differences are expressed in the template layer and the output is solidified by the pre-compilation.

[0031] Example 4: Three-level hash verification and environment arbitration priority 1) Three-level hash verification: Template hash is used to verify the integrity of template files during construction to reduce the risk of tampering; resource hash is used to calculate the digest of the compiled deployment package to ensure that the compilation process and output resources are consistent; runtime hash is used to calculate the digest of ConfigMap and loaded resources during deployment and to match and verify with resource hash to avoid version mismatch.

[0032] 2) Environment Arbitration Priority Strategy: The dynamic arbitrator determines the environment type based on priority. It can prioritize manual forced configuration, then read Kubernetes node tags, and finally combine these with the characteristics of the hardware fingerprint recognition device. If none of these match, it reverts to the default environment type. This strategy facilitates manual fallback in special scenarios while maintaining automatic identification capabilities.

[0033] Example 5: Differentiated Deployment Example of Instance Management Module. Taking the instance management module as an example, the appliance environment needs to record regional information, while the cloud environment does not require this function. The `platType` can be specified as `local` in the YAML configuration, and the generation of the `region_code` field can be controlled by conditional compilation directives in the SQL template. During the build phase, the pre-compilation engine retains the `region_code` field when parsing the template and outputting the appliance version SQL, but deletes the corresponding field when outputting the cloud version SQL. During deployment, if the dynamic arbitrator reads `platType` as `local`, it loads the appliance version SQL and configuration, and enables the validation logic related to `region_code`.

[0034] This example demonstrates that by using conditional templates and dynamic arbitration, environmental differences can be transformed from "manual script modification and branch maintenance" to "template expression and automatic generation loading," thereby reducing the amount of manual operation in the deployment process and minimizing errors.

[0035] Example 6: Version Migration, Security Isolation and Toolchain Integration. In cross-environment switching or upgrade migration scenarios, version migration tools can be provided to convert configuration items and database change scripts according to preset mapping rules. For example, differences can be handled for the addition or deletion of SQL fields, making the version switching between the cloud and the appliance smoother.

[0036] In terms of security, sensitive configurations are stored in isolation according to the environment. In the all-in-one machine environment, local encrypted storage can be enabled, and Kubernetes RBAC is used to restrict access permissions for configurations to avoid unauthorized access across environments.

[0037] From a practical implementation perspective, it can be integrated with CI / CD tools to form an automated process from code submission, pre-compilation, generation of deployment packages, to deployment in the target environment; at the same time, it provides CLI tools to support developers to perform pre-compilation and verification locally, reducing debugging costs and exposing environmental differences in advance.

[0038] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A dynamic dual-state deployment management method for hybrid cloud environments, wherein the hybrid cloud environment includes a cloud platform and an all-in-one machine platform, characterized in that, include: S1. Obtain the platform type variable platType, resource path, and placeholder parameters defined in the deployment description file; S2. During the build phase, pre-compile the template resources to be released, identify the conditional compilation instructions embedded in the template resources, generate the corresponding target resource file set according to the platType or its candidate values, and calculate the resource hash for the target resource file set; S3. Encapsulate the target resource file set, the resource hash, and fingerprint information into a deployment package, wherein the fingerprint information includes at least the platform type identifier, version number, and build identifier; S4. During the deployment phase, the dynamic environment arbitrator determines the target running platform type according to a preset priority, wherein the priority is, in order, forced configuration, Kubernetes node label, hardware fingerprint, and default value; S5. At runtime, load the configuration and target resource file set that match the target running platform type, and calculate the runtime hash; S6. Perform a consistency check based on the runtime hash and the resource hash. If the check passes, continue deployment; if the check fails, output an alarm and abort or rollback the deployment.

2. The method according to claim 1, characterized in that, The template resources include at least one or more of the following: SQL scripts, YAML resource manifests, and application static configuration files. The pre-compilation scans the template resources file by file to extract conditional compilation directives and placeholder parameters.

3. The method according to claim 1 or 2, characterized in that, The conditional compilation directive includes a condition start marker and a condition end marker. The condition start marker is used to express a Boolean condition related to platType. The pre-compilation retains the corresponding code block when the condition is met, and deletes or comments the corresponding code block when the condition is not met.

4. The method according to claim 1, characterized in that, The pre-compilation generates at least two sets of target resource files according to different values ​​of platType, and outputs the target resources corresponding to different values ​​to mutually isolated resource paths or directory levels, so that the same deployment package contains resource versions that can be selected for different platform types.

5. The method according to claim 1, characterized in that, The fingerprint information is output with the deployment package in the form of a manifest file. The manifest file records at least the platform type identifier, version number, build time, and hash digest of the target resource file set to support deployment package version tracing and rollback location.

6. The method according to claim 1, characterized in that, When determining the target operating platform type, the dynamic environment arbitrator directly uses the platType specified by the forced configuration when a forced configuration is detected; when no forced configuration is detected, it reads the Kubernetes node label and obtains the platType based on the label value mapping; when the node label is not matched, it collects the hardware fingerprint and obtains the platType based on the hardware fingerprint feature matching; when none of the above matches, it uses the preset default platType.

7. The method according to claim 1, characterized in that, The consistency verification includes at least three levels of hash verification: During the build phase, a template hash is calculated for the template resources; after pre-compilation, a resource hash is calculated for the target resource file set; and during the deployment phase, a runtime hash is calculated for the runtime-loaded configuration and target resources, and the runtime hash is matched and verified against the resource hash.

8. The method according to claim 1, characterized in that, The method also includes version migration processing: when switching or migrating between the cloud platform and the all-in-one machine platform, the configuration items and database change scripts are converted according to preset mapping rules. The conversion includes at least the adaptation of field addition, deletion or differential initialization logic.

9. A dynamic dual-state deployment management system for hybrid cloud environments, characterized in that, include: A dual-state pre-compilation engine is used to parse conditional compilation directives in template resources during the build phase and generate a set of target resource files corresponding to different platTypes; A dynamic environment arbitrator is used to determine the target runtime platform type during the deployment phase based on the priority of forced configuration, Kubernetes node tags, hardware fingerprints, and default values. The consistency verification module is used to perform matching verification between the pre-compiled resource hash and the runtime hash; The fingerprinting module is used to generate and output a list of deployment package fingerprints that include platform type identifiers and version information.

10. The system according to claim 9, characterized in that, It also includes a resource isolation and security control module, which is used to isolate and store sensitive configurations according to platform type, enable local encrypted storage under the appliance platform, and restrict access permissions for configurations of different platform types based on Kubernetes RBAC.

Images