A method and apparatus for deploying a grid middleware

Abstract

The application relates to a deployment method of grid middleware, which comprises the following steps: when detecting that the latest version of the grid middleware exists in a publishable software warehouse, determining a first identifier; then, determining a second identifier according to the first identifier; then, determining a deployment declaration file according to the first identifier and the second identifier; determining a deployment instruction of a corresponding server according to the deployment declaration file, and sending the deployment instruction to the corresponding server; and the corresponding server can deploy the latest version of the grid middleware according to the deployment instruction. The application can monitor the publishable software warehouse in real time, determine the deployment declaration file, and deploy the latest version of the grid middleware on the corresponding server according to the deployment declaration file, so that the distributed deployment of the grid middleware is realized, and the software update can be quickly delivered to the user.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of distributed network, in particular to a deployment method and device of distributed grid middleware. BACKGROUND

[0002] The grid computing service environment aggregates multiple heterogeneous supercomputing resources distributed in different regions, thereby forming a large-scale distributed computing environment across regions. The grid computing service environment shields the heterogeneity of the underlying supercomputing resources through grid middleware, realizes unified management and scheduling of resources, and provides users with convenient, low-threshold high-performance computing services.

[0003] The grid middleware belongs to a kind of distributed software, and is the core part of the entire grid computing service environment. The grid middleware needs to be deployed on different types of devices in different regions, and the production environment is relatively complex. With the continuous increase of user demand, the grid middleware deployed on different types of supercomputing resources in different regions also needs to be continuously improved. However, the current rapid deployment of grid middleware is a problem that needs to be solved in the development process of the software. SUMMARY

[0004] The present application relates to a deployment method of grid middleware, which monitors a publishable software repository in real time. When the latest version of grid middleware is detected, the latest version of grid middleware is obtained, and the deployment declaration file is determined in combination with the configuration information matching the version, so that the corresponding server can be deployed with the latest version of grid middleware according to the deployment declaration file. The distributed deployment of grid middleware is realized, so that the software update can be quickly delivered to the user for use.

[0005] To achieve the above purpose, the first aspect of the present application provides a deployment method of grid middleware, which is applied to a distributed network including multiple servers distributed in different regions. The method can include: when it is detected that the latest version of grid middleware exists in a publishable software repository, determining a first identifier. The first identifier is the identifier of the latest version of grid middleware in the publishable software repository. Then, a second identifier is determined according to the first identifier. The second identifier is the identifier of the configuration information matching the version of the latest version of grid middleware. Then, a deployment declaration file is determined according to the first identifier and the second identifier. Then, the deployment instruction of the corresponding server is determined according to the deployment declaration file, and the deployment instruction is sent to the corresponding server, so that the corresponding server can deploy the latest version of grid middleware according to the deployment instruction. The present application monitors the publishable software repository in real time, and then determines the deployment declaration file, so that each server can be deployed with the latest version of grid middleware according to the deployment declaration file. The distributed deployment of grid middleware is realized, and the software update can be quickly delivered to the user for use.

[0006] Preferably, the detecting that the latest version of the grid middleware exists in the publishable software repository can comprise: obtaining a name of the latest stored grid middleware in the publishable software repository. When the name of the latest stored grid middleware in the publishable software repository is different from the previously obtained name of the grid middleware, it is determined that the latest version of the grid middleware exists in the publishable software repository. The determining the first identifier can comprise: taking the name of the latest stored grid middleware in the publishable software repository as the first identifier.

[0007] Preferably, the determining the second identifier according to the first identifier can comprise: determining the second identifier from the version association list according to the first identifier. The first identifier matches the version of the second identifier. The version association list is pre-stored.

[0008] Preferably, the determining the deployment declaration file further comprises: when it is detected that the latest version of the configuration information exists in the configuration repository, determining a third identifier. The third identifier is an identifier of the latest version of the configuration information in the configuration repository. A fourth identifier is determined according to the third identifier. The fourth identifier is an identifier of the grid middleware matching the version of the latest version of the configuration information. The deployment declaration file is determined according to the third identifier and the fourth identifier. The present application can also monitor the configuration repository in real time and obtain the latest version of the configuration information in time. Then the deployment declaration file is determined through the latest version of the configuration information, so that the latest version of the grid middleware can be deployed to each server according to the deployment declaration file. The distributed deployment of the grid middleware is realized, and the software update can be quickly delivered to the user for use.

[0009] Preferably, the detecting that the latest version of the configuration information exists in the configuration repository can comprise: obtaining a name of the latest stored configuration information in the configuration repository. When the name of the latest stored configuration information in the configuration repository is different from the previously obtained name of the configuration information, it is determined that the latest version of the configuration information exists in the configuration repository. The determining the third identifier can comprise: taking the name of the latest stored configuration information in the configuration repository as the third identifier.

[0010] Preferably, before detecting the existence of the latest version of the grid middleware in the releasable software repository, the method further includes: when the existence of the latest version of the source code in the source code repository is detected, obtaining the latest version of the source code from the source code repository; building the latest version of the source code into a new grid middleware and deploying it to the test environment; determining a test case set matching the latest version of the source code based on the latest version of the source code; testing the new grid middleware in the test environment using the test case set and generating a test report; and determining whether to store the new grid middleware in the releasable software repository based on the test report. This invention can also monitor the latest source code in real time before deploying the grid middleware and build it into grid middleware for testing. Then, the grid middleware that passes the test is released and saved for subsequent deployment of the latest version of the grid middleware.

[0011] Preferably, determining whether to store the new grid middleware in the deployable software repository based on the test report may include: if the test report meets preset conditions, then determining to store the new grid middleware in the deployable software repository.

[0012] Preferably, determining whether to store the new grid middleware in the releasable software repository based on the test report may include: outputting the latest version of the source code when the test report does not meet preset conditions. This invention facilitates modification and adjustment of the latest version of the source code by outputting the latest version when the test report does not meet preset conditions.

[0013] Preferably, detecting the existence of the latest version of source code in the source code repository may include: obtaining the name of the most recently stored source code in the source code repository. When the name of the most recently stored source code in the source code repository is different from the name of the previously obtained source code, it is determined that the latest version of source code exists in the source code repository.

[0014] Preferably, the preset conditions may include one or more of the following: the pass rate of the test case set meets the pass rate threshold, the number of passed tests in the test case set meets the number threshold, and the test time meets the time threshold.

[0015] Preferably, sending the deployment command to the corresponding server may include: retrieving the latest version of the grid middleware from a releasable software repository based on a first identifier; retrieving configuration information matching the latest version of the grid middleware from a configuration repository based on a second identifier; and then sending the deployment command, the latest version of the grid middleware, and the configuration information matching the latest version of the grid middleware to the corresponding server. This invention can also simultaneously send the latest version of the grid middleware and the corresponding configuration file to the corresponding server, facilitating rapid distributed deployment on the server.

[0016] To achieve the above objectives, a second aspect of the present invention provides a deployment apparatus for grid middleware. This apparatus may include: a software monitoring module, configured to determine a first identifier when a latest version of the grid middleware is detected in a releasable software repository, wherein the first identifier is an identifier of the latest version of the grid middleware in the releasable software repository; a deployment parameter update module, configured to determine a second identifier based on the first identifier, wherein the second identifier is an identifier of configuration information matching the latest version of the grid middleware; the deployment parameter update module is further configured to determine a deployment declaration file based on the first identifier and the second identifier; and a service update module, configured to determine deployment instructions for corresponding servers based on the deployment declaration file, and send the deployment instructions to the corresponding servers so that the corresponding servers deploy the latest version of the grid middleware according to the deployment instructions. The present invention monitors the releasable software repository in real time and then determines the deployment declaration file, enabling the deployment of the latest version of the grid middleware to each server according to the deployment declaration file. This achieves distributed deployment of the grid middleware and allows for rapid delivery of software updates to users.

[0017] Preferably, the software monitoring module is further configured to: obtain the name of the most recently stored grid middleware in the deployable software repository; determine that the latest version of the grid middleware exists in the deployable software repository when the name of the most recently stored grid middleware in the deployable software repository is different from the name of the previously obtained grid middleware; and use the name of the most recently stored grid middleware in the deployable software repository as the first identifier.

[0018] Preferably, the deployment parameter update module is further configured to: determine a second identifier from the version association list based on a first identifier. The first identifier matches the version of the second identifier.

[0019] Preferably, the apparatus may further include: a configuration monitoring module, used to determine a third identifier when a new version of configuration information is detected in the configuration repository. The third identifier is the identifier of the newest version of configuration information in the configuration repository; the deployment parameter update module is further used to determine a fourth identifier based on the third identifier. The fourth identifier is the identifier of the grid middleware that matches the version of the newest configuration information; the deployment parameter update module is further used to determine a deployment declaration file based on the third identifier and the fourth identifier. This invention can also monitor the configuration repository in real time and obtain the newest version of configuration information promptly. Then, a deployment declaration file is determined based on the newest version of configuration information, so that the newest version of the grid middleware can be deployed to each server according to the deployment declaration file. This achieves distributed deployment of the grid middleware and allows for rapid delivery of software updates to users.

[0020] Preferably, the configuration monitoring module is further configured to: obtain the name of the most recently stored configuration information in the configuration repository; when the name of the most recently stored configuration information in the configuration repository is different from the name of the previously obtained configuration information, determine that the latest version of configuration information exists in the configuration repository; and use the name of the most recently stored configuration information in the configuration repository as a third identifier.

[0021] Preferably, the apparatus further includes: a source code monitoring module, used to retrieve the latest version of source code from the source code repository when the latest version of source code is detected in the repository; a software package building module, used to build the latest version of source code into a new grid middleware and deploy it to the test environment; a test execution module, used to determine a test case set that matches the latest version of source code; the test execution module is also used to perform tests using the test case set in the test environment where the new grid middleware is deployed and to determine a test report; and a test feedback module, used to determine whether to store the new grid middleware in a releasable software repository based on the test report. This invention can monitor the latest source code in real time before deploying the grid middleware and build it into grid middleware for testing. Then, the grid middleware that passes the test is released and saved for subsequent deployment of the latest version of the grid middleware.

[0022] Preferably, the test feedback module is further configured to: when the test report meets preset conditions, determine to store the new grid middleware in the releasable software repository.

[0023] Preferably, the test feedback module is also used to: output the latest version of the source code when the test report does not meet the preset conditions.

[0024] Preferably, the source code monitoring module is further configured to: obtain the name of the most recently stored source code in the source code repository; and determine that the latest version of the source code exists in the source code repository when the name of the most recently stored source code in the source code repository is different from the name of the source code obtained last time.

[0025] Preferably, the preset conditions include one or more of the following: the pass rate of the test case set meets the pass rate threshold, the number of passed tests in the test case set meets the number threshold, and the test time meets the time threshold.

[0026] Preferably, the service update module is further configured to: obtain the latest version of the grid middleware from the publishable software repository based on the first identifier; obtain configuration information matching the latest version of the grid middleware from the configuration repository based on the second identifier; and send the deployment command, the latest version of the grid middleware, and the configuration information matching the latest version of the grid middleware to the corresponding server. This invention can also simultaneously send the latest version of the grid middleware and the corresponding configuration file to the corresponding server, facilitating rapid distributed deployment on the corresponding server.

[0027] This invention implements a method and device for deploying grid middleware. By monitoring repositories of deployable software in real time, when a new version of the grid middleware exists, a deployment declaration file can be determined based on the version of the latest grid middleware and the version of the matching configuration information. This allows the latest version of the grid middleware to be deployed to the corresponding servers according to the deployment declaration file, achieving distributed deployment of the grid middleware and rapid delivery of software updates to users. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of a distributed network deployment scenario provided by an embodiment of the present invention;

[0029] Figure 2 This is a schematic diagram of a grid middleware deployment system structure provided in an embodiment of the present invention;

[0030] Figure 3 A schematic diagram of a deployment subsystem structure provided in an embodiment of the present invention;

[0031] Figure 4 A schematic diagram of a test subsystem structure provided in an embodiment of the present invention;

[0032] Figure 5 A method for deploying a grid middleware is provided in this embodiment of the invention;

[0033] Figure 6 Another method for deploying grid middleware provided in this embodiment of the invention;

[0034] Figure 7 This invention provides yet another method for deploying a grid middleware;

[0035] Figure 8 This is a schematic diagram of a deployment device for a grid middleware provided in an embodiment of the present invention. Detailed Implementation

[0036] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0037] This invention primarily utilizes distributed networks, for example... Figure 1 As shown, a distributed network can include supercomputing resources located in various geographical areas. In some examples, computing resources can be a single supercomputing device with extremely high computing power, or a cluster of such devices. Different supercomputing resources may be located in different geographical locations, and each supercomputing resource may also exhibit heterogeneity at its underlying level, for example, by using different architectures. Therefore, deploying network middleware on each supercomputing resource can shield against this heterogeneity, enabling unified management and scheduling of resources within the distributed network. This allows users to access high-performance computing services more conveniently and with lower barriers to entry.

[0038] However, there is currently no solution for quickly deploying network middleware across various supercomputing resources in a distributed network. As user demands continue to increase, grid middleware also faces the need for timely updates to better serve users, making rapid deployment of network middleware a pressing issue.

[0039] Therefore, this invention provides a method and apparatus for deploying grid middleware. It obtains the latest version of the grid middleware by real-time monitoring of releasable software repositories, and then determines a deployment declaration file based on the configuration information matching the version. Deployment instructions are determined according to this deployment declaration file and sent to the corresponding servers in a distributed network, enabling the servers to deploy the latest version of the grid middleware. This achieves distributed deployment of the grid middleware, allowing for rapid software updates and timely delivery to users.

[0040] To more clearly illustrate the solutions of the present invention, the technical solutions of the present invention will be described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0041] Figure 2 This is a schematic diagram of a grid middleware deployment system provided in an embodiment of the present invention.

[0042] like Figure 2As shown, this invention provides a grid middleware deployment system 200, which includes a deployable software repository 201, a configuration repository 202, and a deployment subsystem 203. The deployment subsystem 203 monitors the deployable software repository 201 and the configuration repository 202 in real time, for example, detecting whether the latest version of the grid middleware exists in the deployable software repository 201, and whether the latest version of configuration information exists in the configuration repository 202. When the latest version of the grid middleware is detected in the deployable software repository 201 and / or the latest version of configuration information is detected in the configuration repository 202, the deployment subsystem 203 generates a deployment declaration file. Then, the deployment subsystem 203 can determine the deployment instructions corresponding to the appropriate server based on the deployment declaration file, and send the deployment instructions to the appropriate server in the distributed network, so that the appropriate server can deploy the latest version of the grid middleware and / or configuration information according to the deployment instructions.

[0043] Of course, in some examples, deployment subsystem 203 can also obtain the latest version of the grid middleware and / or the latest version of its configuration information, and send the latest version of the grid middleware and / or the latest version of its configuration information along with deployment instructions to the corresponding servers in the distributed network. This allows the corresponding servers to deploy the latest version of the grid middleware and / or its configuration information more quickly.

[0044] In some examples, system 200 may also include a source code repository 204, a test case repository 205, and a test subsystem 206. The test subsystem 206 monitors the source code repository 204 in real time, for example, checking if the latest version of the source code exists in the repository. When the latest version of the source code is detected in the repository, the test subsystem 206 retrieves it. Then, the test subsystem 206 generates the corresponding grid middleware based on the latest version of the source code and performs testing by matching the corresponding version's test case set with the test case repository 205. The test subsystem 206 saves the tested grid middleware to the releasable software repository 201. This completes the real-time update of the releasable software data 201.

[0045] In some examples, Figure 2The illustrated repositories can have functions such as branch management, version management, update upload, and download. Branch management can be used to manage the content of a specific branch within a grid middleware. For example, a grid middleware may include multiple branches such as a central service branch, a frontend service branch, and a client service branch. It is understood that the above is merely an illustrative description and does not limit the invention. In some examples, management tools such as Subversion, GitHub, and GitLab can be used to manage the repositories. Of course, in some examples, local storage can also be used to manage the repositories; this invention is not limited to this. Naturally, database management can be partially employed during the repository management process.

[0046] The present invention will now be described in more detail through its various subsystems.

[0047] Figure 3 This is a schematic diagram of a deployment subsystem structure provided in an embodiment of the present invention.

[0048] As Figure 3 As shown, it is described in detail. Figure 2 The document describes how to perform distributed deployment of the grid middleware using the software repository 201, configuration repository 202, and deployment subsystem 203. The deployment subsystem 203 may include a software monitoring module 301, a configuration monitoring module 302, a deployment parameter update module 303, and a service update module 304.

[0049] First, the software monitoring module monitors the deployable software repository 201 in real time to determine whether the latest version of the grid middleware exists in the repository. In one example, the software monitoring module 301 can periodically check the deployable software repository 201 at a pre-set frequency. In other examples, the deployable software repository 201 can also proactively send a first identifier to the software monitoring module 301 upon receiving the latest version of the grid middleware. The first identifier can be the name of the latest version of the grid middleware. In still other examples, the deployable software repository 201 can also simultaneously send the latest version of the grid middleware to the software monitoring module 301.

[0050] In some examples, the software monitoring module 301 can determine whether the latest version of the grid middleware exists in the releasable software repository 201 by obtaining the name of the latest version of the grid middleware and comparing it with the name of the previously obtained grid middleware. Once it is determined that the latest version of the grid middleware exists, its name can be used as the first identifier. In this invention, the identifier (ID) can be a name or a grid middleware version number, etc. This invention will use the identifier as the name as an example for description. This invention provides a naming method for grid middleware, as shown in Table 1, etc.

[0051] Grid middleware naming Software version Grid middleware-1 a1 Grid middleware-2 a2 Grid middleware-3 a3

[0052] Table 1

[0053] As shown in Table 1, the name of a grid middleware contains its version information. Therefore, the software monitoring module 301 can determine the version of a grid middleware by retrieving the name of the most recently stored grid middleware in the releasable software repository 201. Of course, in some examples, the software monitoring module 301 can also retrieve the version number of the most recently stored grid middleware.

[0054] In one example, the software monitoring module 301 stores the name or version number of the previously acquired grid middleware. When the name or version number of the most recently stored grid middleware in the releasable software repository 201 differs from the name or version number of the previously acquired grid middleware, the software monitoring module 301 can determine that the latest version of the grid middleware exists in the releasable software repository 201. It is understandable that, generally, the version of newly added grid middleware to the releasable software repository 201 is higher than the version of previously added grid middleware. Simultaneously, the name or version number of the previously acquired grid middleware stored in the software monitoring module 301 is also obtained from the releasable software repository 201. Therefore, when the name or version number differs, it can be directly assumed that the latest version of the grid middleware exists in the releasable software repository 201.

[0055] In one example, during the first deployment, since the name or version number of the previously obtained grid middleware is not found in the software monitoring module 301, the software monitoring module 301 can directly determine that the latest version of the grid middleware exists in the releasable software repository 201.

[0056] In some cases, when the software monitoring module 301 determines that the latest version of the grid middleware exists in the releasable software repository 201, it can send the first identifier to the deployment parameter update module 303, that is, send the name or version number of the latest version of the grid middleware to the deployment parameter update module 303.

[0057] In some examples, the deployment parameter update module 303 can determine the second identifier based on the first identifier. The second identifier can be the name or version number of configuration information that matches the name or version number of the latest version of the grid middleware. That is, the deployment parameter update module 303 can determine the name or version number of the configuration data that matches the received name or version number of the latest version of the grid middleware. For example, after receiving the name or version number of the latest version of the grid middleware from the software monitoring module 301, the deployment parameter update module 303 queries the version association list using that name or version number. It is understood that the version association list is pre-stored and records the version correspondence between each grid middleware and the configuration information. Therefore, the name or version number of configuration information that matches the name or version number of the latest version of the grid middleware can be found through the version association list. Table 2 shows one possible form of the version association list.

[0058] Software module Software version Configuration information version A a1 b2 B a2 b1 C a3 b1

[0059] Table 2

[0060] As shown in Table 2, since grid middleware may have branch management, meaning a certain grid middleware may correspond to a certain software module, the version association list stores the software version and configuration information version for each different software module. The deployment parameter update module 303 queries the software version and configuration information version corresponding to the software module through the software module.

[0061] Understandably, since this is a grid middleware version update, the software version of the corresponding software module in the version association list can be modified, for example, replacing the original software version with the version number of the latest grid middleware. Of course, in some cases, the version number can be received from the software monitoring module 301, or it can be determined based on the name of the latest grid middleware version; this invention does not impose any limitations.

[0062] The deployment parameter update module 303 can determine the deployment declaration file based on the first identifier and the second identifier.

[0063] In one example, the deployment declaration file determined by the deployment parameter update module 303 may include adjustments to certain parameters, such as image version, number of replicas of a single service, service restart strategy, database address updates, etc. The image may be a container engine (Docker) image, etc.

[0064] Subsequently, the deployment parameter update module 303 sends the determined deployment declaration file to the service update module 304. The service update module 304 then determines the corresponding deployment instruction for the appropriate server based on the received deployment declaration file. This deployment instruction instructs the appropriate server to deploy the latest mesh middleware. The deployment instruction is then sent to the appropriate server in the distributed network so that the server can deploy the latest mesh middleware according to the instruction. In some examples, the deployment instruction may include the download address for the latest version of the mesh middleware and the download address for the configuration information matching that version. This allows the server, upon receiving the deployment instruction, to download the latest version of the mesh middleware and the matching configuration information from the two download addresses, thereby deploying the latest version of the mesh middleware. The download addresses may point to the corresponding storage location of the latest version of the mesh middleware in the publishable software repository 201 and the corresponding storage location of the configuration information in the configuration repository 202.

[0065] Of course, in other examples, the service update module 304 can determine the deployment instructions for the corresponding server based on the deployment declaration file. This deployment instruction includes the version of the grid middleware to be deployed and the version of the corresponding configuration information. Then, the service update module 304 can download the grid middleware to be deployed from the publishable software repository 201 and the configuration information to be deployed from the configuration repository 202, based on the version of the grid middleware and the version of the corresponding configuration information. Then, it sends the downloaded grid middleware, configuration information, and deployment instructions to the corresponding server. Upon receiving the above information, the corresponding server can directly deploy the grid middleware without downloading it again, saving deployment time and improving the deployment efficiency of the distributed grid middleware.

[0066] In some examples, the present invention provides a naming scheme for configuration information, such as that shown in Table 3.

[0067] Configuration information naming Software version Configuration information version Configuration information-1-1 a1 b1 Configuration information-1-2 a1 b2 Configuration information-2-1 a2 b1 Configuration information-3-1 a3 b1

[0068] Table 3

[0069] As shown in Table 2, the configuration information stored in configuration repository 202 is as illustrated in Table 3. In some examples, service update module 304 can query configuration repository 202 based on the version of the mesh middleware being deployed and the version of the corresponding configuration information to accurately match the relevant configuration information. It is understandable that when retrieving configuration information, at least the software version and the configuration information version must be included simultaneously. This is because different software versions may correspond to the same configuration information version, but the actual configuration information is applicable to different software versions. If only the configuration information version is used for matching, it may match configuration information for other software versions, thus failing to complete the final deployment of the mesh middleware.

[0070] For example, if the service update module 304 determines that the version of the mesh middleware deployed this time is a2 and the version of the corresponding configuration information is b1, then it can determine "configuration information-2-1" and obtain the configuration information.

[0071] In some examples, branch management may exist for grid middleware, meaning that a certain grid middleware may correspond to a certain software module, and different grid middleware may be adapted to supercomputing resources in different geographical locations. Therefore, the deployment instructions determined by the service update module 304 based on the deployment declaration file may also include branch information, deployment region information, etc. Furthermore, Table 4 shows another naming method for configuration information.

[0072] Configuration information naming Software module Software version Deployment region Configuration information version Configuration information-A-1-111-1 A a1 111 b1 Configuration information-A-1-111-2 A a1 111 b2 Configuration information-A-2-222-2 A a2 222 b2 Configuration information-C-1-333-1 C a1 333 b1 Configuration information-C-1-444-1 C a1 444 b1 Configuration information-C-2-222-2 C a2 222 b2 Configuration information-C-2-555-2 C a2 555 b3

[0073] Table 4

[0074] As shown in Table 4, when downloading configuration information, the service update module 304 can also query the configuration repository 202 based on information such as the software module and / or deployment region, combined with the version of the grid middleware deployed and the version of the corresponding configuration information. For example, if the service update module 304 determines that the version of the grid middleware deployed is a2, the version of the corresponding configuration information is b2, the branch information is module A, and the deployment region information is "222", then it can determine "Configuration Information -A-2-222-2" and obtain this configuration information. Of course, if the service update module 304 determines that the version of the grid middleware deployed is a2, the version of the corresponding configuration information is b1, the branch information is module A, and the deployment region information is "222", and there is no corresponding data in the configuration repository 202, it means that the configuration information matching failed, and there is no configuration information with a matching version. At this time, the deployment of the grid middleware can be terminated.

[0075] In other examples, deployment declaration files can be generated and distributed deployment of the grid middleware can be performed when configuration information is updated. For instance, a similar deployment can be performed if only the configuration information in the configuration repository is updated.

[0076] In one example, the configuration monitoring module 302 can also monitor the configuration repository 202 in real time. When it detects that the latest version of configuration information exists in the configuration repository 202, it determines a third identifier. The third identifier can be an identifier for the latest version of the configuration information in the configuration repository 202.

[0077] In one example, the configuration monitoring module 302 can retrieve the name or version number of the latest version of the configuration information from the configuration repository 202 and compare it with the name or version number of the previously retrieved configuration information to determine whether the latest version of the configuration information exists in the configuration repository 202. It is understood that the configuration monitoring module 302 stores the name or version number of the previously retrieved configuration information. Then, when the name or version number of the latest version of the configuration information is different from the name or version number of the previously retrieved configuration information, it is determined that the latest version of the configuration information exists in the configuration repository 202. The name or version number of the latest version of the configuration information can then be used as a third identifier. The specific names of the configuration information can be shown in Tables 3 and 4. It is understood that determining whether the latest version of the configuration information exists is similar to determining whether the latest version of the mesh middleware exists, and will not be elaborated further here.

[0078] In some examples, the configuration monitoring module 302 can periodically check whether the latest version of the configuration information exists in the configuration repository 202 at a pre-configured frequency. Of course, in other examples, after receiving the latest version of the configuration information, the configuration repository 202 can also actively send the name or version number of the latest version of the configuration information to the configuration monitoring module 302; this invention is not limited to these examples.

[0079] The configuration monitoring module 302 can send the acquired third identifier to the deployment parameter update module 303. The deployment parameter update module 303, based on the third identifier, queries the version association list to determine the fourth identifier. The fourth identifier is the identifier of the mesh middleware that matches the latest version of the configuration information. The process of determining the fourth identifier can be referred to the process of determining the second identifier, and will not be elaborated further in this invention. The deployment parameter update module 303 determines the deployment declaration file based on the third and fourth identifiers.

[0080] Subsequently, the deployment parameter update module 303 can send the deployment declaration file to the service update module 304. The service update module 304 then determines the deployment instructions corresponding to the respective server based on the deployment declaration file, and then sends the deployment instructions to the corresponding service area. In some examples, the grid middleware and configuration information to be deployed can also be downloaded based on the third identifier and the fourth identifier, respectively. For details, please refer to the corresponding steps when updating the grid middleware version; these will not be elaborated upon in this invention.

[0081] Of course, in some cases, the deployment parameter update module 303 can also receive feedback information. This feedback information can be sent by various servers to inform them that there are problems with the grid middleware or its configuration. In this case, a version rollback can be used to regenerate a new deployment declaration file and redeploy the grid middleware to prevent servers from using the problematic grid middleware.

[0082] Understandably, version rollback means reverting the version of the mesh middleware and / or the version of its configuration information to the previous version. Therefore, the version association list in deployment parameter update module 303 can also store the previous software version and configuration information version for each software module, as shown in Table 5.

[0083] Software module Software version Configuration information version A (old) a2 b1 A a3 b2 B (old) a1 b1 B a2 b1 C (old) a2 b3 C a3 b4

[0084] Table 5

[0085] As can be seen, each software module contains two entries, corresponding to the current latest software version and configuration information version, and the previous software version and configuration information version, respectively. It is understood that Table 5 uses "(Old)" to distinguish between the latest version and the previous version. For example, a flag could be used to distinguish between the new version and the previous version; this is merely an illustrative example and does not limit the invention in any way.

[0086] Of course, in another example, the latest version and the previous version can be recorded separately using two version association lists. For example, the latest version association list stores the matching relationships between the latest software module, software version, and configuration information version. The older version association list stores the matching relationships between the previous software module, software version, and configuration information version. Of course, any equivalent method can be used instead, and this invention is not limited thereto.

[0087] After receiving the feedback information, the deployment parameter update module 303 determines that a version rollback is needed. It can then determine the rollback deployment declaration file using the version association list shown in Table 5. Clearly, the rollback deployment declaration file contains the previous software version and the previous configuration information version. The rollback deployment declaration file is then sent to the service update module 304, so that the service update module 304 can determine the deployment instructions based on the rollback deployment declaration file and perform subsequent deployment operations. The subsequent deployment operations are the same as those for the mesh middleware version update and configuration information update described above, and will not be repeated here.

[0088] Figure 4 This is a schematic diagram of a test subsystem structure provided in an embodiment of the present invention.

[0089] like Figure 4 As shown, before deploying the latest version of the grid middleware, the grid middleware can be quickly verified through the source code repository 204, the test case repository 205, and the test subsystem 206. This means that the subsystem is responsible for testing the grid middleware and determining whether to release it based on the test results, such as updating the releasable grid middleware to the releasable software repository 201.

[0090] It can be seen that the test subsystem 206 may further include: source code monitoring module 401, software package building module 402, test execution module 403, and test feedback module 404.

[0091] In one example, the source code monitoring module 401 can perform real-time monitoring of the source code repository 204 to determine whether the latest source code exists in the repository. It is understood that the source code stored in the source code repository 204 is the source code of the grid middleware. In one example, the source code monitoring module 401 can periodically monitor the source code repository 204 according to a pre-set frequency. Of course, in other examples, the source code repository 204 can also proactively send the latest version of the source code to the source code monitoring module 401 when it receives it.

[0092] In some examples, the source code monitoring module 401 can determine whether a newer version of the source code exists in the source code repository 204 by obtaining the name or version number of the most recently stored source code in the source code repository 204 and comparing it with the name or version number of the previously obtained source code. Table 6 shows a source code naming method provided by the present invention.

[0093] Source code naming Source code version Source code-1 c1 Source code-2 c2 Source code-3 c3

[0094] Table 6

[0095] As shown in Table 6, the name of the source code contains its version information. Therefore, the source code monitoring module 401 can determine the version of the source code by retrieving the name of the most recently stored source code in the source code repository 204. Of course, in some examples, the source code monitoring module 401 can directly obtain the version number of the most recently stored source code in the source code repository 204.

[0096] In one example, the source code monitoring module 401 stores the name or version number of the previously retrieved source code. When the name or version number of the most recently stored source code in the source code repository 204 differs from the name or version number of the previously retrieved source code, the source code monitoring module 401 can determine that the latest version of the source code exists in the source code repository 204. Then, the source code monitoring module 401 retrieves the latest version of the source code from the source code repository 204.

[0097] After obtaining the latest version of the source code, the source code monitoring module 401 sends the latest version of the source code to the package building module 402. The package building module 402 builds the corresponding grid middleware based on the latest version of the source code. It can be understood that the package building module 402 is used to build software from the source code. In some examples, different build targets such as RPM packages and Dokcer container images can be selected to build the grid middleware according to specific deployment requirements. Of course, specific requirements can be determined by receiving user input. In some examples, the source code may also carry requirement information; this invention does not limit this.

[0098] Next, the package build module 402 deploys the built grid middleware to the test environment. In some examples, the grid middleware built based on the latest version of the source code can also be referred to as the new grid middleware. It is understood that the test environment can reside in the test execution module 403; that is, the package build module 402 deploys the built grid middleware to the test environment of the test execution module 403.

[0099] The test execution module 403 determines the matching test case set from the test case repository 205 based on the source code version corresponding to the deployed grid middleware, and retrieves the test case set. In some examples, this invention provides a test case naming method, as shown in Table 7.

[0100] Test case set naming Source code version Test case version Test case set-1-1 c1 d1 Test case set-1-2 c1 d2 Test case set-2-1 c2 d1 Test case set-2-2 c2 d2 Test case set-2-3 c2 d3 Test case set-3-3 c3 d1

[0101] Table 7

[0102] As shown in Table 7, the test execution module 403 can determine the test case set required for this test by matching the corresponding source code version and test case version of each test case set stored in the test case repository 205. For example, if the generated software package corresponds to source code version "c3", then only one suitable test case set is matched, so the test case set required for this test can be determined as "test case set-3-3". Of course, if the generated software package corresponds to source code version "c2", then multiple suitable test case sets can be matched. The test execution module 403 then selects the latest test case version as the test case set required for this test. Therefore, the test case set required for this test can be determined as "test case set-2-3". In some examples, the test case repository 205 stores the test case sets required for the test, and may also include test scripts. It is understood that each data entry in Table 7 corresponds to a test case set.

[0103] The test execution module 403 uses the acquired test case set to perform tests in the test environment where the new grid middleware is deployed, and obtains a test report. Then, the test execution module 403 sends the determined test report to the test feedback module 404. Based on the test report, the test feedback module 404 determines whether to release the new grid middleware, i.e., whether to store the new grid middleware in the releasable software repository 201.

[0104] In one example, a test report may include multiple test results, such as pass rate, number of passed tests within the test case set, and test time. The specific test result content can be adjusted arbitrarily according to actual circumstances, and this invention does not impose any limitations. The test feedback module 404 may have pre-set corresponding preset conditions. When one or more test results in the test report meet the prediction conditions, it can be determined that the new grid middleware has passed the test and can be stored in the releasable software repository 201. In some examples, the preset conditions may include one or more of the following: the test case set pass rate meets a pass rate threshold, the number of passed tests within the test case set meets a quantity threshold, and the test time meets a time threshold. The specific preset conditions can be adjusted arbitrarily according to actual circumstances, and this invention does not impose any limitations.

[0105] Of course, in some cases, if one or more test results fail to meet the prediction conditions, it can be determined that the new grid middleware has failed the test. In this situation, the latest version of the source code can be output, i.e., feedback can be given to the relevant staff so that they can adjust and modify the source code. After the staff has completed the modifications, the modified source code is stored back in the source code repository 204. Understandably, the version of the modified source code is also updated at this time, therefore the above process will be repeated.Figure 4 The process described.

[0106] Therefore, it is understood that the grid middleware stored in the releasable software repository 201 of the present invention are all grid middleware that have undergone correctness verification tests.

[0107] Command line is an important usage method for grid middleware. However, as user demands increase, grid middleware needs continuous improvement, leading to higher requirements for software testing. Currently, most mainstream automated testing tools and methods are suitable for web applications and not for command line. Therefore, in some cases, this invention can use command line to test grid middleware.

[0108] Through the above Figure 2 to Figure 4 It can enable automated testing and distributed deployment of grid middleware command lines, and deliver software updates to users quickly.

[0109] Figure 5 This invention provides a method for deploying a grid middleware.

[0110] like Figure 5 As shown, this invention provides a method for deploying grid middleware. This method is applied in a distributed network, which includes multiple servers distributed across different regions. The method may include the following steps:

[0111] S501, when the latest version of the grid middleware is detected in the releasable software repository, a first identifier is determined. The first identifier is the identifier for obtaining the latest version of the grid middleware from the releasable software repository.

[0112] Preferably, detecting the existence of a latest version of the grid middleware in the deployable software repository may include: obtaining the name of the most recently stored grid middleware in the deployable software repository. When the name of the most recently stored grid middleware in the deployable software repository differs from the name of the previously obtained grid middleware, it is determined that a latest version of the grid middleware exists in the deployable software repository. Determining the first identifier may include: using the name of the most recently stored grid middleware in the deployable software repository as the first identifier.

[0113] S502, determine the second identifier based on the first identifier. The second identifier is an identifier for configuration information that matches the latest version of the mesh middleware.

[0114] S503, determine the deployment statement document based on the first identifier and the second identifier.

[0115] Preferably, the second identifier is determined from the version association list based on the first identifier. The first identifier matches the version of the second identifier.

[0116] S504 determines the deployment instructions based on the deployment declaration file and sends the deployment instructions to the corresponding server so that the corresponding server can deploy the latest version of the mesh middleware according to the deployment instructions.

[0117] Preferably, sending the deployment command to the corresponding server includes: obtaining the latest version of the grid middleware from a publishable software repository based on a first identifier; obtaining configuration information matching the latest version of the grid middleware from a configuration repository based on a second identifier; and sending the deployment command, the latest version of the grid middleware, and the configuration information matching the latest version of the grid middleware to the corresponding server. This invention can also simultaneously send the latest version of the grid middleware and its corresponding configuration file to the corresponding server, facilitating rapid distributed deployment across servers.

[0118] This invention enables real-time monitoring of releasable software repositories to promptly obtain the latest version of the grid middleware, and then determines the deployment declaration file. The deployment declaration file is then used to determine the corresponding deployment instructions. This allows the appropriate servers to deploy the latest version of the grid middleware according to the deployment instructions. This achieves distributed deployment of the grid middleware and enables rapid delivery of software updates to users.

[0119] Figure 6 Another method for deploying grid middleware is provided in this embodiment of the invention.

[0120] like Figure 6 As shown, if the configuration information is updated, a deployment declaration file can also be generated for the deployment of the distributed grid middleware. Therefore, prior to S504, this method could also include the following steps:

[0121] S601, when a new version of configuration information is detected in the configuration repository, a third identifier is determined. The third identifier is the identifier used to retrieve the newest version of configuration information from the configuration repository.

[0122] Preferably, detecting the existence of a latest version of configuration information in the configuration repository may include: obtaining the name of the most recently stored configuration information in the configuration repository. When the name of the most recently stored configuration information in the configuration repository differs from the name of the previously obtained configuration information, it is determined that a latest version of configuration information exists in the configuration repository. Determining the third identifier may include: using the name of the most recently stored configuration information in the configuration repository as the third identifier.

[0123] S602, determine the fourth identifier based on the third identifier. The fourth identifier is the identifier of the mesh middleware that matches the latest version of the configuration information.

[0124] S603, determine the deployment statement document based on the third and fourth identifiers.

[0125] This invention can also monitor the configuration repository in real time and obtain the latest version of configuration information promptly. Then, it determines the deployment declaration file based on the latest version of the configuration information. The deployment declaration file then determines the corresponding deployment instructions. This allows the appropriate servers to deploy the latest version of the grid middleware according to the deployment instructions. This achieves distributed deployment of the grid middleware and enables rapid delivery of software updates to users.

[0126] Figure 7 This invention provides yet another method for deploying a grid middleware.

[0127] like Figure 7 As shown, before obtaining the latest version of the grid middleware, the present invention may further include building the source code into grid middleware and testing it, and storing the grid middleware that passes the test into a releasable software repository 201 for deployment of the grid middleware.

[0128] Therefore, prior to S501, the method may also include the following steps:

[0129] S701: When the latest version of the source code is detected in the source code repository, the latest version of the source code is retrieved from the source code repository.

[0130] Preferably, detecting the existence of the latest version of source code in the source code repository may include: obtaining the name of the most recently stored source code in the source code repository. When the name of the most recently stored source code in the source code repository is different from the name of the previously obtained source code, it is determined that the latest version of source code exists in the source code repository.

[0131] S702 builds the latest version of the source code into a new grid middleware and deploys it to the test environment.

[0132] S703 determines a set of test cases that match the latest version of the source code.

[0133] S704 uses a test case set to perform tests in a test environment where the new grid middleware is deployed, and determines the test report.

[0134] S705 determines whether to store the new mesh middleware in the releasable software repository based on the test report.

[0135] Preferably, determining whether to store the new grid middleware in the deployable software repository based on the test report may include: if the test report meets preset conditions, then determining to store the new grid middleware in the deployable software repository.

[0136] Preferably, determining whether to store the new grid middleware in the releasable software repository based on the test report may include: outputting the source code of the latest version when the test report does not meet preset conditions.

[0137] Preferably, the preset conditions may include one or more of the following: the pass rate of the test case set meets the pass rate threshold, the number of passed tests in the test case set meets the number threshold, and the test time meets the time threshold.

[0138] Before deploying the grid middleware, this invention can monitor the latest source code in real time and build it into the grid middleware for testing. Then, the grid middleware that passes the test is released and saved for subsequent deployment of the latest version of the grid middleware.

[0139] Understandable, Figure 5 to Figure 7 For the specific implementation process of the described method, please refer to [link / reference]. Figure 2 to Figure 4 The specific descriptions in the text will not be repeated here.

[0140] Figure 8 This is a schematic diagram of a deployment device for a grid middleware provided in an embodiment of the present invention.

[0141] like Figure 5 As shown, the present invention also provides a deployment apparatus 800 for a grid middleware. The apparatus 800 may include a processor 810, a memory 820, a transmitter 830, a receiver 840, and a bus 850. The processor 810, memory 820, transmitter 830, and receiver 840 in the apparatus 800 can establish a communication connection via the bus 850.

[0142] The transmitter 830 is used to send deployable instructions. In some examples, it can also send the latest version of the mesh middleware and matching configuration information, or vice versa.

[0143] Receiver 840 is used to receive the latest version of the source code, the latest version of the test case set, the latest version of the configuration information, etc. It can also receive the latest version of the grid middleware. In some examples, it can also receive deployment requirement information, feedback information, etc., but this invention is not limited thereto.

[0144] Memory 820 is used to store instructions. When processor 810 calls the instructions stored in memory 820, processor 810 executes the above-mentioned instructions. Figure 2 to Figure 7 Any method involved in the Grid Middleware Deployment System 200.

[0145] Among them, processor 810 can be a CPU.

[0146] The memory 820 may include volatile memory, such as random-access memory (RAM); the memory 820 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD); the memory 820 may also include a combination of the above types of memory.

[0147] In some examples, the deployable software repository 201, configuration repository 202, source code repository 204, and test case repository 205 may reside in the storage device 820. Of course, in other examples, they may also reside on other storage devices and be accessed via the receiver 840.

[0148] Of course, it is understood that the device 800 may also include other hardware devices that may be used, such as I / O interfaces for data transmission, etc., which are not limited here.

[0149] This invention implements a method and device for deploying grid middleware. By monitoring repositories of deployable software in real time, the latest version of the grid middleware is obtained, and a deployment declaration file is determined by combining the configuration information matching the version. The deployment declaration file then determines the corresponding deployment instructions, enabling the appropriate servers to deploy the latest version of the grid middleware according to these instructions. This achieves distributed deployment of the grid middleware and rapid delivery of software updates to users.

[0150] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0151] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0152] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for deploying a grid middleware, characterized in that, The method is applied in a distributed network, which includes multiple servers distributed across different regions. The method includes: When a new version of the grid middleware is detected in the releasable software repository, a first identifier is determined, wherein the first identifier is the identifier of the new version of the grid middleware in the releasable software repository; A second identifier is determined based on the first identifier, wherein the second identifier is an identifier of configuration information that matches the latest version of the mesh middleware; Based on the first identifier and the second identifier, a deployment declaration file is determined; the deployment declaration file includes at least one of the following: image version, number of service replicas, restart policy, deployment region information, and branch information; The deployment instructions for the corresponding server are determined according to the deployment declaration file, and the deployment instructions are sent to the corresponding server so that the corresponding server can deploy the latest version of the mesh middleware according to the deployment instructions.

2. The method according to claim 1, characterized in that, The detection of the latest version of the grid middleware in the releasable software repository includes: Retrieve the name of the most recently stored grid middleware in the releasable software repository; When the name of the most recently stored grid middleware in the deployable software repository is different from the name of the previously obtained grid middleware, it is determined that the latest version of the grid middleware exists in the deployable software repository. The determination of the first identifier includes: Use the name of the most recently stored grid middleware in the releasable software repository as the first identifier.

3. The method according to claim 1, characterized in that, Determining the second identifier based on the first identifier includes: The second identifier is determined from the version association list based on the first identifier, wherein the first identifier matches the version of the second identifier.

4. The method according to claim 1, characterized in that, The deployment declaration document also includes: When the latest version of configuration information is detected in the configuration repository, a third identifier is determined, wherein the third identifier is the identifier of the latest version of configuration information in the configuration repository; A fourth identifier is determined based on the third identifier, wherein the fourth identifier is an identifier of the mesh middleware that matches the latest version of the configuration information; The deployment declaration file is determined based on the third identifier and the fourth identifier.

5. The method according to claim 1, characterized in that, Prior to detecting the existence of the latest version of the grid middleware in the releasable software repository, the method further includes: When a new version of the source code is detected in the source code repository, the new version of the source code is retrieved from the source code repository; The source code of the latest version is built into a new grid middleware and deployed to the test environment; Determine a set of test cases that match the latest version of the source code; The test case set is used to conduct tests in the test environment where the new mesh middleware is deployed, and a test report is generated. Based on the test report, determine whether to store the new mesh middleware in the releasable software repository.

6. The method according to claim 5, characterized in that, The step of determining whether to store the new mesh middleware in the releasable software repository based on the test report includes: If the test report meets the preset conditions, then the new grid middleware will be stored in the releasable software repository.

7. The method according to any one of claims 1-6, characterized in that, Sending the deployment command to the corresponding server includes: The latest version of the grid middleware is obtained from the releasable software repository based on the first identifier; Based on the second identifier, retrieve configuration information from the configuration repository that matches the latest version of the mesh middleware; The deployment instructions, along with the latest version of the grid middleware and configuration information matching the latest version of the grid middleware, are sent to the corresponding server.

8. A deployment device for a grid middleware, characterized in that, The device includes: The software monitoring module is used to determine a first identifier when it detects that the latest version of the grid middleware exists in the releasable software repository, wherein the first identifier is the identifier of the latest version of the grid middleware in the releasable software repository; A deployment parameter update module is used to determine a second identifier based on the first identifier, wherein the second identifier is an identifier of configuration information that matches the latest version of the mesh middleware. The deployment parameter update module is further configured to determine a deployment declaration file based on the first identifier and the second identifier; The service update module is used to determine the deployment instructions for the corresponding server based on the deployment declaration file, and send the deployment instructions to the corresponding server so that the corresponding server can deploy the latest version of the mesh middleware according to the deployment instructions.

9. The apparatus according to claim 8, characterized in that, The device further includes: A configuration monitoring module is configured to determine a third identifier when the latest version of configuration information is detected in the configuration repository, wherein the third identifier is the identifier of the latest version of configuration information in the configuration repository; The deployment parameter update module is further configured to determine a fourth identifier based on the third identifier, wherein the fourth identifier is an identifier of the grid middleware that matches the latest version of the configuration information; The deployment parameter update module is further configured to determine the deployment declaration file based on the third identifier and the fourth identifier.

10. The apparatus according to claim 8 or 9, characterized in that, The device further includes: The source code monitoring module is used to retrieve the latest version of the source code from the source code repository when the latest version of the source code is detected in the source code repository. A package build module is used to build the latest version of the source code into a new grid middleware and deploy it to the test environment; The test execution module is used to determine a set of test cases that match the latest version of the source code based on the latest version of the source code. The test execution module is also used to perform tests in the test environment where the new grid middleware is deployed using the test case set, and to determine a test report; The test feedback module is used to determine whether to store the new mesh middleware in the releasable software repository based on the test report.

Images