A salt-stack-based configuration and verification system and method

By encapsulating configuration data into HTTP static files at the edge nodes and restarting the business software, version information is uploaded asynchronously for verification, thus solving the problems of configuration file effectiveness and version consistency, and achieving reliable and consistent management of configuration distribution.

CN114579344BActive Publication Date: 2025-02-18BEIJING XINLIU WANLIAN NETWORK TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202210234732.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-03-09
Publication Date
2025-02-18
Estimated Expiration
2042-03-09

AI Technical Summary

Technical Problem

Existing open-source salt-stack configuration distribution platforms cannot effectively verify whether configuration files are truly effective, nor can they guarantee that the configuration file version matches the expected version.

Method used

By encapsulating configuration data and version information into an HTTP static file at the edge node, restarting the business software, and asynchronously uploading the version information to the control node for verification, the system ensures that the configuration file takes effect while checking version consistency.

Benefits of technology

It enables configuration files to take effect while ensuring consistency between the actual configuration file version and the expected version, provides a verification method for configuration distribution, and improves the reliability of configuration management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114579344B_ABST
    Figure CN114579344B_ABST
Patent Text Reader

Abstract

The present invention provides a salt-stack configuration-based verification system and method, including step 1, initiating configuration data verification; if the configuration data in the central node and the edge node are inconsistent, the edge node stores the configuration data in the central node; the edge node encapsulates the version information corresponding to the configuration data before and after the capture as an http static file and sends it to the business software, restarting the business software; the edge node requests the version information corresponding to the configuration data in the http static file that takes effect after the business software is restarted; the edge node asynchronously uploads the version information requested in step 4 to the control node; the control node verifies the consistency between the version information uploaded from the edge node and the locally stored version information and makes it public at the same time. The verification method based on the open source salt-stack configuration-based verification method of the present invention ensures that the configuration file takes effect and checks the version of the configuration file to ensure that the version of the actual configuration file is consistent with the expected version.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The invention belongs to the field of computer technology, and in particular relates to a hoisting tool for a rocket engine nozzle diffusion section. Background Art

[0002] Salt-stack is a new infrastructure management method. It is easy to deploy and can be run in a few minutes. It has good scalability and can easily manage tens of thousands of servers. It is fast enough and can communicate between servers in seconds. It is a set of C / S automated operation and maintenance tools developed based on Python. The communication uses zeromq message queue (pub / sub), data transmission uses AES (advanced encryption) to ensure security, and authentication uses SSL. It is a popular open source platform for configuration distribution.

[0003] However, this configuration distribution platform can only push configuration files to business machines and restart the corresponding business software. As long as the business software is successfully started, it will be reported successfully. However, there is no way to know whether the actual configuration file content is actually effective. The specific process steps are as follows: the user modifies the data of the business software configuration items through the console interface or external interface, which can be one or more items; the edge node software salt-minion edge triggers and regularly queries the central salt-master for new configuration data; salt-minion terminates if there is no new data, and if there is configuration data update, it grabs the latest configuration data, assembles a new configuration file, moves it to the corresponding business software directory, calls the business software syntax to check the configuration file, and restarts the business software; salt-minion reports the execution status, and if there is an error, it returns the error result of the execution; manual intervention checks the error result, modifies it, and then the central triggers the configuration distribution.

[0004] In view of this, it is urgent to propose a verification method based on the open source salt-stack configuration distribution to ensure that the configuration file takes effect and check the version of the configuration file to ensure that the actual configuration file version is consistent with the expected version. Summary of the invention

[0005] To this end, the present invention proposes a verification method based on the open source salt-stack configuration and distribution, which ensures that the configuration file is effective and checks the version of the configuration file to ensure that the actual configuration file version is consistent with the expected version.

[0006] The configuration delivery verification method based on salt-stack of the present invention comprises the following steps:

[0007] Step 1: Initiate configuration data verification;

[0008] Step 2: If the configuration data in the central node is inconsistent with the configuration data in the edge node, the edge node stores the configuration data in the central node;

[0009] Step 3: The edge node encapsulates the version information corresponding to the configuration data before and after the capture into an http static file and sends it to the business software, and restarts the business software;

[0010] Step 4: The edge node requests the version information corresponding to the configuration data in the http static file that takes effect after the business software is restarted;

[0011] Step 5: The edge node asynchronously uploads the version information requested in step 4 to the control node;

[0012] Step 6: The control node verifies the consistency between the version information uploaded from the edge node and the locally stored version information and makes it public at the same time.

[0013] Furthermore, before initiating configuration data verification in step 1, the following steps are included:

[0014] Central triggering, where the central node periodically sends configuration data and corresponding version information to the edge node, and the edge node performs storage; or

[0015] Edge triggering: the edge node periodically queries the configuration data in the central node, and the edge node captures and executes the storage.

[0016] Furthermore, in step 3, the specific process of encapsulating the version information into an http static file is to traverse each data item in the configuration data, extract the domain name data item and the corresponding time data item

[0017] by

[0018] Domain name data item, time data item;

[0019] Format to concatenate strings, and then concatenate multiple strings in different configuration data

[0020] After completion, the final result is output as an http static file.

[0021] Furthermore, when the edge node requests in step 4,

[0022] curl -svo http static file address -x IP

[0023] Initiate commands to the specified business software;

[0024] in,

[0025] Curl is a client tool for grabbing http resource content. Its corresponding parameters are:

[0026] s: The output does not print error and progress information, and the response body will be printed if the response is correct;

[0027] v: Display detailed request and response information;

[0028] o: Save the server's response body to the file version.html;

[0029] x: Use a proxy on the specified IP and port.

[0030] Furthermore, before step 4, the method further includes: when the edge node executes any one of steps 1 to 3, reporting the execution status to the central node;

[0031] If there is an error in the execution status, return to the currently executed step;

[0032] If there is no error in the execution status, proceed to the next step.

[0033] Furthermore, step seven is included, if the control node verifies that the version information uploaded from the edge node is inconsistent with the locally stored version information, the inconsistent configuration data and the corresponding version information are extracted and modified to the version information stored locally in the control node, and then sent down through the central trigger.

[0034] The present invention also provides an open source-based salt-stack configuration and delivery verification system, comprising a console, wherein the console is connected to an alarm platform;

[0035] A central configuration node, the central configuration node including at least one primary salt-master and one backup salt-master;

[0036] Edge nodes, there are multiple edge nodes, each of which is in communication connection with the central configuration node, and the edge nodes include salt-minion and business software.

[0037] Furthermore, the console has multiple APIs.

[0038] The present invention further provides an electronic device, comprising:

[0039] processor;

[0040] a memory for storing instructions executable by the processor;

[0041] The processor is used to execute the salt-stack-based configuration delivery verification method.

[0042] The present invention also provides a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program is used to execute the salt-stack-based configuration delivery verification method.

[0043] The above technical solution of the present invention has the following advantages compared with the prior art:

[0044] The present invention provides a configuration delivery verification method based on open source salt-stack, which stores the configuration file after the configuration data is modified as a static file and delivers it in batches, ensuring that the configuration file takes effect and checking the version of the configuration file at the same time to ensure that the version of the actual configuration file is consistent with the expected version. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 is a flow chart of a method provided by an embodiment of the present invention;

[0046] Figure 2 is a schematic diagram of module connections of a system provided by an embodiment of the present invention;

[0047] Figure 3 It is a schematic diagram of module connection of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0048] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0049] Embodiment 1

[0050] The method of this embodiment, such as Figure 1 As shown, it includes: step 1, initiating configuration data verification;

[0051] Step 2: If the configuration data in the central node is inconsistent with the configuration data in the edge node, the edge node stores the configuration data in the central node;

[0052] Step 3: The edge node encapsulates the version information corresponding to the configuration data before and after the capture into an http static file and sends it to the business software, and restarts the business software;

[0053] Step 4: The edge node requests the version information corresponding to the configuration data in the http static file that takes effect after the business software is restarted;

[0054] Step 5: The edge node asynchronously uploads the version information requested in step 4 to the control node;

[0055] Step 6: The control node verifies the consistency between the version information uploaded from the edge node and the locally stored version information and makes it public at the same time.

[0056] Furthermore, before initiating configuration data verification in step 1, the following steps are included:

[0057] Central triggering, where the central node periodically sends configuration data and corresponding version information to the edge node, and the edge node performs storage; or

[0058] Edge triggering: the edge node periodically queries the configuration data in the central node, and the edge node captures and executes the storage.

[0059] Furthermore, in step 3, the specific process of encapsulating the version information into an http static file is to traverse each data item in the configuration data, extract the domain name data item and the corresponding time data item

[0060] by

[0061] Domain name data item, time data item;

[0062] Format to concatenate strings, and then concatenate multiple strings in different configuration data

[0063] After completion, the final result is output as an http static file.

[0064] Furthermore, when the edge node requests in step 4,

[0065] curl -svo http static file address -x IP

[0066] Initiate commands to the specified business software;

[0067] in,

[0068] Curl is a client tool for grabbing http resource content. Its corresponding parameters are:

[0069] s: The output does not print error and progress information, and the response body will be printed if the response is correct;

[0070] v: Display detailed request and response information;

[0071] o: Save the server's response body to the file version.html;

[0072] x: Use a proxy on the specified IP and port.

[0073] Furthermore, before step 4, the method further includes: when the edge node executes any one of steps 1 to 3, reporting the execution status to the central node;

[0074] If there is an error in the execution status, return to the currently executed step;

[0075] If there is no error in the execution status, proceed to the next step.

[0076] Furthermore, step seven is included, if the control node verifies that the version information uploaded from the edge node is inconsistent with the locally stored version information, the inconsistent configuration data and the corresponding version information are extracted and modified to the version information stored locally in the control node, and then sent down through the central trigger.

[0077] The present invention also provides a verification system based on open source and salt-stack configuration, such as Figure 2 As shown, it includes a console, and the console is connected to the alarm platform;

[0078] A central configuration node, the central configuration node including at least one primary salt-master and one backup salt-master;

[0079] Edge nodes, there are multiple edge nodes, each of which is in communication connection with the central configuration node, and the edge nodes include salt-minion and business software.

[0080] Furthermore, the console has multiple APIs.

[0081] Below, reference Figure 3 The electronic device according to the embodiment of the present application is described. The electronic device may be any one or both of the first device and the second device, or a stand-alone device independent of them, and the stand-alone device may communicate with the first device and the second device to receive the collected input signal from them.

[0082] Figure 3 A block diagram of an electronic device according to an embodiment of the present application is shown.

[0083] like Figure 3 As shown, the electronic device 10 includes one or more processors 11 and a memory 12 .

[0084] The processor 11 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 10 to perform desired functions.

[0085] The memory 12 may include one or more computer program products, and the computer program product may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory (cache), etc. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 11 may run the program instructions to implement the video generation method supporting multi-protocol video live broadcast of the various embodiments of the present application described above and / or other desired functions. Various contents such as input signals, signal components, noise components, etc. may also be stored in the computer-readable storage medium.

[0086] In one example, the electronic device 10 may further include: an input device 13 and an output device 14, and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0087] When the electronic device is a stand-alone device, the input device 13 may be a communication network connector, which is used to receive the collected input signals from the first device and the second device.

[0088] In addition, the input device 13 may also include, for example, a keyboard, a mouse, and the like.

[0089] The output device 14 can output various information to the outside, including determined distance information, direction information, etc. The output device 14 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0090] Of course, to simplify, Figure 3 Only some of the components related to the present application in the electronic device 10 are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, according to specific application situations, the electronic device 10 may also include any other appropriate components.

[0091] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the video generation method supporting multi-protocol video live broadcast according to various embodiments of the present application described in the above-mentioned "Exemplary Method" section of this specification.

[0092] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0093] In addition, an embodiment of the present application may also be a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, enables the processor to execute the steps of a video generation method supporting multi-protocol video live broadcast according to various embodiments of the present application described in the above “Exemplary Method” section of this specification.

[0094] The computer readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can include, for example, but is not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0095] Embodiment 2

[0096] This embodiment is an application embodiment based on the first embodiment, and reproduces the method in the first embodiment in a certain scenario.

[0097] The user modifies the data of the business software configuration items through the console interface or external interface, which can be one or more items.

[0098] The edge node software salt-minion is triggered at the edge to periodically query the central salt-master for new configuration data

[0099] If there is no new data, salt-minion will terminate. If there is a configuration data update, it will grab the latest configuration data, assemble a new configuration file, move it to the corresponding business software directory, call the business software syntax check configuration file, and restart the business software.

[0100] Create a new version list configuration file. Encapsulate the version information currently used by this salt-minion and the latest version issued into a new configuration file version.html and send it to the business software. At the same time, the business software uses this file as a static file of HTTP to provide GET request service.

[0101] The requested command is similar to the following:

[0102] curl-svo version.html"http: / / version.sinocache.net / version.html"-x127.0.0.1:80

[0103] The obtained content contains a list of all corresponding configuration versions, separated by semicolons, as follows:

[0104] tccdn.jsfz.czedu.com.cn,20200921143449833; hls-playback-l.nje.cn,202009211 43449529;tvcdn.sinotruk.com,20200921143449160;cdn-x1art-assets.n1.com.cn, 20200921143449777; live.educlouds.cn,20200921143449564; wxwb.scqstv.com,202 00921143449405;hls-playback-h.nje.cn,20200921143449492;upload.qudong.com.

[0105] Salt-minion reports the execution status and, if an error occurs, returns the error result of the execution.

[0106] After the end, salt-minion immediately initiates an HTTP GET request to the local business software to obtain the above version.html and obtain the effective configuration version information list of the business software. Salt-minion also asynchronously reports the configuration version information list to the console for unified display.

[0107] The console periodically checks the actual reported configuration version against the expected configuration version. If they are consistent, the release is successful. If they are inconsistent, an alarm is triggered. After receiving the alarm, manual intervention is performed to check the error results, modify them, and then the central configuration is triggered to release and execute the above steps.

[0108] The console receives the above message, parses, stores, displays, proofreads, and issues an alarm, completing the closed loop of the entire configuration delivery.

[0109] Obviously, the above embodiments are merely examples for the purpose of clear explanation, and are not intended to limit the implementation methods. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the implementation methods here. The obvious changes or modifications derived therefrom are still within the scope of protection of the invention.

Claims

1. A configuration delivery verification method based on salt-stack, characterized in that: The steps include: Step 1: Initiate configuration data verification; Step 2: If the configuration data in the central node is inconsistent with the configuration data in the edge node, the edge node stores the configuration data in the central node; Step 3: The edge node encapsulates the version information corresponding to the configuration data before and after the capture into an http static file and sends it to the business software, and restarts the business software; Step 4: The edge node requests the version information corresponding to the configuration data in the http static file that takes effect after the business software is restarted; Step 5: The edge node asynchronously uploads the version information requested in step 4 to the control node; Step 6: The control node verifies the consistency between the version information uploaded from the edge node and the locally stored version information and makes it public at the same time.

2. According to the salt-stack-based configuration delivery verification method described in claim 1, it is characterized in that: Before initiating configuration data verification in step 1, include: Central triggering, where the central node periodically sends configuration data and corresponding version information to the edge node, and the edge node performs storage; or Edge triggering: the edge node periodically queries the configuration data in the central node, and the edge node captures and executes the storage.

3. According to the salt-stack-based configuration delivery verification method described in claim 2, it is characterized in that: In step three, the specific process of encapsulating the version information into an http static file is to traverse each data item in the configuration data, extract the domain name data item and the corresponding time data item to splice the string in the format of domain name data item, time data item; and then output the final result as an http static file after splicing multiple strings in different configuration data.

4. The configuration delivery verification method based on salt-stack according to claim 3 is characterized in that: When the edge node requests in step 4, a command is initiated to the specified business software using curl-svo http static file address -x IP; curl is a client tool for grabbing http resource content, and its corresponding parameters are: s: output does not print error and progress information, and the response body will be printed if the return is correct; v: display detailed request and response information; o: save the server's response body to the file version.html; x: use a proxy on the specified IP and port.

5. The configuration delivery verification method based on salt-stack according to claim 4 is characterized in that: Before step 4, the method also includes: when the edge node executes any step from step 1 to step 3, reporting the execution status to the central node; if there is an error in the execution status, returning to the currently executed step; if there is no error in the execution status, executing the next step.

6. The configuration delivery verification method based on salt-stack according to claim 5, characterized in that: It also includes step seven, if the control node verifies that the version information uploaded from the edge node is inconsistent with the locally stored version information, extract the inconsistent configuration data and the corresponding version information, modify it to the version information stored locally in the control node, and send it down through the central trigger.

7. A salt-stack-based open source configuration and verification system, characterized in that: The method described in any one of claims 1 to 6 includes a console, which is connected to an alarm platform; a central configuration node, which includes at least one main salt-master and one backup salt-master; an edge node, which is multiple, each of which is communicatively connected to the central configuration node, and includes a salt-minion and business software.

8. The salt-stack-based configuration and verification system according to claim 7, characterized in that: The console has multiple APIs.

9. A computer-readable storage medium storing a computer program, wherein the computer program is used to execute the salt-stack-based configuration delivery verification method according to any one of claims 1 to 6.

10. An electronic device, comprising: processor; a memory for storing instructions executable by the processor; The processor is used to execute the salt-stack-based configuration delivery verification method described in any one of claims 1 to 6 above.