A software environment deployment method and related apparatus

Abstract

This application discloses a software environment deployment method and related apparatus. First, deployment information is acquired, including deployment parameters corresponding to multiple nodes. Then, a corresponding deployment orchestration script is generated based on the deployment parameters for each node. Next, the deployment orchestration scripts for each node are sent to their respective nodes. Then, a scheduling script triggers multiple nodes to execute the corresponding deployment orchestration scripts to deploy the software environment. Furthermore, a deployment server provides unified management of the deployment logic and batch deployment process for each node. Compared to the existing method where each node maintains its deployment logic locally, this method eliminates the need to modify each node individually; changes to the deployment logic are achieved simply by modifying the deployment parameters on the deployment server. This significantly reduces the maintenance cost of batch software environment deployment and improves automation and deployment efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a software environment deployment method and related apparatus. Background Technology

[0002] Software environment deployment refers to installing, updating, or uninstalling a software runtime environment on a target node that meets the needs of business operation, system testing, or automated verification.

[0003] Existing software environment deployment methods typically employ a client / server architecture. Specifically, the client initiates a software deployment request to the server, the server sends the corresponding deployment resources to the client based on the request, and the client, upon receiving the deployment resources, deploys the software environment according to the corresponding deployment logic.

[0004] However, existing methods are costly and inefficient in batch deployment scenarios. Summary of the Invention

[0005] In view of this, this application provides a software environment deployment method and related apparatus, which uniformly manages the deployment logic and batch deployment process corresponding to multiple nodes through a deployment server. Compared with the existing technology where each node maintains its deployment logic locally, it is not necessary to modify multiple nodes one by one. The deployment logic can be changed simply by modifying the deployment parameters in the deployment server, which significantly reduces the maintenance cost of batch deployment of software environment and improves the degree of automation and deployment efficiency.

[0006] To solve the above problems, the technical solution provided in this application is as follows: On one hand, this application provides a software environment deployment method, the method comprising: Obtain deployment information, which includes deployment parameters corresponding to multiple nodes; Based on the deployment information, multiple deployment orchestration scripts corresponding to the multiple nodes are generated, and the deployment orchestration scripts are used to identify the deployment logic corresponding to the nodes; The multiple deployment orchestration scripts are sent to the corresponding nodes among the multiple nodes respectively; Based on the scheduling script, the multiple nodes are triggered to deploy the software environment according to the corresponding deployment orchestration script.

[0007] In another aspect, embodiments of this application provide a software environment configuration apparatus, the apparatus comprising: An acquisition unit is used to acquire deployment information, which includes deployment parameters corresponding to multiple nodes. The generation unit is configured to generate multiple deployment orchestration scripts corresponding to the multiple nodes based on the deployment information, wherein the deployment orchestration scripts are used to identify the deployment logic corresponding to the nodes; The sending unit is used to send the plurality of deployment orchestration scripts to the corresponding nodes among the plurality of nodes respectively; The deployment unit is used to trigger the multiple nodes to deploy the software environment based on the corresponding deployment orchestration script, according to the scheduling script.

[0008] In another aspect, this application provides a computer device, which includes a processor and a memory: The memory is used to store computer programs; The processor is configured to execute the method described in any of the above-described embodiments according to the computer program.

[0009] In another aspect, this application provides a computer-readable storage medium for storing a computer program that, when executed by a computer device, implements the method described in any of the above-mentioned embodiments.

[0010] In another aspect, this application provides a computer program product including a computer program, which, when run on a computer device, causes the computer device to perform any of the methods described above.

[0011] As can be seen from the above technical solution, this application first obtains deployment information, which includes deployment parameters corresponding to multiple nodes. Then, based on the deployment parameters of each node, a corresponding deployment orchestration script is generated. This deployment orchestration script is used to identify the deployment logic corresponding to the node. Next, the deployment orchestration scripts corresponding to each node are sent to their respective nodes. Then, based on the scheduling script, multiple nodes are triggered to deploy the software environment according to the corresponding deployment orchestration script, thereby improving the automation level and deployment efficiency of batch deployment. Thus, by generating deployment orchestration scripts for each node through the deployment server, the deployment logic corresponding to multiple nodes can be uniformly managed. Based on the scheduling script, each node can be triggered to automatically execute the software environment deployment process, achieving batch deployment. Compared with the existing technology where each node maintains its deployment logic locally, this application does not require modification of multiple nodes individually; only the deployment parameters need to be modified in the deployment server to achieve changes in the deployment logic. This significantly reduces the maintenance cost of batch deployment of the software environment and improves the automation level and deployment efficiency. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A flowchart illustrating a software environment deployment method provided in an embodiment of this application; Figure 2 A system architecture diagram of an application software environment deployment method provided in this application embodiment; Figure 3 An interactive flow diagram provided for an embodiment of this application; Figure 4 This is a schematic diagram of a software environment configuration device provided in an embodiment of this application. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0015] As described in the background section, existing software environment deployment methods have the following shortcomings: (1) High deployment cost.

[0016] Installation scripts and deployment logic are typically written locally on the client, resulting in strong coupling between the deployment logic and the client. If the deployment process, software version, or installation parameters change, the deployment logic on the corresponding client needs to be updated. In batch deployment scenarios, this leads to high deployment costs and untimely updates.

[0017] (2) Deployment consistency is difficult to guarantee.

[0018] When deploying multiple clients in batches, differences in the client's installation script version and execution environment can easily lead to inconsistent deployment results on different nodes, increasing the difficulty of later maintenance and troubleshooting.

[0019] (3) Low efficiency of automation and batch deployment.

[0020] Because the deployment logic is fixed on the client side, local execution relies on manual or local scheduling. Each time a batch of deployment nodes is added, the client needs to be adapted and modified, making it impossible to achieve unified scheduling and dynamic generation on the server side. The logic of deployment order, dependency installation, and parameter configuration between nodes lacks centralized control, resulting in low batch deployment efficiency and failing to meet the needs of large-scale, high-concurrency, and multi-node automated deployment.

[0021] To address the aforementioned issues, this application provides a software environment deployment method. By generating deployment orchestration scripts for each node through a deployment server, the deployment logic corresponding to multiple nodes can be uniformly managed. Based on the scheduling scripts, the software environment deployment process can be automatically executed on each node. Compared to the existing technology where each node maintains its deployment logic locally, this method eliminates the need to modify multiple nodes one by one. Changes to the deployment logic can be achieved simply by modifying the deployment parameters on the deployment server. This significantly reduces the maintenance cost of batch deployment of software environments and improves the degree of automation and deployment efficiency.

[0022] The solutions provided in this application relate to the field of computer technology, and are specifically illustrated through the following embodiments.

[0023] This method is executed through a deployment server, which is used to uniformly manage the deployment of software environments.

[0024] Software environment deployment refers to installing, updating, or uninstalling a software runtime environment on a target node that meets the needs of business operation, system testing, or automated verification. This software environment may include one or more of the following: operating system components, runtime framework, middleware, database services, drivers, dependency libraries, test execution components, configuration files, system environment parameters, environment variables, and registry parameters.

[0025] See Figure 1 The diagram shown is a flowchart of a software environment deployment method provided in an embodiment of this application, which includes steps S101-S104.

[0026] S101: Obtain deployment information.

[0027] The deployment information includes deployment parameters corresponding to multiple nodes. Here, a node refers to the client that deploys the software environment, which can be a physical host, server, test host, or industrial control computer to be deployed; this embodiment does not impose specific limitations on this.

[0028] Deployment parameters are parameters used to deploy the software environment. For example, the deployment information includes information for generating the corresponding node installation script, determining the node deployment content, and controlling the node deployment process. This application embodiment does not impose specific limitations on this. Further, the deployment information may include one or more of the following: node identifier, node address, node login information, software identifier to be installed, software version information, installation path, installation order, installation parameters, configuration file path, dependency information, deployment mode, log path, and execution timeout.

[0029] This application does not impose specific limitations on the method of obtaining deployment information. For example, users can upload the requirement text corresponding to the deployment task in file form, and then the deployment server can parse the requirement text to obtain the deployment information. Alternatively, configuration information can be obtained from configuration files, databases, or third-party management systems.

[0030] Furthermore, the deployment server can uniformly obtain the deployment information corresponding to multiple nodes before the deployment task begins, providing a data foundation for the subsequent generation of deployment logic corresponding to multiple nodes.

[0031] S102: Generate multiple deployment orchestration scripts corresponding to multiple nodes based on the deployment information.

[0032] Deployment orchestration scripts are used to identify the deployment logic corresponding to a node, guiding the node to complete operations such as software installation, parameter configuration, dependency initialization, and environment configuration. Deployment orchestration scripts may include one or more of the following: installation resource call paths, software installation commands, configuration file copy commands, dependency installation commands, and environment variable configuration commands. This application embodiment does not impose specific limitations on these.

[0033] For multiple nodes with the same deployment parameters, generate the same deployment orchestration script and ensure that the nodes obtain the same installation resources to guarantee deployment consistency.

[0034] In this embodiment, the deployment orchestration script is generated by the deployment server based on the deployment parameters of each node, rather than being pre-installed on the local nodes. This decouples the deployment logic from the local client programs on each node, allowing the deployment server to uniformly generate and manage the deployment logic for each node. When software versions, installation paths, deployment processes, etc., change, the deployment server can regenerate the deployment orchestration script based on the updated deployment parameters without requiring individual modifications to the deployment logic on each node. This improves the consistency and maintainability of multi-node software environment deployments.

[0035] S103: Send multiple deployment orchestration scripts to the corresponding nodes in the multiple nodes respectively.

[0036] The deployment server sends each deployment orchestration script to the corresponding node based on the mapping between the deployment orchestration script and the node. This allows each node to subsequently deploy the software environment locally based on the corresponding deployment logic.

[0037] This application does not impose specific restrictions on the sending method. For example, the deployment orchestration script can be sent to the corresponding node through communication protocols, remote interface calls, or file transfer services.

[0038] The deployment server sends the corresponding deployment orchestration scripts to the nodes, instead of requiring each node to pre-store the deployment logic. Therefore, when deployment requirements change, the deployment server can regenerate and send new deployment orchestration scripts, thereby reducing the cost of script maintenance and synchronization across multiple nodes.

[0039] Furthermore, when the deployment logic changes, only the deployment orchestration script on the deployment server needs to be updated by modifying the deployment parameters, without having to modify the local deployment logic of multiple nodes one by one, which further reduces the cost of multi-node deployment and maintenance.

[0040] As one possible implementation, multiple nodes and the deployment server are equipped with file transfer tools. Through these tools, multiple deployment orchestration scripts and deployment resources are sent to their corresponding nodes.

[0041] The file transfer tool can be a software tool or communication component that supports remote file transfer, such as OpenSSH, SCP, SFTP, FTP, etc. This application embodiment does not limit this.

[0042] Deployment resources refer to the resources that a node needs to call or use when deploying the software environment. These resources may include one or more of the following: software installation packages, tool installation packages, runtime dependencies, driver files, configuration files, license files, patch files, and resource compressed packages.

[0043] After the deployment server generates multiple deployment orchestration scripts corresponding to multiple nodes, it can send the corresponding deployment orchestration scripts to the appropriate nodes based on the mapping between nodes and deployment orchestration scripts. Simultaneously, the deployment server can also acquire deployment resources according to deployment requirements and then distribute these resources uniformly to multiple nodes, enabling each node to call the corresponding deployment resources to deploy the software environment based on its deployment logic.

[0044] Therefore, by installing file transfer tools on the deployment server and multiple nodes, the deployment server can automatically send deployment orchestration scripts and deployment resources to the corresponding nodes, reducing the manual copying of deployment resources and improving the automation level of software environment deployment and resource distribution efficiency.

[0045] S104: Based on the scheduling script, multiple nodes are triggered to deploy the software environment according to the corresponding deployment orchestration script.

[0046] The scheduling script is used to control the software environment deployment process of multiple nodes. For example, the deployment orchestration script can control the calling order, execution timing, and exception handling of multiple nodes. This application embodiment does not impose specific limitations on this. For example, the configuration information is parsed, and then the scheduling order of each node is determined based on the parsed content. Then, the scheduling script is obtained by writing code to encapsulate the scheduling order of each node, as well as the preset deployment trigger conditions and exception handling mechanisms.

[0047] Setting the scheduling script on the deployment server side allows the deployment server to uniformly control the software environment deployment process of multiple nodes, thereby enabling batch deployment of software environments on multiple nodes.

[0048] This application does not impose specific restrictions on the method of triggering the multiple nodes to deploy the software environment based on the corresponding deployment orchestration scripts. For example, multiple nodes can be called sequentially to execute the corresponding deployment orchestration scripts to deploy the software environment based on the scheduling order of the scheduling script, instead of each node independently and in an unordered manner performing the deployment. Furthermore, the deployment server can remotely access the node's command-line environment and enter commands in that environment to trigger the node to run its local deployment orchestration script to deploy the software environment.

[0049] Furthermore, the deployment server can centrally control multiple nodes using scheduling scripts, enabling each node to automatically execute the software environment deployment for multiple nodes according to the corresponding deployment orchestration scripts issued by the server.

[0050] This application first obtains deployment information, including deployment parameters for multiple nodes. Then, based on these parameters, it generates corresponding deployment orchestration scripts to identify the deployment logic for each node. These scripts are then sent to their respective nodes. Finally, a scheduling script triggers multiple nodes to deploy the software environment based on these scripts, thereby improving the automation and efficiency of batch deployment. Thus, by generating deployment orchestration scripts for each node through a deployment server, the deployment logic for multiple nodes can be uniformly managed. Based on the scheduling script, each node can be automatically triggered to execute the software environment deployment process. Compared to existing technologies where each node maintains its deployment logic locally, this method eliminates the need to modify each node individually; changes to the deployment logic are achieved simply by modifying the deployment parameters on the deployment server. This significantly reduces the maintenance cost of batch software environment deployment and improves automation and efficiency.

[0051] For remote deployment scenarios of software environments, user interface (UI) automation technology can be used to achieve standardized deployment. However, UI automation technology relies on the normal graphical rendering, control recognition, and interactive operation of the GUI interface. The headless running environment corresponding to remote deployment will directly lead to the lack of this prerequisite, causing the UI automation deployment process to fail to execute normally.

[0052] Based on this, the embodiments of this application provide an automated deployment method, as detailed in A1-A3.

[0053] A1: Obtain the user interface automation script.

[0054] User interface automation scripts are script files used to automate operations. These scripts can simulate input commands to enable interactive operations within the graphical user interface corresponding to a target node. Simulated input commands are instructions used to mimic user input behaviors, such as keyboard input, mouse clicks, mouse movements, keyboard shortcuts, or window focus switching.

[0055] For example, a configurable script containing deployment process templates and parameter placeholders for different nodes can be pre-written. After obtaining the deployment parameters for each node, the deployment parameters for each node are filled into the parameter placeholders corresponding to the node identifiers in the configurable script, generating a user interface automation script. Then, the user interface automation script is uniformly distributed to each node so that each node can match and execute the corresponding deployment process from the user interface automation script based on its own node identifier.

[0056] By acquiring user interface automation scripts, a scripting foundation can be provided for performing graphical interface automation operations in subsequent graphical sessions.

[0057] A2: Based on the scheduling script, multiple graphical sessions corresponding to each node are created through the remote desktop protocol.

[0058] The Remote Desktop Protocol (RDP) is used to establish a remote desktop connection between the deployment server and the node, thereby enabling the deployment server to retrieve or display the graphical session corresponding to the node.

[0059] A graphical session refers to a session window formed through a remote desktop protocol, used to display the graphical user interface (GUI) corresponding to a node. The GUI includes rendered content such as the installation window, buttons, input boxes, configuration pages, and pop-ups of the software to be deployed; this application embodiment does not impose specific limitations on this.

[0060] For example, the scheduling script can sequentially establish remote desktop sessions for multiple nodes according to the deployment order of the software environment, so as to display the GUI of the corresponding node through the session window. That is, the GUI of each node can be displayed sequentially in the interface of the deployment server to realize graphical remote operation of multiple nodes.

[0061] Even if the node is in an environment without a local physical display, a displayable and interactive GUI can be provided to the node through the remote desktop protocol, thereby supporting the automatic execution of automation scripts.

[0062] A3: In the graphical session corresponding to the first node, call the deployment orchestration script corresponding to the first node, and simulate input commands based on the user interface automation script to deploy the software environment of the first node.

[0063] The first node can be any of the multiple nodes that the currently deployed server calls up and executes the software environment deployment.

[0064] In the deployment server, the GUI of the first node can be operated via remote desktop protocol. A scheduling script calls the deployment orchestration script within the GUI of the first node and initiates the software environment deployment task in conjunction with the corresponding deployment resources. Subsequently, a user interface automation script simulates input commands, completing the interface interactions during the software installation process within the rendered GUI. For example, the user interface automation script can trigger simulated mouse clicks to click the "Next" button on the installation interface, simulated keyboard input to enter the installation path or license information, or trigger confirmation operations to complete parameter configuration, thereby achieving the deployment of the software environment for the first node.

[0065] This application does not impose specific restrictions on the deployment method of the software environment of multiple nodes. For example, the software environment of the next node can be deployed after the software environment of one node is deployed, or the software environment of multiple nodes can be deployed in parallel.

[0066] Therefore, the deployment server creates a graphical session for nodes without a local physical monitor through the remote desktop protocol, enabling the nodes to have a displayable and interactive graphical deployment environment. By simulating input commands through deployment orchestration scripts and user interface automation scripts, the graphical interface interaction operations during the software installation process can be completed automatically. This solves the problem of UI automation deployment in a headless environment lacking graphical interface support and thus being unable to execute. It improves the automation and standardization of software environment deployment, reduces manual remote operation, lowers the risk of human error, and improves the efficiency of software environment deployment.

[0067] The aforementioned method of deploying automated execution software environments is prone to multi-node session conflicts. For example, the Windows operating system implements a strict resource binding policy based on a session isolation architecture: physical console devices (display adapters, human-machine interface devices, etc.) are statically allocated to a single interactive session, and the scope of simulated input injection (such as SendInput, keybd_event) is limited to the currently active session at the time of execution. Under this constraint, if a graphical session hosting environment is provided for nodes without a local physical monitor via Remote Desktop Protocol (RDP) to host UI user interface automation scripts, the following problems arise: On the one hand, the keyboard and mouse input commands provided by the deployment server are usually applied to the global active session. When multiple nodes without display adapters run UI user interface automation script workloads that rely on graphical user interface (GUI) rendering independently at the same time, there are multiple remote desktop sessions. Automated operations such as interface clicks and text input on one node may be incorrectly routed to the remote sessions of other concurrently deployed nodes, causing interface misoperation, incorrect installation parameter filling, or interruption of the installation process.

[0068] On the other hand, the automated execution of input commands relies on GUI rendering resources. When multiple remote desktop sessions are created, switched, or minimized at the same time, there are limitations on the use of GUI rendering resources. This can easily lead to problems such as session preemption, abnormal loading of the graphical context, or freezing of the window message queue. Consequently, some nodes may fail to load the complete graphical interface, causing the software to be deployed to fail to start or the automated deployment script to terminate.

[0069] Therefore, how to reduce input stream and GUI rendering conflicts between remote sessions and improve the stability and reliability of automated software environment deployment during multi-node batch deployment has become an urgent problem to be solved.

[0070] Based on this, this application provides a deployment method to solve the session conflict problem in parallel deployment scenarios, see B1-B2 for details.

[0071] B1: Based on the scheduling script, after creating multiple graphical sessions corresponding to each node via the remote desktop protocol, configuration operations are performed on the registry to obtain registry information.

[0072] The registry information is used to indicate the state of the graphical user interface rendering. In this embodiment, the registry information can be used to maintain continuous rendering of the graphical user interface even when the graphical session is minimized.

[0073] For example, a user modifies two specified registry entries (data type DWord, value 2) in the deployment server to obtain registry information.

[0074] This registry information can disable the GUI auto-suppression function, continuously maintaining the complete graphical context and input routing capabilities of the remote session. Even if the graphical session is minimized or disconnected, the target node's GUI environment remains active, and simulated input interfaces such as SendInput can execute normally. This effectively solves the problem of user interface automation script interruption caused by switching graphical sessions during multi-node deployment in headless environments, thus ensuring that each node can continuously perform automated deployment in scenarios with concurrent multi-node deployment.

[0075] B2: During the deployment of the software environment of the first node, based on the registry information, minimize the graphical session corresponding to the second node, and continuously execute the graphical user interface rendering for the second node.

[0076] The second node is different from the first node. Furthermore, the second node has already had its graphical session invoked and the software environment deployment process initiated.

[0077] Minimizing the graphical session corresponding to the second node is mainly used to reduce interface focus conflicts and simulated input stream risks when multiple graphical sessions are active at the same time.

[0078] This method continuously renders the graphical user interface for the second node based on registry information, primarily to prevent the graphical interface from stopping refreshing or the window message queue from freezing due to the minimization of the graphical session.

[0079] In one example, the deployment server first retrieves the graphical session corresponding to the second node and invokes the deployment orchestration script and deployment resources for that node to initiate the software environment deployment task. Then, it executes the software environment deployment for the second node based on the user interface automation script. Next, the deployment server minimizes the graphical session corresponding to the second node and, based on registry information, allows the remote desktop session of the second node to continue rendering the graphical user interface and handling window messages. Simultaneously, it determines the next node to be deployed based on the scheduling script. Subsequently, the deployment server retrieves the graphical session corresponding to the first node and executes the software environment deployment for that node. At this point, the second node can continue the installation process while its graphical session is minimized, and the first node can also execute the deployment process within the currently retrieved graphical session.

[0080] Therefore, during the concurrent deployment of software environments across multiple nodes, the deployment server can access the graphical sessions of different nodes and minimize the graphical sessions of other nodes. At the same time, it can ensure the continuous rendering of the graphical user interface of the minimized node through registry information, thereby reducing interference from simulated input between nodes and preventing the installation process of the minimized node from being interrupted. This effectively ensures the deployment stability and success rate in concurrent deployment scenarios.

[0081] As one possible implementation, the deployment server has a visual user interface that allows users to manually configure deployment parameters for multiple nodes and obtain deployment information.

[0082] Specifically, it retrieves deployment information in response to configuration operations for deployment parameters corresponding to multiple nodes in the visual operation interface.

[0083] The visual operation interface refers to the operable interface provided to the user. This application embodiment does not impose specific limitations on the visual interface. For example, the visual interface can be the native Jenkins interface generated by the Blue Ocean front-end plugin that comes with Jenkins, or it can be a front-end interface built based on HTML and CSS technologies.

[0084] Users can configure the node addresses, software to be installed, software versions, installation paths, and installation parameters for multiple nodes in a visual interface, and then submit deployment tasks. The deployment server responds to the user's configuration operations for the deployment parameters corresponding to the multiple nodes and obtains the deployment parameter information.

[0085] The visual interface allows users to easily configure deployment information, simplifying and visualizing deployment parameter configuration and increasing its flexibility and efficiency. Furthermore, the visual interface makes the input of deployment parameters more intuitive, contributing to improved efficiency in configuring differentiated deployment parameters across multiple nodes.

[0086] In related technologies, the deployment server only handles request processing and data return, and cannot monitor the deployment status of nodes. Once the installation script execution is abnormal, the deployment server has difficulty in detecting and handling it, which can easily lead to deployment failure and inconsistent status.

[0087] As one possible implementation, the visual interface includes a progress display interaction entry point, and the method also includes: C1: Get the deployment status of multiple nodes respectively.

[0088] The progress display interaction entry point can be a button, link, tab, status bar, progress display area, or other user-triggerable interface control within the visual operation interface. This application does not limit the specific form of the progress display interaction entry point.

[0089] The deployment status is used to characterize the current software environment deployment and execution status of a node. For example, the deployment status may include deployment in progress, deployment successful, deployment failed, waiting for deployment, script has been distributed, installation script is executing, installation resource transfer completed, installation completed, abnormal interruption, etc. This application embodiment does not impose specific limitations on this.

[0090] For example, multiple nodes can return deployment status to the deployment server during the execution of their respective installation scripts. The deployment server can then determine the deployment status of each node based on the status information returned by the nodes. Alternatively, the deployment server can proactively obtain the call results, installation script execution results, or log information from multiple nodes to determine the deployment status of each node. This application does not impose specific limitations in this regard.

[0091] In this embodiment, the deployment of software environment for multiple nodes is treated as a deployment task. When the installation script and installation resources are distributed through the Jenkins SHH plugin and the OpenSSH Server configured on the client, and the software environment deployment task for each node is started, Jenkins generates a unique build number for the deployment task, so that the build number is associated with the deployment task. Then, the deployment status of multiple nodes in the deployment task can be uniformly monitored through the build number.

[0092] C2: Responds to the triggered operation of the progress display interaction entry, and displays the deployment status of multiple nodes respectively.

[0093] Users can trigger the progress display interaction entry in the visual operation interface. The deployment server responds to the trigger operation of the progress display interaction entry and displays the deployment status of multiple nodes in the visual operation interface.

[0094] During the demonstration, the visual interface can display the deployment status of each node by node dimension. For example, it can display the node identifier and current deployment status of each node. For nodes that fail to deploy, it can also display the reason for the failure or error message to help users locate the deployment anomaly.

[0095] Therefore, by setting up a progress display interaction entry in the visual operation interface, and displaying the deployment status of multiple nodes after the user triggers the entry, users can intuitively and centrally understand the deployment progress and execution results of the software environment of multiple nodes, improve the visualization and monitorability of the deployment process, and thus improve the troubleshooting and management efficiency of multi-node software environment deployment.

[0096] To more clearly illustrate the software environment deployment method provided in the embodiments of this application, the overall architecture of the software environment deployment method is described below by way of example.

[0097] See Figure 2 The diagram shown is a system architecture diagram of an application software environment deployment method provided in an embodiment of this application. It includes two parts: a deployment server and a client. The deployment server adopts a Model-View-Controller (MVC) architecture and Jenkins technology to manage the software environment deployment process in layers.

[0098] The system architecture comprises a front-end interaction layer, a back-end control layer, a Jenkins scheduling layer, and a client execution layer. The composition, configuration, and functions of each layer are described below: (1) Front-end interaction layer.

[0099] The system uses HTML5 and CSS3 technologies to build a visual operation interface that runs on the user terminal corresponding to the deployment server. It is used to receive the IP address of the host to be deployed (the IP address of the node) and the corresponding deployment parameters configured by the user, and provides interactive entry points such as deployment triggering, progress display, and task query.

[0100] (2) Backend control layer.

[0101] Based on the Django framework, an MVC architecture is implemented, with the functions of each layer as follows: Model layer: Responsible for storing deployment configurations, client information, Jenkins build number, deployment status, and other data.

[0102] View layer: Responsible for the interaction and rendering of the front-end interface and back-end data.

[0103] Controller layer: As the core control unit, it completes front-end parameter parsing, Jenkins interface calls, node deployment status reception, and association and binding of deployment tasks with build numbers.

[0104] (3) Jenkins scheduling layer.

[0105] Deployed on a dedicated server, it serves as the core deployment engine, enabling unified storage and distribution of software installation packages and standardized installation scripts, batch deployment task scheduling and execution, establishing remote connections via the RDP remote desktop protocol to provide a graphical session environment for nodes, and resolving concurrent conflicts in software environment deployment through registry information.

[0106] (4) Client execution layer.

[0107] This is the physical host / server node to be deployed, used to receive deployment files and installation scripts, and to transmit deployment progress and status back in real time.

[0108] Based on the system architecture diagram above, an example is provided to illustrate the implementation process of the software environment deployment method. (See also...) Figure 3 The diagram shown is a schematic representation of an interactive process provided in an embodiment of this application.

[0109] Step 1: The user enters deployment parameters such as the IP address of the host to be deployed, the software to be installed, and its version information through input on the front-end interface.

[0110] Step 2: In response to the user's submission of deployment parameters, generate a deployment request to the Django backend.

[0111] Step 3: After the Django backend Controller layer verifies the deployment request received by the frontend, it calls the Jenkins API to trigger the corresponding deployment task, generates the deployment orchestration script for each node, obtains the unique build number returned by Jenkins, and binds and stores the build number with this deployment task.

[0112] Step 4: On the deployment server side, the Jenkins scheduler creates an independent graphical session host environment for each node via RDP to host the UI automation scripts. Simultaneously, the Jenkins scheduler performs automatic registry configuration on the deployment server side, setting registry entries to achieve session and input isolation at the server level, thus resolving session conflicts when multiple nodes execute concurrently.

[0113] Step 5: Distribute deployment resources and deployment orchestration scripts to all nodes through Jenkins to ensure that the script versions and execution environments of multiple nodes are completely consistent. Each node will automatically deploy the software environment based on the received deployment orchestration scripts and deployment resources.

[0114] Step 6: Each node uploads deployment progress, execution results, and exception information to the deployment server backend in real time. The deployment server backend associates the corresponding deployment task with the Jenkins build number and displays the full-process monitoring data on the front-end interface.

[0115] The system architecture communicates with each node via a TCP / IP network. The front-end terminal, Django back-end, Jenkins scheduler, and multiple client nodes are located on the same local area network / private network, enabling stable transmission of commands, files, and status data.

[0116] In addition to the execution steps corresponding to the above computer equipment, users also need to perform some user operations to complete the overall process.

[0117] (1) Power on the physical host nodes to be deployed and configure the network connectivity to ensure that the physical devices are operating normally.

[0118] (2) Perform physical deployment, network cabling and basic network connectivity testing on each server (including the deployment server and the server node to be deployed).

[0119] (3) Write and configure batch scripts to enable Jenkins to start automatically on boot, so that it can bind to a graphical display server in a headless environment, thus solving the problem of UI automation scripts failing to execute due to the lack of a graphical device.

[0120] (4) Install and configure OpenSSH Server on each node to provide a secure transmission channel for Jenkins to transmit installation packages and scripts to the nodes.

[0121] Apart from the physical operations and pre-configuration steps mentioned above, the entire subsequent process, including batch deployment, remote session management, installation execution, and status feedback, is executed automatically.

[0122] Therefore, the key design and advantages of the software environment deployment method proposed in this application are as follows.

[0123] (1) Layered architecture design with complete decoupling between deployment logic and client.

[0124] This application adopts a four-layer architecture of MVC layered architecture + Jenkins scheduling layer, which centralizes all deployment logic and deployment resources for unified management on the server side. Jenkins completes the standardized and unified distribution. The client only needs to receive the file and perform the installation operation, without needing to pre-store or maintain any deployment-related scripts and logic.

[0125] This application decouples the deployment logic from the client. The deployment process and version updates only need to be modified once on the server side to be synchronized to all nodes without any modification to the nodes, reducing system maintenance costs by more than 80%. At the same time, it greatly improves system adaptability and can quickly meet the deployment needs of different software types and different operating environments.

[0126] (2) Consistency guarantee mechanism for multi-node parallel deployment.

[0127] This application uses the Jenkins scheduling layer to uniformly distribute the same version of the software installation package and standardized deployment orchestration script to all nodes to be deployed, ensuring that the execution environment, script version, and deployment parameters of all clients are completely consistent, eliminating version and environment differences from the source.

[0128] This application ensures that all nodes receive and execute a completely consistent deployment process synchronously, solving the problems of long serial deployment time, concurrent session conflicts, and inconsistent deployment results in traditional multi-node deployment solutions. It significantly improves the efficiency of large-scale deployment, guarantees the consistency of deployment results across all nodes, eliminates deployment anomalies caused by version and environment differences, and can greatly reduce the cost of later operation and maintenance troubleshooting.

[0129] (3) Session conflict resolution mechanism for UI automated deployment in headless environment.

[0130] This application integrates an RDP module and a registry auto-configuration module on the deployment server. For headless environments, the deployment server creates an independent graphical session host environment for each client node. At the same time, it modifies two specified registry entries (data type DWord, value 2) on the deployment server, and uses a batch script to start automatically at boot to force the binding of the Jenkins agent process and the graphical display server.

[0131] When Jenkins runs in a headless environment, the default agent process lacks a binding with the graphics display server, causing UI automation scripts to terminate execution due to display device initialization failure. This application fundamentally solves the problem of UI automation scripts failing to run in a headless environment. Furthermore, through server-side session isolation configuration, it completely resolves session conflicts during concurrent deployment across multiple nodes, enabling parallel UI automation deployment on a large scale, significantly improving deployment success rate and concurrency capacity.

[0132] (4) A deployment status monitoring mechanism that is monitorable and traceable throughout the entire process.

[0133] This application completes the deployment parameter configuration through a front-end visual interface, the back-end obtains the unique Jenkins build number and binds it to this deployment task, each node transmits the deployment progress and deployment status back to the back-end in real time, the back-end associates the corresponding deployment task with the build number and displays it in real time on the front-end, realizing the visual management and control of the entire deployment process.

[0134] This application enables real-time monitoring, anomaly alerts, and full-link traceability of the entire deployment process, from triggering, distribution, execution to completion. The controllability and transparency of the deployment process are greatly improved, and the efficiency of troubleshooting anomalies is increased by more than 90%. At the same time, the visual interface lowers the user's operating threshold, allowing for full-process management of batch deployments without the need for professional operation and maintenance capabilities. The operation is simple and easy to use.

[0135] (5) A highly adaptable and secure large-scale deployment support system.

[0136] This application utilizes an MVC front-end and back-end separation architecture, supporting users to batch configure deployment parameters such as host IPs and software information, and enabling one-click triggering of batch deployments. By configuring OpenSSH Server on each node, it provides a secure and stable file transfer channel between the deployment server and the node, allowing for quick access to new deployment nodes without requiring additional modifications to the nodes.

[0137] This application enables rapid node access and horizontal scaling, meeting the needs of large-scale cluster automated deployment and significantly improving deployment efficiency. At the same time, it ensures the security and stability of file transfer through the OpenSSH protocol, avoiding abnormal risks during the deployment file transfer process and improving the security and reliability of the system.

[0138] Based on the above embodiments, this application provides a software environment configuration device, with reference to... Figure 4 The diagram shown is a schematic of a software environment configuration device provided in an embodiment of this application. The device 400 includes: The acquisition unit 401 is used to acquire deployment information, which includes deployment parameters corresponding to multiple nodes respectively; The generation unit 402 is used to generate multiple deployment orchestration scripts corresponding to the multiple nodes based on the deployment information, wherein the deployment orchestration scripts are used to identify the deployment logic corresponding to the nodes; The sending unit 403 is used to send the plurality of deployment orchestration scripts to the corresponding nodes among the plurality of nodes respectively; Deployment unit 404 is used to trigger the multiple nodes to deploy the software environment based on the corresponding deployment orchestration script, according to the scheduling script.

[0139] As one possible implementation, the deployment unit is specifically used for: Get user interface automation scripts; Based on the scheduling script, graphical sessions corresponding to the multiple nodes are created sequentially via the remote desktop protocol; In the graphical session corresponding to the first node, the deployment orchestration script corresponding to the first node is invoked, and input commands are simulated based on the user interface automation script to deploy the software environment of the first node.

[0140] As one possible implementation, the deployment unit is also used for: Perform configuration operations on the registry to obtain registry information; During the software environment deployment process of the first node, based on the registry information, the graphical session corresponding to the second node is minimized, and the graphical user interface rendering for the second node is continuously executed. The second node is a node different from the first node.

[0141] As one possible implementation, the deployment server has a visual user interface, and the acquisition unit is specifically used for: In response to the configuration operations of deployment parameters for multiple nodes in the visual operation interface, deployment information is obtained.

[0142] As one possible implementation, the visual operation interface includes a progress display interaction entry, and the device further includes a display unit: The acquisition unit is also used to acquire the deployment status corresponding to the plurality of nodes respectively; The display unit is used to display the deployment status of the multiple nodes respectively in response to the triggered operation of the progress display interaction entry.

[0143] As one possible implementation, the plurality of nodes and the deployment server are equipped with a file transfer tool, and the sending unit is specifically used for: The file transfer tool is used to send the multiple deployment orchestration scripts and deployment resources to the corresponding nodes among the multiple nodes.

[0144] Based on the above embodiments, this application provides a computer device, which includes a processor and a memory: The memory is used to store computer programs; The processor is used to execute the above-described software environment deployment method according to the computer program.

[0145] Based on the above embodiments, this application provides a computer-readable storage medium for storing a computer program, which, when executed by a computer device, implements the above-described software environment deployment method.

[0146] Based on the above embodiments, this application provides a computer program product including a computer program, which, when run on a computer device, causes the computer device to execute the above-described software environment deployment method.

[0147] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.

[0148] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A software environment deployment method, characterized in that, The method includes: Obtain deployment information, which includes deployment parameters corresponding to multiple nodes; Based on the deployment information, multiple deployment orchestration scripts corresponding to the multiple nodes are generated, and the deployment orchestration scripts are used to identify the deployment logic corresponding to the nodes; The multiple deployment orchestration scripts are sent to the corresponding nodes among the multiple nodes respectively; Based on the scheduling script, the multiple nodes are triggered to deploy the software environment according to the corresponding deployment orchestration script.

2. The method according to claim 1, characterized in that, The step of triggering the multiple nodes to deploy the software environment based on the corresponding deployment orchestration script, based on the scheduling script, includes: Get user interface automation scripts; Based on the scheduling script, graphical sessions corresponding to the multiple nodes are created through the remote desktop protocol; In the graphical session corresponding to the first node, the deployment orchestration script corresponding to the first node is invoked, and input commands are simulated based on the user interface automation script to deploy the software environment of the first node.

3. The method according to claim 2, characterized in that, After creating graphical sessions corresponding to the multiple nodes respectively based on the scheduling script and via the remote desktop protocol, the method further includes: Perform configuration operations on the registry to obtain registry information; During the software environment deployment process of the first node, based on the registry information, the graphical session corresponding to the second node is minimized, and the graphical user interface rendering for the second node is continuously executed. The second node is a node different from the first node.

4. The method according to claim 1, characterized in that, The deployment server has a visual user interface, and obtaining deployment information includes: In response to the configuration operations of deployment parameters for multiple nodes in the visual operation interface, deployment information is obtained.

5. The method according to claim 4, characterized in that, The visual operation interface includes a progress display interaction entry, and the method further includes: Obtain the deployment status of each of the multiple nodes; In response to the triggered operation of the progress display interaction entry, the deployment status of each of the multiple nodes is displayed.

6. The method according to claim 1, characterized in that, The plurality of nodes and the deployment server are equipped with file transfer tools. Sending the plurality of deployment orchestration scripts to the corresponding nodes among the plurality of nodes includes: The file transfer tool is used to send the multiple deployment orchestration scripts and deployment resources to the corresponding nodes among the multiple nodes.

7. A software environment configuration device, characterized in that, The device includes: An acquisition unit is used to acquire deployment information, which includes deployment parameters corresponding to multiple nodes. The generation unit is configured to generate multiple deployment orchestration scripts corresponding to the multiple nodes based on the deployment information, wherein the deployment orchestration scripts are used to identify the deployment logic corresponding to the nodes; The sending unit is used to send the plurality of deployment orchestration scripts to the corresponding nodes among the plurality of nodes respectively; The deployment unit is used to trigger the multiple nodes to deploy the software environment based on the corresponding deployment orchestration script, according to the scheduling script.

8. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store computer programs; The processor is configured to perform the method according to any one of claims 1-6 according to the computer program.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when executed by a computer device, performs the method described in any one of claims 1-6.

10. A computer program product comprising a computer program, characterized in that, When it is run on a computer device, it causes the computer device to perform the method described in any one of claims 1-6.

Images