Software installation package construction method, system, device, equipment and storage medium
By using an automated software installer building method and detailed build configuration parameters and preset host manifest files, the problems of low build efficiency and poor accuracy under multi-CPU architecture and multi-operating system combinations are solved, achieving efficient and accurate software installer building.
Patent Information
- Application Number
- CN202411187410.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-28
- Publication Date
- 2026-01-23
- Estimated Expiration
- 2044-08-28
AI Technical Summary
In test application verification environments with multi-CPU architecture and multiple operating system combinations, existing technologies have low efficiency and accuracy in building software installation packages, and their reliance on manual intervention leads to low building efficiency and frequent errors.
By obtaining the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built, detailed build configuration parameters are generated, and the build task is sent to the target remote host using a preset host manifest file, thereby realizing the automated synchronous build of the software installation package and avoiding manual intervention.
It improves the efficiency and accuracy of software installation package building, reduces labor costs, enables synchronous building under multiple operating systems and CPU architecture combinations, and avoids human error.
Smart Images

Figure CN118708235B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software compilation technology, and in particular to methods, systems, apparatus, devices and storage media for constructing software installation packages. Background Technology
[0002] In test application verification environments with multiple CPU architectures and operating system combinations, since there are many possible combinations of CPU architectures and operating systems, it is often necessary to create software installation packages for the test application from one or more branches of a source code repository for multiple combinations of CPU architectures and operating systems.
[0003] In related technologies, when building a software installation package for a test application for a combination of multiple CPU architectures and operating systems, it is usually necessary to first confirm whether the operating system currently installed on the host is compatible with the target. Then, after logging into the operating system, the code is cloned from the source code repository according to the software source code repository and branch where the software installation package is located. At the same time, the necessary build dependency packages are installed, and the necessary source code compressed package is created before the compilation and build work is carried out. After the compilation is successfully completed, relevant information such as the software installation package and build logs located in the parent directory of the source code are collected.
[0004] However, when using the above method to build the software installation package for the test application, there are problems with low build efficiency and accuracy. Summary of the Invention
[0005] This application aims to at least solve the technical problems existing in the prior art. To this end, the first aspect of this application proposes a method for constructing a software installation package, applied to a control client, the method comprising:
[0006] Obtain the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; among which, the basic information includes package name information, version number information, software repository information, software repository branch information and dependency package list information, and there is a corresponding relationship between the combination of various operating systems and CPU architectures and the specific configuration values of the software installation package to be built;
[0007] Based on the general build configuration parameters and the specific configuration values of the software installation package to be built, generate detailed build configuration parameters for the software installation package to be built;
[0008] Based on detailed build configuration parameters, a build task is sent to the target remote host in the preset host manifest file, and the target software compressed package returned by the target remote host is obtained.
[0009] The target software package is copied and decompressed to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software package.
[0010] In one possible implementation, the method further includes:
[0011] Retrieve remote host information corresponding to each remote host in the current host resource pool; the remote host information includes operating system code name information, CPU architecture information, kernel version information, boot time information, and processor core count information;
[0012] Based on the host information, each remote host is classified and categorized to generate a preset host list file.
[0013] In one possible implementation, remote hosts are categorized and classified based on host information to generate a preset host list file, including:
[0014] Based on the combination of operating system code information and CPU architecture information in the host information, each remote host is grouped and classified to obtain multiple categories and multiple remote hosts corresponding to each category.
[0015] For each category of remote host, multiple remote hosts are sorted based on the boot duration information and the number of processor cores in the host information to obtain the sorted remote hosts.
[0016] For each sorted remote host, construct group parameter information and host-related definitions; where the group parameter information is used to mark the suffix of the target software compressed package, and the host-related definitions are used to determine the target remote host to receive the build task;
[0017] Based on multiple categories, multiple remote hosts corresponding to each category, group parameter information, and host-related definitions, a preset host list file is generated.
[0018] In one possible implementation, before obtaining the remote host information corresponding to each remote host in the current host resource pool, the method further includes:
[0019] The necessary dependency tools of each remote host in the current host resource pool are checked to obtain the first check result;
[0020] When the first check result is passed, the log system of the control client is initialized, and the current public and private key pairs of each remote host are checked by parsing the command line parameters to obtain the second check result;
[0021] If the second check fails, target public-private key pairs are generated for each remote host, and multiple processes are used to attempt logins and install credentials for each remote host in the current host resource pool, generating the processing result.
[0022] In one possible implementation, multiple processes are used to perform login attempts and credential installation on each remote host in the current host resource pool, generating processing results, including:
[0023] For each remote host in the current host resource pool, a login attempt is made to the remote host using the first preset login information, and a first return value is obtained;
[0024] If the first return value is inconsistent with the first target value, then determine whether the first return value is consistent with the second target value, and obtain the judgment result;
[0025] If the judgment result determines that the first return value is consistent with the second target value, then the processing result is determined to be that the remote host is unreachable or the first preset login information is incorrect.
[0026] If the judgment result determines that the first return value is inconsistent with the second target value, then the remote host is logged in using the second preset login information to obtain the second return value;
[0027] If the second return value is consistent with the second target value, the processing result is determined to be either that the remote host is unreachable or that the second preset login information is incorrect.
[0028] If the second return value is inconsistent with the second target value, the host public key of the control client will be installed on the remote host to obtain the processing result.
[0029] In one possible implementation, the method further includes:
[0030] Retrieve host-related definitions from the host manifest file;
[0031] Based on the remarks information in the host-related definitions, the target remote host whose boot duration information and processor core count information meet the preset conditions is determined; wherein, the remarks information includes the boot duration information and processor core count information of the target remote host.
[0032] The second aspect of this application proposes a software installation package building system, which includes a control client and multiple remote hosts, wherein the control client communicates with each remote host.
[0033] The control client is used to obtain the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built. The basic information includes package name, version number, software repository information, software repository branch information, and dependency package list information. There is a correspondence between the combinations of operating systems and CPU architectures and the specific configuration values of the software installation package to be built. Based on the general build configuration parameters and the specific configuration values of the software installation package to be built, detailed build configuration parameters for the software installation package to be built are generated. Based on the detailed build configuration parameters, a build task is sent to the target remote host in the preset host manifest file, and the target software compressed package returned by the target remote host is obtained. The target software compressed package is copied and decompressed to each remote host corresponding to the corresponding combination of operating system and CPU architecture, so that each remote host can install the target software compressed package.
[0034] The remote host is used to install the target software package.
[0035] A third aspect of this application provides a software installation package building apparatus, the apparatus comprising:
[0036] The first acquisition module is used to acquire the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; the basic information includes package name information, version number information, software repository information, software repository branch information and dependency package list information, and there is a corresponding relationship between the combination of various operating systems and CPU architectures and the specific configuration values of the software installation package to be built;
[0037] The generation module is used to generate detailed build configuration parameters for the software installation package to be built based on general build configuration parameters and the specific configuration values of the software installation package to be built.
[0038] The second acquisition module is used to send a build task to the target remote host in the preset host manifest file based on detailed build configuration parameters, and to obtain the target software compressed package returned by the target remote host.
[0039] The installation module is used to copy and decompress the target software package to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software package.
[0040] In one possible implementation, the above-described software installation package building apparatus is further configured to:
[0041] Retrieve remote host information corresponding to each remote host in the current host resource pool; the remote host information includes operating system code name information, CPU architecture information, kernel version information, boot time information, and processor core count information;
[0042] Based on the host information, each remote host is classified and categorized to generate a preset host list file.
[0043] In one possible implementation, the above-described software installation package building apparatus is further configured to:
[0044] Based on the combination of operating system code information and CPU architecture information in the host information, each remote host is grouped and classified to obtain multiple categories and multiple remote hosts corresponding to each category.
[0045] For each category of remote host, multiple remote hosts are sorted based on the boot duration information and the number of processor cores in the host information to obtain the sorted remote hosts.
[0046] For each sorted remote host, construct group parameter information and host-related definitions; where the group parameter information is used to mark the suffix of the target software compressed package, and the host-related definitions are used to determine the target remote host to receive the build task;
[0047] Based on multiple categories, multiple remote hosts corresponding to each category, group parameter information, and host-related definitions, a preset host list file is generated.
[0048] In one possible implementation, the above-described software installation package building apparatus is further configured to:
[0049] The necessary dependency tools of each remote host in the current host resource pool are checked to obtain the first check result;
[0050] When the first check result is passed, the log system of the control client is initialized, and the current public and private key pairs of each remote host are checked by parsing the command line parameters to obtain the second check result;
[0051] If the second check fails, target public-private key pairs are generated for each remote host, and multiple processes are used to attempt logins and install credentials for each remote host in the current host resource pool, generating the processing result.
[0052] In one possible implementation, the above-described software installation package building apparatus is further configured to:
[0053] For each remote host in the current host resource pool, a login attempt is made to the remote host using the first preset login information, and a first return value is obtained;
[0054] If the first return value is inconsistent with the first target value, then determine whether the first return value is consistent with the second target value, and obtain the judgment result;
[0055] If the judgment result determines that the first return value is consistent with the second target value, then the processing result is determined to be that the remote host is unreachable or the first preset login information is incorrect.
[0056] If the judgment result determines that the first return value is inconsistent with the second target value, then the remote host is logged in using the second preset login information to obtain the second return value;
[0057] If the second return value is consistent with the second target value, the processing result is determined to be either that the remote host is unreachable or that the second preset login information is incorrect.
[0058] If the second return value is inconsistent with the second target value, the host public key of the control client will be installed on the remote host to obtain the processing result.
[0059] In one possible implementation, the above-described software installation package building apparatus is further configured to:
[0060] Retrieve host-related definitions from the host manifest file;
[0061] Based on the remarks information in the host-related definitions, the target remote host whose boot duration information and processor core count information meet the preset conditions is determined; wherein, the remarks information includes the boot duration information and processor core count information of the target remote host.
[0062] The fourth aspect of this application provides an electronic device comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set, or an instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the method for constructing a software installation package as described in the first aspect.
[0063] The fifth aspect of this application provides a computer-readable storage medium storing at least one instruction, at least one program, a code set, or an instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the method for constructing a software installation package as described in the first aspect.
[0064] The embodiments of this application have the following beneficial effects:
[0065] The software installation package construction method provided in this application includes: obtaining general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; generating detailed build configuration parameters for the software installation package to be built based on the general build configuration parameters and the specific configuration values of the software installation package to be built; issuing a build task to a target remote host in a preset host manifest file based on the detailed build configuration parameters; obtaining the target software compressed package returned by the target remote host; and copying and decompressing the target software compressed package to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software compressed package. This solution achieves synchronous construction of software installation packages under multiple operating system and CPU architecture combinations by using detailed build configuration parameters for different software installation packages to be built corresponding to combinations of operating systems and CPU architectures, thus improving the efficiency of software installation package construction. Furthermore, the synchronous build task is executed automatically without manual intervention, saving labor costs and further improving the efficiency of software installation package construction. It also avoids errors caused by manual intervention, improving the accuracy of software installation package construction. Attached Figure Description
[0066] Figure 1 A block diagram of a computer device provided in an embodiment of this application;
[0067] Figure 2 A flowchart illustrating the steps of a method for constructing a software installation package, as provided in an embodiment of this application;
[0068] Figure 3 A flowchart illustrating the steps for processing each remote host in the current host resource pool, as provided in this application embodiment;
[0069] Figure 4 A flowchart illustrating the steps for generating a preset host manifest file is provided in this application embodiment;
[0070] Figure 5 A flowchart illustrating another step in generating a preset host manifest file, as provided in this application embodiment;
[0071] Figure 6 A flowchart illustrating the steps for determining a target remote host, as provided in this application embodiment;
[0072] Figure 7 A structural block diagram of the software installation package building apparatus provided in the embodiments of this application. Detailed Implementation
[0073] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0074] When building a test application software installation package for a combination of multiple CPU architectures and operating systems, the process usually begins by confirming whether the operating system currently installed on the host is compatible with the target. Then, after logging into the operating system, the code is cloned from the source code repository according to the software source code repository and branch where the software installation package is located. At the same time, the necessary build dependency packages are installed, and the necessary source code compressed package is created before the compilation and build process is performed. After the compilation is completed successfully, relevant information such as the software installation package and build logs located in the parent directory of the source code is collected.
[0075] However, the software installation package construction scheme of the above test application has the following problems:
[0076] 1. Assuming the existing network environment already has hosts with the same CPU architecture and operating system as the target, the process of building the software installation package requires first determining whether the host's current operating system and CPU architecture match the expected target before logging into the remote host to compile and create the software installation package. This often means sifting through several pages of the host resource pool list maintained by the development and operations team to find a host record that meets the target, resulting in a significant workload.
[0077] 2. The entire build process requires manual intervention. After each step, there may be a waiting period before proceeding to the next, making it highly dependent on human resources. Furthermore, due to the need for human intervention, the build process often has to be completed sequentially under one CPU architecture and operating system combination before moving on to the next. Assuming a single software installer build takes 30 minutes, if you need to prepare 10 software installers for a test application from source code, with different CPU architectures and operating system combinations, it will take at least 5 hours.
[0078] 3. Since it is necessary to manually query the source code URLs of the software installation packages of each test application, as well as the correct branches used under different CPU architectures and operating system combinations, this means that it is necessary to manually maintain the source code URLs and source code branch combinations corresponding to the target CPU architecture and operating system combinations. This will be a very large task, and errors can easily be introduced during the query process.
[0079] 4. Due to the different CPU architectures and operating system combinations, the dependencies on the same test application may vary, making it often impossible to install all the corresponding build dependency packages completely and correctly in one go before building.
[0080] 5. Also, because it relies on human intervention, it is impossible to automate parallel building tasks, and the hosts in the host resource pool will not be used efficiently.
[0081] In view of this, this application proposes a method for building software installation packages. By using detailed build configuration parameters for different software installation packages to be built corresponding to combinations of operating systems and CPU architectures, the method achieves synchronous building of software installation packages under combinations of multiple operating systems and CPU architectures, thereby improving the efficiency of building software installation packages. In addition, this synchronous build task is executed automatically without human intervention, saving labor costs and further improving the efficiency of building software installation packages. Moreover, it avoids errors caused by human intervention and improves the accuracy of building software installation packages.
[0082] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, the use of "based on" or "according to" implies openness and inclusiveness, because processes, steps, calculations, or other actions "based on" or "according to" one or more of the stated conditions or values may in practice be based on additional conditions or beyond the stated values.
[0083] The method for constructing the software installation package provided in this application can be applied to computer devices (electronic devices). The computer device can be a server or a terminal. The server can be a single server or a server cluster composed of multiple servers. This application does not specifically limit this. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices.
[0084] Taking a computer device as an example, Figure 1 A block diagram of a server is shown, such as Figure 1As shown, the server may include a processor and memory connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. When the computer program is executed by the processor, it implements a method for building a software installation package.
[0085] Those skilled in the art will understand that Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the server to which the present application is applied. Optionally, the server may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.
[0086] It should be noted that the execution subject of the embodiments of this application can be a computer device or a software installation package building device. The following method embodiments will be described with a computer device as the execution subject.
[0087] Figure 2 This is a flowchart illustrating the steps of a method for constructing a software installation package, as provided in an embodiment of this application. Figure 2 As shown, the method includes the following steps:
[0088] Step 202: Obtain the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built.
[0089] The basic information may include package name, version number, software repository, software repository branch, and dependency package list. There is a correspondence between the combination of operating systems and CPU architectures and the specific configuration values of the software installation package to be built.
[0090] In some optional embodiments, Ansible can be chosen as the configuration and automation framework when building the software installation package. Ansible has advantages such as no client installation required, immediate task push and execution, fast response speed, and rich community support information. In particular, its support for multi-level variable overriding makes it convenient to set parameters for different groups in a hierarchical manner, so as to achieve the effect of child group variables overriding parent group variables. This allows for unified setting of general build configuration parameters for the software installation package to be built, and then selection of differentiated specific configuration values for specific CPU architecture and operating system combinations.
[0091] Before distributing the synchronized build tasks for the software installation package, it's necessary to perform dynamic probing, SSH login credential installation, and information collection on the hosts in the current host resource pool. Then, based on the collected information, the hosts are categorized hierarchically to generate a pre-defined host manifest file for subsequent build task distribution using ansible-playbooks. SSH login credentials are authentication information used for authentication via SSH, typically including a username and password or an SSH private key. Ansible-playbooks are the configuration, deployment, and orchestration language for Ansible.
[0092] Optionally, such as Figure 3 As shown, Figure 3 A flowchart illustrating the steps for processing each remote host in the current host resource pool, as provided in this application embodiment, includes:
[0093] Step 302: Check the necessary dependency tools of each remote host in the current host resource pool and obtain the first check result.
[0094] Step 304: When the first check result is that the check passes, the log system of the control client is initialized, and the current public and private key pairs of each remote host are checked by parsing the command line parameters to obtain the second check result.
[0095] Step 306: When the second check result is that the check fails, generate the target public-private key pair for each remote host, and use multiple processes to perform login attempts and credential installation on each remote host in the current host resource pool, and generate the processing result.
[0096] The necessary dependencies for each remote host may include sshpass, ssh, and ssh-keygen. Checking whether these necessary dependencies are installed yields the first check result. sshpass is a command-line tool for non-interactive SSH login, allowing use in scripts without manually entering a password. SSH is a protocol for secure communication over insecure networks and is the primary way Ansible connects to and manages remote hosts. ssh-keygen is a tool for generating, managing, and converting SSH keys. It can generate SSH public-private key pairs, which are an authentication mechanism that uses the public key for encryption and the private key for decryption to achieve passwordless secure login.
[0097] If the first check passes, meaning the necessary dependencies have been installed, the control client's logging system needs to be initialized. Next, the current public / private key pairs on each remote host are checked using command-line arguments to verify if the corresponding SSH public / private key pairs have been created, thus obtaining the second check result.
[0098] If the second check fails, meaning the corresponding SSH public / private key pair has not been created, then ssh-keygen needs to be used to create the target public / private key pair, thereby generating the target public / private key pair for each remote host. Then, a multi-process approach is used to perform login attempts and credential installation on each remote host in the current host resource pool, generating the processing results.
[0099] Optionally, to accelerate the detection process of remote hosts in the current host resource pool, the repetitive tasks of login detection, credential installation, and information collection can be distributed to multiple cores of the processor acting as the control client for parallel execution using Python's ProcessPoolExecutor. This allows for login probing and credential installation processing of each remote host in the current host resource pool through multiple processes. In actual testing on a 48-core host scanning a private network with Class C addresses and a maximum of 254 remote hosts, the entire network topology check, credential installation, and information collection process can be completed in approximately 18 seconds.
[0100] In some optional embodiments, when using multiple processes to perform login attempts and credential installation on each remote host in the current host resource pool and generate processing results, the following steps can be taken: First, for each remote host in the current host resource pool, a login attempt can be made using first preset login information to obtain a first return value. If the first return value is inconsistent with the first target value, it can be determined whether the first return value is consistent with the second target value to obtain a judgment result. If the judgment result determines that the first return value is consistent with the second target value, the processing result is determined to be that the remote host is unreachable or the first preset login information is incorrect. If the judgment result determines that the first return value is inconsistent with the second target value, a login attempt can be made on the remote host using second preset login information to obtain a second return value. If the second return value is consistent with the second target value, the processing result is determined to be that the remote host is unreachable or the second preset login information is incorrect. If the second return value is inconsistent with the second target value, the host public key of the control client can be installed on the remote host to obtain the processing result.
[0101] The first preset login information is a strict login check command, specifically the `-o StrictHostKeyChecking=yes` command. This means that under strict login check, a non-interactive login attempt is made to obtain a first return value. The first target value can be 0. If the first return value is 0, it indicates that the remote host can be logged into normally.
[0102] If the first return value is inconsistent with the first target value, then it is determined whether the first return value is consistent with the second target value, and a judgment result is obtained. The second target value can be 5. If the first return value is 5, it can be determined based on the judgment result that the first return value is consistent with the second target value, and the processing result is determined to be either the remote host is unreachable or the first preset login information is incorrect.
[0103] If the second return value is any other value, it can be determined from the judgment result that the first return value and the second target value are inconsistent. This indicates that the information of the remote host recorded on the control client, i.e., the host key, is outdated. This may be because the remote host has reinstalled a new operating system. In this case, it is necessary to attempt to log in to the remote host using the second preset login information to obtain the second return value. The second preset login information can be set to -o StrictHostKeyChecking=no, which means that the strict verification of the remote host is skipped using the second preset login information.
[0104] If verifying the login to the remote host with StrictHostKeyChecking=no still returns a value of 5, meaning the second return value matches the second target value, then the result is determined to be that the remote host is unreachable or the second preset login information is incorrect. In this case, you can skip the remote host and try the next remote host.
[0105] If the return value obtained when verifying login to the remote host using `StrictHostKeyChecking=no` is not 5, meaning the second return value does not match the second target value, it indicates that the remote host can be verified using `-o StrictHostKeyChecking=no`. In this case, it is necessary to clear the host key information recorded on the remote host and install the host public key of the control client onto the remote host to achieve passwordless login to that remote host. Furthermore, the sshpass settings in Ansible can be skipped during the subsequent generation of the preset host manifest file.
[0106] It should be noted that in the implementation environment of this software package synchronous build method, although each remote host may be in a specific operating system in the operating system list corresponding to the host's CPU architecture at different times, all operating systems have created a unified default login user and use the same default login password. This is a necessary prerequisite for this method to successfully perform dynamic detection, SSH login credential installation and information collection in the intranet environment where the host resource pool is located.
[0107] Next, we can obtain the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built. This basic information can include package name, version number, software repository information, software repository branch information, and dependency list information. The package name can be defined by the parameter `pkg_name`, the version number by the parameter `pkg_ver`, the software repository by the parameter `repo_url`, the software repository branch by the parameter `repo_branch`, and the dependency list by the parameter `build_depends`.
[0108] The software packages to be built for different test cases differ only in the basic information mentioned above, or, for the same test case, the basic information may differ depending on the CPU architecture and operating system combination. Therefore, for different software packages to be built, the `include_vars` directive in Ansible can be used to dynamically load various basic information from the corresponding YAML file in the `playbook / var / debian / ` directory. YAML is a concise and easy-to-read data serialization format.
[0109] Next, this basic information can be used to select general build configuration parameters for each parameter, as well as specific configuration values in the YAML files of each sub-level operating system and CPU architecture combination corresponding to the remote host where the build task is located, through the lookup method provided by Ansible. The lookup method is used to retrieve variables.
[0110] Step 204: Based on the general build configuration parameters and the specific configuration values of the software installation package to be built, generate detailed build configuration parameters for the software installation package to be built.
[0111] Once the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built are obtained, detailed build configuration parameters can be derived based on the general build configuration parameters and the specific configuration values of the software installation package to be built.
[0112] In some optional embodiments, if the two software installation packages to be built are clpeak and glmark2, their corresponding glmark2.yaml and clpeak.yaml files only define the variable names of the five necessary build elements of the software package, i.e., the basic information mentioned above, without specifically defining their variable values. The final variable values are defined in the root-level all.yaml file. The reason for not directly defining the variable values here, but rather deriving the specific variable values through intermediate variable names, is mainly designed for the variable overriding feature of Ansible. That is, all.yaml stores general build configuration parameters, and based on the specific characteristics of different automated build tasks, when the corresponding build task is sent to the target remote host, the configuration parameters of the specific automated build task are dynamically derived, i.e., the detailed build configuration parameters mentioned above are obtained.
[0113] In some alternative embodiments, for example, for the build task of the software installation package clpeak to be built, for a variety of operating systems and CPU architectures, the version number information defined by clpeak_ver, the software repository branch information defined by clpeak_branch, and the dependency package list information defined by clpeak_build_depends in the all.yaml file can be used.
[0114] For example, for the glmark2 software installation package to be built, since the versions and capabilities of wayland-protocal and libdrm differ across operating systems, different software repository branches are needed to maintain whether different libdrm and wayland-protocal are enabled during the glmark2 configuration phase for each operating system. Therefore, different glmark2_branch software repository branch information is defined in the files for different operating system and CPU architecture combinations. libdrm is an application-layer dynamic link library that encapsulates the underlying interface and provides a common API interface to the upper layer. wayland-protocal is a protocol that defines how to manage windows. On an operating system, many applications are launched, and a window for that application pops up. Creating this window requires calling a specific interface, which is equivalent to the interface provided by the window management protocol.
[0115] Step 206: Based on the detailed build configuration parameters, send the build task to the target remote host in the preset host manifest file, and obtain the target software compressed package returned by the target remote host.
[0116] In some optional embodiments, such as Figure 4 As shown, Figure 4 A flowchart illustrating the steps for generating a preset host manifest file, provided in this application embodiment, includes:
[0117] Step 402: Obtain the remote host information corresponding to each remote host in the current host resource pool.
[0118] Step 404: Based on the host information, classify and categorize each remote host to generate a preset host list file.
[0119] The remote host information may include operating system codename, CPU architecture, kernel version, boot time, and number of processor cores. Optionally, the operating system codename can be obtained from the codename in the result of `lsb_release -a`, the CPU architecture can be obtained from `uname -m`, the kernel version can be obtained from `uname -r`, the boot time can be obtained from `cat / proc / uptime`, and the number of processor cores can be obtained from `nproc`.
[0120] Optionally, such as Figure 5 As shown, Figure 5 Another flowchart for generating a preset host manifest file provided in this application embodiment includes:
[0121] Step 502: Based on the combination of operating system code information and CPU architecture information in the host information, group and classify each remote host to obtain multiple categories and multiple remote hosts corresponding to each category.
[0122] Step 504: For each category of remote hosts, sort the remote hosts based on the boot duration information and the number of processor cores in the host information to obtain the sorted remote hosts.
[0123] Step 506: For each sorted remote host, construct group parameter information and host-related definitions.
[0124] Step 508: Generate a preset host list file based on multiple categories, multiple remote hosts corresponding to each category, group parameter information, and host-related definitions.
[0125] One operating system may correspond to multiple CPU architectures. Therefore, remote hosts can be grouped and classified based on the combination of operating system code information and CPU architecture information in the host information, resulting in multiple categories and multiple remote hosts corresponding to each category. The grouped and classified remote hosts have a hierarchical relationship.
[0126] Next, for each category of remote hosts, multiple remote hosts can be sorted based on their boot time and processor core count information to obtain the sorted remote hosts. Optionally, the boot time can be sorted in descending order to ensure that remote hosts with longer boot times are listed first, and the processor core count can be sorted in descending order to ensure that remote hosts with more processor cores are listed first.
[0127] Next, for each sorted remote host, group parameter information and host-related definitions are constructed. The group parameter information is used to annotate the suffix of the target software compressed package, and the host-related definitions are used to determine the target remote host receiving the build task. Finally, a preset host list file can be generated based on multiple categories, multiple remote hosts corresponding to each category, group parameter information, and host-related definitions.
[0128] It should be noted that remote hosts that cannot be grouped and categorized according to the combination of operating system codename information and CPU architecture information can also be output. This is usually because these remote hosts cannot obtain the corresponding operating system codename information due to the lack of relevant commands. Therefore, these remote hosts can be further grouped and categorized separately according to their operating system codename information and CPU architecture information at a higher level.
[0129] Optionally, this default host manifest file can be edited using the ini format so that ansible-playbook can recognize it. In this default host manifest file, the content to the right of the '#' is a comment and will not be read by the program. For lines defining a group of categories, the non-comment content following that line defines the information of each remote host within that group. For example, the information of each remote host may include the hostname, IP address, and the user logged in when performing SSH operations.
[0130] The generated default host manifest file determines how to specify the remote host or remote host group used to execute a build or installation task when it is subsequently issued in ansible playbook. In some optional embodiments, such as Figure 6 As shown, Figure 6 A flowchart illustrating the steps for determining a target remote host, as provided in this application embodiment, includes:
[0131] Step 602: Obtain the host-related definitions from the host manifest file.
[0132] Step 604: Based on the remarks information in the host-related definitions, determine the target remote host whose boot duration information and processor core count information meet the preset conditions.
[0133] The remarks information may include the target remote host's boot time and the number of processor cores. The preset condition is the first remote host with the longest boot time and the most processor cores, under a given operating system and CPU architecture combination.
[0134] Therefore, under a combination of operating system and CPU architecture, the remote host with the longest boot time and the most processor cores can be identified as the target remote host, and the target remote host can be used as a representative to distribute the build task.
[0135] Step 208: Copy and decompress the target software package to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software package.
[0136] Specifically, for the target software compressed package built on the target remote host and retrieved back to the control client, it can be automatically copied and decompressed to each remote host or remote host group corresponding to the combination of operating system and CPU architecture and installed, so that the build result can be deployed to other remote hosts in a synchronous manner.
[0137] In this embodiment, the method includes: obtaining general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; generating detailed build configuration parameters for the software installation package to be built based on the general build configuration parameters and the specific configuration values of the software installation package to be built; issuing a build task to the target remote host in a preset host manifest file based on the detailed build configuration parameters; obtaining the target software compressed package returned by the target remote host; and copying and decompressing the target software compressed package to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software compressed package. This solution achieves synchronous building of software installation packages under multiple operating system and CPU architecture combinations by using detailed build configuration parameters for different software installation packages corresponding to various combinations of operating systems and CPU architectures, thus improving the efficiency of building software installation packages. Furthermore, this synchronous build task is executed automatically without manual intervention, saving labor costs and further improving the efficiency of building software installation packages. It also avoids errors caused by manual intervention, improving the accuracy of building software installation packages.
[0138] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0139] This application also provides a software installation package building system, characterized in that the system includes a control client and multiple remote hosts, and the control client communicates with each remote host.
[0140] The control client is used to obtain the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built. The basic information includes package name, version number, software repository information, software repository branch information, and dependency package list information. There is a correspondence between the combinations of operating systems and CPU architectures and the specific configuration values of the software installation package to be built. Based on the general build configuration parameters and the specific configuration values of the software installation package to be built, detailed build configuration parameters for the software installation package to be built are generated. Based on the detailed build configuration parameters, a build task is issued to the target remote host in the preset host manifest file, and the target software compressed package returned by the target remote host is obtained. The target software compressed package is copied and decompressed to each remote host corresponding to the corresponding combination of operating system and CPU architecture, so that each remote host can install the target software compressed package.
[0141] The remote host is used to install the target software package.
[0142] The software installation package building system provided in this application embodiment has similar implementation principles and technical effects to the above method embodiments, and will not be described again here.
[0143] Figure 7 This is a structural block diagram of a software installation package building apparatus provided in an embodiment of this application.
[0144] like Figure 7 As shown, the software installation package building apparatus 700 includes:
[0145] The first acquisition module 702 is used to acquire the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; wherein, the basic information includes package name information, version number information, software repository information, software repository branch information and dependency package list information, and there is a corresponding relationship between the combination of various operating systems and CPU architectures and the specific configuration values of the software installation package to be built.
[0146] Module 704 is used to generate detailed build configuration parameters for the software installation package to be built based on general build configuration parameters and the specific configuration values of the software installation package to be built.
[0147] The second acquisition module 706 is used to send a build task to the target remote host in the preset host manifest file based on detailed build configuration parameters, and to obtain the target software compressed package returned by the target remote host.
[0148] The installation module 708 is used to copy and decompress the target software package to each remote host corresponding to the combination of the operating system and CPU architecture, so that each remote host can install the target software package.
[0149] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here. Each module in the above software installation package building apparatus can be implemented entirely or partially through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations of each module.
[0150] In one embodiment of this application, a computer device is provided, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:
[0151] Obtain the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; among which, the basic information includes package name information, version number information, software repository information, software repository branch information and dependency package list information, and there is a corresponding relationship between the combination of various operating systems and CPU architectures and the specific configuration values of the software installation package to be built;
[0152] Based on the general build configuration parameters and the specific configuration values of the software installation package to be built, generate detailed build configuration parameters for the software installation package to be built;
[0153] Based on detailed build configuration parameters, a build task is sent to the target remote host in the preset host manifest file, and the target software compressed package returned by the target remote host is obtained.
[0154] The target software package is copied and decompressed to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software package.
[0155] In one embodiment of this application, the processor further performs the following steps when executing the computer program:
[0156] Retrieve remote host information corresponding to each remote host in the current host resource pool; the remote host information includes operating system code name information, CPU architecture information, kernel version information, boot time information, and processor core count information;
[0157] Based on the host information, each remote host is classified and categorized to generate a preset host list file.
[0158] In one embodiment of this application, the processor further performs the following steps when executing the computer program:
[0159] Based on the combination of operating system code information and CPU architecture information in the host information, each remote host is grouped and classified to obtain multiple categories and multiple remote hosts corresponding to each category.
[0160] For each category of remote host, multiple remote hosts are sorted based on the boot duration information and the number of processor cores in the host information to obtain the sorted remote hosts.
[0161] For each sorted remote host, construct group parameter information and host-related definitions; where the group parameter information is used to mark the suffix of the target software compressed package, and the host-related definitions are used to determine the target remote host to receive the build task;
[0162] Based on multiple categories, multiple remote hosts corresponding to each category, group parameter information, and host-related definitions, a preset host list file is generated.
[0163] In one embodiment of this application, the processor further performs the following steps when executing the computer program:
[0164] The necessary dependency tools of each remote host in the current host resource pool are checked to obtain the first check result;
[0165] When the first check result is passed, the log system of the control client is initialized, and the current public and private key pairs of each remote host are checked by parsing the command line parameters to obtain the second check result;
[0166] If the second check fails, target public-private key pairs are generated for each remote host, and multiple processes are used to attempt logins and install credentials for each remote host in the current host resource pool, generating the processing result.
[0167] In one embodiment of this application, the processor further performs the following steps when executing the computer program:
[0168] For each remote host in the current host resource pool, a login attempt is made to the remote host using the first preset login information, and a first return value is obtained;
[0169] If the first return value is inconsistent with the first target value, then determine whether the first return value is consistent with the second target value, and obtain the judgment result;
[0170] If the judgment result determines that the first return value is consistent with the second target value, then the processing result is determined to be that the remote host is unreachable or the first preset login information is incorrect.
[0171] If the judgment result determines that the first return value is inconsistent with the second target value, then the remote host is logged in using the second preset login information to obtain the second return value;
[0172] If the second return value is consistent with the second target value, the processing result is determined to be either that the remote host is unreachable or that the second preset login information is incorrect.
[0173] If the second return value is inconsistent with the second target value, the host public key of the control client will be installed on the remote host to obtain the processing result.
[0174] In one embodiment of this application, the processor further performs the following steps when executing the computer program:
[0175] Retrieve host-related definitions from the host manifest file;
[0176] Based on the remarks information in the host-related definitions, the target remote host whose boot duration information and processor core count information meet the preset conditions is determined; wherein, the remarks information includes the boot duration information and processor core count information of the target remote host.
[0177] The computer device provided in this application embodiment has a similar implementation principle and technical effect to the above method embodiment, and will not be described again here.
[0178] In one embodiment of this application, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, it performs the following steps:
[0179] Obtain the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; among which, the basic information includes package name information, version number information, software repository information, software repository branch information and dependency package list information, and there is a corresponding relationship between the combination of various operating systems and CPU architectures and the specific configuration values of the software installation package to be built;
[0180] Based on the general build configuration parameters and the specific configuration values of the software installation package to be built, generate detailed build configuration parameters for the software installation package to be built;
[0181] Based on detailed build configuration parameters, a build task is sent to the target remote host in the preset host manifest file, and the target software compressed package returned by the target remote host is obtained.
[0182] The target software package is copied and decompressed to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software package.
[0183] In one embodiment of this application, the computer program, when executed by a processor, further performs the following steps:
[0184] Retrieve remote host information corresponding to each remote host in the current host resource pool; the remote host information includes operating system code name information, CPU architecture information, kernel version information, boot time information, and processor core count information;
[0185] Based on the host information, each remote host is classified and categorized to generate a preset host list file.
[0186] In one embodiment of this application, the computer program, when executed by a processor, further performs the following steps:
[0187] Based on the combination of operating system code information and CPU architecture information in the host information, each remote host is grouped and classified to obtain multiple categories and multiple remote hosts corresponding to each category.
[0188] For each category of remote host, multiple remote hosts are sorted based on the boot duration information and the number of processor cores in the host information to obtain the sorted remote hosts.
[0189] For each sorted remote host, construct group parameter information and host-related definitions; where the group parameter information is used to mark the suffix of the target software compressed package, and the host-related definitions are used to determine the target remote host to receive the build task;
[0190] Based on multiple categories, multiple remote hosts corresponding to each category, group parameter information, and host-related definitions, a preset host list file is generated.
[0191] In one embodiment of this application, the computer program, when executed by a processor, further performs the following steps:
[0192] The necessary dependency tools of each remote host in the current host resource pool are checked to obtain the first check result;
[0193] When the first check result is passed, the log system of the control client is initialized, and the current public and private key pairs of each remote host are checked by parsing the command line parameters to obtain the second check result;
[0194] If the second check fails, target public-private key pairs are generated for each remote host, and multiple processes are used to attempt logins and install credentials for each remote host in the current host resource pool, generating the processing result.
[0195] In one embodiment of this application, the computer program, when executed by a processor, further performs the following steps:
[0196] For each remote host in the current host resource pool, a login attempt is made to the remote host using the first preset login information, and a first return value is obtained;
[0197] If the first return value is inconsistent with the first target value, then determine whether the first return value is consistent with the second target value, and obtain the judgment result;
[0198] If the judgment result determines that the first return value is consistent with the second target value, then the processing result is determined to be that the remote host is unreachable or the first preset login information is incorrect.
[0199] If the judgment result determines that the first return value is inconsistent with the second target value, then the remote host is logged in using the second preset login information to obtain the second return value;
[0200] If the second return value is consistent with the second target value, the processing result is determined to be either that the remote host is unreachable or that the second preset login information is incorrect.
[0201] If the second return value is inconsistent with the second target value, the host public key of the control client will be installed on the remote host to obtain the processing result.
[0202] In one embodiment of this application, the computer program, when executed by a processor, further performs the following steps:
[0203] Retrieve host-related definitions from the host manifest file;
[0204] Based on the remarks information in the host-related definitions, the target remote host whose boot duration information and processor core count information meet the preset conditions is determined; wherein, the remarks information includes the boot duration information and processor core count information of the target remote host.
[0205] The computer-readable storage medium provided in this embodiment is similar in principle and technical effect to the method embodiment described above, and will not be repeated here.
[0206] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.
[0207] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.
[0208] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.
Claims
1. A method for constructing a software installation package, applied to a control client, characterized in that, The method includes: Obtain the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; wherein, the basic information includes package name information, version number information, software repository information, software repository branch information and dependency package list information, and there is a corresponding relationship between the combination of various operating systems and CPU architectures and the specific configuration values of the software installation package to be built; Based on the general build configuration parameters and the specific configuration values of the software installation package to be built, detailed build configuration parameters of the software installation package to be built are generated. Based on the detailed build configuration parameters, a build task is issued to the target remote host in the preset host manifest file, and the target software compressed package returned by the target remote host is obtained; wherein, the target remote host is a remote host whose boot duration information and processor core count information meet preset conditions after obtaining the host-related definitions in the preset host manifest file and based on the remarks information in the host-related definitions; the remarks information includes the boot duration information and processor core count information of the target remote host; the generation process of the preset host manifest file includes: obtaining the remote host information corresponding to each remote host in the current host resource pool; wherein, the remote host information includes operating system code name information, CPU architecture information, kernel version information, boot duration information, and processor core count information; based on The remote hosts are grouped and categorized based on the combination of the operating system code information and the CPU architecture information in the host information, resulting in multiple categories and multiple remote hosts corresponding to each category. For the remote hosts in each category, the multiple remote hosts are sorted based on the boot duration information and the number of processor cores in the host information, resulting in sorted remote hosts. For each sorted remote host, group parameter information and host-related definitions are constructed. The group parameter information is used to label the suffix of the target software compressed package, and the host-related definitions are used to determine the target remote host receiving the construction task. Based on the multiple categories, the multiple remote hosts corresponding to each category, the group parameter information, and the host-related definitions, the preset host list file is generated. The target software package is copied and decompressed to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software package.
2. The method according to claim 1, characterized in that, Before obtaining the remote host information corresponding to each remote host in the current host resource pool, the method further includes: The necessary dependency tools of each remote host in the current host resource pool are checked to obtain the first check result; When the first check result is passed, the log system of the control client is initialized, and the current public and private key pairs of each remote host are checked by parsing command line parameters to obtain the second check result; If the second check result is that the check fails, a target public-private key pair is generated for each of the remote hosts, and a multi-process approach is used to perform login attempts and credential installation on each remote host in the current host resource pool, generating a processing result.
3. The method according to claim 2, characterized in that, The process of using multiple processes to perform login attempts and credential installation on each remote host in the current host resource pool, and generating processing results, includes: For each remote host in the current host resource pool, a login attempt is made to the remote host using the first preset login information, and a first return value is obtained; If the first return value is inconsistent with the first target value, then determine whether the first return value is consistent with the second target value, and obtain the determination result; If the first return value is determined to be consistent with the second target value based on the judgment result, then the processing result is determined to be that the remote host is unreachable or the first preset login information is incorrect. If, based on the judgment result, it is determined that the first return value is inconsistent with the second target value, then a login attempt is made on the remote host using the second preset login information to obtain the second return value; If the second return value is consistent with the second target value, then the processing result is determined to be that the remote host is unreachable or the second preset login information is incorrect; If the second return value is inconsistent with the second target value, then the host public key of the control client is installed on the remote host to obtain the processing result.
4. A software installation package building system, characterized in that, The system includes a control client and multiple remote hosts, and the control client is communicatively connected to each of the remote hosts. The control client is used to obtain general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; wherein, the basic information includes package name information, version number information, software repository information, software repository branch information, and dependency package list information, and there is a correspondence between the combination of operating systems and CPU architectures and the specific configuration values of the software installation package to be built; based on the general build configuration parameters and the specific configuration values of the software installation package to be built, detailed build configuration parameters of the software installation package to be built are generated; based on the detailed build configuration parameters, a build task is issued to the target remote host in the preset host manifest file, and the target software compressed package returned by the target remote host is obtained; the target software compressed package is copied and decompressed to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host installs the target software compressed package; wherein, the target remote host is a remote host whose boot duration information and processor core count information meet preset conditions after obtaining the host-related definitions in the preset host manifest file and based on the remarks information in the host-related definitions; the remarks information includes The preset host list file includes the boot duration information and processor core count information of the target remote host; the generation process of the preset host list file includes: obtaining remote host information corresponding to each remote host in the current host resource pool; wherein, the remote host information includes operating system code name information, CPU architecture information, kernel version information, boot duration information, and processor core count information; grouping and classifying each remote host based on the combination of the operating system code name information and the CPU architecture information in the host information to obtain multiple categories and multiple remote hosts corresponding to each category; sorting the multiple remote hosts in each category based on the boot duration information and the processor core count information in the host information to obtain sorted remote hosts; constructing group parameter information and host-related definitions for each sorted remote host; wherein, the group parameter information is used to mark the suffix of the target software compressed package, and the host-related definitions are used to determine the target remote host receiving the construction task; generating the preset host list file based on the multiple categories, the multiple remote hosts corresponding to each category, the group parameter information, and the host-related definitions. The remote host is used to install the target software package.
5. A software installation package building apparatus, characterized in that, The device includes: The first acquisition module is used to acquire the general build configuration parameters and specific configuration values corresponding to the basic information of the software installation package to be built; wherein, the basic information includes package name information, version number information, software repository information, software repository branch information and dependency package list information, and there is a corresponding relationship between the combination of each operating system and CPU architecture and the specific configuration values of the software installation package to be built; The generation module is used to generate detailed build configuration parameters for the software installation package to be built based on the general build configuration parameters and the specific configuration values of the software installation package to be built. The second acquisition module is used to issue a build task to the target remote host in the preset host list file based on the detailed build configuration parameters, and to acquire the target software compressed package returned by the target remote host; wherein, the target remote host is a remote host whose boot duration information and processor core count information meet preset conditions after acquiring the host-related definitions in the preset host list file and determining them based on the remarks information in the host-related definitions; the remarks information includes the boot duration information and processor core count information of the target remote host; the generation process of the preset host list file includes: acquiring the remote host information corresponding to each remote host in the current host resource pool; wherein, the remote host information includes operating system code name information, CPU architecture information, kernel version information, boot duration information, and processor core count information. The remote hosts are grouped and categorized based on a combination of the operating system code information and the CPU architecture information in the host information, resulting in multiple categories and multiple remote hosts corresponding to each category. For each category of remote hosts, the remote hosts are sorted based on the boot duration information and the number of processor cores in the host information, resulting in sorted remote hosts. For each sorted remote host, group parameter information and host-related definitions are constructed. The group parameter information is used to label the suffix of the target software compressed package, and the host-related definitions are used to determine the target remote host receiving the construction task. Based on the multiple categories, the multiple remote hosts corresponding to each category, the group parameter information, and the host-related definitions, a preset host list file is generated. The installation module is used to copy and decompress the target software package to each remote host corresponding to the combination of operating system and CPU architecture, so that each remote host can install the target software package.
6. An electronic device, characterized in that, The electronic device includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the method for constructing a software installation package as described in any one of claims 1-3.
7. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the method for constructing a software installation package as described in any one of claims 1-3.
Citation Information
Patent Citations
Method and device for installing software installation package
CN114296747A