A multi-cloud environment upgrade method and control platform based on GitOps

Abstract

This invention discloses a GitOps-based method and control platform for upgrading multi-cloud environments, aiming to reduce the deployment and upgrade costs of multi-cloud environments and enable OP users to manage, iterate, and maintain them in a unified manner, just like SaaS users. This method takes snapshots of the SaaS environment in the cloud and, with the help of GitOps repository commits and parsing, solidifies complex microservice architectures, database objects, seed scripts, template files, etc., in the form of environment snapshots. It uses GitOps technology to drive the environment initialization engine and facilitates convenient transfer between environments through snapshot replay for deployment and upgrades. This allows OP users to freely choose data storage locations while enjoying the benefits of out-of-the-box, cloud-native, and continuous iteration capabilities, achieving unified management, iteration, and maintenance of multi-cloud environments.

Description

Technical Field

[0001] The present application relates to the technical field of SaaS system development, and in particular to a multi-cloud environment upgrade method and control platform. Background Art

[0002] In the enterprise software market, SaaS (Software as a Service) enterprise applications have developed rapidly. A considerable number of users have been educated by the market and have begun to embrace SaaS, enjoying the benefits of SaaS's out-of-the-box use, cloud native, and continuous iteration.

[0003] However, some users still prefer to store data in their own computer rooms for various reasons and choose the OP (On-Premise) deployment mode. The traditional OP deployment mode is often a project delivery system, and the launch of the project means the end of the application development cycle. The later operation and maintenance often revolve around bug fixes. If there are new requirements, it usually takes a long supplementary contract cycle, which cannot quickly respond to the user's subsequent needs. In addition, there may be major personnel changes in subsequent developers and even project managers. The code is full of a large number of temporary, arbitrary, and even subversive modifications, and the delivery quality cannot be well guaranteed. At the same time, some valuable experience related to the project cannot be fed back to the software supplier's SaaS products. A large number of repetitive and homogeneous requirements are repeatedly implemented and cannot be effectively precipitated. Summary of the invention

[0004] Based on this, the present invention provides a multi-cloud environment upgrade method and control platform based on GitOps, aiming to reduce the deployment and upgrade costs of the multi-cloud environment, so that OP users can be uniformly managed, iterated, and operated and maintained like SaaS users.

[0005] First, (1) Generate an environment snapshot

[0006] Through scheduled tasks, the environment initialization engine periodically takes snapshots of the cloud SaaS environment, solidifies the version dependencies between microservices, between microservices and database objects, between microservices and seed data (i.e., the configuration data that the service depends on), and between microservices and template files, generates a unified product version, and saves it in the Harbor warehouse in the form of a docker image; the products here include microservices, database objects, seed data, and template files;

[0007] (2) Upgrade the environment initialization engine

[0008] When a multi-cloud environment upgrade is required, select the product version to be upgraded, obtain the environment initialization engine corresponding to the product version, update the version information of the environment initialization engine to the GitOps repository corresponding to the multi-cloud environment, and pull the docker image corresponding to the environment initialization engine from the Harbor repository according to the image information of the environment initialization engine described in the GitOps repository; complete the upgrade of the engine itself, and then start the environment initialization engine;

[0009] (3) Snapshot Replay

[0010] After the environment initialization engine is started, GitOps technology is used to drive the environment initialization engine to perform the replay of the environment snapshot: according to the image information of the product described in the GitOps warehouse, the docker image corresponding to the product is pulled from the Harbor warehouse to achieve the upgrade of the multi-cloud environment.

[0011] Furthermore, the step (1) of taking an environment snapshot of the SaaS environment in the cloud includes: capturing a snapshot of the microservice docker image version of the SaaS version production environment, a database object creation script, a seed data import script, and a template file, and compressing them, and then generating the unified product version according to the timestamp.

[0012] Furthermore, the environment initialization engine runs as an application in each multi-cloud environment; step (2) specifically includes:

[0013] 2.1) Select the multi-cloud environment to be upgraded, select the version generated in step (1) from the drop-down list of the environment initialization engine application, and confirm to execute the deployment;

[0014] 2.2) Update the version of the environment initialization engine to the GitOps repository corresponding to the multi-cloud environment;

[0015] 2.3) Using polling, when changes in the GitOps repository corresponding to the current multi-cloud environment are detected, the latest changes in the corresponding GitOps repository are pulled through SSH authentication and analyzed;

[0016] 2.4) After the analysis is completed, use helm to call the Kubernetes API to upgrade the environment initialization engine. Kubernetes pulls the corresponding version of the Docker image and starts running.

[0017] Furthermore, step (3) specifically includes:

[0018] 3.1) Decompress the existing compressed package;

[0019] 3.2) If there is a database object script update, use Liquibase to execute the database object creation script;

[0020] 3.3) If the seed data import script is updated, choose to use Liquibase to execute the seed data import script;

[0021] 3.4) Call the file service through feign to upload the template file;

[0022] 3.5) If there are application updates, submit the version updates of each application to the GitOps repository corresponding to the environment;

[0023] 3.6) Using polling, when changes in the GitOps repository corresponding to the environment are detected, the latest changes of the GitOps repository are pulled through SSH authentication and analyzed;

[0024] 3.7) After parsing is complete, use Helm to call the Kubernetes API to upgrade each application.

[0025] Second, a multi-cloud deployment control platform based on GitOps, including:

[0026] The environment initialization engine runs as an application in each multi-cloud environment. It takes snapshots of the cloud SaaS environment, solidifies the version dependencies between microservices, between microservices and database objects, between microservices and seed data, and between microservices and template files, and generates a unified product version. It replays the snapshot in the target environment to initialize or upgrade the environment.

[0027] The DevOps subsystem is used to perform unified CI / CD for products deployed to multi-cloud environments, and uses GitOps technology to drive the environment initialization engine to deploy and upgrade the environment;

[0028] DevOps Agent, as an agent tool, connects to the DevOps subsystem through WebSocket to receive commands and execute them.

[0029] Optionally, the multi-cloud deployment control platform also includes a UVPN subsystem for realizing a unified entrance for multi-cloud and multi-IDC, thereby supporting simultaneous operation and maintenance of SaaS environment and OP environment.

[0030] Optionally, the multi-cloud deployment control platform also includes a monitoring and early warning subsystem for realizing unified collection and unified early warning of cross-cloud and cross-IDC monitoring indicators and performance indicators with the help of UVPN.

[0031] Optionally, the multi-cloud deployment control platform also includes a log analysis subsystem for achieving unified collection and unified query of cross-cloud and cross-IDC application logs with the help of UVPN.

[0032] The present invention has at least the following beneficial effects:

[0033] The present invention solidifies complex microservice architectures, database objects, seed data scripts, template files, etc. in the form of environment snapshots by capturing environment snapshots and snapshot replays, and with the help of submission and analysis of GitOps repositories, and conveniently transfers them between environments through snapshot replay, allowing OP users to freely choose the data storage location while also enjoying the benefits of out-of-the-box use, cloud native, and continuous iteration, thereby achieving unified management, unified iteration, and unified operation and maintenance of multi-cloud environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 A schematic diagram of the architecture of a multi-cloud deployment control platform based on GitOps provided in one embodiment of the present invention;

[0035] Figure 2 A flowchart of a multi-cloud environment upgrade method based on GitOps provided by an embodiment of the present invention;

[0036] Figure 3 A schematic diagram of a snapshot replay process provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0038] like Figure 1 As shown, a multi-cloud deployment control platform based on GitOps provided by an embodiment of the present invention includes the following components:

[0039] UVPN subsystem: By creating tunnels at Layer 3 of the network to connect different networks and using the LDAP protocol for unified authentication, a unified entrance for multiple clouds and multiple IDCs is realized. Operation and maintenance personnel can operate and maintain SaaS environments and OP environments at the same time without installing additional VPN software, thus reducing operation and maintenance costs.

[0040] Environment initialization engine (environment initialization application): deployed in each multi-cloud environment, it takes snapshots of the cloud SaaS environment, solidifies the version dependencies between microservices, between microservices and database objects, between microservices and seed data (i.e., the configuration data that the service depends on), and between microservices and template files, and generates a unified product version. Snapshots can be easily transferred between different environments, and by replaying the snapshots in the target environment, the environment can be quickly initialized or upgraded;

[0041] Monitoring and early warning subsystem: With the help of UVPN, unified collection and early warning of cross-cloud and cross-IDC monitoring indicators and performance indicators are realized, which is used for early warning of abnormal indicators to avoid major catastrophic accidents;

[0042] Log analysis subsystem: With the help of UVPN, unified collection and query of cross-cloud and cross-IDC application logs are realized to assist in later troubleshooting and problem handling;

[0043] DevOps subsystem: Unify CI / CD for products deployed to multiple clouds, and use GitOps technology to drive the environment initialization engine to deploy and upgrade the environment;

[0044] DevOps Agent: An agent tool deployed in the corresponding environment, connected to the DevOps subsystem through WebSocket to receive commands and execute them.

[0045] The embodiment of the present invention also proposes a multi-cloud environment upgrade method based on GitOps, such as Figure 2 As shown, it mainly includes:

[0046] S1: Generate an environment snapshot

[0047] Through scheduled tasks, the environment initialization engine captures snapshots of necessary data files such as the microservice docker image version, database object creation script, seed data import script, template file, etc. of the SaaS version production environment every night, compresses them, and then generates snapshot versions according to timestamps, that is, generates a unified product version (involving microservices, database objects, seed data, and template files); then saves the environment snapshot in the Harbor warehouse in the form of a docker image;

[0048] S2: Upgrade the environment initialization engine

[0049] In the DevOps subsystem, all environments are deployed in the Kubernetes cluster. Each existing multi-cloud environment corresponds to an environment object and has a corresponding GitOps repository to record all changes in the environment. Each microservice is saved as an application in the form of a file in the corresponding GitOps repository of the corresponding environment. The environment initialization engine also runs as an application in each multi-cloud environment. The specific steps are as follows:

[0050] (1) In the DevOps subsystem, select the multi-cloud environment to be upgraded, then select the version generated in step 1 from the drop-down list of the environment deployment engine application, and confirm to execute the deployment;

[0051] (2) The DevOps subsystem updates the version of the environment initialization engine to the GitOps repository corresponding to the multi-cloud environment;

[0052] (3) The Agent deployed in the environment detects changes in the GitOps repository corresponding to the environment through polling, pulls the latest changes in the GitOps repository through built-in SSH authentication, and parses them;

[0053] (4) After the analysis is completed, the agent uses helm to call the Kubernetes API to upgrade the environment initialization engine. Kubernetes pulls the corresponding version of the Docker image and starts running.

[0054] S3: Snapshot Replay

[0055] After the environment initialization engine is started, snapshot replay begins. Figure 3 As shown, the specific steps are as follows:

[0056] (1) Decompress the existing compressed package;

[0057] (2) If there is a database object script update, use Liquibase to execute the database object creation script;

[0058] (3) If there is an update to the seed data import script, choose to use Liquibase to execute the seed data import script;

[0059] (4) Call the file service through feign to upload the template file;

[0060] (5) If there are application updates, submit the version updates of each application to the GitOps repository corresponding to the environment;

[0061] (6) The Agent deployed in the environment detects changes in the GitOps repository corresponding to the environment through polling, pulls the latest changes in the GitOps repository through built-in SSH authentication, and parses them;

[0062] (7) After parsing is complete, the Agent uses Helm to call the Kubernetes API to upgrade each application;

[0063] The above completes the upgrade of a multi-cloud environment.

[0064] It should be understood that the above steps are not necessarily executed in the order of the numerical sequence. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Figure 2 As shown, it involves different aspects such as database object script update, file service, application update, etc.

[0065] The embodiments of the present invention capture environment snapshots and snapshot replays (snapshot generation and transfer), and with the help of submission and analysis of GitOps repositories, complex microservice architectures, database objects, seed data scripts, template files, etc. are solidified in the form of environment snapshots, and are conveniently transferred between environments through snapshot replay, so that OP users can freely choose the data storage location while also enjoying the benefits of out-of-the-box, cloud-native, and continuous iteration. The deployment and upgrade process of a set of environments is shortened from the original one day to half an hour, greatly reducing the deployment and upgrade costs of multi-cloud environments, and realizing the automation of deployment and upgrades, so that OP users, like SaaS users, are uniformly managed, iterated, and operated and maintained.

[0066] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0067] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A multi-cloud environment upgrade method based on GitOps, characterized in that: include: Step (1) Generate environment snapshots: Through scheduled tasks, the environment initialization engine periodically takes environment snapshots of the cloud SaaS environment, solidifies the version dependencies between microservices, between microservices and database objects, between microservices and seed data, and between microservices and template files, generates a unified product version, and saves it in the Harbor warehouse in the form of a docker image; Step (2) Upgrading the environment initialization engine: When a multi-cloud environment upgrade is required, select the product version to be upgraded, obtain the environment initialization engine corresponding to the product version, update the version information of the environment initialization engine to the GitOps repository corresponding to the multi-cloud environment, and pull the docker image corresponding to the environment initialization engine from the Harbor repository according to the image information of the environment initialization engine described in the GitOps repository; complete the upgrade of the engine itself, and then start the environment initialization engine; Step (3) snapshot replay: After the environment initialization engine is started, the GitOps technology is used to drive the environment initialization engine to perform the replay of the environment snapshot: according to the image information of the product described in the GitOps warehouse, the docker image corresponding to the product is pulled from the Harbor warehouse to achieve the upgrade of the multi-cloud environment; Step (3) specifically includes: 3.1) Decompress the existing compressed package; 3.2) If there is a database object script update, use Liquibase to execute the database object creation script; 3.3) If there is an update to the seed data import script, use the import tool to execute the seed data import script; 3.4) Call the file service through feign to upload the template file; 3.5) If there are application updates, submit the version updates of each application to the GitOps repository corresponding to the environment; 3.6) Using polling, when changes in the GitOps repository corresponding to the environment are detected, the latest changes of the GitOps repository are pulled through SSH authentication and analyzed; 3.7) After parsing is complete, use Helm to call the Kubernetes API to upgrade each application.

2. The multi-cloud environment upgrade method based on GitOps according to claim 1, characterized in that: The step (1) of taking a snapshot of the SaaS environment in the cloud includes: capturing the snapshot of the microservice docker image version, database object creation script, seed data import script and template file of the SaaS version production environment, compressing them, and then generating the unified product version according to the timestamp.

3. The multi-cloud environment upgrade method based on GitOps according to claim 1, characterized in that: The environment initialization engine runs as an application in each multi-cloud environment; step (2) specifically includes: 2.1) Select the multi-cloud environment to be upgraded, select the version generated in step (1) from the drop-down list of the environment initialization engine application, and confirm the execution of the deployment; 2.2) Update the version of the environment initialization engine to the GitOps repository corresponding to the multi-cloud environment; 2.3) Using polling, when changes in the GitOps repository corresponding to the current multi-cloud environment are detected, the latest changes in the corresponding GitOps repository are pulled through SSH authentication and analyzed; 2.4) After the analysis is completed, use helm to call the Kubernetes API to upgrade the environment initialization engine. Kubernetes pulls the corresponding version of the Docker image and starts running.

4. A multi-cloud deployment control platform based on GitOps, characterized in that: include: The environment initialization engine runs as an application in each multi-cloud environment. It takes a snapshot of the cloud SaaS environment, solidifies the version dependencies between microservices, between microservices and database objects, between microservices and seed data, and between microservices and template files, and generates a unified product version. Initialize or upgrade the environment by replaying the snapshot in the target environment; The DevOps subsystem is used to perform unified CI / CD for products deployed to multi-cloud environments, and uses GitOps technology to drive the environment initialization engine to deploy and upgrade the environment; DevOps Agent, as an agent tool, connects to the DevOps subsystem through WebSocket to receive commands and execute them; The specific steps of replaying the snapshot in the target environment include: 3.1) Decompress the existing compressed package; 3.2) If there is a database object script update, use Liquibase to execute the database object creation script; 3.3) If there is an update to the seed data import script, use the import tool to execute the seed data import script; 3.4) Call the file service through feign to upload the template file; 3.5) If there are application updates, submit the version updates of each application to the GitOps repository corresponding to the environment; 3.6) Using polling, when changes in the GitOps repository corresponding to the environment are detected, the latest changes of the GitOps repository are pulled through SSH authentication and analyzed; 3.7) After parsing is complete, use Helm to call the Kubernetes API to upgrade each application.

5. The multi-cloud deployment control platform based on GitOps according to claim 4, characterized in that: It also includes a UVPN subsystem, which is used to achieve a unified entrance for multiple clouds and multiple IDCs, thereby supporting the simultaneous operation and maintenance of SaaS environments and OP environments.

6. The multi-cloud deployment control platform based on GitOps according to claim 4, characterized in that: It also includes a monitoring and early warning subsystem, which is used to achieve unified collection and unified early warning of cross-cloud and cross-IDC monitoring indicators and performance indicators with the help of UVPN.

7. The multi-cloud deployment control platform based on GitOps according to claim 4, characterized in that: It also includes a log analysis subsystem, which is used to achieve unified collection and unified query of cross-cloud and cross-IDC application logs with the help of UVPN.

Images