Gray strategy synchronization system and synchronization method based on Puppet server and client

Abstract

The invention relates to the technical field of operation and maintenance, in particular to a grayscale strategy synchronization system and a synchronization method based on a Puppet server and a client. The system comprises a Puppet server side and a Puppet client side, a Web console, an Nginx agent side and a Redis strategy side are deployed on the Puppet server side, and a front-end user interface of the Web console comprises a strategy mode and a multi-dimensional control dimension; the Nginx agent side is used for acquiring a synchronization strategy, writing the synchronization strategy into a preset Redis strategy side and forwarding a received synchronization request to the Puppet server side; and the Puppet server side is used for issuing a pre-generated MD5 verification list and a synchronization file to the Puppet client side according to a synchronization strategy after receiving the synchronization request. The problems that high-concurrency scene synchronization interruption risks exist in gray level strategy synchronization and differential requirements of multiple directories and multiple machine rooms cannot be met are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of operation and maintenance, and in particular to a gray release policy synchronization system and a synchronization method based on a Puppet server and a client. BACKGROUND

[0002] Gray release refers to gradually introducing a new version into part of users or user groups for testing and verification during the update process of software or a system, so as to reduce risks and ensure the stability and performance of the system. The existing gray release policy is synchronized in full through a configuration file, and therefore in the case of an increase in malicious traffic in a CDN multi-machine room environment, the existing gray release policy synchronization has the risk of interruption in a high concurrency scenario. Meanwhile, it cannot adapt to differentiated needs of multiple directories and multiple machine rooms. SUMMARY

[0003] Therefore, one of the technical problems solved by the embodiments of the present application is to provide a gray release synchronization method and device based on a Puppet architecture, which solves the problems of the risk of interruption in a high concurrency scenario and the inability to adapt to differentiated needs of multiple directories and multiple machine rooms.

[0004] According to a first aspect of the embodiments of the present application, a gray release policy synchronization system is provided, which includes a Puppet server and a Puppet client. The Puppet server is deployed with a Web console, an Nginx proxy end and a Redis policy end. The Web console is configured to obtain a synchronization configuration generated based on a front-end user interface, to verify and convert the synchronization configuration to obtain a synchronization policy, and the front-end user interface includes a policy mode and a control dimension, and the control dimension includes a directory, a file, a node and a host. The Nginx proxy end is configured to obtain the synchronization policy and write it into the preset Redis policy end, to receive a synchronization request sent by the Puppet client, and to forward the synchronization request to the Puppet server after the synchronization request is verified. The Puppet server is configured to, after receiving the synchronization request, distribute a pre-generated MD5 verification manifest and a synchronization file to the Puppet client according to the synchronization policy.

[0005] According to a second aspect of the embodiments of the present application, a gray release policy synchronization method based on a Puppet server is disclosed, which includes the following steps.

[0006] Obtaining a synchronization policy sent by a Web console, the synchronization policy being a synchronization configuration generated by the Web console based on a front-end user interface, and the synchronization configuration being converted to obtain the synchronization policy, and the front-end user interface including at least a machine room, a directory, a node identifier and a policy mode;

[0007] Using a first interface of an Nginx proxy end to obtain the synchronization policy and write it into a Redis policy end.

[0008] In a third aspect, the embodiment of the present application discloses a method for synchronizing a gray policy based on a Puppet client, which comprises the following steps:

[0009] When the MD5 check list and the synchronization file issued by the Puppet server are detected to be updated, a pre-configured check script is loaded.

[0010] The MD5 check list and the synchronization file are subjected to check processing according to the check script, and a corresponding synchronization log is generated according to a matching result.

[0011] In a fourth aspect, the embodiment of the present application discloses an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the above method when executing the computer program.

[0012] In a fifth aspect, the embodiment of the present application discloses a computer readable storage medium, which stores a computer program, and the computer program implements the steps of the above method when executed by a processor.

[0013] The embodiment of the present application provides a four-dimensional control configuration item including a directory, a file, a node and a host through a front-end user interface of a Web console, converts policy control from static code compilation to a policy injection mode based on a front-end interface, simplifies a gray policy synchronization step, achieves fine control of gray policy synchronization, and realizes the purpose of dynamically adjusting policy granularity. BRIEF DESCRIPTION OF DRAWINGS

[0014] The accompanying drawings, which are incorporated into and form a part of the specification, illustrate one embodiment consistent with the present application and, together with the specification, serve to explain the principles of the application.

[0015] Figure 1 A block diagram of a gray policy synchronization system provided by one embodiment of the present application is shown in the figure;

[0016] Figure 2 A schematic diagram of a front-end user interface of a Web console in a gray policy synchronization system provided by one embodiment of the present application is shown in the figure;

[0017] Figure 3 A flowchart of a gray policy synchronization method based on a Puppet server provided by one embodiment of the present application is shown in the figure;

[0018] Figure 4 A flowchart of a gray policy synchronization method based on a Puppet client provided by one embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0019] In order to make the purposes, technical solutions and advantages of the present application clearer, further detailed description will be made to the embodiments of the present application in combination with the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present application and not used to limit the present application.

[0020] It should be noted that although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a manner different from the module division in the device or the order in the flowchart.

[0021] In order to make the purposes, technical solutions and advantages of the present application clearer, further detailed description will be made to the embodiments of the present application in combination with the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present application and not used to limit the present application.

[0022] According to an embodiment of the present application, a gray-scale policy synchronization system is provided, as shown in Figure 1 The system includes a Puppet server 10 and a Puppet client 20, and the Puppet server 10 is deployed with a Web console 101, an Nginx proxy 102 and a Redis policy end 103. The Web console is used to obtain a synchronization configuration generated based on a front-end user interface, and a synchronization policy is obtained by verifying and converting the synchronization configuration. The front-end user interface includes at least room, directory, node identification and policy mode. The Nginx proxy is used to obtain the synchronization policy and write it into the preset Redis policy end, receive a synchronization request sent by the Puppet client, and forward the synchronization request to the Puppet server after the synchronization request is verified. The Puppet server is used to distribute a pre-generated MD5 verification manifest and a synchronization file to the Puppet client according to the synchronization policy after receiving the synchronization request.

[0023] The embodiment of the present application provides four-dimensional control configuration items including directory, file, node and host through the front-end user interface of the Web console, converts the policy control from static code compilation to policy injection based on the front-end interface, simplifies the gray-scale policy synchronization steps, achieves fine control of gray-scale policy synchronization, and achieves the purpose of dynamically adjusting the policy granularity.

[0024] Specifically, the Web console provides a visual multi-dimensional synchronization rule distribution function through the front-end user interface and the back-end logic. The front-end user interface provides the following dimensions: mode, directory, file, node and host. As shown in Figure 2As shown, the mode configuration item provides global switches for "Allow Synchronization" and "Disable Synchronization"; the directory configuration item supports multi-level directory tree selection, allowing users to select parent directories or subdirectories (such as / data1 / init_gray), and supports online addition or deletion of synchronization directories; the node configuration item allows pre-setting the node loading hierarchy using the node selector. Specifically, the node hierarchy can include a first level, a second level, and a third level. The first level is used to select all nodes, the second level is used to select by data center group, and the third level is used to select hosts within the data center group. In other words, the node configuration item supports selecting all, filtering by data center group, or a single hostname. For example, selecting "all" selects all nodes; another example is selecting the next level of the "czt" node and the host configuration item "s2.yunwei.czt.cn", indicating that the node with the hostname "s2.yunwei.czt.cn" under the "czt" data center group is selected. When applying this, the administrator... Figure 2 When selecting a Field in the front-end user interface, such as selecting / data1 / init_gray, it indicates that the corresponding file / directory path in the server's source directory needs to be synchronized. Administrators can select all nodes or all hosts in an entire data center group (e.g., the czt data center group) for synchronization, or they can select a specific host within a data center group (e.g., a host named s2.yunwei.czt.cn in the czt data center group). The web console generates a corresponding synchronization policy based on the administrator's selections in the front-end user interface, which can be based on the nodes selected by the administrator. For example, assuming the administrator only selected s2.yunwei.czt.cn in the czt data center group, the web console receives the administrator's selections in the front-end user interface, performs policy verification, and converts the configuration corresponding to the selections into JSON format data, such as {"action":"allow","dir":" / init","nodes":["node1","node2"]}.

[0025] In this embodiment, the web console retrieves a list of hosts under the selected node level (e.g., data center group czt) from the backend in real time based on the node level selected by the administrator in the frontend user interface, and renders it on the frontend user interface (e.g., as a checkbox list). This not only facilitates the administrator's hierarchical display in large cluster management but also effectively improves selection efficiency. During application, data can be retrieved from the backend via AJAX requests, and the frontend framework (Vue / React) dynamically generates DOM elements based on the returned data.

[0026] In some embodiments, the Nginx proxy end checks the synchronization request, including: parsing the synchronization request to obtain an IP address and a node identifier, and forwarding the synchronization request to the Puppet server end in a case that the IP address hits a preset whitelist and a synchronization permission of the node identifier is allowed.

[0027] Specifically, the Nginx proxy end judges whether the IP address of the client sending the synchronization request is in the allowed IP range by a preset ACL access control rule.

[0028] Specifically, the synchronization request sent by the Puppet client includes certificate information, the Nginx proxy end parses the IP address, and according to the certificate information, extracts the node identifier, and then uses the node identifier to search in the ACL access control rule, and obtains a case that the parsed IP address is in the allowed IP range and the policy mode corresponding to the node identifier is allowed, and executes the operation of forwarding the synchronization request. Similarly, return a prompt of prohibiting synchronization when any of the following conditions is met: the IP address does not hit the allowed IP range of the node identifier, and the policy mode of the node identifier is prohibited.

[0029] In application, the Nginx proxy end can set a whitelist through the ACL access control rule, and query the whitelist after receiving the synchronization request. If the query hits the whitelist, the synchronization strategy stored by the Redis policy end can be used to check whether the node identifier is allowed to synchronize.

[0030] The application uses the Web console and the Redis policy end to perform policy control, and uses the Nginx proxy end to perform dynamic interception to achieve the purpose of millisecond-level policy effect, which uses the reliability of certificate authentication and the flexibility of IP restriction to build the first line of defense of the Puppet system. At the same time, the modification of the policy is upgraded from code compilation to real-time injection through the front-end user interface, which realizes the purpose of millisecond-level policy effect, sets the policy in multiple dimensions, and solves the problem that the nodes need to be classified and cannot be dynamically adjusted during running in the prior art.

[0031] In some embodiments, the Web console is also used to perform policy checking on the synchronization configuration, and encapsulates the synchronization configuration to obtain a synchronization policy after the policy checking is passed. Specifically, the administrator can execute a selected operation according to the interface as shown in Figure 2 to obtain a corresponding configuration according to the selected operation of the administrator, and perform policy checking on the configuration, such as checking whether the directory exists and whether the IP format is legal, and encapsulate the data to obtain the synchronization policy after the checking is passed.

[0032] In application, the web console can also output the policy of the directory pointed by the selection operation of the user in the directory selection operation of the front-end user interface by using the policy display area included in the front-end user interface after detecting the selection operation. Figure 2 As shown in FIG. 7, the web console detects that the user selects the int directory item, and the web console controls the front-end user interface to output the synchronization policy of int on the right side as {“all”:“1”} and {“w-waf05.nbzt.cn”:“1”}.

[0033] In some embodiments, the Redis policy end is also used to establish a target permission index, so that the user can edit the target permission index through the web console. The application sets a depth value for the directory path through the target permission index, so that subsequent processing such as policy query, directory level control, and gray release can be accelerated according to the depth value. For example, the depth value of the directory is set through the target permission index, thereby generating a multi-level directory tree to allow the user to filter directories at different levels.

[0034] In some embodiments, the Nginx proxy end is also used to obtain node information of a plurality of Puppet clients and generate a node list, so that the web console performs corresponding display processing according to the selection operation of the user in the front-end user interface, and the node information includes a node name and an IP address. Specifically, the Nginx proxy end can store the hostnames and IPs of the nodes in the all_ip.lua file, and the file storage format can be: [“ip”] = [“hostname”], so as to facilitate the front-end to call and check the node or hostname option. In application, the hostnames of the nodes should be unified and obviously identified, so as to be easily identified and checked, for example, waf05.nbzt.cn, indicating that the host is the fifth business machine of nbzt (NingX City computer room).

[0035] In some embodiments, the synchronization request includes certificate information, and the Puppet service end is used to parse the node identifier corresponding to the certificate information, and query the policy mode of the synchronization policy in the Redis policy end by using the node identifier.

[0036] One embodiment of the application provides a gray policy synchronization method based on a Puppet service end, wherein the Puppet service end is deployed with a web console, an Nginx proxy end, and a Redis policy end, as shown in FIG. 8, the method includes steps S101 and S102. Figure 3

[0037] ​Step S101: Obtain the synchronization policy sent by the Web console. The synchronization policy is the synchronization configuration generated by the Web console based on the front-end user interface, and the synchronization configuration is verified and converted. The front-end user interface includes the policy mode and control dimensions. The control dimensions include directories, files, nodes and hosts.

[0038] Step S102: Obtain the synchronization strategy using the first interface of the Nginx proxy and write it to the Redis strategy side.

[0039] Specifically, the front-end user interface provides users with multi-dimensional control through multiple pre-configured controls (such as directories). During application, files can be at the bottom of the directory dimension, allowing users to select files to be synchronized at the directory level. This provides not only directory-level file control but also individual file control. Similarly, hosts can be at the bottom of the node dimension, enabling node control at the data center group and host levels.

[0040] This application provides four-dimensional control configuration items, including directories, files, nodes, and hosts, through the front-end user interface of the Web console. It transforms policy control from static code compilation to a policy injection method based on the front-end interface, simplifies the gray-scale policy synchronization steps, achieves fine-grained control of gray-scale policy synchronization, and realizes the goal of dynamically adjusting the fine-grained nature of the policy. The Nginx proxy can intercept illegal clients on the one hand, and speed up policy execution on the other hand, achieving millisecond-level response for policy execution.

[0041] In some embodiments, the method further includes: when the second interface of the Nginx proxy detects a synchronization request sent by the Puppet client, performing access control verification on the synchronization request; when the access control verification passes, forwarding the synchronization request to the Puppet server; and after receiving the synchronization request, the Puppet server sends the pre-generated MD5 checksum and synchronization file to the Puppet client according to the synchronization policy.

[0042] Specifically, the Puppet client can send a synchronization request to the Puppet server when it detects that a scheduled task has been triggered, based on preset synchronization tasks, such as timed tasks.

[0043] In practice, the Nginx proxy typically uses port 8140 to detect synchronization requests sent by clients and port 8141 to receive synchronization policies sent from the web console, which are then stored in the Redis policy server.

[0044] One embodiment of this application provides a gray-scale policy synchronization method based on a Puppet client, such as... Figure 4 As shown, the method includes:

[0045] Step S201: When the MD5 checksum and the synchronization file update are detected by the Puppet server, load the pre-configured checksum script;

[0046] Step S202: Perform verification processing on the MD5 checklist and the synchronization file according to the verification script, and generate the corresponding synchronization log based on the matching result.

[0047] Specifically, after receiving the MD5 checksum and synchronization file from the Puppet server, the Puppet client performs the following synchronization steps: first, it performs synchronization on the MD5 checksum; after synchronization is complete, it performs synchronization on the synchronization file. This avoids using the old MD5 checksum to verify the new file, ensuring that the verification script always uses the latest MD5 checksum to verify the latest file, thereby ensuring that the file content is consistent with expectations and improving the reliability of gray-scale releases.

[0048] In some embodiments, step S202 further includes: traversing multiple entries corresponding to the MD5 checklist, each entry including an expected MD5 value and a file path; determining the existence status of local files corresponding to the multiple entries based on their respective file paths; if the existence status of any local file corresponding to any entry is yes, calculating the local MD5 value of that local file; matching the local MD5 value of that local file with the expected MD5 value of that entry, and generating a corresponding synchronization log based on the matching result.

[0049] Before application, a shell script check_md5.sh can be written in the Puppet client. This script will be loaded and run by the Puppet client when it detects the MD5 checksum list sent by the Puppet server and the synchronization file has been updated.

[0050] Specifically, when the local MD5 value of the local file corresponding to any entry matches the expected MD5 value corresponding to that entry, a synchronization success indication is generated to prompt the user to perform a restart task or other operations. Similarly, in the case of a failed match, a corresponding log (including the file that failed to match and its corresponding MD5 value) is generated, and an alarm can also be executed so that the administrator can take corresponding actions based on the alarm.

[0051] Specifically, when the verification script (such as check_md5.sh) runs, it first parses the MD5 checksum updated locally, obtaining entries including hash values ​​and corresponding file paths. The file path of each entry is then used to determine if a local file exists on the Puppet client. If it does, the corresponding MD5 value is calculated and matched against the expected MD5 value (i.e., the parsed hash value) for that entry. A match indicates synchronization is complete. If the expected MD5 value does not match or the file is missing (i.e., the file to be synchronized has not been received locally), log processing is performed, and alarm information can be generated using a preset interface. Before determining whether the file to be synchronized has been received on the Puppet client, a predefined file filtering mechanism can be used to ignore files in the parsed results. For example, each parsed entry is matched against file ignore rules; if a match is successful, the verification of that file is skipped, such as temporary files or cached files. That is, if temporary files or cached files are detected, the current file is ignored to reduce resource consumption, lower the false alarm rate, and improve verification efficiency. Therefore, by modifying the file filtering mechanism, the selection of files to be ignored for verification can be achieved.

[0052] In some embodiments, before calculating the local MD5 value of the local file corresponding to any entry in step S202, the method further includes: matching the local file corresponding to any entry with a pre-configured ignore list; if the match fails, calculating the MD5 value of the local file corresponding to any entry.

[0053] Specifically, you can set up an ignore list based on the types of files that need to be skipped to avoid calculating the MD5 value of specific files. For example, the ignore list can include specific files such as temporary files, cache files, and log files, along with their filtering rules, such as regular expressions. This way, if a regular expression is matched, the validation of the specific file is skipped, allowing you to quickly determine the target file that needs to be synchronized and then calculate its MD5 value.

[0054] Specifically, file filtering rules for different application scenarios can be pre-set, and the file filtering rules for the target file can be determined when the user's selected operation is detected, thereby avoiding the problem of massive alarms caused by frequent file changes.

[0055] When applying this feature, you can handle versions requiring urgent updates by updating the ignore list. This involves adding files that need temporary modifications to the ignore list configuration in the verification script. For example, if version A is being released in a canary rollout, and a temporary version B is released to urgently fix a bug, assuming temporary version B only modifies one file: ` / home / work / waf / conf / nginx.conf`, then this temporary version B should be added to the ignore list of the verification script (e.g., `check_md5.sh`). Assuming the original ignore list is:

[0056]

[0057] The ignored list has been modified to:

[0058]

[0059] Since this file is already in the ignore list, even if its MD5 value does not match the MD5 checksum list (version A's list) sent by the server, the checksum script will skip it and will not issue an alert. Later, when you need to roll back to the official version or merge it with a new official version, simply remove the newly added record [' / home / work / waf / conf / nginx.conf']=1 from the modified ignore list.

[0060] The gray-scale policy synchronization system of this embodiment can execute the gray-scale policy synchronization method based on the Puppet server and the gray-scale policy synchronization method based on the Puppet client shown in the embodiments of this application. Their implementation principles are similar and will not be described again here.

[0061] Another embodiment of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0062] Specifically, the processor can be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic device, transistor logic device, hardware component, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0063] Specifically, the processor connects to the memory via a bus, which may include a path for transmitting information. The bus can be a PCI bus or an EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc.

[0064] The memory may be ROM or other types of static storage devices that can store static information and instructions, RAM or other types of dynamic storage devices that can store information and instructions, or EEPROM, CD-ROM or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto.

[0065] Optionally, the memory stores the code of a computer program that executes the scheme of this application, and the execution is controlled by a processor. The processor executes the application code stored in the memory to implement the operation of the apparatus provided in the above embodiments.

[0066] Another embodiment of this application provides a computer-readable storage medium storing computer-executable instructions for performing the methods provided in the above embodiments.

[0067] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0068] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0069] The above is a detailed description of the preferred embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A gray-scale strategy synchronization system, comprising a Puppet server and a Puppet client, characterized in that, The Puppet server is deployed with a web console, an Nginx proxy, and a Redis policy client. The Web console is used to obtain the synchronization configuration generated based on the front-end user interface, verify and convert the synchronization configuration to obtain the synchronization policy. The front-end user interface includes policy mode and control dimension. The control dimension includes directory, file, node and host. The Nginx proxy is used to obtain the synchronization strategy and write it into the preset Redis strategy; receive the synchronization request sent by the Puppet client, and forward it to the Puppet server after the synchronization request passes the verification. The Puppet server is used to send the pre-generated MD5 checksum and synchronization file to the Puppet client according to the synchronization strategy after receiving the synchronization request.

2. The system according to claim 1, characterized in that, The Nginx proxy verifies the synchronization request by parsing the synchronization request to obtain the IP address and synchronization directory. If the IP address matches a preset whitelist and the synchronization directory has allowed synchronization permissions, the synchronization request is forwarded to the Puppet server.

3. The system according to claim 1, characterized in that, The web console is also used to perform policy verification on the synchronization configuration, and after the policy verification passes, to encapsulate the synchronization configuration into a synchronization policy.

4. The system according to claim 1, characterized in that, The Redis policy interface is also used to create a target permission index, allowing users to edit the target permission index through the web console.

5. The system according to claim 1, characterized in that, The Nginx proxy is also used to obtain node information from multiple Puppet clients and generate a node list, so that the Web console can perform corresponding display processing based on the user's selected operation in the front-end user interface. The node information includes node name and IP address.

6. The system according to claim 1, characterized in that, The synchronization request includes certificate information from the Puppet client. The Puppet server parses the node identifier corresponding to the certificate information and uses the node identifier to query the corresponding synchronization strategy pattern in the Redis strategy client.

7. A method for synchronizing a canary deployment strategy based on a Puppet server, characterized in that, The Puppet server is deployed with a web console, an Nginx proxy, and a Redis strategy client. The method includes: Obtain the synchronization policy sent by the Web console. The synchronization policy is a synchronization configuration generated by the Web console based on the front-end user interface, and the synchronization configuration is converted. The front-end user interface includes at least the data center, directory and node identifiers and the policy mode. The synchronization strategy is obtained using the first interface of the Nginx proxy and written to the Redis strategy client.

8. The method according to claim 7, characterized in that, The method further includes: When the second interface of the Nginx proxy detects a synchronization request sent by the Puppet client, it performs access control verification on the synchronization request. Once the access control verification passes, the synchronization request is forwarded to the Puppet server. After receiving the synchronization request, the Puppet server sends the pre-generated MD5 checksum and synchronization file to the Puppet client according to the synchronization strategy.

9. A method for synchronizing a canary strategy based on a Puppet client, characterized in that, include: When the MD5 checksum and synchronized file update are detected by the Puppet server, the pre-configured checksum script is loaded. The verification script is used to perform verification processing on the MD5 verification list and the synchronization file, and corresponding synchronization logs are generated based on the matching results.

10. The method according to claim 9, characterized in that, The step of performing verification processing on the MD5 checksum and the synchronized file according to the verification script includes: Iterate through multiple entries corresponding to the MD5 checksum list, where each entry includes the expected MD5 value and the file path; Based on the file paths corresponding to the multiple entries, determine the existence status of the local files corresponding to the multiple entries. If the local file corresponding to any entry exists, then calculate the local MD5 value of the local file corresponding to that entry. Match the local MD5 value of the local file corresponding to any entry with the expected MD5 value corresponding to any entry, and generate the corresponding synchronization log based on the matching result.

Images