CN107659458B - Agent deployment and upgrade method and system based on git version control - Google Patents
Agent deployment and upgrade method and system based on git version control Download PDFInfo
- Publication number
- CN107659458B CN107659458B CN201711063697.7A CN201711063697A CN107659458B CN 107659458 B CN107659458 B CN 107659458B CN 201711063697 A CN201711063697 A CN 201711063697A CN 107659458 B CN107659458 B CN 107659458B
- Authority
- CN
- China
- Prior art keywords
- agent
- version
- deployment
- deployed
- target server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The invention relates to an Agent deployment and upgrade method and a system based on Git version control, wherein the method comprises the steps of deploying an Agent configuration management service end component and a Git warehouse to a target server and respectively starting the Agent configuration management service end component and the Git warehouse; deploying an Agent Daemon service component for a target server; uploading the Agent deployment package to a Git warehouse and configuring an Agent deployment strategy; and synchronizing the Agent deployment strategy aiming at the Agent Daemon service component, and executing command operation corresponding to the Agent deployment strategy. The invention simplifies the deployment configuration difficulty, realizes the quick rollback of the version, separates the deployment package from the configuration file, provides a simple configuration upgrading management mechanism by utilizing a Git version mechanism and avoids introducing a complex configuration management system.
Description
Technical Field
The invention relates to an Agent deployment and upgrade method, in particular to an Agent deployment and upgrade method and system based on git version control.
Background
The traditional computing system is closed and needs to meet the requirement of consistency, however, the social mechanism is open and cannot meet the consistency condition, some individuals under the mechanism need to achieve an acceptable solution through a certain negotiation mechanism under the condition of contradiction, the individuals in the computing society are called agents, the organic combination of the individuals forms a computing society-multi-Agent system, namely, the agents refer to computing entities which are resident in a certain environment, can continuously and autonomously play a role and have the characteristics of residence, reactivity, sociality, initiative and the like.
With the development of internet distributed technology, more and more systems adopt the architecture design of agents, so that a plurality of agents (such as monitoring agents, deployment agents, naming agents, log collection agents and the like) need to be deployed on each server, if the public driver has a small amount of devices, the problem of manual installation by using tools such as pssh, infrastructure, fabric and the like is not great, but after the public driver has a large amount of devices, manual installation, upgrading and rollback of the agents are troublesome. At present, two ways are adopted for deployment, one way is that the scripts written by using the ansable and the like can also realize batch deployment, the target server IP address is appointed by writing the Agent installation script, and the installation script is pushed to the target server to execute installation; meanwhile, the scheme can independently push the configuration file to the target server, but the server address, the account number and other information are required to be configured for each deployment, the configuration is troublesome, especially the IP address and other information of the server are difficult to know in time by the current popular virtual machine and container creation server mode, and the deployment state of the Agent cannot be monitored in real time; moreover, version management is lacked, installation scripts need to be modified every time updating is carried out, and rollback efficiency is low; secondly, when the virtual machine is created, the agents are bound to the mirror image to realize deployment, but the method does not consider the condition of Agent version upgrading, the agents are likely to be configured differently when deployed to different servers, and after the virtual machine is started, manual login is needed to modify the configuration of each Agent.
Therefore, it is necessary to design an Agent deployment and upgrade method based on git version control, which simplifies the difficulty of batch deployment and configuration, realizes the quick rollback of versions, avoids introducing a complex configuration management system, and is simple to deploy.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provides a method and a system for Agent deployment and upgrading based on git version control.
In order to achieve the purpose, the invention adopts the following technical scheme: the Agent deployment and upgrade method based on git version control comprises the following steps:
deploying an Agent configuration management service end component and a git warehouse to a target server and starting the Agent configuration management service end component and the git warehouse respectively;
deploying an Agent Daemon service component for a target server;
uploading the Agent deployment package to a git warehouse and configuring an Agent deployment strategy;
synchronizing an Agent deployment strategy aiming at an Agent Daemon service component, and executing command operation corresponding to the Agent deployment strategy;
the method comprises the steps of synchronizing an Agent deployment strategy aiming at an Agent Daemon service component and executing command operation corresponding to the Agent deployment strategy, and comprises the following specific steps:
the Agent Daemon service component synchronizes an Agent deployment strategy;
acquiring Agent version information to be deployed by a target server;
judging whether the Agent version information is consistent with the Agent version currently deployed by the target server;
if the Agent version information is consistent with the Agent version currently deployed by the target server, updating a configuration file corresponding to the Agent deployment package, and uploading an Agent deployment state;
if the Agent version information is not consistent with the Agent version currently deployed by the target server, judging whether the Agent version information needing to be deployed is contained in the target server or not through a git version management mechanism;
if the target server already contains the Agent version information to be deployed, switching the Agent version currently deployed by the target server to the Agent version to be deployed, updating an Agent deployment package and a corresponding configuration file, and uploading the Agent deployment state;
and if the target server does not contain the Agent version information to be deployed, downloading the Agent version to be deployed from the git warehouse, and switching the currently deployed Agent version of the target server to the Agent version to be deployed.
The further technical scheme is as follows: the method comprises the following steps of uploading an Agent deployment package to a git warehouse and configuring an Agent deployment strategy, wherein the steps comprise the following specific steps:
acquiring an Agent deployment package to be deployed and a corresponding configuration file;
submitting the Agent deployment package and the corresponding configuration file to a git warehouse;
reporting the address of a target server, and grouping the target servers;
setting Agent version information to be deployed for each group of target servers;
and setting an execution operation command of the Agent.
The further technical scheme is as follows: acquiring version information of a configuration file corresponding to an Agent deployment package;
judging whether the version information of the configuration file is consistent with the current version information of the configuration file of the target server or not;
if the version information of the configuration file is consistent with the current version information of the configuration file of the target server, uploading an Agent deployment state;
if the version information of the configuration file is inconsistent with the current configuration file version information of the target server, judging whether the target server contains the version of the configuration file corresponding to the Agent deployment package to be deployed or not through a git version management mechanism;
if the target server already contains the version of the configuration file corresponding to the Agent deployment package to be deployed, switching the version of the current configuration file of the target server to the version information of the configuration file corresponding to the Agent deployment package to be deployed, and uploading the Agent deployment state;
and if the target server does not contain the version of the configuration file corresponding to the Agent deployment package to be deployed, downloading the version information of the configuration file corresponding to the Agent deployment package to be deployed from the git warehouse, and uploading the Agent deployment state.
The invention also provides an Agent deployment and upgrade system based on git version control, which comprises an assembly processing unit, an Agent Daemon processing unit, a deployment package processing unit and a deployment unit;
the component processing unit is used for deploying the Agent configuration management service end component and the git warehouse to a target server and respectively starting the Agent configuration management service end component and the git warehouse;
the Agent Daemon processing unit is used for deploying an Agent Daemon service component to a target server;
the deployment package processing unit is used for uploading the Agent deployment package to a git warehouse and configuring an Agent deployment strategy;
the deployment unit is used for synchronizing the Agent deployment strategy aiming at the Agent Daemon service component and executing command operation corresponding to the Agent deployment strategy;
the deployment unit comprises a synchronization module, an Agent version information acquisition module, an Agent version judgment module, an update module, an Agent version existence judgment module, an Agent version switching module and an Agent version downloading module;
the synchronization module is used for synchronizing Agent deployment strategies of the Agent Daemon service components;
the Agent version information acquisition module is used for acquiring Agent version information required to be deployed by a target server;
the Agent version judging module is used for judging whether the Agent version information is consistent with the Agent version currently deployed by the target server;
the updating module is used for updating the configuration file corresponding to the Agent deployment package and uploading the Agent deployment state if the Agent version information is consistent with the Agent version currently deployed by the target server;
the Agent version existence judging module is used for judging whether the Agent version information needing to be deployed is contained in the target server through a git version management mechanism if the Agent version information is inconsistent with the Agent version currently deployed by the target server;
the Agent version switching module is used for switching the Agent version currently deployed by the target server to the Agent version to be deployed if the Agent version information to be deployed is contained in the target server;
and the Agent version downloading module is used for downloading the Agent version to be deployed from the git warehouse if the target server does not contain the Agent version information to be deployed.
The further technical scheme is as follows: the deployment package processing unit comprises a data acquisition module, a submission module, an address reporting module, a version information setting module and a command setting module;
the data acquisition module is used for acquiring the Agent deployment package to be deployed and the corresponding configuration file;
the submitting module is used for submitting the Agent deployment package and the corresponding configuration file to a git warehouse;
the address reporting module is used for reporting the address of the target server and grouping the target servers;
the version information setting module is used for setting the Agent version information to be deployed of each group of target servers;
and the command setting module is used for setting an execution operation command of the Agent.
The further technical scheme is as follows: the updating module comprises a file version obtaining sub-module, a file version judging sub-module, a state uploading sub-module, a file version existence judging sub-module, a file version switching sub-module and a file version downloading sub-module;
the file version acquisition submodule is used for acquiring version information of a configuration file corresponding to the Agent deployment package;
the file version judging submodule is used for judging whether the version information of the configuration file is consistent with the current version information of the configuration file of the target server or not;
the state uploading sub-module is used for uploading the Agent deployment state if the version information of the configuration file is consistent with the current version information of the configuration file of the target server;
the file version existence judgment submodule is used for judging whether the version information of the configuration file is inconsistent with the current configuration file version information of the target server or not through a git version management mechanism, wherein the version information of the configuration file is not consistent with the current configuration file version information of the target server;
the file version switching submodule is used for switching the version of the current configuration file of the target server to the version information of the configuration file corresponding to the Agent deployment package to be deployed if the version of the configuration file corresponding to the Agent deployment package to be deployed is contained in the target server;
and the file version downloading submodule is used for downloading the version information of the configuration file corresponding to the Agent deployment package to be deployed from the git warehouse if the version of the configuration file corresponding to the Agent deployment package to be deployed is not contained in the target server.
Compared with the prior art, the invention has the beneficial effects that: according to the Agent deployment and upgrade method based on git version control, the Agent configuration management service end component and the Agent Daemon service component are adopted to automatically discover the IP and the name of the target server, so that the deployment and configuration difficulty is simplified, the Agent Daemon service component is convenient for monitoring various Agent deployment states of the target server, the self version management mechanism of a git warehouse is utilized to realize quick rollback of the version, the deployment package is separated from the configuration file, and the git version mechanism is utilized to provide a simple configuration upgrade management mechanism and avoid introducing a complex configuration management system.
The invention is further described below with reference to the accompanying drawings and specific embodiments.
Drawings
Fig. 1 is a first flowchart of an Agent deployment and upgrade method based on git version control according to an embodiment of the present invention;
fig. 2 is a flowchart ii of an Agent deployment and upgrade method based on git version control according to an embodiment of the present invention;
FIG. 3 is a flowchart for uploading an Agent deployment package to a git repository and configuring an Agent deployment policy, according to an embodiment of the present invention;
fig. 4 is a flowchart of synchronizing Agent deployment policies for Agent Daemon service components and executing command operations corresponding to the Agent deployment policies, according to an embodiment of the present invention;
fig. 5 is a flowchart of updating a configuration file corresponding to an Agent deployment package and uploading an Agent deployment state according to an embodiment of the present invention;
fig. 6 is a block diagram of a configuration of an Agent deployment and upgrade system based on git version control according to an embodiment of the present invention;
fig. 7 is a block diagram of a deployment package processing unit according to an embodiment of the present invention;
fig. 8 is a block diagram of a deployment unit according to an embodiment of the present invention;
fig. 9 is a block diagram of an update module according to an embodiment of the present invention.
Detailed Description
In order to more fully understand the technical content of the present invention, the technical solution of the present invention will be further described and illustrated with reference to the following specific embodiments, but not limited thereto.
As shown in specific embodiments of fig. 1 to 9, the Agent deployment and upgrade method based on git version control provided in this embodiment can be applied to a batch deployment and upgrade process of zabbix-Agent, so that batch deployment configuration difficulty is simplified, quick rollback of versions is realized, a complex configuration management system is avoided, and deployment is simple.
As shown in fig. 1, the embodiment provides an Agent deployment and upgrade method based on git version control, and the method includes:
s1, deploying the Agent configuration management service end component and the git warehouse to a target server and respectively starting;
s2, deploying an Agent Daemon service component for the target server;
s3, uploading the Agent deployment package to a git warehouse and configuring an Agent deployment strategy;
and S4, synchronizing the Agent deployment strategy aiming at the Agent Daemon service component, and executing command operation corresponding to the Agent deployment strategy.
For the step S1, the Agent configuration management service end component is responsible for policy setting of Agent deployment, monitoring the deployment state of each server, and managing configuration information of the Agent; the git warehouse mainly stores Agent deployment packages and configuration files and provides version management support; the Agent configuration management service end component and the git warehouse are deployed to the target server and are respectively started, so that the target server has the functions of the Agent configuration management service end component and the git warehouse, and the git warehouse does not contain any configuration data and is empty when deployed.
In addition, in the step S2, an Agent Daemon service component is deployed on a target server where the Agent needs to be deployed. The Agent Daemon service component is deployed on each target server, is responsible for synchronously deploying the strategy, executes the operations of deployment, upgrading and the like of various agents of the local machine according to the strategy, and reports the deployment state of the Agent of the server to the Agent configuration management service component; the Agent Daemon service component generally changes little and can be bound into a virtual machine mirror image, so that Daemon service is automatically deployed when a virtual machine is newly created, Daemon starting can be configured to automatically start, and a Daemon program automatically reports the IP address and the server name of the server to the Agent configuration management service component after starting. By adopting the Agent mode, the IP and the name of the server can be automatically discovered, the deployment and configuration difficulty is simplified, and the advantages are more prominent especially when the number of the servers is large; meanwhile, the Agent Daemon service component can monitor the deployment states of various agents of the machine more conveniently, and the deployment process is simple.
Further, in some embodiments, the step of S4, uploading the Agent deployment package to the git repository and configuring the Agent deployment policy, includes the following specific steps:
s41, acquiring an Agent deployment package to be deployed and a corresponding configuration file;
s42, submitting the Agent deployment package and the corresponding configuration file to a git warehouse;
s43, reporting the address of the target server, and grouping the target servers;
s44, setting Agent version information to be deployed for each group of target servers;
and S45, setting an execution operation command of the Agent.
For the steps from the step S41 to the step S42, the Agent deployment package to be deployed and the corresponding configuration file are first submitted to the git repository through the git tool, so that version management is facilitated to be achieved by adopting a git mechanism in an auxiliary mode, including version storage, version updating, version comparison, local switching and the like.
For the steps from S43 to S45, the target servers are grouped according to the automatically reported target server addresses, Agent version information (the version information includes a name, an Agent version number, a deployment package git address, a corresponding configuration file address, a configuration file version, a running account, a deployed target path, and other attributes) that each group of target servers needs to be deployed is set, and an Agent execution operation command (start/stop/none) is set.
Further, in some embodiments, the step S5 includes the following specific steps of synchronizing the Agent deployment policy for the Agent Daemon service component, and executing a command operation corresponding to the Agent deployment policy:
s51, synchronizing Agent deployment strategies by Agent Daemon service components;
s52, acquiring Agent version information to be deployed by the target server;
s53, judging whether the Agent version information is consistent with the Agent version currently deployed by the target server;
if yes, S54, updating a configuration file corresponding to the Agent deployment package, and uploading an Agent deployment state;
if not, S55, judging whether the Agent version information needing to be deployed is contained in the target server through the git version management mechanism;
if yes, S56, switching the Agent version currently deployed by the target server to the Agent version needing to be deployed, and entering the step S54;
if not, S57, downloading the Agent version to be deployed from the git warehouse, and proceeding to the step of S56.
Specifically, the above-mentioned steps S51 to S53 compare whether the Agent version information that needs to be deployed is consistent with the Agent version currently deployed by the target server, so as to confirm whether the target server needs to be deployed currently.
For the steps from the step S55 to the step S57, the version rolling back can be quickly realized by using the version management mechanism of git itself; by separating the deployment package from the configuration file and utilizing a git version mechanism, a simple configuration upgrading management mechanism is provided, and the introduction of a complex configuration management system is avoided.
Further, in some embodiments, the step of S54, updating the configuration file corresponding to the Agent deployment package, and uploading the Agent deployment state includes the following specific steps:
s541, acquiring version information of a configuration file corresponding to the Agent deployment package;
s542, judging whether the version information of the configuration file is consistent with the current version information of the configuration file of the target server;
if yes, S543 uploading Agent deployment state;
if not, S544 judges whether the target server contains the version of the configuration file corresponding to the Agent deployment package to be deployed through the git version management mechanism;
if yes, S545, switching the version of the current configuration file of the target server to the version information of the configuration file corresponding to the Agent deployment package to be deployed, and entering the step S543;
if not, S546, downloading the version information of the configuration file corresponding to the Agent deployment package to be deployed from the git repository, and proceeding to S543.
By separating the deployment package from the configuration file, updating the deployment package and the configuration file respectively, and utilizing a git version mechanism, a simple configuration upgrading management mechanism is provided, and the introduction of a complex configuration management system is avoided. After the configuration update is completed, the operation command corresponding to the target Agent is executed (the appointed Agent deployment package at least needs to provide support of a start/stop/none command), and finally the deployed state information is reported to an Agent configuration management service end component, so that monitoring and management of a publisher are facilitated.
In consideration of the complexity of deployment, the Agent configuration management service end component, the git warehouse and the Agent Daemon service component are all developed and realized by adopting a go language, so that the Agent configuration management service end component, the git warehouse and the Agent Daemon service component can be used by being directly started without depending on other environments during deployment, the environment dependence on third-party software is avoided, and the deployment is simple.
According to the Agent deployment and upgrade method based on git version control, the IP and the name of the target server are automatically found by adopting the Agent configuration management service end component and the Agent Daemon service component, the deployment and configuration difficulty is simplified, the Agent Daemon service component is convenient for monitoring various Agent deployment states of the target server, the self version management mechanism of a git warehouse is utilized to realize quick rollback of the version, the deployment package is separated from the configuration file, and the git version mechanism is utilized to provide a simple configuration and upgrade management mechanism and avoid introducing a complex configuration management system.
As shown in fig. 6, the embodiment also provides an Agent deployment and upgrade system based on git version control, which includes a component processing unit 1, an Agent Daemon processing unit 2, a deployment package processing unit 3, and a deployment unit 4.
And the component processing unit 1 is used for deploying the Agent configuration management service end component and the git warehouse to the target server and respectively starting the Agent configuration management service end component and the git warehouse.
And the Agent Daemon processing unit 2 is used for deploying the Agent Daemon service component to the target server.
And the deployment package processing unit 3 is used for uploading the Agent deployment package to the git warehouse and configuring an Agent deployment strategy.
And the deployment unit 4 is used for synchronizing the Agent deployment strategy aiming at the Agent Daemon service component and executing command operation corresponding to the Agent deployment strategy.
For the component processing unit 1, an Agent configuration management service end component is responsible for policy setting of Agent deployment, monitoring the deployment state of each server, and managing configuration information of the Agent; the git warehouse mainly stores Agent deployment packages and configuration files and provides version management support; the Agent configuration management service end component and the git warehouse are deployed to the target server and are respectively started, so that the target server has the functions of the Agent configuration management service end component and the git warehouse, and the git warehouse does not contain any configuration data and is empty when deployed.
In addition, for the Agent Daemon processing unit 2, an Agent Daemon service component is deployed on a target server where the Agent needs to be deployed. The Agent Daemon service component is deployed on each target server, is responsible for synchronously deploying the strategy, executes the operations of deployment, upgrading and the like of various agents of the local machine according to the strategy, and reports the deployment state of the Agent of the server to the Agent configuration management service component; the Agent Daemon service component generally changes rarely and can be bound into a virtual machine mirror image, so that Daemon service is automatically deployed when a virtual machine is newly created, the Daemon starting machine can be configured to be started automatically, after the Daemon starting machine is started, the Daemon program automatically reports the IP address and the server name of the server to the Agent configuration management service component, an Agent mode is adopted, the IP and the name of the server can be automatically discovered, the deployment configuration difficulty is simplified, and particularly, the Agent configuration management method has more advantages when the number of servers is large; meanwhile, the Agent Daemon service component can monitor the deployment states of various agents of the machine more conveniently, and the deployment process is simple.
Further, in some embodiments, the deployment package processing unit 3 includes a material obtaining module 31, a submitting module 32, an address reporting module 33, a version information setting module 34, and a command setting module 35.
The data obtaining module 31 is configured to obtain an Agent deployment package to be deployed and a corresponding configuration file.
And the submitting module 32 is used for submitting the Agent deployment package and the corresponding configuration file to the git warehouse.
And an address reporting module 33, configured to report an address of the target server and group the target servers.
And the version information setting module 34 is used for setting the Agent version information to be deployed for each group of target servers.
And the command setting module 35 is used for setting an execution operation command of the Agent.
Firstly, an Agent deployment package to be deployed and a corresponding configuration file are submitted to a git warehouse through a git tool, so that version management including version storage, version updating, version comparison, local switching and the like can be achieved by assistance of a git mechanism.
According to the automatically reported target server addresses, grouping the target servers, setting Agent version information (the version information comprises a name, an Agent version number, a deployment package git address, a corresponding configuration file address, a configuration file version, a running account number, a deployed target path and other attributes) to be deployed by each group of target servers, and setting an execution operation command (start/stop/none) of the Agent.
Further, in some embodiments, the deployment unit 4 includes a synchronization module 41, an Agent version information obtaining module 42, an Agent version determining module 43, an updating module 44, an Agent version existence determining module 45, an Agent version switching module 46, and an Agent version downloading module 47.
And the synchronization module 41 is used for synchronizing the Agent deployment strategy by the Agent Daemon service component.
And the Agent version information acquisition module 42 is used for acquiring the Agent version information required to be deployed by the target server.
And the Agent version judging module 43 is configured to judge whether the Agent version information is consistent with the Agent version currently deployed by the target server.
And the updating module 44 is configured to update the configuration file corresponding to the Agent deployment package and upload the Agent deployment state if the configuration file is positive.
And the Agent version existence judging module 45 is used for judging whether the target server contains the Agent version information to be deployed or not through the git version management mechanism if the target server does not contain the Agent version information to be deployed.
And the Agent version switching module 46 is configured to switch the Agent version currently deployed by the target server to the Agent version needing to be deployed if the Agent version is included.
And the Agent version downloading module 47 is used for downloading the Agent version to be deployed from the git warehouse if the Agent version is not contained.
The rollback of the version can be quickly realized by utilizing the version management mechanism of the git; by separating the deployment package from the configuration file and utilizing a git version mechanism, a simple configuration upgrading management mechanism is provided, and the introduction of a complex configuration management system is avoided.
Further, in some embodiments, the update module 44 includes a file version acquisition sub-module 441, a file version determination sub-module 442, a status upload sub-module 443, a file version existence determination sub-module 444, a file version switching sub-module 445, and a file version download sub-module 446.
The file version obtaining sub-module 441 is configured to obtain version information of a configuration file corresponding to the Agent deployment package.
The file version determining sub-module 442 is configured to determine whether the version information of the configuration file is consistent with the current version information of the configuration file of the target server.
And the state uploading submodule 443 is used for uploading the Agent deployment state if the state is positive.
And the file version existence judgment sub-module 444 is configured to judge, if the configuration file does not exist, whether the version of the configuration file corresponding to the Agent deployment package to be deployed is included in the target server through the git version management mechanism.
And the file version switching submodule 445 is configured to switch the version of the current configuration file of the target server to the version information of the configuration file corresponding to the Agent deployment package to be deployed if the configuration file is included.
And the file version downloading submodule 446 is configured to, if the configuration file is not included, download the version information of the configuration file corresponding to the Agent deployment package to be deployed from the git repository.
By separating the deployment package from the configuration file, updating the deployment package and the configuration file respectively, and utilizing a git version mechanism, a simple configuration upgrading management mechanism is provided, and the introduction of a complex configuration management system is avoided. After the configuration update is completed, the operation command corresponding to the target Agent is executed (the appointed Agent deployment package at least needs to provide support of a start/stop/none command), and finally the deployed state information is reported to an Agent configuration management service end component, so that monitoring and management of a publisher are facilitated.
In consideration of the complexity of deployment, the Agent configuration management service end component, the git warehouse and the Agent Daemon service component are all developed and realized by adopting a go language, so that the Agent configuration management service end component, the git warehouse and the Agent Daemon service component can be used by being directly started without depending on other environments during deployment, the environment dependence on third-party software is avoided, and the deployment is simple.
According to the Agent deployment and upgrade system based on git version control, the IP and the name of the target server are automatically found by adopting the Agent configuration management service end component and the Agent Daemon service component, the deployment and configuration difficulty is simplified, the Agent Daemon service component is convenient for monitoring various Agent deployment states of the target server, the self version management mechanism of a git warehouse is utilized to realize quick rollback of the version, the deployment package is separated from the configuration file, and the git version mechanism is utilized to provide a simple configuration and upgrade management mechanism and avoid introducing a complex configuration management system.
The technical contents of the present invention are further illustrated by the examples only for the convenience of the reader, but the embodiments of the present invention are not limited thereto, and any technical extension or re-creation based on the present invention is protected by the present invention. The protection scope of the invention is subject to the claims.
Claims (6)
1. The Agent deployment and upgrade method based on git version control is characterized by comprising the following steps:
deploying an Agent configuration management service end component and a git warehouse to a target server and starting the Agent configuration management service end component and the git warehouse respectively;
deploying an Agent Daemon service component for a target server;
uploading the Agent deployment package to a git warehouse and configuring an Agent deployment strategy;
synchronizing an Agent deployment strategy aiming at an Agent Daemon service component, and executing command operation corresponding to the Agent deployment strategy;
the method comprises the following steps of synchronizing an Agent deployment strategy aiming at an Agent Daemon service component, and executing command operation corresponding to the Agent deployment strategy, wherein the steps comprise the following specific steps:
the Agent Daemon service component synchronizes an Agent deployment strategy; acquiring Agent version information to be deployed by a target server; judging whether the Agent version information is consistent with the Agent version currently deployed by the target server; if the Agent version information is consistent with the Agent version currently deployed by the target server, updating a configuration file corresponding to the Agent deployment package, and uploading an Agent deployment state; if the Agent version information is not consistent with the Agent version currently deployed by the target server, judging whether the Agent version information needing to be deployed is contained in the target server or not through a git version management mechanism; if the target server already contains the Agent version information to be deployed, switching the Agent version currently deployed by the target server to the Agent version to be deployed, updating an Agent deployment package and a corresponding configuration file, and uploading the Agent deployment state; and if the target server does not contain the Agent version information to be deployed, downloading the Agent version to be deployed from the git warehouse, and switching the currently deployed Agent version of the target server to the Agent version to be deployed.
2. The git version control-based Agent deployment and upgrade method according to claim 1, wherein the step of uploading an Agent deployment package to a git warehouse and configuring an Agent deployment policy comprises the following specific steps:
acquiring an Agent deployment package to be deployed and a corresponding configuration file;
submitting the Agent deployment package and the corresponding configuration file to a git warehouse;
reporting the address of a target server, and grouping the target servers;
setting Agent version information to be deployed for each group of target servers;
and setting an execution operation command of the Agent.
3. The git version control-based Agent deployment and upgrade method according to claim 2, wherein the step of updating the configuration file corresponding to the Agent deployment package and uploading the Agent deployment state comprises the following specific steps:
acquiring version information of a configuration file corresponding to an Agent deployment package;
judging whether the version information of the configuration file is consistent with the current version information of the configuration file of the target server or not;
if the version information of the configuration file is consistent with the current version information of the configuration file of the target server, uploading an Agent deployment state;
if the version information of the configuration file is inconsistent with the current configuration file version information of the target server, judging whether the target server contains the version of the configuration file corresponding to the Agent deployment package to be deployed or not through a git version management mechanism;
if the target server already contains the version of the configuration file corresponding to the Agent deployment package to be deployed, switching the version of the current configuration file of the target server to the version information of the configuration file corresponding to the Agent deployment package to be deployed, and uploading the Agent deployment state;
and if the target server does not contain the version of the configuration file corresponding to the Agent deployment package to be deployed, downloading the version information of the configuration file corresponding to the Agent deployment package to be deployed from the git warehouse, and uploading the Agent deployment state.
4. The Agent deployment and upgrade system based on git version control is characterized by comprising an assembly processing unit, an Agent Daemon processing unit, a deployment package processing unit and a deployment unit;
the component processing unit is used for deploying the Agent configuration management service end component and the git warehouse to a target server and respectively starting the Agent configuration management service end component and the git warehouse;
the Agent Daemon processing unit is used for deploying an Agent Daemon service component to a target server;
the deployment package processing unit is used for uploading the Agent deployment package to a git warehouse and configuring an Agent deployment strategy;
the deployment unit is used for synchronizing the Agent deployment strategy aiming at the Agent Daemon service component and executing command operation corresponding to the Agent deployment strategy;
the deployment unit comprises a synchronization module, an Agent version information acquisition module, an Agent version judgment module, an update module, an Agent version existence judgment module, an Agent version switching module and an Agent version downloading module;
the synchronization module is used for synchronizing Agent deployment strategies of the Agent Daemon service components;
the Agent version information acquisition module is used for acquiring Agent version information required to be deployed by a target server;
the Agent version judging module is used for judging whether the Agent version information is consistent with the Agent version currently deployed by the target server;
the updating module is used for updating the configuration file corresponding to the Agent deployment package and uploading the Agent deployment state if the Agent version information is consistent with the Agent version currently deployed by the target server;
the Agent version existence judging module is used for judging whether the Agent version information needing to be deployed is contained in the target server through a git version management mechanism if the Agent version information is inconsistent with the Agent version currently deployed by the target server;
the Agent version switching module is used for switching the Agent version currently deployed by the target server to the Agent version to be deployed if the Agent version information to be deployed is contained in the target server;
and the Agent version downloading module is used for downloading the Agent version to be deployed from the git warehouse if the target server does not contain the Agent version information to be deployed.
5. The git version control-based Agent deployment and upgrade system according to claim 4, wherein the deployment package processing unit comprises a data acquisition module, a submission module, an address reporting module, a version information setting module and a command setting module;
the data acquisition module is used for acquiring the Agent deployment package to be deployed and the corresponding configuration file;
the submitting module is used for submitting the Agent deployment package and the corresponding configuration file to a git warehouse;
the address reporting module is used for reporting the address of the target server and grouping the target servers;
the version information setting module is used for setting the Agent version information to be deployed of each group of target servers;
and the command setting module is used for setting an execution operation command of the Agent.
6. The git version control-based Agent deployment upgrade system according to claim 5, wherein the upgrade module comprises a file version acquisition sub-module, a file version judgment sub-module, a status upload sub-module, a file version existence judgment sub-module, a file version switching sub-module and a file version download sub-module;
the file version acquisition submodule is used for acquiring version information of a configuration file corresponding to the Agent deployment package;
the file version judging submodule is used for judging whether the version information of the configuration file is consistent with the current version information of the configuration file of the target server or not;
the state uploading sub-module is used for uploading the Agent deployment state if the version information of the configuration file is consistent with the current version information of the configuration file of the target server;
the file version existence judgment submodule is used for judging whether the version information of the configuration file is inconsistent with the current configuration file version information of the target server or not through a git version management mechanism, wherein the version information of the configuration file is not consistent with the current configuration file version information of the target server;
the file version switching submodule is used for switching the version of the current configuration file of the target server to the version information of the configuration file corresponding to the Agent deployment package to be deployed if the version of the configuration file corresponding to the Agent deployment package to be deployed is contained in the target server;
and the file version downloading submodule is used for downloading the version information of the configuration file corresponding to the Agent deployment package to be deployed from the git warehouse if the version of the configuration file corresponding to the Agent deployment package to be deployed is not contained in the target server.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711063697.7A CN107659458B (en) | 2017-11-02 | 2017-11-02 | Agent deployment and upgrade method and system based on git version control |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711063697.7A CN107659458B (en) | 2017-11-02 | 2017-11-02 | Agent deployment and upgrade method and system based on git version control |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107659458A CN107659458A (en) | 2018-02-02 |
| CN107659458B true CN107659458B (en) | 2021-04-13 |
Family
ID=61095769
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711063697.7A Active CN107659458B (en) | 2017-11-02 | 2017-11-02 | Agent deployment and upgrade method and system based on git version control |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107659458B (en) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108540341B (en) * | 2018-03-19 | 2021-01-29 | 云宏信息科技股份有限公司 | Resource monitoring method and device |
| CN108829433A (en) * | 2018-05-24 | 2018-11-16 | 努比亚技术有限公司 | A kind of web system version dispositions method, equipment and storage medium |
| DK3617875T3 (en) * | 2018-08-27 | 2021-07-19 | Ovh | PROCEDURE FOR IMPROVED AUTOMATED SOFTWARE UPDATE USING A NETWORK DEVICE |
| CN112416385A (en) * | 2020-08-13 | 2021-02-26 | 上海哔哩哔哩科技有限公司 | Acquisition component management method and system |
| CN112272200B (en) * | 2020-09-11 | 2022-05-13 | 苏州浪潮智能科技有限公司 | Gitlab container cloud workload deployment version management method and device |
| CN113031977A (en) * | 2021-04-07 | 2021-06-25 | 深圳云之家网络有限公司 | Software batch installation method and related device |
| CN114327499B (en) * | 2021-12-28 | 2024-05-14 | 浪潮卓数大数据产业发展有限公司 | Method, device, equipment and medium for rapidly deploying and rolling off remote service |
| CN116820526B (en) * | 2023-08-25 | 2023-11-24 | 建信金融科技有限责任公司 | Operating system upgrading method, device, equipment and storage medium |
| CN117319196B (en) * | 2023-10-26 | 2024-05-14 | 无锡芯光互连技术研究院有限公司 | User server cluster environment deployment management system and method |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101945135A (en) * | 2010-09-20 | 2011-01-12 | 中兴通讯股份有限公司 | Method and system for upgrading widget system |
| US7937482B1 (en) * | 2008-03-27 | 2011-05-03 | Amazon Technologies, Inc. | Scalable consensus protocol |
| CN102339366A (en) * | 2010-07-28 | 2012-02-01 | 上海交泰信息科技有限公司 | OMA (Open Mobile Alliance) DRM (Digital Rights Management) Agent based on radio frequency mobile phone and RO (right object) design method thereof |
| CN102868731A (en) * | 2012-08-27 | 2013-01-09 | 济南大学 | Method and device for software online updating and downloading acceleration |
| CN103049268A (en) * | 2012-12-25 | 2013-04-17 | 中国科学院深圳先进技术研究院 | Naplet based application development and management system |
| CN106997297A (en) * | 2017-03-31 | 2017-08-01 | 广东亿迅科技有限公司 | A kind of software development management platform and method based on DevOps |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9052961B2 (en) * | 2012-03-02 | 2015-06-09 | Vmware, Inc. | System to generate a deployment plan for a cloud infrastructure according to logical, multi-tier application blueprint |
-
2017
- 2017-11-02 CN CN201711063697.7A patent/CN107659458B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7937482B1 (en) * | 2008-03-27 | 2011-05-03 | Amazon Technologies, Inc. | Scalable consensus protocol |
| CN102339366A (en) * | 2010-07-28 | 2012-02-01 | 上海交泰信息科技有限公司 | OMA (Open Mobile Alliance) DRM (Digital Rights Management) Agent based on radio frequency mobile phone and RO (right object) design method thereof |
| CN101945135A (en) * | 2010-09-20 | 2011-01-12 | 中兴通讯股份有限公司 | Method and system for upgrading widget system |
| CN102868731A (en) * | 2012-08-27 | 2013-01-09 | 济南大学 | Method and device for software online updating and downloading acceleration |
| CN103049268A (en) * | 2012-12-25 | 2013-04-17 | 中国科学院深圳先进技术研究院 | Naplet based application development and management system |
| CN106997297A (en) * | 2017-03-31 | 2017-08-01 | 广东亿迅科技有限公司 | A kind of software development management platform and method based on DevOps |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107659458A (en) | 2018-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107659458B (en) | Agent deployment and upgrade method and system based on git version control | |
| US9250672B2 (en) | Cloning target machines in a software provisioning environment | |
| US9405630B2 (en) | Methods and apparatus to perform site recovery of a virtual data center | |
| US11016761B2 (en) | Container based application reification | |
| US8099720B2 (en) | Translating declarative models | |
| US8024721B2 (en) | System and method for implementing a safe framework | |
| US20160350102A1 (en) | Multivariate metadata based cloud deployment monitoring for lifecycle operations | |
| US10958720B2 (en) | Methods, apparatuses and systems for cloud based disaster recovery | |
| CN112214227A (en) | Edge server mirror image customization and deployment system and method | |
| EP4162649B1 (en) | Stable references for network function life cycle management automation | |
| US20120324279A1 (en) | Method and Apparatus of Backing up Subversion Repository | |
| US10146520B1 (en) | Updating a running application on a computing device | |
| US20080059949A1 (en) | System and method for implementing a safe framework | |
| CN114443239A (en) | Method and device for filling container | |
| CN112130889A (en) | Resource management method and device, storage medium and electronic device | |
| CN106484442B (en) | Server system and method for updating startup mapping file | |
| US11178221B2 (en) | Methods, apparatuses and systems for cloud-based disaster recovery | |
| US20200192763A1 (en) | Methods, apparatuses and systems for cloud-based disaster recovery | |
| CN106708541A (en) | Version upgrading processing method and apparatus | |
| CN114003256A (en) | Method, device and equipment for updating FRU information of server and storage medium | |
| US20150350340A1 (en) | Management of headless hardware in data center | |
| US11477090B1 (en) | Detecting deployment problems of containerized applications in a multiple-cluster environment | |
| CN109254899B (en) | Server monitoring method and device | |
| CN117573280A (en) | Virtual machine state synchronization method, device, equipment and storage medium | |
| CN116719820A (en) | Database operation and maintenance control method based on general model |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |