Plug-in deployment method, apparatus, device, medium, and program product

Abstract

Embodiments of the present application provide a plug-in deployment method, device, equipment, medium and program product. The method comprises: obtaining expected configuration information of a target plug-in, and performing a multiplexing compatibility check process based on the expected configuration information, to determine a specific deployment scenario (such as, a reusable started / unstarted plug-in instance, a deployable new instance, or a conflict) corresponding to a current deployment environment by comprehensively analyzing a port occupation state, a user permission state of an occupied process, and an occupation state of a preset deployment path, and then performing a corresponding deployment decision according to the determined scenario. The method is used to improve the reliability of the plug-in deployment process and the overall maintainability of the system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a plug-in deployment method, apparatus, device, medium, and program product. Background Technology

[0002] As enterprise IT architectures become increasingly complex, database management systems typically need to provide data services to multiple different business projects or user groups within a single physical or logical cluster. To meet these diverse needs, plugins that provide extended functionality beyond the main database program are widely adopted. Currently, multiple plugin versions deployed by different user groups at different times and in different ways may coexist within the same system, creating an environment with mixed plugin deployment states.

[0003] When making new deployments in an environment where multiple versions of plugins coexist, existing technologies typically rely on process name matching or reading fixed configuration files to locate and identify plugin instances in order to determine whether the plugin is already running. If it is running, there is no need to directly execute the new deployment.

[0004] However, when faced with plugins deployed by other users, residual files with inconsistent configurations, or permission conflicts, existing methods struggle to accurately distinguish between plugins that can be safely reused and conflicts that need to be avoided, reducing the reliability of plugin deployment and the maintainability of the deployment system. Summary of the Invention

[0005] This application provides plug-in deployment methods, apparatus, devices, media, and program products to improve the reliability of the plug-in deployment process and the maintainability of the deployment system.

[0006] In a first aspect, embodiments of this application provide a plugin deployment method, including:

[0007] Obtain the target plugin's expected configuration information, which includes at least the target monitoring port and the default deployment path;

[0008] Based on the expected configuration information, a reuse compatibility check process is executed to determine the deployment scenario corresponding to the current deployment environment. The reuse compatibility check process includes analyzing the port occupancy status, the user permission status of the occupant process, and the occupancy status of the preset deployment path.

[0009] Based on the deployment scenario, execute the corresponding deployment decision; wherein the deployment scenario includes at least: a scenario in which an already started plugin instance can be reused, a scenario in which an unstarted plugin instance can be reused, a scenario in which a new plugin instance can be deployed, and a deployment conflict scenario; and the deployment decision includes at least: reusing an already started plugin instance, reusing a deployed but unstarted plugin instance, deploying and starting a new plugin instance, or terminating the deployment process and outputting error information.

[0010] Optionally, based on the expected configuration information, a reuse compatibility check process is performed, specifically including:

[0011] Determine if the target monitoring port is occupied;

[0012] If it is determined that the target monitoring port has been occupied, the first-level reuse judgment process is executed for the process that has occupied the target monitoring port to determine whether there is a reusable started plugin instance;

[0013] If the target monitoring port is not occupied, a check on the occupancy status of the preset deployment path will be triggered.

[0014] Optionally, the execution of the first-level reuse judgment process specifically includes:

[0015] Determine whether the service identifier information of the process occupying the target monitoring port can be read;

[0016] If the service identifier information can be successfully read, the service identifier information is matched with the preset plugin service characteristics, and the process is determined to constitute a reusable started plugin instance based on the matching result and the user permission information of the process.

[0017] If the service identifier information cannot be read, a process deep probing sub-process under restricted permissions will be executed to determine whether the process occupying the target monitoring port is a plugin instance started by a user with special permissions.

[0018] Optionally, based on the matching results and the process's user permission information, it can be determined whether the process constitutes a reusable instance of an started plugin, specifically including:

[0019] During the matching process, the user permission information of the process is further checked. If the user permission information indicates that the process was started by the current user or a system-level privileged user, it is determined that there is a reusable instance of the started plugin. Otherwise, it is determined that there is no reusable instance of the started plugin.

[0020] If there is a mismatch, it is determined that there is no reusable instance of the started plugin.

[0021] Optionally, the process deep probing sub-process under restricted privileges includes:

[0022] Get a list of all processes started by the preset system-privileged user in the current system;

[0023] Filter out candidate processes from the list of all processes whose service identification information matches the characteristics of the preset plugin services;

[0024] For each candidate process, based on the execution path of the candidate process, locate and parse the associated configuration file to obtain the actual monitoring port configured for the candidate process;

[0025] Compare the actual monitoring ports of each candidate process with the target monitoring ports;

[0026] If a candidate process with the same port exists, it is determined that there is a reusable instance of a started plugin initiated by a system-level privileged user.

[0027] If no candidate process with the same port is found, then it is determined that there is no reusable instance of an already started plugin.

[0028] Optionally, a check on the occupancy status of the preset deployment path is triggered, and after confirming through the first-level reuse judgment process that there are no reusable started plugin instances, a check on the occupancy status of the preset deployment path is performed, including:

[0029] Check if the default deployment path is already in use;

[0030] If the preset deployment path is already in use, the second-level reuse judgment process is executed: determine the configuration information of the plugin instance located under the preset deployment path, and obtain the monitoring port configured in the configuration information of the plugin instance; compare the monitoring port with the target monitoring port; if the ports are consistent, it is determined that there is a reusable but not started plugin instance; if the ports are inconsistent, it is determined that there is a deployment conflict.

[0031] If the preset deployment path is not occupied, then the conditions for deploying a new plugin instance are met.

[0032] Optionally, based on the determined deployment scenario, corresponding deployment decisions are executed, specifically including:

[0033] When the deployment scenario is one where already started plugin instances can be reused, the deployment decision to reuse already started plugin instances is executed, and service availability verification is performed on the plugin instances.

[0034] When the deployment scenario is a scenario where reusable but not started plugin instances are used, the deployment decision is made to start the deployed but not started plugin instances, and service availability verification is performed on the plugin instances.

[0035] When the deployment scenario allows for the deployment of new plugin instances, the deployment decision is made to execute the deployment and start the new plugin instance.

[0036] When the deployment scenario is a deployment conflict scenario, execute the deployment decision to terminate the deployment process and output error information.

[0037] Secondly, embodiments of this application provide a plug-in deployment apparatus, comprising:

[0038] The acquisition module is used to acquire the expected configuration information of the target plugin. The expected configuration information includes at least the target monitoring port and the preset deployment path.

[0039] The processing module is used to perform a reuse compatibility check process based on the expected configuration information to determine the deployment scenario corresponding to the current deployment environment. The reuse compatibility check process includes analyzing the port occupancy status, the user permission status of the occupant process, and the occupancy status of the preset deployment path.

[0040] The processing module is also used to execute corresponding deployment decisions based on the deployment scenario. The deployment scenario includes at least the following: scenarios where already started plugin instances can be reused, scenarios where unstarted plugin instances can be reused, scenarios where new plugin instances can be deployed, and deployment conflict scenarios. The deployment decisions include at least the following: reusing already started plugin instances, reusing already deployed but unstarted plugin instances, deploying and starting new plugin instances, or terminating the deployment process and outputting error information.

[0041] Optionally, the processing module is also used to determine whether the target monitoring port is occupied;

[0042] If it is determined that the target monitoring port has been occupied, the first-level reuse judgment process is executed for the process that has occupied the target monitoring port to determine whether there is a reusable started plugin instance;

[0043] If the target monitoring port is not occupied, a check on the occupancy status of the preset deployment path will be triggered.

[0044] Optionally, the processing module is also used to determine whether the service identifier information of the process occupying the target monitoring port can be read;

[0045] If the service identifier information can be successfully read, the service identifier information is matched with the preset plugin service characteristics, and the process is determined to constitute a reusable started plugin instance based on the matching result and the user permission information of the process.

[0046] If the service identifier information cannot be read, a process deep probing sub-process under restricted permissions will be executed to determine whether the process occupying the target monitoring port is a plugin instance started by a user with special permissions.

[0047] Optionally, the processing module is also used to further check the user permission information of the process during matching; if the user permission information indicates that the process was started by the currently executing user or a system-level privileged user, then it is determined that there is a reusable instance of the started plugin; otherwise, it is determined that there is no reusable instance of the started plugin.

[0048] If there is a mismatch, it is determined that there is no reusable instance of the started plugin.

[0049] Optionally, the processing module is also used to obtain a list of all processes started by a preset system-level privileged user in the current system;

[0050] Filter out candidate processes from the list of all processes whose service identification information matches the characteristics of the preset plugin services;

[0051] For each candidate process, based on the execution path of the candidate process, locate and parse the associated configuration file to obtain the actual monitoring port configured for the candidate process;

[0052] Compare the actual monitoring ports of each candidate process with the target monitoring ports;

[0053] If a candidate process with the same port exists, it is determined that there is a reusable instance of a started plugin initiated by a system-level privileged user.

[0054] If no candidate process with the same port is found, then it is determined that there is no reusable instance of an already started plugin.

[0055] Optionally, the processing module is also used to check whether the preset deployment path has been occupied;

[0056] If the preset deployment path is already in use, the second-level reuse judgment process is executed: determine the configuration information of the plugin instance located under the preset deployment path, and obtain the monitoring port configured in the configuration information of the plugin instance; compare the monitoring port with the target monitoring port; if the ports are consistent, it is determined that there is a reusable but not started plugin instance; if the ports are inconsistent, it is determined that there is a deployment conflict.

[0057] If the preset deployment path is not occupied, then the conditions for deploying a new plugin instance are met.

[0058] Optionally, the processing module is also used to make deployment decisions to reuse the already started plugin instance when the deployment scenario is a scenario where the already started plugin instance can be reused, and to perform service availability verification on the plugin instance;

[0059] When the deployment scenario is a scenario where reusable but not started plugin instances are used, the deployment decision is made to start the deployed but not started plugin instances, and service availability verification is performed on the plugin instances.

[0060] When the deployment scenario allows for the deployment of new plugin instances, the deployment decision is made to execute the deployment and start the new plugin instance.

[0061] When the deployment scenario is a deployment conflict scenario, execute the deployment decision to terminate the deployment process and output error information.

[0062] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0063] The memory stores the instructions that the computer executes;

[0064] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0065] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0066] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0067] The plugin deployment method, apparatus, device, medium, and program product provided in this application obtain the expected configuration information of the target plugin (including the target monitoring port and preset deployment path), and execute a reuse compatibility check process based on the expected configuration information. By comprehensively analyzing the port occupancy status, the user permission status of the occupant process, and the occupancy status of the preset deployment path, the specific deployment scenario corresponding to the current deployment environment is determined (e.g., whether an already started / not started plugin instance can be reused, a new instance can be deployed, or there is a conflict). Then, the corresponding deployment decision is executed according to the determined scenario. In this process, the problem of reliably and conflict-free reuse of existing plugins or secure deployment of new plugins is difficult to solve in complex environments with multiple users, multiple servers, and chaotic historical plugin deployments. This achieves the effect of improving the reliability of the plugin deployment process and the overall maintainability of the system. Attached Figure Description

[0068] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0069] Figure 1 A flowchart illustrating the plugin deployment method provided in this application. Figure 1 ;

[0070] Figure 2 A flowchart illustrating the plugin deployment method provided in this application. Figure 2 ;

[0071] Figure 3 A schematic diagram of the plug-in deployment device provided in this application;

[0072] Figure 4 A schematic diagram of the structure of the electronic device provided in this application.

[0073] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0074] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0075] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0076] In the operation and maintenance scenarios of enterprise-level database management systems, plugins, as extended functional modules, are often used to meet customers' customized needs. For example, a plugin might be designed for service management in a multi-user, multi-server environment, involving complex operations such as cross-server resource coordination, permission allocation, and service status synchronization. Due to the special nature of plugin functionality, its deployment path, starting user, and running status can be highly uncertain due to differences in server configuration. For example, the same plugin might be deployed on different servers with different paths, or even started by users with different permissions, which exacerbates the uncontrollability of the plugin's state. This dispersion makes it difficult to track the dependencies between plugins and product services, especially during system upgrades or version iterations, where compatibility management of older plugin versions becomes a pain point. Furthermore, the running status of plugins directly affects the stability of the entire system. If a plugin exits or is uninstalled abnormally, it may cause product services that depend on its functionality to stop. For example, when deploying a new service, it is impossible to determine whether an existing plugin needs to be reused; during runtime, it is difficult to confirm the correspondence between plugins and services; and when uninstalling a service, critical plugins may be accidentally deleted, leading to system crashes.

[0077] Existing technologies for managing plugins typically determine their running status by checking the system process list and matching it with the plugin process name. For example, if the plugin process name is `scmd_plugin`, the process table is traversed to find a process with the same name. However, since different plugins or services may use the same process name, existing methods are prone to misjudgment. Furthermore, because the process name does not contain plugin deployment path information, it is difficult to determine whether a plugin is associated with a target service. Ordinary users cannot easily read the detailed information (e.g., command-line parameters, configuration file paths) and critical information of processes launched with special privileges, limiting the completeness of information acquisition. In addition, existing technologies also indirectly infer plugin status by parsing port numbers or path information in plugin configuration files. However, older versions of plugins may have their configuration files scattered in arbitrary paths without version information, making them difficult to locate.

[0078] Based on the above scenarios, it can be seen that existing technologies have the technical problem of difficulty in dynamically identifying the relationship between plugins and services, resulting in high operation and maintenance costs, low efficiency, and low system reliability and stability.

[0079] The plugin deployment method provided in this application obtains the expected configuration information of the target plugin, which includes at least the target monitoring port and the preset deployment path. Based on the expected configuration information, it analyzes the port occupancy status, the user permission status of the occupant process, and the occupancy status of the preset deployment path to determine the deployment scenario corresponding to the current deployment environment. According to the deployment scenario, it executes the corresponding deployment decision. The deployment scenarios include at least: scenarios where already started plugin instances can be reused, scenarios where unstarted plugin instances can be reused, scenarios where new plugin instances can be deployed, and deployment conflict scenarios. The deployment decisions include at least: reusing already started plugin instances, reusing already deployed but unstarted plugin instances, deploying and starting a new plugin instance, or terminating the deployment process and outputting error information. This process effectively solves the problem of reliably and conflict-free reuse of existing plugins or secure deployment of new plugins in complex environments with multiple users, multiple servers, and chaotic historical plugin deployments, thereby improving the reliability of the plugin deployment process and the overall maintainability of the system.

[0080] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0081] Figure 1 A flowchart illustrating the plugin deployment method provided in this application. Figure 1 ,like Figure 1 As shown, the method includes:

[0082] S101. Obtain the expected configuration information of the target plugin. The expected configuration information includes at least the target monitoring port and the preset deployment path.

[0083] S102. Based on the expected configuration information, perform a reuse compatibility check process to determine the deployment scenario corresponding to the current deployment environment.

[0084] More specifically, based on the expected configuration information, a reuse compatibility check process is executed to determine the deployment scenario corresponding to the current deployment environment; the reuse compatibility check process includes analyzing the port occupancy status, the user permission status of the occupant process, and the occupancy status of the preset deployment path.

[0085] Optionally, based on the expected configuration information, a reuse compatibility check process is executed, which specifically includes: determining whether the target monitoring port is occupied; if it is determined that the target monitoring port is occupied, then for the process that occupies the target monitoring port, the first-level reuse judgment process is executed to determine whether there is a reusable started plugin instance; if the target monitoring port is not occupied, then the occupancy status check of the preset deployment path is triggered.

[0086] In one possible implementation, if it is desired to deploy a plugin monitoring port 8080, the system first checks whether port 8080 is already in use. If port 8080 is found to be in use by any process, a first-level reuse check is performed for that process. If port 8080 is not in use, the first-level reuse check is skipped, and the system directly triggers a check on the occupancy status of a preset deployment path (e.g., / opt / plugin / v2.0).

[0087] This embodiment implements a port-first inspection strategy by using port occupancy status as the primary basis for the inspection process. This strategy enables rapid identification and handling of scenarios where monitoring services already exist, while avoiding unnecessary process analysis when ports are idle, thus improving the efficiency of the inspection process.

[0088] Optionally, the first-level reuse judgment process includes: determining whether the service identifier information of the process occupying the target monitoring port can be read; if the service identifier information can be successfully read, then a matching judgment is made based on the service identifier information and the preset plugin service characteristics, and based on the matching result and the user permission information of the process, it is determined whether the process constitutes a reusable started plugin instance; if the service identifier information cannot be read, then a process deep probing sub-process under restricted permissions is executed to determine whether the process occupying the target monitoring port is a plugin instance started by a user with special permissions.

[0089] In one possible implementation, for a process occupying port 8080, the system first attempts to read the process's service identifier information (e.g., the process name "plugin-server"). If the service identifier information "plugin-server" can be successfully read with the current user's privileges, subsequent matching and permission determination steps are performed based on this service identifier information. If the process's service identifier information cannot be read due to insufficient privileges (e.g., the process needs to be started by the root user), a process deep probing sub-process under restricted privileges is executed to probe the process's identity in another way.

[0090] This embodiment attempts to read the service identifier information of the process currently occupying the target monitoring port to reflect the user's permission status, thereby dynamically selecting the subsequent judgment path. This solves the technical problem that it is difficult to directly detect high-privilege processes under ordinary user permissions, and improves the effectiveness of identifying services occupying ports under different permission scenarios.

[0091] Optionally, based on the matching results and the process's user permission information, it is determined whether the process constitutes a reusable started plugin instance. Specifically, this includes: during matching, further checking the process's user permission information; if the user permission information indicates that the process was started by the currently executing user or a system-level privileged user, then it is determined that a reusable started plugin instance exists; otherwise, it is determined that no reusable started plugin instance exists; if there is no match, it is determined that no reusable started plugin instance exists.

[0092] In one possible implementation, if the service identifier information of the process occupying port 8080 is read as "plugin-server", and this service identifier information matches the preset plugin service characteristics, then the user permission information of the process is further checked. If it is found that the process was started by the currently deployed user (e.g., user_a) or by a system-level privileged user (e.g., root user), then it is determined that the process is a reusable started plugin instance. If it is found that the process was started by another ordinary user (e.g., user_b), then it is determined that the process is not reusable.

[0093] This embodiment combines service identifier matching with user permission checks for a comprehensive judgment, accurately determining whether reusability is defined. It requires not only that the plugin be the target plugin, but also that the corresponding permissions are controllable or accessible within the current deployment context. This effectively prevents misuse or deployment failures caused by user permission isolation.

[0094] Optionally, the process deep probing sub-process under restricted permissions specifically includes: obtaining a list of all processes started by a preset system-level privileged user in the current system; filtering out candidate processes from the list of all processes whose service identification information matches the preset plugin service characteristics; for each candidate process, locating and parsing the associated configuration file based on the execution path of the candidate process to obtain the actual monitoring port configured by the candidate process; comparing the actual monitoring port of each candidate process with the target monitoring port; if there are candidate processes with the same port, it is determined that there is a reusable started plugin instance started by a system-level privileged user; if there are no candidate processes with the same port, it is determined that there is no reusable started plugin instance.

[0095] In one possible implementation, if the service identifier information of the process occupying port 8080 cannot be read, a list of all processes started by system-level privileged users (e.g., the root user) is obtained. Processes with the service identifier information "plugin-server" are then selected as candidate processes from this list. Next, for each candidate process, its corresponding configuration file (e.g., / usr / local / plugin / bin / server) is located and parsed based on its execution path (e.g., / usr / local / plugin / conf / config.ini). If the actual monitoring port configured for the candidate process is found to be 8080, this actual monitoring port is compared with the target monitoring port 8080. If they match, it is determined that a reusable, already started plugin instance started by the root user exists.

[0096] For example, the execution path of the candidate process is / usr / local / plugin / bin / server, and the configuration file is / usr / local / plugin / conf / config.ini.

[0097] This embodiment combines privileged process enumeration, service feature filtering, and configuration file reverse port lookup. This method can break through the permission barrier of direct information reading, accurately determine whether the plugin instance started by a high-privilege user occupies the target port, and solve the identification blind spot problem caused by inconsistent permissions in a multi-user environment.

[0098] Optionally, a check on the occupancy status of a preset deployment path is triggered. After confirming through the first-level reuse judgment process that there are no reusable started plugin instances, a check on the occupancy status of the preset deployment path is performed, including: checking whether the preset deployment path is occupied; if the preset deployment path is occupied, then the second-level reuse judgment process is executed: determining the configuration information of the plugin instance located under the preset deployment path, and obtaining the monitoring port configured in the configuration information of the plugin instance; comparing the monitoring port with the target monitoring port; wherein, if the ports are consistent, it is determined that there is a reusable but not started plugin instance; if the ports are inconsistent, it is determined that there is a deployment conflict; if the preset deployment path is not occupied, it is determined that the conditions for deploying a new plugin instance are met.

[0099] In one possible implementation, if the target monitoring port 8080 is idle, or the process occupying port 8080 is determined to be unusable, then the preset deployment path (e.g., / opt / plugin / v2.0) is checked. If the preset deployment path is found to be occupied (e.g., a file or directory exists there), the configuration file of the plugin instance under the preset deployment path is read, and the configured monitoring port, for example, 8080, is obtained. This monitoring port is compared with the target monitoring port 8080. If they match, it is determined that there is a configured, reusable, but not started plugin instance under the preset deployment path. If the configured monitoring port is 9090, which is inconsistent with the target monitoring port 8080, then a deployment conflict is determined, i.e., the current deployment scenario is a deployment conflict scenario.

[0100] For example, if the preset deployment path (e.g., / opt / plugin / v2.0) is not occupied, then the conditions for directly deploying a new plugin instance are met, meaning the current deployment scenario is a scenario where a new plugin instance can be deployed.

[0101] This embodiment can detect and handle deployed but not started plugin instances by checking the occupancy status of the preset deployment path and comparing the monitoring ports configured for plugin instances under the preset deployment path. It can also accurately identify potential conflicts caused by inconsistent configurations (e.g., the deployment path is occupied but the port is incompatible), avoid service interruptions or configuration loss that may be caused by blind overlay deployment, and improve the reliability and stability of plugin deployment management.

[0102] S103. Execute the corresponding deployment decision based on the deployment scenario.

[0103] More specifically, based on the deployment scenario, corresponding deployment decisions are executed; wherein, the deployment scenario includes at least: scenarios where already started plugin instances can be reused, scenarios where unstarted plugin instances can be reused, scenarios where new plugin instances can be deployed, and deployment conflict scenarios; and the deployment decisions include at least: reusing already started plugin instances, reusing deployed but not started plugin instances, deploying and starting new plugin instances, or terminating the deployment process and outputting error information.

[0104] Optionally, based on the determined deployment scenario, corresponding deployment decisions are executed, specifically including: when the deployment scenario is a scenario where already started plugin instances can be reused, a deployment decision to reuse already started plugin instances is executed, and service availability verification is performed on the plugin instances; when the deployment scenario is a scenario where unstarted plugin instances can be reused, a deployment decision to start already deployed but not started plugin instances is executed, and service availability verification is performed on the plugin instances; when the deployment scenario is a scenario where new plugin instances can be deployed, a deployment decision to deploy and start new plugin instances is executed; when the deployment scenario is a deployment conflict scenario, a deployment decision to terminate the deployment process and output error information is executed.

[0105] In one possible embodiment, according to the embodiment in step S102, if it is determined that the current scenario is a "reusable started plugin instance scenario", then it is decided to reuse the started plugin instance and send a test request to the plugin instance to perform service availability verification.

[0106] Optionally, if the scenario is determined to be a "reusable unstarted plugin instance scenario", then a decision is made to start the plugin program located in the deployment path corresponding to the plugin instance, and then perform availability verification.

[0107] Optionally, if the scenario is determined to be a "new plugin instance deployment scenario", then the decision is made to unzip the new plugin instance package to the target deployment path and start the new plugin instance.

[0108] Optionally, if the scenario is determined to be a "deployment conflict scenario", the decision is to immediately stop the deployment and return an error message to the user that "there is a conflict between the target port or path".

[0109] This embodiment binds a corresponding deployment decision action to each deployment scenario, transforming the conclusions obtained through preliminary checks into executable operation instructions. This reduces the possibility of improper operation due to ambiguity in scenario judgment and improves the certainty and security of the deployment process.

[0110] The plugin deployment method provided in this application obtains the expected configuration information of the target plugin and performs a reuse compatibility check process based on this expected configuration information. By comprehensively analyzing port occupancy status, user permission status of the occupant process, and occupancy status of the preset deployment path, it determines the specific deployment scenario corresponding to the current deployment environment (e.g., whether an already started / not started plugin instance can be reused, a new instance can be deployed, or there is a conflict). Then, it executes the corresponding deployment decision based on the determined scenario. In this process, it effectively solves the problem of reliably and conflict-free reuse of existing plugins or secure deployment of new plugins in complex environments with multiple users, multiple servers, and chaotic historical plugin deployments. This improves deployment success rate and reliability, enhances system stability, and reduces the complexity of plugin operation and maintenance.

[0111] Figure 2 A flowchart illustrating the plugin deployment method provided in this application. Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, the plugin deployment method is described in detail. This method includes: obtaining the expected configuration information of the target plugin, which explicitly specifies the target monitoring port (e.g., port 8080) and the preset deployment path (e.g., / opt / plugin / v2.0). Then, a reuse compatibility check process is executed to clarify the deployment scenario of the current environment. In the reuse compatibility check process, a port occupancy check step is first performed based on the expected configuration information to determine whether the target monitoring port is already in use.

[0112] For example, if the port occupancy check step finds that the target monitoring port is not occupied by any process, it is determined that there is no reusable running plugin instance, and the execution flow switches to the path check branch: checking whether the preset deployment path ( / opt / plugin / v2.0) in the expected configuration information is occupied. If the preset deployment path is not occupied, it is determined that the condition of "new plugin instance deployment scenario" is met, and at this time, it is decided to directly deploy and start a new plugin instance, and the deployment process ends. If the preset deployment path is occupied, the configuration file of the deployed but not started plugin instance is read.

[0113] For example, if the target monitoring port is found to be occupied by a process during the port occupancy check step, the first-level reuse judgment process is initiated: an attempt is made to read the service identifier information of the occupying process to determine whether the service identifier information of the process occupying the target monitoring port can be successfully read. If the service identifier information of the process occupying the target monitoring port can be read (e.g., the occupying process is named "plugin_daemon"), the service identifier information is matched with preset plugin service characteristics to determine whether the service identifier information matches the preset plugin service characteristics. If the match is successful (i.e., it is confirmed to be the target plugin), it is further determined whether the occupying process was started by the current executing user or a system-level privileged user (i.e., the user permission information of the occupying process is checked). If the check finds that the occupying process was started by the current executing user or a system-level privileged user (e.g., the root user), it is determined that there is a "reusable started plugin instance". Subsequently, the system decides to reuse the started plugin instance and executes a business request on the plugin instance to check the service availability corresponding to the plugin instance. The process ends after the service availability verification is passed. The implementation principle and technical effect of service availability verification based on business requests in this embodiment are similar to those of the prior art, and will not be described in detail here.

[0114] For example, if the service identifier information of the process occupying the target monitoring port cannot be read (e.g., due to insufficient permissions causing the failure to read the service identifier information of the occupying process), a deep probing sub-process under restricted permissions is executed. First, a list of all processes started by system-level privileged users (e.g., root user) in the current system is obtained. Next, candidate processes whose service identifier information matches the preset plugin service characteristics are filtered from this list. For each candidate process, the associated configuration file is located based on the corresponding execution path, and the actual monitoring port configured for the candidate process is obtained by parsing the configuration file. This actual monitoring port is compared one by one with the target monitoring port (i.e., 8080). If the actual monitoring port of any candidate process is found to be 8080, it is determined that a "reusable started plugin instance" started by a system-level privileged user exists, and subsequent reuse and availability verification are performed. If the actual monitoring ports of all candidate processes are inconsistent with the target monitoring port (i.e., 8080), it is determined that no reusable started plugin instance exists, and finally, an error is reported and the process exits.

[0115] For example, in the port occupancy check step, if the target monitoring port is not occupied, or if the target monitoring port is occupied but the first-level reuse judgment process confirms that there is no reusable started plugin instance, the process will switch to checking the occupancy status of the preset deployment path ( / opt / plugin / v2.0), that is, to determine whether the new plugin deployment path is occupied.

[0116] For example, during the occupancy check, if a preset deployment path is found to be occupied, a second-level reuse judgment process is executed: The configuration file of the deployed (potentially not started) plugin instance under that preset deployment path is read, and the configured actual monitoring port is obtained based on the configuration file. This actual monitoring port is compared with the target monitoring port (i.e., 8080). If they match, it is determined that there is a "reusable but not started plugin instance," and the decision is to start the deployed but not started plugin instance and perform service availability verification. If they do not match (e.g., the actual monitoring port indicated by the configuration file is 9090), it is determined that there is a "deployment conflict," and the decision is to report an error and exit the deployment process to avoid service unrecoverability caused by overlay deployment.

[0117] Figure 3 A schematic diagram of the plug-in deployment device provided in this application is shown below. Figure 3 As shown, the plug-in deployment device 30 provided in this embodiment includes:

[0118] The acquisition module 301 is used to acquire the expected configuration information of the target plugin. The expected configuration information includes at least the target monitoring port and the preset deployment path.

[0119] The processing module 302 is used to perform a reuse compatibility check process based on the expected configuration information to determine the deployment scenario corresponding to the current deployment environment. The reuse compatibility check process includes analyzing the port occupancy status, the user permission status of the occupant process, and the occupancy status of the preset deployment path.

[0120] The processing module 302 is also used to execute corresponding deployment decisions based on the deployment scenario; wherein the deployment scenario includes at least: a scenario where an already started plugin instance can be reused, a scenario where an unstarted plugin instance can be reused, a scenario where a new plugin instance can be deployed, and a deployment conflict scenario; and the deployment decision includes at least: reusing an already started plugin instance, reusing a deployed but unstarted plugin instance, deploying and starting a new plugin instance, or terminating the deployment process and outputting error information.

[0121] Optionally, the processing module 302 is also used to determine whether the target monitoring port is occupied;

[0122] If it is determined that the target monitoring port has been occupied, the first-level reuse judgment process is executed for the process that has occupied the target monitoring port to determine whether there is a reusable started plugin instance;

[0123] If the target monitoring port is not occupied, a check on the occupancy status of the preset deployment path will be triggered.

[0124] Optionally, the processing module 302 is also used to determine whether the service identifier information of the process occupying the target monitoring port can be read;

[0125] If the service identifier information can be successfully read, the service identifier information is matched with the preset plugin service characteristics, and the process is determined to constitute a reusable started plugin instance based on the matching result and the user permission information of the process.

[0126] If the service identifier information cannot be read, a process deep probing sub-process under restricted permissions will be executed to determine whether the process occupying the target monitoring port is a plugin instance started by a user with special permissions.

[0127] Optionally, the processing module 302 is further configured to check the user permission information of the process during matching; if the user permission information indicates that the process was started by the currently executing user or a system-level privileged user, then it is determined that there is a reusable started plugin instance; otherwise, it is determined that there is no reusable started plugin instance.

[0128] If there is a mismatch, it is determined that there is no reusable instance of the started plugin.

[0129] Optionally, the processing module 302 is also used to obtain a list of all processes started by a preset system-level privileged user in the current system;

[0130] Filter out candidate processes from the list of all processes whose service identification information matches the characteristics of the preset plugin services;

[0131] For each candidate process, based on the execution path of the candidate process, locate and parse the associated configuration file to obtain the actual monitoring port configured for the candidate process;

[0132] Compare the actual monitoring ports of each candidate process with the target monitoring ports;

[0133] If a candidate process with the same port exists, it is determined that there is a reusable instance of a started plugin initiated by a system-level privileged user.

[0134] If no candidate process with the same port is found, then it is determined that there is no reusable instance of an already started plugin.

[0135] Optionally, the processing module 302 is also used to check whether the preset deployment path has been occupied;

[0136] If the preset deployment path is already in use, the second-level reuse judgment process is executed: determine the configuration information of the plugin instance located under the preset deployment path, and obtain the monitoring port configured in the configuration information of the plugin instance; compare the monitoring port with the target monitoring port; if the ports are consistent, it is determined that there is a reusable but not started plugin instance; if the ports are inconsistent, it is determined that there is a deployment conflict.

[0137] If the preset deployment path is not occupied, then the conditions for deploying a new plugin instance are met.

[0138] Optionally, the processing module 302 is also used to execute a deployment decision to reuse the already started plugin instance when the deployment scenario is a scenario where the already started plugin instance can be reused, and to perform service availability verification on the plugin instance;

[0139] When the deployment scenario is a scenario where reusable but not started plugin instances are used, the deployment decision is made to start the deployed but not started plugin instances, and service availability verification is performed on the plugin instances.

[0140] When the deployment scenario allows for the deployment of new plugin instances, the deployment decision is made to execute the deployment and start the new plugin instance.

[0141] When the deployment scenario is a deployment conflict scenario, execute the deployment decision to terminate the deployment process and output error information.

[0142] The plug-in deployment device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0143] Figure 4 A schematic diagram of the structure of the electronic device provided in this application. Figure 4 As shown, the electronic device 40 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the device 40 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0144] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

[0145] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0146] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0147] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0148] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0149] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0150] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0151] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0152] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0153] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0154] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0155] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0156] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0157] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0158] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A plugin deployment method, characterized in that, include: Obtain the desired configuration information of the target plugin, which includes at least the target monitoring port and the preset deployment path; Based on the expected configuration information, a reuse compatibility check process is executed to determine the deployment scenario corresponding to the current deployment environment; The reuse compatibility check process includes analyzing the port occupancy status, the user permission status of the occupant process, and the occupancy status of the preset deployment path. Based on the deployment scenario, execute the corresponding deployment decision; wherein the deployment scenario includes at least: a scenario where an already started plugin instance can be reused, a scenario where an unstarted plugin instance can be reused, a scenario where a new plugin instance can be deployed, and a deployment conflict scenario; and the deployment decision includes at least: reusing an already started plugin instance, reusing a deployed but unstarted plugin instance, deploying and starting a new plugin instance, or terminating the deployment process and outputting error information.

2. The method according to claim 1, characterized in that, Based on the desired configuration information, a reuse compatibility check process is performed, specifically including: Determine whether the target monitoring port is occupied; If it is determined that the target monitoring port has been occupied, then for the process that has occupied the target monitoring port, the first-level reuse judgment process is executed to determine whether there is a reusable started plugin instance; If the target monitoring port is not occupied, an occupation status check of the preset deployment path is triggered.

3. The method according to claim 2, characterized in that, The first-level reuse judgment process specifically includes: Determine whether the service identifier information of the process occupying the target monitoring port can be read; If the service identifier information can be successfully read, then a matching judgment is made based on the service identifier information and the preset plugin service characteristics, and based on the matching result and the user permission information of the process, it is determined whether the process constitutes a reusable started plugin instance. If the service identifier information cannot be read, a process deep probing sub-process under restricted permissions is executed to determine whether the process occupying the target monitoring port is a plugin instance started by a user with special permissions.

4. The method according to claim 3, characterized in that, Based on the matching results and the user permission information of the process, it is determined whether the process constitutes a reusable instance of an activated plugin, specifically including: During the matching process, the user permission information of the process is further checked; if the user permission information indicates that the process was started by the currently executing user or a system-level privileged user, it is determined that there is a reusable instance of the started plugin; otherwise, it is determined that there is no reusable instance of the started plugin. If there is a mismatch, it is determined that there is no reusable instance of the started plugin.

5. The method according to claim 3, characterized in that, The process deep probing sub-process under restricted privileges specifically includes: Get a list of all processes started by the preset system-privileged user in the current system; Candidate processes whose service identification information matches the preset plug-in service characteristics are selected from the list of all processes; For each candidate process, based on the execution path of the candidate process, locate and parse the associated configuration file to obtain the actual monitoring port configured for the candidate process; The actual monitoring port of each candidate process is compared with the target monitoring port; If a candidate process with the same port exists, it is determined that there is a reusable instance of a started plugin initiated by the system-level privileged user. If no candidate process with the same port is found, then it is determined that there is no reusable instance of an already started plugin.

6. The method according to claim 2, characterized in that, Triggering a check on the occupancy status of the preset deployment path, and after confirming through the first-level reuse judgment process that there are no reusable started plugin instances, performing a check on the occupancy status of the preset deployment path, including: Check if the preset deployment path is already in use; If the preset deployment path is already in use, the second-level reuse judgment process is executed: determine the configuration information of the plugin instance located under the preset deployment path, and obtain the monitoring port configured in the configuration information of the plugin instance; compare the monitoring port with the target monitoring port; wherein, if the ports are consistent, it is determined that there is a reusable but not started plugin instance; if the ports are inconsistent, it is determined that there is a deployment conflict. If the preset deployment path is not occupied, then the conditions for deploying a new plugin instance are met.

7. The method according to claim 1, characterized in that, Based on the determined deployment scenario, execute the corresponding deployment decision, specifically including: When the deployment scenario is a scenario where already started plugin instances can be reused, a deployment decision to reuse already started plugin instances is executed, and service availability verification is performed on the plugin instances. When the deployment scenario is a scenario where a reusable but not started plugin instance can be used, a deployment decision is made to start the deployed but not started plugin instance, and service availability verification is performed on the plugin instance. When the deployment scenario is one in which new plugin instances can be deployed, the deployment decision is made to execute the deployment and start the new plugin instance. When the deployment scenario is a deployment conflict scenario, a deployment decision is made to terminate the deployment process and output an error message.

8. A plug-in deployment device, characterized in that, include: The acquisition module is used to acquire the expected configuration information of the target plugin, wherein the expected configuration information includes at least the target monitoring port and the preset deployment path; The processing module is used to perform a reuse compatibility check process based on the expected configuration information to determine the deployment scenario corresponding to the current deployment environment; The reuse compatibility check process includes analyzing the port occupancy status, the user permission status of the occupant process, and the occupancy status of the preset deployment path. The processing module is further configured to execute corresponding deployment decisions based on the deployment scenario; wherein the deployment scenario includes at least: a scenario where an already started plugin instance can be reused, a scenario where an unstarted plugin instance can be reused, a scenario where a new plugin instance can be deployed, and a deployment conflict scenario; and the deployment decision includes at least: reusing an already started plugin instance, reusing a deployed but unstarted plugin instance, deploying and starting a new plugin instance, or terminating the deployment process and outputting error information.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images