CN119065694A - A cross-platform visual server firmware concurrent update method and device - Google Patents
A cross-platform visual server firmware concurrent update method and device Download PDFInfo
- Publication number
- CN119065694A CN119065694A CN202411548113.5A CN202411548113A CN119065694A CN 119065694 A CN119065694 A CN 119065694A CN 202411548113 A CN202411548113 A CN 202411548113A CN 119065694 A CN119065694 A CN 119065694A
- Authority
- CN
- China
- Prior art keywords
- firmware
- platform
- server
- installation package
- build
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 63
- 230000000007 visual effect Effects 0.000 title claims abstract description 50
- 238000009434 installation Methods 0.000 claims abstract description 153
- 238000010276 construction Methods 0.000 claims abstract description 36
- 238000007405 data analysis Methods 0.000 claims abstract description 22
- 238000007726 management method Methods 0.000 claims abstract description 17
- 238000013524 data verification Methods 0.000 claims abstract description 5
- 238000012800 visualization Methods 0.000 claims description 24
- 238000012423 maintenance Methods 0.000 claims description 20
- 238000013515 script Methods 0.000 claims description 18
- 238000004891 communication Methods 0.000 claims description 5
- 230000008676 import Effects 0.000 claims description 4
- 230000001419 dependent effect Effects 0.000 claims description 3
- 238000004806 packaging method and process Methods 0.000 description 9
- 238000011161 development Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000012856 packing Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 1
- 208000033748 Device issues Diseases 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The invention relates to a method and a device for concurrently updating firmware of a cross-platform visual server, wherein an installation package construction module is used for constructing installation packages of different platforms installed on an upper computer based on an Electron frame, the upper computer is used for importing or adding server information and storing the server information in the upper computer, the front end of the device on the upper computer is used for constructing a Session ID and data related to firmware update acquired from a rear end management Session module into a data package and sending the data package to a rear end data analysis module, the data analysis module is used for carrying out data verification and then sending the data package to a task distribution module for distributing tasks to generate corresponding threads, the server is used for executing the update tasks, and the rear end is used for returning the task progress to the front end of the upper computer device in real time and displaying the task progress. The method and the device for concurrently updating the firmware of the cross-platform visual server provide clear and visual operation interfaces, have the capability of concurrently executing tasks in a cross-platform manner, can be used by one-key installation, and simply and efficiently execute the firmware updating tasks.
Description
Technical Field
The invention relates to the field of server operation and maintenance, in particular to a method and a device for concurrently updating cross-platform visual server firmware.
Background
The existing server operation and maintenance generally upgrades the firmware of the server one by one through a Web interface or realizes the upgrade of the firmware of the server through a script writing mode. The operation and maintenance personnel upgrade on the Web interface, and the firmware is upgraded one by one, and when the operation and maintenance personnel need to restart, the operation and maintenance personnel need to restart manually, which is time-consuming and labor-consuming. The mode of executing the firmware update task by the Shell script needs to construct a development environment for executing the Shell script, the development environment needs to be constructed again after the computer is replaced, and complex Shell script codes need to be written to meet the requirement of firmware update, so that the requirement on the programming capability of operation and maintenance personnel is high, the operation is complex, the script files need to be modified each time the update task is executed, and the possibility of causing the program BUG by code modification exists. In addition, the serial execution efficiency of the tasks is low, the Shell script does not have concurrency capability, the tasks for executing the firmware update need to be executed in series, namely, the next task can be executed after one task is executed, the operation is not intuitive and unclear, the whole process needs to be executed at the terminal, the operation is in the form of character strings, the state of the firmware update task cannot be intuitively and clearly seen, the operation is time-consuming and labor-consuming, no corresponding task log exists, and when a problem occurs, the operation needs to take energy time to conduct problem investigation.
Disclosure of Invention
The invention provides a method and a device for concurrently updating cross-platform visual server firmware, which aim to at least solve one of the technical problems in the prior art.
The technical scheme of the invention is a cross-platform visual server firmware concurrency updating method, which is applied to a cross-platform visual server firmware concurrency updating device, the cross-platform visual server firmware concurrency updating device comprises an installation package construction module, a session management module, a data analysis module and a task distribution module, the cross-platform visual server firmware concurrency updating device is installed on an upper computer and also comprises a plurality of servers for updating the firmware, the upper computer is respectively connected with the plurality of servers for updating through network equipment, and the cross-platform visual server firmware concurrency updating method comprises the following steps:
S100, if the upper computer does not have a cross-platform visual server firmware concurrency updating device, the installation package construction module constructs an installation package based on an Electron frame, selects Windows or Linux compiling environment for construction according to the platform architecture of the upper computer, and then installs the constructed installation package on the upper computer;
S200, if the data of the server of the firmware to be updated does not exist, the upper computer needs to import or add the server data, and the server data is stored in the upper computer;
S300, based on a server of firmware to be updated and a firmware type, the front end of the device on the upper computer initiates a request to acquire a Session ID to the back end Session management module, and then the front end sends the acquired Session ID, necessary data related to firmware update and HTTP address of a firmware packet to a data analysis module of the back end;
S400, after the data analysis module receives the data packet, data verification is carried out, the task distribution module is called to carry out task distribution, threads with the corresponding number are generated based on the number of server equipment to be updated, the threads execute the update task, and corresponding firmware is updated on the corresponding server;
s500, when the update task is executed, the upper computer displays the progress of the update task in real time, and displays the success or failure result and details of the firmware update task of each server.
Further, in the step S100,
S110, if the upper computer is a Windows platform, a Windows platform installation package is required to be constructed, a back-end executable file is firstly constructed in a compiling environment under the Windows platform, and then the Windows platform installation package is constructed based on a configuration file of the Windows installation package in the Electron framework;
S120, if the upper computer is a Linux platform, a Linux platform installation package is required to be built, an executable file at the rear end of the device is firstly built in a compiling environment under the Linux platform, and then the Linux platform installation package is built based on a configuration file of the Linux installation package in the Electron frame.
Further, the step S110 includes:
S111, executing npm run build a command to construct an installation package, and specifically executing a node build_python.js & vite build & electron-build, wherein the node build_python.js is a command for constructing an executable file at the rear end of the device, and the vite build & electron-build command is a command for constructing the installation package;
S112, copying the constructed back-end executable file pl_tool.exe to the project catalog tools/servers, and packaging the tools/servers into an installation package at the same time, and calling the front end when the device operates;
S113, an Electron framework constructs a Windows installation package based on a Windows installation package configuration item in a configuration file Electron-builder.json5, wherein the configuration file at least comprises a Windows program icon field, a program execution level field, an installation package construction tool field, a platform architecture field, an installation package name field and a program name field;
s114, generating a Windows installation package.
Further, the step S120 includes:
S121, executing npm run build, namely constructing an installation package by using a linux command, and specifically executing a node build_python.js & vite build &electron-builder-linux, wherein the node build_python.js is a command for constructing a back-end executable file;
s122, copying the built back-end executable file pl_tool to the project catalog tools/servers, and packaging the tools/servers into an installation package at the same time, wherein the front-end is called when the device operates;
S123, an Electron framework constructs a Linux installation package based on a Linux installation package configuration item in a configuration file Electron-builder.json5, wherein the configuration item at least comprises a Linux program icon field, an installation package type field, a platform architecture field, an installation package name field, a program category field, a program description field and a desktop item information field;
S124, generating a corresponding Linux platform installation package.
Further, the step S200 includes:
s210, based on a visual operation interface, the upper computer is used for importing server information in batches in a mode of reading an Excel table or adding the server information stored in the upper computer in a single adding mode;
and S220, the upper computer stores server information in the upper computer in json format, wherein the server information at least comprises IP address information, user name, password and port of the server.
Further, in S300, the firmware types include BIOS firmware, BMC firmware, and CPLD firmware, where the BIOS firmware, BMC firmware, and CPLD firmware correspond to different installation packages respectively;
If the BIOS firmware is selected to be updated, whether the corresponding server is restarted is further selected, if the BMC firmware is selected to be updated, the first mirror image, the second mirror image and the first mirror image and the second mirror image are selected to be updated simultaneously, and after the address of the firmware file is filled, the corresponding BMC firmware is selected to be updated.
Further, the step S400 includes:
s410, the front end of the upper computer login initiates a request to a back end Session management module to acquire a Session ID, and the front end and the back end of the upper computer device communicate based on the Session ID;
S420, after acquiring a Session ID, the upper computer sends the corresponding data packet to a data analysis module, and the data analysis module determines a thread for actually executing a task according to a module name field module_name and a task name field task_name in the data packet and then sends a configuration list config_list and a variable sil containing a Session ID value to the task distribution module;
S430, the task distribution module circulates the configuration list config_list, generates one thread once every circulation, and transmits one element in the variable sed containing the Session ID value, the data sending method send_data and the configuration list config_list to the corresponding thread.
Further, the data sending method send_data is used for sending data to the front end of the upper computer by the task distribution module;
One element in the configuration list config_list at least comprises a device IP address, a device port, a user password, a user name, a machine model project_name and a firmware package file address link which needs to be upgraded, and whether to restart the machine is_reboot.
Further, the step S500 includes:
S510, creating a virtual environment in a compiling environment of a corresponding platform, and installing a dependency library required by a back end in the virtual environment;
S520, the program traverses the back-end service code catalog to acquire a corresponding code module and generate a spec file;
S530, based on spec files, a construction tool PYINSTALLER of a back-end code executable file generates executable files of corresponding platforms according to different platforms;
S540, constructing scripts of a back-end executable file, namely, a build_python_for_ps.ps1, a build_python_for_sh or a build_python_for_linux.sh, copying the generated binary executable file of the corresponding platform to a tools/server directory, packaging the binary executable file to a designated position by a to-be-installed package construction module, and calling the corresponding back-end executable file by the front end of the device after the installation package is installed;
S550, returning the task progress and the successful or failed update information to the upper computer in real time.
The invention further provides a cross-platform visual server firmware concurrency updating device, which is used for executing the cross-platform visual server firmware concurrency updating method, and the cross-platform visual server firmware concurrency updating device is arranged on an upper computer and comprises the following steps:
the installation package construction module is used for generating an installation package of the Windows platform or the Linux platform;
The Session management module is used for generating Session ID of the front-end and back-end communication of the device, creating and destroying the Session and managing the whole Session life cycle;
the data analysis module is used for analyzing the data issued by the operation and maintenance personnel at the front end of the device, and the analyzed data is forwarded to the task distribution module;
The task distribution module is connected with the data analysis module, and after distributing the task to the corresponding threads, each thread is connected with a server to be updated by the firmware based on the HTTP protocol, and the corresponding server firmware concurrent update is realized by sending the HTTP request.
The beneficial effects of the invention are as follows:
The method and the device for concurrently updating the firmware of the cross-platform visual server provide a clear and visual operation interface, have the capability of concurrently executing tasks in a cross-platform manner, can be used by one-key installation, and simply and efficiently execute the firmware updating task.
Drawings
FIG. 1 is an overall flow chart of a method for concurrently updating cross-platform visualization server firmware.
FIG. 2 is a flowchart of the installation package construction steps in a cross-platform visualization server firmware concurrent update method.
FIG. 3 is a flow chart of back-end executable file construction in a cross-platform visualization server firmware concurrent update method.
Fig. 4 is a schematic diagram of a communication connection between a front end and a back end of a method for concurrently updating firmware of a cross-platform visualization server.
Fig. 5 is a schematic diagram of a communication flow between the front end and the back end of a method for concurrently updating firmware of a cross-platform visualization server.
FIG. 6 is a schematic diagram of the update progress, result details and BIOS firmware package HTTP address of the cross-platform visual server firmware concurrent update method in a BIOS firmware update.
Detailed Description
The conception, specific structure, and technical effects produced by the present application will be clearly and completely described below with reference to the embodiments and the drawings to fully understand the objects, aspects, and effects of the present application. It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other.
It should be noted that, unless otherwise specified, when a feature is referred to as being "fixed" or "connected" to another feature, it may be directly or indirectly fixed or connected to the other feature. Further, the descriptions of the upper, lower, left, right, top, bottom, etc. used in the present invention are merely with respect to the mutual positional relationship of the respective constituent elements of the present invention in the drawings.
Furthermore, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the description presented herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and/or" as used herein includes any combination of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in this disclosure to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element of the same type from another. For example, a first element could also be termed a second element, and, similarly, a second element could also be termed a first element, without departing from the scope of the present disclosure.
Referring to fig. 1 to 6, in some embodiments, the technical solution of the present invention is a cross-platform visual server firmware concurrency update method, which is applied to a cross-platform visual server firmware concurrency update device, where the cross-platform visual server firmware concurrency update device includes an installation package construction module, a session management module, a data analysis module, and a task distribution module, and the cross-platform visual server firmware concurrency update device is installed on a host computer, and further includes a plurality of servers to be updated, where the host computer is connected with a plurality of servers to be updated (typically including a combination of one or more of a BMC firmware, a BIOS firmware, and a CPLD firmware) through a network device, and referring to fig. 1, the cross-platform visual server firmware concurrency update method includes the following steps:
S100, if the upper computer does not have a cross-platform visual server firmware concurrency updating device, the installation package construction module constructs an installation package based on an Electron frame, selects Windows or Linux compiling environment for construction according to the platform architecture of the upper computer, and then installs the constructed installation package on the upper computer;
S200, if the data of the server of the firmware to be updated does not exist, the upper computer needs to import or add the server data, and the server data is stored in the upper computer;
S300, based on a server of firmware to be updated and a firmware type, the front end of the device on the upper computer initiates a request to acquire a Session ID to the back end Session management module, and then the front end sends the acquired Session ID, necessary data related to firmware update and HTTP address of a firmware packet to a data analysis module of the back end;
S400, after the data analysis module receives the data packet, data verification is carried out, the task distribution module is called to carry out task distribution, threads with the corresponding number are generated based on the number of server equipment to be updated, the threads execute the update task, and corresponding firmware is updated on the corresponding server;
s500, when the update task is executed, the upper computer displays the progress of the update task in real time, and displays the success or failure result and details of the firmware update task of each server.
The beneficial effects of the invention are as follows:
The method and the device for concurrently updating the firmware of the cross-platform visual server provide a clear and visual operation interface, have the capability of concurrently executing tasks in a cross-platform manner, can be used by one-key installation, and simply and efficiently execute the firmware updating task.
The method and the device for concurrently updating the firmware of the cross-platform visual server have the cross-platform capability, meet the requirements of using different operating systems, and realize the cross-platform operating device because the internal operation and maintenance of a company can only use a certain operating system, such as a domestic Linux operating system only using an ARM architecture.
The method and the device for concurrently updating the firmware of the cross-platform visual server are simple and efficient in operation, can be used by installing only one computer which can be operated, are intuitive and clear in operation interface, and can complete the firmware updating task only by operating and maintaining personnel at one point of the interface point.
The method and the device for concurrently updating the cross-platform visual server firmware save a great deal of energy and time for operation and maintenance personnel to concurrently execute tasks, and once the device issues the update tasks, all the tasks are concurrently executed, so that a great deal of time and energy cost are saved, and the operation and maintenance efficiency is greatly improved.
The firmware update task executed by the cross-platform visual server firmware concurrent update method and device is rich, and the device can update BMC, BIOS, CPLD firmware so as to meet the daily work demands of operation and maintenance personnel.
The method and the device for concurrently updating the cross-platform visual server firmware have lower requirements on programming capability of operation and maintenance personnel, and can directly operate the device to execute the firmware updating task only by looking at the device document once.
The cross-platform visual server firmware concurrent updating method and the cross-platform visual server firmware concurrent updating device have complete operation records in the task execution process, so that operation and maintenance personnel can conveniently check problems when executing tasks.
Specifically, the method and the device for concurrently updating the firmware of the cross-platform visual server have the cross-platform capability, and an installation package for a device program running on a Windows/Linux platform is constructed based on an open source frame Electron for constructing a cross-platform desktop application program. The device has the cross-platform capability, and is specifically realized by modifying the configuration file of an Electron compiling construction installation package, executing corresponding construction commands on different platforms to generate the installation package of the corresponding platform, and integrating a binary package executable at the back end into the installation package to realize the cross-platform capability, wherein the back end framework for concurrent tasks is also cross-platform and an automatic installation package construction tool is executed.
In the step S500, the cross-platform visual server firmware concurrency updating device has a visual capability, and the browser chrome rendering engine is combined based on the Electron, so that the device can write a front-end code by using the front-end frame Vue, and the visual capability of the device is realized.
In a specific embodiment, the following update steps are generally included:
1) The upper computer updates the server firmware under the Windows platform, taking BIOS as an example,
(1) The installation package of the device under the Windows platform is constructed in the compiling environment, and the following installation package construction process is referred to,
electron-builder version=24.6.4 os=10.0.22631
loaded configuration file=D:\coding\XXX-TOOL\electron-builder.json5
writing effective config file=release\builder-effective-config.yaml
packaging platform=win32 arch=x64 electron=28.1.4 appOutDir=release\win-unpacked
building target=nsis file=release\XXXManagementTool_Setup_1.1.1.exe archs=x64 perMachine=true
building block map blockMapFile=release\XXXManagementTool_Setup_1.1.1.exe.blockmap
After the installation package construction module completes construction in the compiling environment, a Windows platform installation package ending with exe is generated;
(2) Taking out an installation package file with the suffix exe, installing the installation package on an upper computer, generating an icon of the device on a desktop, and double-clicking the icon operation device;
(3) The newly built equipment can be imported or newly built into a single equipment according to Excel;
(4) After the addition of the device is completed, selecting the device needing to update the BIOS firmware;
(5) After the equipment is selected, selecting the updated firmware type as BIOS, filling the HTTP address of the firmware file to be updated, and clicking the update;
(6) At the time of firmware update, details of task progress, update results, and update results can be seen. Referring to fig. 6, an upgrade result of a BIOS is shown, in which HTTP address of a firmware package, firmware upgrade progress, upgrade status, upgrade result, and upgrade details that can be viewed by clicking are shown.
2) The upper computer is basically consistent with the Windows platform in terms of firmware update under the Linux platform, taking the Ubuntu system under the RAM architecture as an example, updating the BIOS,
(1) Building an installation package of a device under a Linux platform in a compiling environment, referring to the following installation package building process,
electron-builder version=24.13.3 os=5.15.0-117-generic
loaded configuration file=/home/tree/POWER-TOOL/electron-builder.json5
writing effective config file=release/builder-effective-config.yaml
packaging platform=linux arch=x64 electron=28.3.3 appOutDir=release/linux-unpacked
building target=deb arch=x64
file=release/PowerleaderManagementTool_1.1.1_amd64.deb
packaging platform=linux arch=arm64 electron=28.3.3 appOutDir=release/linux-arm64-unpacked
building target=deb arch=arm64
file=release/PowerleaderManagementTool_1.1.1_arm64.deb
building target=rpm arch=x64
file=release/PowerleaderManagementTool_1.1.1_x86_64.rpm
building target=rpm arch=arm64
file=release/PowerleaderManagementTool_1.1.1_aarch64.rpm
After the build module completes the build, four installation packages ending with amd64.Deb, arm64.Deb, x86_64.Rpm, aarch64.Rpm will be generated;
(2) Taking out an installation package file with a suffix of arm64.Deb, installing the installation package on an upper computer, generating an icon of a device on a desktop, and operating the device by double clicking the icon;
(3) The newly built equipment can be imported or newly built into a single equipment according to Excel;
(4) After the addition of the device is completed, selecting the device needing to update the BIOS firmware;
(5) After the equipment is selected, selecting the updated firmware type as BIOS, filling the HTTP address of the firmware file to be updated, and clicking the update;
(6) At the time of firmware update, details of task progress, update results, and update results can be seen.
Further, referring to fig. 2 and 3, in the step S100,
S110, if the upper computer is a Windows platform, a Windows platform installation package is required to be constructed, a back-end executable file is firstly constructed in a compiling environment under the Windows platform, and then the Windows platform installation package is constructed based on a configuration file of the Windows installation package in the Electron framework;
S120, if the upper computer is a Linux platform, a Linux platform installation package is required to be built, an executable file at the rear end of the device is firstly built in a compiling environment under the Linux platform, and then the Linux platform installation package is built based on a configuration file of the Linux installation package in the Electron frame.
Specifically, referring to fig. 2 and 3, the construction of different platform installation packages needs to be performed on the corresponding platform, for example, the Windows platform installation package needs to be performed in a Windows compiling environment, and the Linux platform installation package needs to be performed in a Linux compiling environment.
Further, referring to fig. 2, the step S110 includes:
S111, executing npm run build a command to construct an installation package, and specifically executing a node build_python.js & vite build & electron-build, wherein the node build_python.js is a command for constructing an executable file at the rear end of the device, and the vite build & electron-build command is a command for constructing the installation package;
S112, copying the constructed back-end executable file pl_tool.exe to the project catalog tools/servers, and packaging the tools/servers into an installation package at the same time, and calling the front end when the device operates;
S113, an Electron framework constructs a Windows installation package based on a Windows installation package configuration item in a configuration file Electron-builder.json5, wherein the configuration file at least comprises a Windows program icon field, a program execution level field, an installation package construction tool field, a platform architecture field, an installation package name field and a program name field;
s114, generating a Windows installation package.
In a specific embodiment, if the Windows platform installation package is constructed, a npm run build command is executed to construct, the command actually executes a node build_python.js & vite build & & electronics-builder, wherein the node build_python.js is a command for constructing a back-end code as an executable file, then the constructed executable file pl_tool.exe is copied under an item catalog tools/servers, then the tools/servers are packed into an installation package when the installation package is constructed, and when the program runs, the front-end call is made, and the vite build & electronics-builder command is a command for constructing the platform installation package.
After the construction of the executable file of the back-end code is completed, an Electron starts to construct an installation package of the Windows platform based on a configuration file Electron-builder.json5, wherein a configuration file part is as follows, an icon field is a specific program icon, a target field in a target field is a construction tool for specifying the installation package under Windows, an arch field specifies a platform architecture, and ARTIFACTNAME and executableName fields respectively specify an installation package name and a program name:
"win": {
"icon": "public/favicon.ico",
"requestedExecutionLevel": "requireAdministrator",
"target": [
{ "target": "nsis",
"arch": [
"x64" ]
}
],
"artifactName": "xxx_Setup_${version}.${ext}",
"executableName": "xxx"
},
after the execution of the build installation package command is completed, a command, for example, named as
XXXManagementTool _setup_1.1.1.Exe, and the construction of the Windows platform installation package is completed. An executable file named xxxmanagement tool.exe, for example, appears after installation.
Further, referring to fig. 3, the step S120 includes:
S121, executing npm run build, namely constructing an installation package by using a linux command, and specifically executing a node build_python.js & vite build &electron-builder-linux, wherein the node build_python.js is a command for constructing a back-end executable file;
s122, copying the built back-end executable file pl_tool to the project catalog tools/servers, and packaging the tools/servers into an installation package at the same time, wherein the front-end is called when the device operates;
S123, an Electron framework constructs a Linux installation package based on a Linux installation package configuration item in a configuration file Electron-builder.json5, wherein the configuration item at least comprises a Linux program icon field, an installation package type field, a platform architecture field, an installation package name field, a program category field, a program description field and a desktop item information field;
S124, generating a corresponding Linux platform installation package.
Specifically, in step S123, the installation package related field is set according to the need, the deban installation package type DEB of the deban series and the Red Hat series RPM installation package type are set, the platform architecture field is also set according to the need, and the settable options include the X64 platform architecture and the ARM64 platform architecture.
In a specific embodiment, if the Linux platform is used for constructing the installation package, the construction process is similar to that of the Windows platform, the installation package is constructed in the Linux environment, a Linux command is executed npm run build, the actual executed command is a node build_python.js & & vite build & & electron-builder-Linux, wherein the node build_python.js is a command for constructing a back end code as an executable file, the constructed executable file pl_tool is copied to the project catalog under the tools/servers, the tools/servers are packed into the installation package when the installation package is constructed, and the front end call is executed when the program is executed, and then the Linux electron-builder-Linux command is executed vite build.
After the construction of the executable file of the back-end code is completed, an Electron starts to construct an installation package of the Linux platform based on a configuration file Electron-builder.json5, wherein a configuration file part comprises a program icon specified by an icon field, an installation package type packed by a target specified in a target field is a Debian series installation package type deb and a Red Hat series installation package type rpm respectively, a platform architecture is x64 and arm64, ARTIFACTNAME and executableName are an installation package name and a program name respectively, a category field specifies a program category, a field description specifies a program description, and a desktop field is Linux desktop item information:
"linux": {
"icon": "public/icons",
"target": [
{ "target": "deb",
"arch": [
"x64",
"arm64"
]
},
{ "target": "rpm",
"arch": [
"x64",
"arm64"
]
}
],
"artifactName": "PowerleaderManagementTool_${version}_${arch}.${ext}",
"executableName": "PowerleaderManagementTool",
"category": "Utility",
"description": "Powerleader Management Tool",
"desktop": {
"Name": "PowerleaderManagementTool",
"Comment": "Powerleader Management Tool",
"Categories": "Utility;"
} }
and the installation package construction task is completed, four Linux installation packages are generated, and the construction of the Linux platform installation packages is completed. Different installation packages are installed according to different types of operating systems on the upper computer,
The four installation packages are respectively:
XXXManagementTool_1.1.1_aarch64.rpm、
XXXManagementTool_1.1.1_arm64.deb、
XXXManagementTool _1.1.1_amd64.Deb and
XXXManagementTool_1.1.1_x86_64.rpm。
When the back-end executable file is constructed, the installation package construction module can uniformly package all the dependency packages and the resource packages of the back-end into the binary file, so that the trouble of resource configuration is omitted, and the mode is a basis for device installation and use. The back end is constructed and executed by a node build_python.js command, and the general logic of command execution is to execute a corresponding constructed back end executable script according to a constructed platform, if the command is a Linux platform, execute a build_python_for_linux.sh script, and execute the build_python_for_ps.ps1 or the build_python_for_sh.sh script according to different terminals on the Windows platform.
The build_python. Js content is as follows:
const { execSync } = require('child_process');
const os = require('os');
const isWindows = os.platform() === 'win32';
const isLinux = os.platform() === 'linux';
const isGitBash = process.env.MSYSTEM === 'MINGW64' || process.env.MSYSTEM === 'MINGW32';
try {
if (isLinux) {
Executing Bash script if it is Linux platform
execSync('bash build_python_for_linux.sh', { stdio: 'inherit' });
} else if (isWindows) {
if (isGitBash) {
Executing a Bash script if it is Git Bash on Windows
execSync('bash build_python_for_sh.sh', { stdio: 'inherit' });
} else {
Executing PowerShell script if Windows but not Git Bash
execSync('powershell -Command "& { Set-ExecutionPolicy Bypass -Scope Process -Force }; .\\build_python_for_ps.ps1"', { stdio: 'inherit' });
}
} else {
console.error('Unsupported operating system');
process.exit(1);
}
} catch (error) {
console.error('Error running script:', error);
process.exit(1);
}
Build_python_for ps. ps1 file:
# virtual Environment directory
$ENV_NAME = "myenv"
# Enter python project
cd "socketio_server"
# Determine if virtual Environment exists
if (-not (Test-Path $ENV_NAME)) {
Write-Host -ForegroundColor Green "Creating virtual environment..."
python -m venv $ENV_NAME
Write-Host -ForegroundColor Green "The virtual environment is created"
}
# Active virtual Environment
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
. .\$ENV_NAME\Scripts\Activate
Dependency bag for # installation
Write-Host -ForegroundColor Green "Install python dependencies in a virtual environment..."
pip install -r requirements.txt > $null
Write-Host -ForegroundColor Green "The virtual environment python dependency installation is completed"
# Generating document
cd "docs"
sphinx-build -b html source\ build\ > $null
# Packing
cd ..
cd "build"
python setup.py
The # server directory may not exist
if (-not (Test-Path "../../tools/server")) {
New-Item -ItemType Directory -Path "../../tools/server/"
}
Copy # to server directory
Copy-Item -Recurse "dist\pl_tool.exe" "../../tools/server/"
Write-Host "`nPython Project Compiled Successfully!"
# Exit virtual Environment
deactivate
Build_python_for_sh file
#!/bin/bash
# Virtual Environment directory
ENV_NAME="myenv"
# Enter python project
cd socketio_server
# Determine if virtual Environment exists
If [ | -d "$ { ENV_NAME }" ], the then echo-e "\e [32m is creating a virtual environment..A.. The then-m venv $ { ENV_NAME }, echo-e" \e [32m virtual environment is created \e [0m\n "; fi
# Active virtual Environment
source ${ENV_NAME}/Scripts/activate
Dependency bag for # installation
Echo-e "\e [32m virtual environment installation python dependency..\e [0m\n ]"
pip install -r requirements.txt 1> /dev/null
Echo-e [32m virtual environment python dependent installation completion \e [0m\n ] "
# Generating document
cd docs
sphinx-build -b html source/ build/ 1> /dev/null
# Packing
cd -
cd build
python setup.py
The # server directory may not exist
if [ ! -d "../../tools/server" ]; then mkdir ../../tools/server/; fi
Copy # to serevr directory
cp -r dist/pl_tool.exe ../../tools/server/
echo -e "\n\e[32mPython Project Compiled Successfully!\e[0m\n"
# Exit virtual Environment
deactivate
Build_python_for a _linux.sh file:
#!/bin/bash
# virtual Environment directory
ENV_NAME="myenv"
# Enter python project
cd socketio_server
# Determine if virtual Environment exists
If [ | -d "$ { ENV_NAME }" ], the then echo-e "\e [32m is creating a virtual environment..A.. The then-m venv $ { ENV_NAME }, echo-e" \e [32m virtual environment is created \e [0m\n "; fi
# Active virtual Environment
source ${ENV_NAME}/bin/activate
Dependency bag for # installation
Echo-e "\e [32m virtual environment installation python dependency..\e [0m\n ]"
pip install -r requirements.txt 1> /dev/null
Echo-e [32m virtual environment python dependent installation completion \e [0m\n ] "
# Generating document
cd docs
sphinx-build -b html source/ build/ 1> /dev/null
# Packing
cd -
cd build
python setup.py
The # server directory may not exist
if [ ! -d "../../tools/server" ]; then mkdir ../../tools/server/; fi
Copy # to serevr directory
cp -r dist/pl_tool ../../tools/server/
echo -e "\n\e[32mPython Project Compiled Successfully!\e[0m\n"
# Exit virtual Environment
deactivate
Further, the step S200 includes:
s210, based on a visual operation interface, the upper computer is used for importing server information in batches in a mode of reading an Excel table or adding the server information stored in the upper computer in a single adding mode;
and S220, the upper computer stores server information in the upper computer in json format, wherein the server information at least comprises IP address information, user name, password and port of the server.
Specifically, after the device is installed, when a user uses the device for the first time, the device needs to be added, the device is realized by importing an Excel table containing a plurality of pieces of device IP information or separately creating one device, and then the device can be added or deleted. And if the equipment is successfully added, the device returns the information of the corresponding equipment and stores the information into a local json file. When executing the task, the device can read the json file, display the corresponding equipment IP address on the page, and the operation and maintenance personnel execute the firmware update task of the equipment corresponding to the IP address by checking the IP address.
Further, in S300, the firmware types include BIOS firmware, BMC firmware, and CPLD firmware, where the BIOS firmware, BMC firmware, and CPLD firmware correspond to different installation packages respectively;
If the BIOS firmware is selected to be updated, whether the corresponding server is restarted is further selected, if the BMC firmware is selected to be updated, the first mirror image, the second mirror image and the first mirror image and the second mirror image are selected to be updated simultaneously, and after the address of the firmware file is filled, the corresponding BMC firmware is selected to be updated.
Specifically, the BMC has two chips on the motherboard, and each chip has a firmware, mainly for improving reliability and manageability, and generally uses a first BMC chip, and the other is used as a spare. When updating, the firmware of the first chip can be updated, or the firmware of the second chip (standby) can be updated, or all the updates, namely the first mirror image and the second mirror image are updated simultaneously, can be understood as firmware files according to the requirement.
Further, referring to fig. 4 and 5, the step S400 includes:
s410, the front end of the upper computer login initiates a request to a back end Session management module to acquire a Session ID, and the front end and the back end of the upper computer device communicate based on the Session ID;
S420, after acquiring a Session ID, the upper computer sends the corresponding data packet to a data analysis module, and the data analysis module determines a thread for actually executing a task according to a module name field module_name and a task name field task_name in the data packet and then sends a configuration list config_list and a variable sil containing a Session ID value to the task distribution module;
S430, the task distribution module circulates the configuration list config_list, generates one thread once every circulation, and transmits one element in the variable sed containing the Session ID value, the data sending method send_data and the configuration list config_list to the corresponding thread.
In a specific embodiment, after the updated firmware is selected to update the firmware, the front-end configuration data is sent to the back-end service, after the back-end receives the data, the back-end service performs simple data verification, starts to distribute tasks, generates a corresponding number of threads according to the number of devices, and starts to execute the update tasks.
Further, referring to fig. 4 and 5, the data transmission method send_data is used for the task distribution module to transmit data to the front end of the upper computer;
one element in the configuration list config_list at least comprises a device IP address, a device port, a user password, a user name, a machine model project_name, a firmware package file address link to be upgraded and whether to restart the machine is_reboot.
Specifically, the cross-platform visual server firmware concurrency updating method has concurrency capability, and based on a programming language Python and a technical stack thereof, a back-end service is constructed, so that the device has the capability of executing tasks concurrently. The method comprises the steps that a front end of a device obtains a Session ID (identity) from a back end Session module, the front end is connected with a back end service through the Session ID, data is issued, after the front end is connected with the back end service, corresponding firmware updated data and the Session ID are issued to the back end, a data analysis module determines a thread for actually executing a task according to a module_name and a task_name in the issued data, then the config_list and the sild (variable containing the Session ID value) are transmitted to a task distribution module, the task distribution module circulates the config_list, one thread is generated once in each circulation, one element in the sild, the send_data method and the config_list is transmitted to the thread, and then the thread starts executing the task. The send_data method is used for sending data from the back end to the front end, and one element in the config_list comprises a device ip, a device port, a user password, a user name, a machine model project_name and a firmware package file address link to be upgraded, and whether to restart the machine is_reboot or not.
Taking update bios as an example, the data issued is as follows:
{ "module_name": "model.update_service.update_bios",
"sid": sid,
"task_name": "TaskManager",
"config_list": [{
"ip": "192.168.44.38",
"port": "443",
"username": "admin",
"password": "Admin123.",
"project_name": "XXX",
"link":"https://test.hpm",
"is_reboot": false,},
{"ip": "192.168.44.53",
"port": "443",
"username": "admin",
"password": "Admin123.",
"project_name": "XXX",
"link":"https://test.hpm",
"is_reboot": false,},
] }。
After the task distribution module distributes each task to a corresponding thread, the thread starts to execute the corresponding task, and then each thread sends the execution progress, the result and the record operation log to the front end, and the front end is responsible for displaying the data sent by the back end. The transmitted data is that the thread calls send_data (sed, data), and transmits the data to the front end, wherein sed is session id for the front end to identify the connection, data is specific data in the execution process, wherein type is the returned task execution progress when 1, progress is specific progress, the last execution result when 0, message is the result description of the execution task, result is the execution success or failure, success when 0, failure when 1, and the front end renders the data according to the returned data and presents the data as visual data to the operation and maintenance personnel.
{"ip":"ip",
"port":"port",
"type":1,
"progress":50
"message": message,
"result": 0
}
Further, the step S500 includes:
S510, creating a virtual environment in a compiling environment of a corresponding platform, and installing a dependency library required by a back end in the virtual environment;
S520, the program traverses the back-end service code catalog to acquire a corresponding code module and generate a spec file;
S530, based on spec files, a construction tool PYINSTALLER of a back-end code executable file generates executable files of corresponding platforms according to different platforms;
S540, constructing a script build_python_for_ps.ps1, build_python_for_sh or build_python_for_linux.sh of a back-end executable file, copying the generated executable file of a corresponding platform to a tools/server directory, packaging the executable file to a designated position by a to-be-installed package construction module, and calling the back-end executable file of the corresponding platform by a front-end program of the device after installation of an installation package;
S550, returning the task progress and the successful or failed update information to the upper computer in real time.
Specifically, in step S550, the thread may call send_data (sed, data), and send the data to the front end, where sed is a Session ID for the front end to identify the connection of this time, data is specific data in the execution process, where type is a task execution progress returned when 1, progress is a specific progress, type is a final execution result when 0, message is a result description of the execution task, result is execution success or failure, task failure is executed when 0, and the front end renders the data according to the returned data as visual data to be presented to the operation and maintenance personnel.
{"ip":"ip",
"port":"port",
"type":1,
"progress":50
"message": message,
"result": 0}
The invention further provides a cross-platform visual server firmware concurrency updating device, which is used for executing the cross-platform visual server firmware concurrency updating method, and the cross-platform visual server firmware concurrency updating device is arranged on an upper computer and comprises the following steps:
the installation package construction module is used for generating an installation package of the Windows platform or the Linux platform;
The Session management module is used for generating Session ID of the front-end and back-end communication of the device, creating and destroying the Session and managing the whole Session life cycle;
the data analysis module is used for analyzing the data issued by the operation and maintenance personnel at the front end of the device, and the analyzed data is forwarded to the task distribution module;
The task distribution module is connected with the data analysis module, and after distributing the task to the corresponding threads, each thread is connected with a server to be updated by the firmware based on the HTTP protocol, and the corresponding server firmware concurrent update is realized by sending the HTTP request.
Some of the technical terms appearing herein have the following meanings:
And concurrently, executing the tasks simultaneously.
And (5) performing serial tasks in sequence.
Firmware, which is a special type of software embedded in server hardware that provides the basic control and operational functions of the hardware, is common firmware such as BMC, BIOS, and CPLD firmware.
The BMC is a special microcontroller and is responsible for remote management and monitoring of the server, and the BMC is provided with a corresponding Web interface and a corresponding management background for operation and maintenance/development personnel.
BIOS is the first software program run at the start-up of the computer.
CPLD is a programmable logic device for implementing specific hardware functions.
ARM/X86 is a different bottom layer architecture of computer hardware, and the different hardware architectures run corresponding operating systems.
DEB/RPM: the most common mainstream installation package format in Linux release, · DEB format is mainly a Debian series operation installation package, · RPM format is mainly a Red Hat series system installation package.
The front end of the device is provided with a visual operation interface, related data for issuing firmware update, a result and progress of the firmware update are received and are rendered into visual data for operation and maintenance personnel to check.
And the back end of the device is used for receiving the data issued by the front end, executing the corresponding task, returning the task progress and the result to the front end and the like.
The present invention is not limited to the above embodiments, but can be modified, equivalent, improved, etc. by the same means to achieve the technical effects of the present invention, which are included in the spirit and principle of the present disclosure. Are intended to fall within the scope of the present invention. Various modifications and variations are possible in the technical solution and/or in the embodiments within the scope of the invention.
Claims (10)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411548113.5A CN119065694A (en) | 2024-11-01 | 2024-11-01 | A cross-platform visual server firmware concurrent update method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411548113.5A CN119065694A (en) | 2024-11-01 | 2024-11-01 | A cross-platform visual server firmware concurrent update method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN119065694A true CN119065694A (en) | 2024-12-03 |
Family
ID=93632404
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202411548113.5A Pending CN119065694A (en) | 2024-11-01 | 2024-11-01 | A cross-platform visual server firmware concurrent update method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119065694A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN119311296A (en) * | 2024-12-10 | 2025-01-14 | 苏州元脑智能科技有限公司 | Concurrent software upgrading method and device |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110457217A (en) * | 2019-07-31 | 2019-11-15 | 上海赫千电子科技有限公司 | A cross-platform MCU debugging device |
| CN113467801A (en) * | 2021-06-11 | 2021-10-01 | 浪潮电子信息产业股份有限公司 | BMC firmware application updating method, BMC, system and storage medium |
-
2024
- 2024-11-01 CN CN202411548113.5A patent/CN119065694A/en active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110457217A (en) * | 2019-07-31 | 2019-11-15 | 上海赫千电子科技有限公司 | A cross-platform MCU debugging device |
| CN113467801A (en) * | 2021-06-11 | 2021-10-01 | 浪潮电子信息产业股份有限公司 | BMC firmware application updating method, BMC, system and storage medium |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN119311296A (en) * | 2024-12-10 | 2025-01-14 | 苏州元脑智能科技有限公司 | Concurrent software upgrading method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8938523B2 (en) | System and method for deploying and maintaining software applications | |
| JP5362974B2 (en) | How to use virtualization software for shipping software products | |
| US7937455B2 (en) | Methods and systems for modifying nodes in a cluster environment | |
| US8127268B2 (en) | Server testing framework | |
| US8464246B2 (en) | Automation of mainframe software deployment | |
| US6871223B2 (en) | System and method for agent reporting in to server | |
| US20130232245A1 (en) | Automation for virtualized it environments | |
| CN103927260B (en) | A kind of telecommunication apparatus method of testing and system | |
| US20080288622A1 (en) | Managing Server Farms | |
| US20170220324A1 (en) | Data communication accelerator system | |
| CN113127098A (en) | Micro-service architecture-based application program creating method and related equipment | |
| CN112596779B (en) | Method, device, equipment and storage medium for generating dependency packages compatible with dual versions | |
| CN119065694A (en) | A cross-platform visual server firmware concurrent update method and device | |
| CN115291946A (en) | Hongmong system transplanting method, device, electronic equipment and readable medium | |
| CN115220863A (en) | Operation and maintenance method and device for container application, computer equipment and storage medium | |
| CN117573111A (en) | Micro-service deployment method, device, equipment and storage medium | |
| CN116243929A (en) | Automatic code package release system | |
| US11314500B2 (en) | System and method for modularizing update environment in life cycle manager | |
| Cisco | Release Notes for Cisco Element Management Framework v3.2 | |
| WO2022140376A1 (en) | Software defined build infrastructure for hybrid, virtualized and native build environments | |
| US20240192974A1 (en) | Simulation of one or more pipeline jobs in a software deployment pipeline | |
| CN117873650B (en) | Real-time running environment generation system, method, computer device and storage medium | |
| Benton et al. | Wallaby: A scalable semantic configuration service for grids and clouds | |
| Ruiz et al. | Embedded Systems | |
| PR | CHRISTIAN DEBOVI PAIM DE OLIVEIRA |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |