Application installation package installation process control method, storage medium and electronic equipment

Abstract

The invention provides an application installation package installation process control method, a storage medium and electronic equipment. The method comprises the following steps: constructing an application installation package, wherein the application installation package comprises an info.json service folder, a conf folder, a gateway folder, a cdn folder and a data folder; installing the application installation package: decompressing the application installation package; reading the conf folder, and writing the configuration information in the conf folder into the configuration service; the gateway folder is read, and the routing information in the gateway folder is written into the gateway service; reading the cdn folder, and writing the information of the cdn folder into the cdn service; basic application information in an info.json service folder is read, account and password information is created, and the account and password information is written into the configuration service; and reading the corresponding file in the data folder, starting a docker service, and running the database file in the docker container. According to the application, different developers can conveniently construct and install the application installation package, and the deployment efficiency and consistency are improved.

Description

Technical Field

[0001] This application belongs to the field of software control technology, and in particular relates to the field of software program installation package installation process control technology. Background Technology

[0002] In the software deployment and delivery process, application installation and configuration is a core step in ensuring the software goes live. Currently, most software companies adopt a traditional model of collaboration between operations and maintenance (O&M) personnel and development teams. In this model, O&M personnel lead the installation process, while developers provide scattered data such as scripts, installation packages, and documentation. O&M personnel then use this data to complete the installation, configuration, and debugging of the application on the target device.

[0003] However, this traditional model suffers from numerous technical flaws, resulting in low installation efficiency, poor execution consistency, and frequent failures, severely impacting deployment progress and operational stability. The specific core issues are as follows:

[0004] First, the installation dependency data is scattered and non-standardized, lacking unified management and verification. The installation packages, scripts, and other data provided by developers are stored in a scattered manner and lack standardized delivery kits, which can easily lead to data omissions and version mismatches when maintenance personnel retrieve and integrate them. In addition, the scripts may have hidden dangers such as syntax errors and insufficient environment adaptation. The existing model lacks an automated verification process, and problems are mostly exposed during the installation stage, increasing the cost of troubleshooting and rework.

[0005] Secondly, installation accuracy relies on manual collaboration, which can easily lead to problems due to information discrepancies or operational oversights. The installation logic largely depends on verbal instructions or simple documentation. If maintenance personnel misunderstand or make manual operational errors (such as entering incorrect parameters or omitting steps), it can lead to installation failures or application anomalies. Furthermore, when installation anomalies occur, maintenance and development personnel need to communicate repeatedly to troubleshoot, resulting in delayed information transmission, high communication costs, and delays in deployment progress.

[0006] Third, developers cannot directly control the entire installation process, which can easily deviate from the original design intent. The installation process is led by operations and maintenance personnel, and developers cannot monitor the progress and status in real time. If operations and maintenance personnel modify the scripts or steps without authorization, it will lead to inconsistencies between the application's operating environment and the design standards, causing potential compatibility and performance issues. Furthermore, it will be difficult to locate such problems in subsequent operations and maintenance, affecting the long-term stable operation of the software.

[0007] Fourth, the model has poor reusability and scalability, and cannot adapt to large-scale multi-environment deployment. As business grows, applications need to be deployed on multiple servers and in multiple environments (testing, pre-release, production, etc.), but traditional models are mostly one-time manual configurations, lack standardized and reusable processes, have low efficiency due to repetitive operations, and are prone to inconsistencies in configurations across multiple environments, which cannot meet the needs of large-scale deployment.

[0008] In summary, existing application installation models that rely on fragmented data and require collaboration among multiple personnel suffer from drawbacks such as non-standardized data management, low execution accuracy, high communication costs, lack of development control, and insufficient scalability. This results in low installation efficiency, frequent failures, and inconsistent deployments, hindering deployment delivery efficiency and quality, and failing to meet the industry's demands for efficient, standardized, and precise installation processes. Therefore, there is an urgent need for an application installation model that is directly controlled by developers, eliminates the need for cross-personnel communication, and ensures accurate installation execution to address these issues. Summary of the Invention

[0009] This application provides an application installation package installation process control method, storage medium, and electronic device to facilitate different developers in building and installing application installation packages.

[0010] In a first aspect, embodiments of this application provide a method for controlling the installation process of an application installation package, comprising: constructing an application installation package, the application installation package including: an info.json service folder recording basic application information, a conf folder storing configuration information files, a gateway folder storing routing information, a cdn folder storing files to be stored in a CDN, and a data folder storing Docker image files and a database; installing the application installation package, comprising: decompressing the application installation package; reading the conf folder and writing the configuration information in the conf folder into the configuration service; reading the gateway folder and writing the routing information in the gateway folder into the gateway service; reading the cdn folder and writing the information in the cdn folder into the CDN service; reading the basic application information in the info.json service folder, creating account and password information, and writing the account and password information into the configuration service; reading the corresponding files in the data folder, starting the Docker service, and running the database files in the Docker container.

[0011] In one implementation of the first aspect, the configuration information of the configuration file to be configured in the conf folder is written to the .yml file in the conf folder according to a preset fixed format; wherein, the variable values ​​in the preset fixed format are configured as placeholders.

[0012] In one implementation of the first aspect, when the application installation package is installed and deployed to different environments, reading the conf folder and writing the configuration information in the conf folder into the configuration service includes: reading the environment variables of the current environment; replacing the placeholders of the configuration files in the conf folder with the environment variables of the current environment; and writing the replaced configuration information in the conf folder into the configuration service.

[0013] In one implementation of the first aspect, in the gateway folder storing routing information, the configuration information of each route is written into a separate JSON file; reading the gateway folder and writing the routing information in the gateway folder into the gateway service includes: traversing all JSON files in the gateway folder and parsing the routing configuration information of each file; calling the automated interface provided by the gateway service to submit all the parsed routing configuration information to the gateway service to complete the route registration.

[0014] In one implementation of the first aspect, the CDN folder stores files to be stored in the CDN according to the folder path; the step of reading the CDN folder and writing the information of the CDN folder to the CDN service includes: reading the folder path corresponding to each file; creating a folder corresponding to the folder path according to the folder path, and storing the file in the corresponding folder; generating a file access path for accessing the folder according to the folder path.

[0015] In one implementation of the first aspect, the Docker image file includes: a Docker image package and an image startup file; the database file includes a database upgrade script file.

[0016] In one implementation of the first aspect, reading the corresponding file in the data folder, starting the Docker service, and running the database file in the Docker container includes: traversing the directory of the data folder, finding and obtaining the Docker image package, decompressing the Docker image package, and executing the Docker loading command to load the image; finding and obtaining the image startup file in the data folder, and starting the Docker container; reading the database upgrade script file, and running the database upgrade script file in the Docker container.

[0017] Secondly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, characterized in that the computer program, when executed by a processor, implements the application installation package installation process control method as described above.

[0018] Thirdly, embodiments of this application provide a computer program product, which includes computer program code. When the computer program code is run on a computer, the computer implements the application installation package installation process control method described above.

[0019] Fourthly, embodiments of this application provide an electronic terminal, including a memory, a processor, and a computer program stored in the memory, characterized in that the processor executes the computer program to implement the application installation package installation process control method as described above.

[0020] The application installation package installation process control method, storage medium, and electronic device provided in this application embodiment have the following beneficial effects:

[0021] This application facilitates the building and installation of application packages by different developers, significantly reduces communication costs between operations and maintenance personnel and developers, reduces errors caused by human intervention, standardizes the deployment process of application packages, ensures developers' accurate expectations of application installation results, and improves deployment efficiency and consistency. Attached Figure Description

[0022] Figure 1 The diagram shown is an overall flowchart of an application installation package installation process control method according to an embodiment of this application.

[0023] Figure 2 The diagram shown illustrates the processing flow of the conf folder during application installation in the application installation package installation process control method according to an embodiment of this application.

[0024] Figure 3 The diagram shown illustrates the processing flow of the gateway folder during application installation in the application installation package installation process control method according to an embodiment of this application.

[0025] Figure 4 The diagram shows the processing flow of the CDN folder during application installation in the application installation package installation process control method according to an embodiment of this application.

[0026] Figure 5 The diagram shown illustrates the processing flow of the data folder during application installation in an application installation package installation process control method according to an embodiment of this application.

[0027] Figure 6 The diagram shown is an implementation architecture diagram of an application installation package installation process control method according to an embodiment of this application.

[0028] Figure 7 The diagram shown illustrates the overall implementation principle of the application installation package installation process control method according to an embodiment of this application.

[0029] Figure 8 The diagram shown is a schematic diagram of the principle structure of an electronic terminal in one embodiment of this application. Detailed Implementation

[0030] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0031] This embodiment provides an application installation package installation process control method, storage medium, and electronic device. By combining the application installation package structure and installation process, a new software installation process model is defined. This model can parse standard, compliant application installation package structures and complete the entire lifecycle of software application installation. Furthermore, this embodiment provides a standardized application installation package structure and a standardized installation process, facilitating the creation of application installation packages by different developers. Standardization also eliminates the need for developers to communicate with operations and maintenance personnel. Simultaneously, developers can store their own defined configuration information, database upgrade scripts, etc., in the corresponding locations according to the standard, and the execution results are consistent with the developers' expectations.

[0032] The following will refer to the appendices in the embodiments of this application. Figure 1 To be continued Figure 7 This application provides a detailed description of the technical solution for the application installation package installation process control method in the embodiments of this application. This allows those skilled in the art to understand and implement the application installation package installation process control method of this embodiment without creative effort.

[0033] This embodiment provides a method for controlling the application installation package installation process. Figure 1 The flowchart shown is an example of the application of the installation package installation process control method in this application embodiment. For example... Figure 1 As shown, the application installation package installation process control method provided in this application embodiment includes the following steps S100 to S500.

[0034] Step S100: Build an application installation package, which includes: an info.json service folder that records basic application information, a conf folder that stores configuration information files, a gateway folder that stores routing information, a cdn folder that stores files that need to be stored in the CDN, and a data folder that stores Docker image files and databases.

[0035] Step S200, install the application installation package, including the following steps S210 to S260.

[0036] Step S210: Unzip the application installation package;

[0037] Step S220: Read the conf folder and write the configuration information in the conf folder into the configuration service;

[0038] Step S230: Read the gateway folder and write the routing information in the gateway folder into the gateway service;

[0039] Step S240: Read the CDN folder and write the information of the CDN folder to the CDN service;

[0040] Step S250: Read the application basic information from the info.json service folder, create account and password information, and write the account and password information to the configuration service;

[0041] Step S260: Read the corresponding file in the data folder, start the Docker service, and run the database file in the Docker container.

[0042] In this embodiment, the application installation package is standardized, and the installation process of the application installation package is fully automated. The communication costs between development and operation and maintenance are eliminated by the unified installation package specification, and manual operation is replaced by an automated installation engine.

[0043] The following is a combination of Figure 2 and Figure 3. Figure 7 The steps S100 to S200 of the installation package installation process control method in this embodiment will be described in detail.

[0044] Step S100: Build the application installation package, which includes: an info.json service folder that records basic application information, a conf folder that stores configuration information files, a gateway folder that stores routing information, a cdn folder that stores files that need to be stored in the CDN, and a data folder that stores Docker image files and databases.

[0045] In some related technologies, the installation package generally refers to a Java JAR file or a Docker image file. In this embodiment, the application installation package directory includes:

[0046] 1) The info.json service folder: Contains basic service information, recording the service name, version, etc. This file records application information, specified by the developers, so operations personnel do not need to verbally ask the developers for application installation package information when installing the application package.

[0047] 2) conf folder: Stores configuration information files. The application installation package includes configuration files, which solves the problem of manually modifying configuration files when the environment is different.

[0048] 3) gateway folder: Stores routing information and is used to register interface information with the API gateway.

[0049] 4) CDN folder: Stores file information that needs to be stored in the CDN.

[0050] 5) The data folder contains Docker image files and database upgrade script files.

[0051] In this embodiment, a unified installation package directory / file standard is used to eliminate communication ambiguities between development and operations.

[0052] Step S200, install the application installation package, including the following steps S210 to S260.

[0053] Step S210: Unzip the application installation package.

[0054] In this embodiment, the application installation package is first pre-verified: it is checked whether the installation package is in ZIP format, whether the naming conforms to the rules, and whether the remaining disk space meets the installation requirements.

[0055] In this embodiment, the application installation package is decompressed to a temporary directory, wherein the directory name contains a random string to avoid overwriting; after decompression, the directory structure of the application installation package is verified a second time, and if any key files are missing, the installation is terminated and the temporary directory is cleaned up.

[0056] If the application installation package is large, directly decompressing it during installation will trigger a memory overflow. In this embodiment, large application installation packages (e.g., >1GB) are decompressed in blocks to avoid memory overflow.

[0057] Specifically, the binary data of the application installation package is split into small blocks of fixed size (e.g., 10MB / block) instead of being read all at once; the data of the application installation package is processed block by block, for example, only one block is read into memory at a time, the contents of the block are decompressed and written to the disk; after writing one block, the memory of that block is immediately released before reading the next block.

[0058] Large application installation packages are processed by segmented decompression. The total memory usage is only equal to the size of a single block plus a small amount of metadata, such as 10MB plus a few KB, which is far lower than the total size of the large installation package, thus completely avoiding overflow.

[0059] The application installation package requires a connection to middleware such as Redis and MySQL to run, but the middleware addresses / accounts for development, testing, and production environments are completely different. For example:

[0060] Development environment: Redis address is local (127.0.0.1), MySQL uses the test database account; Test environment: Redis address is the test server (192.168.1.50), MySQL uses the test environment account.

[0061] Production environment: The Redis address is the production cluster address 10.0.0.20, and the MySQL uses the production account.

[0062] The existing approach involves developers packaging configuration files (such as redis.yml) into the application installation package. When deploying to different environments, operations personnel manually open the configuration file and change the address / account to the corresponding environment's values. This process is prone to problems: incorrect IP addresses, forgotten passwords, forgetting to save changes, and even inconsistencies in the format used by different operations personnel, leading to application startup failures.

[0063] To address the aforementioned issues, in one implementation of this embodiment, the configuration information of the configuration file to be configured in the conf folder is written to the .yml file in the conf folder according to a preset fixed format; wherein, the variable values ​​in the preset fixed format are configured as placeholders.

[0064] For example, developers may configure Redis and MySQL in a fixed format (written in a .yml file in the conf folder). Regardless of the environment, the file structure and field names are completely consistent (e.g., they all have Spring.Redis.Host and Spring.Datasource.Url), only the values ​​are replaced with placeholders to represent the fixed values.

[0065] Figure 2 This diagram illustrates the processing flow of the conf folder during application installation in an application installation package installation process control method according to an embodiment of this application. (See diagram for details.) Figure 2 As shown, in one implementation of this embodiment, when the application installation package is installed and deployed to different environments, reading the conf folder and writing the configuration information in the conf folder into the configuration service includes the following steps S221 to S223.

[0066] Step S221: Read the environment variables of the current environment;

[0067] Step S222: Replace the placeholders in the configuration files in the conf folder with the environment variables of the current environment;

[0068] Step S223: Write the configuration information in the replaced conf folder into the configuration service.

[0069] The developers write the Redis and MySQL configurations in a fixed format in the .yml file in the conf folder. Regardless of the environment, the file structure and field names are completely consistent. For example, they all have Spring.Redis.Host and Spring.Datasource.Url. The only difference is that the values ​​can be replaced with placeholders.

[0070] When the application installation package is deployed to different environments, it reads the environment variables of the current environment. For example, if the production environment has REDIS_HOST=10.0.0.20 configured in advance, it replaces the placeholders in the configuration files in the conf folder with the actual values ​​of the current environment, such as replacing ${REDIS_HOST} with 10.0.0.20.

[0071] The installer writes the replaced configuration to a unified configuration service (such as Nacos / Apollo). When the application starts, it directly pulls the corresponding environment configuration from the configuration service instead of reading local files. Even if the configuration needs to be changed later (such as changing the Redis password), only the value in the configuration service needs to be changed, without repackaging / deploying the application.

[0072] As can be seen in this embodiment, the configuration file structure is uniform, the installer can automatically parse it, and automatically adapt the configuration values ​​of different environments through placeholders and environment variables. The configuration is stored in the configuration service, and the application package does not need to be modified when changing the configuration. Therefore, in this embodiment, the operation and maintenance personnel can deploy the application installation package to any environment without manually opening the configuration file and changing a single line of code, which avoids human error and greatly improves deployment efficiency.

[0073] When deploying the application installation package, the following steps are required to configure the routing:

[0074] Developers verbally or in writing instruct operations to specify the meeting booking route path as xxxx / xxxx, the ID as xxxx, and the icon path as / xxx / xxx.png. Operations then logs into the gateway's management backend (or modifies the gateway configuration file) and manually enters the ID, path, name, and icon information. This manual configuration is repeated in both test and production environments, which is prone to errors: such as entering the wrong path (omitting a slash), missing the icon, or even configuring the route to the wrong application. If the application has 10 interface routes, operations must add them manually one by one, which is inefficient and prone to confusion.

[0075] In this embodiment, the tasks that maintenance personnel would normally perform are pre-written into a standardized file by the development team and then automatically completed by the installation program, requiring no manual intervention from maintenance personnel.

[0076] Specifically, in one implementation of this embodiment, the configuration information for each route in the gateway folder where routing information is stored is written into a separate JSON file. The route configurations are stored in JSON format in a fixed directory, which the installation program can recognize.

[0077] Figure 3 This diagram illustrates the processing flow of the gateway folder during application installation in an application installation package installation process control method according to an embodiment of this application. Figure 3 As shown, reading the gateway folder and writing the routing information in the gateway folder into the gateway service includes the following steps S231 to S232.

[0078] Step S231: Traverse all JSON files in the gateway folder and parse out the routing configuration information of each file;

[0079] Step S232: Call the automated interface provided by the gateway service to submit all parsed routing configuration information to the gateway service and complete the route registration.

[0080] In this embodiment, the developers write each routing rule (such as meeting appointment) into a separate JSON file (such as web.json) and put it into the Gateway folder of the application installation package.

[0081] In this embodiment, when the application installation package installer is executed, it first traverses all JSON files in the Gateway folder and parses the routing information (Id, Path, Name, etc.) of each file; then it calls the automated interface provided by the gateway (such as the gateway's REST API) to automatically submit this routing information to the gateway service and complete the route registration.

[0082] In this embodiment, the installation process automatically reads the configuration and calls the gateway API to complete registration, replacing manual operation. The entire process does not require operations and maintenance personnel to log in to the gateway backend or manually enter any information; the installation program is completed entirely automatically. Developers no longer need to repeatedly confirm routing information with operations and maintenance personnel. The configuration is written in a file, and the version is controllable (e.g., managed by Git), allowing for traceability of modification records. The routing configuration and application installation are bound together, which not only saves the workload of operations and maintenance personnel but also avoids communication errors and human mistakes, making gateway routing management more efficient and standardized.

[0083] In related technical solutions, the images used to deploy the application typically include:

[0084] 1) The developer needs to write documentation / verbally tell the operations team: 1.png should be uploaded to the / cdn / person / icon folder on the file server, and 2.png should be uploaded to the / cdn / person / img folder;

[0085] 2) The operations and maintenance personnel should first log in to the file server and manually create the corresponding folders (first create person, then create icon and img in person);

[0086] 3) The maintenance team then manually uploads 1.png and 2.png to their respective folders;

[0087] 4) Finally, you need to manually construct the access path (e.g., https: / / file.com / cdn / person / icon / 1.png) to confirm that it can be accessed normally.

[0088] This process is not only time-consuming but also prone to errors: for example, the folder name is misspelled (e.g., "icon" is written as "icons"), files are sent to the wrong directory, or files are omitted, which can cause images in the application to not display.

[0089] In this embodiment, the developer places the files into the CDN directory of the installation package according to the path to be ultimately located on the file server. The installer will automatically complete all operations without requiring manual intervention from operations and maintenance personnel.

[0090] Figure 4 This diagram illustrates the processing flow of the CDN folder during application installation in an application installation package installation process control method according to an embodiment of this application. (See diagram for details.) Figure 4 As shown, in one implementation of this embodiment, the CDN folder stores the files that need to be stored in the CDN according to the folder path; reading the CDN folder and writing the information of the CDN folder to the CDN service includes the following steps S241 to S243.

[0091] Step S241: Read the folder path corresponding to each file;

[0092] Step S242: Create a folder corresponding to the folder path according to the folder path, and store the file in the corresponding folder;

[0093] Step S243: Generate a file access path to access the folder based on the folder path.

[0094] The developers first determine the final storage path of each file, and then completely replicate this path to store the files in the CDN directory of the installation package.

[0095] When the application installer is executed, it will automatically traverse the CDN directory and perform all operations:

[0096] 1) Path recognition: Read the relative path of each file (e.g., the relative path of 1.png is person / icon / 1.png);

[0097] 2) Automatic folder creation and file transfer: On the file server, automatically create folders / cdn / person / icon / and / cdn / person / img / , and then upload 1.png and 2.png to the corresponding folders respectively;

[0098] 3) Generate access path: Concatenate the file server domain name + / cdn + relative path to obtain the final usable access link:

[0099] 1.png → https: / / file.com / cdn / person / icon / 1.png

[0100] 2.png → https: / / file.com / cdn / person / img / 2.png

[0101] In this embodiment, the structure of the CDN directory within the application installation package is the final structure of the file server's / cdn / directory. Developers don't need to repeatedly confirm with operations and maintenance which directory to place files in; the directory structure is agreed upon, eliminating the need for verbal communication. The installer automatically creates folders, transfers files, and generates access paths according to the directory structure, without any manual intervention. The installer is copied to the file server exactly as the directory structure is defined. The paths are set during development and maintenance doesn't need to be monitored during deployment, completely avoiding issues like incorrect paths or missing files. In short, developers arrange the files according to their final location during packaging, and the installer automatically places them on the file server in that location, saving all manual operations and communication.

[0102] In one implementation of this embodiment, the Docker image file includes: a Docker image package and an image startup file; the database file includes a database upgrade script file. The Docker image package (e.g., meeting.zip) contains a directly executable application image, which is the application installation package; the image startup file is the Docker startup configuration file (e.g., docker-compose.yml), which defines how the Docker container starts (e.g., port mapping, dependent middleware, environment variables); the database upgrade script file is the database initialization / upgrade script (e.g., 1. SQL to create tables, 2. SQL to add fields).

[0103] In relevant technical solutions, the operation and maintenance of application deployment and database upgrades includes the following processes, each of which is prone to problems:

[0104] 1) High communication costs: Operations and maintenance personnel have to repeatedly ask the development team for the latest Docker image package, the correct docker-compose.yml, and the database upgrade script, and also have to confirm the script execution order;

[0105] 2) Errors are common in execution order: For example, if the developer provides SQL 1 (to create a table) and SQL 2 (to add fields), and the operations team accidentally runs SQL 2 first when executing it manually, it will immediately throw an error because the table has not been created, so how can fields be added?

[0106] 3) Repeated execution can easily cause problems: For example, if the operations and maintenance personnel forget which script has been executed, and run 1.sql repeatedly (repeated execution of table creation statements will prompt that the table already exists), it will cause database errors;

[0107] 4) Cumbersome manual operation: It requires manually loading the Docker image, manually executing docker-compose up to start the container, and manually logging into the database to execute SQL, which involves many steps and is time-consuming.

[0108] In this embodiment, the developer packages all the files required for deployment / upgrade into the Data folder according to the rules, and the installation program handles it automatically, without requiring any manual intervention from the operations and maintenance team.

[0109] In this embodiment, developers only need to do three things: put the files into the Data folder:

[0110] 1) Docker image package: Name it {application name}.zip (e.g., meeting.zip), and place it in the Data directory;

[0111] 2) Startup configuration: Write the docker-compose.yml file (which defines the container startup rules) and place it in the Data directory;

[0112] 3) SQL scripts: Name them by number and function (e.g., 1init_table.sql, 2add_user_field.sql), the number represents the execution order, and place them in the Data directory.

[0113] Figure 5 This diagram illustrates the processing flow of the data folder during application installation in an application installation package installation process control method according to an embodiment of this application. (See diagram for details.) Figure 5 As shown, in one implementation of this embodiment, reading the corresponding file in the data folder, starting the Docker service, and running the database file in the Docker container includes the following steps S261 to S263.

[0114] Step S261: Traverse the directories of the data folder, find and obtain the Docker image package, decompress the Docker image package, and execute the docker load command to load the image;

[0115] Step S262: Locate and obtain the image startup file in the data folder, and start the Docker container;

[0116] Step S263: Read the database upgrade script file and run the database upgrade script file inside the Docker container.

[0117] When the application installer is executed, it automatically traverses the Data directory and executes the following:

[0118] 1) Automatically load Docker images

[0119] The system iterates through the Data directory to find .zip files (e.g., meeting.zip), extracts them, and then executes the `docker load` command to load the image (e.g., `docker load -i meeting.tar`, where the zip file contains the image tar archive). This eliminates the need for manual image downloading and loading by system administrators; the installer automatically finds and loads the image.

[0120] 2) Automatically start Docker containers

[0121] Locate the docker-compose.yml file in the Data directory and automatically execute the docker-compose up -d command to start the container. The startup rules follow the docker-compose.yml file written by the developer, so operations and maintenance personnel do not need to manually write startup commands or change ports / environment variables, thus avoiding incorrect parameter input.

[0122] 4) Automatically execute SQL scripts in sequence

[0123] This step completely resolves the issues of incorrect execution logs and execution order:

[0124] 4-1) Sorting: Read all .sql files in the Data directory and sort them in ascending order by the numerical sequence of the filenames (1.sql→2.sql→3.sql, the order will never be out of order);

[0125] 4-2) Check execution records: The installer maintains an SQL execution record table in the configuration service / database, such as recording application name + script name + execution time + status. First, check which scripts have been executed;

[0126] 4-3) Execute scripts that have not yet been executed: Only execute scripts that are not in the record table. For example, if 1.sql has already been executed, only 2.sql will be executed.

[0127] 4-4) Record execution results: After a script is executed, the message "meeting+2.sql+2025-12-31 + success" is written to the record table and will not be executed again during the next installation.

[0128] In this embodiment, the installer automatically loads the image, starts the container, and executes SQL in sequence, replacing all manual operations. The sorting is based on the filename numbers, and the execution records are based on the system, so there will be no problems with incorrect execution order or duplicate execution. Developers no longer need to verbally tell operations and maintenance to execute 1.sql first and then 2.sql, or that the image package is on XX cloud drive, etc. The files are all in the Data folder, and the installer follows the rules. The files in the Data folder are bound to the installation package, and which version of the application corresponds to which version of the image and which version of the SQL script, which is traceable and rollbackable.

[0129] Figure 6 The diagram shown is an implementation architecture diagram of an application installation package installation process control method according to an embodiment of this application. Figure 7 This diagram illustrates the overall implementation principle of an application installation package installation process control method according to an embodiment of this application. Figure 6 and Figure 7 As shown, the overall implementation process of the application installation package installation process control method in this embodiment is as follows:

[0130] S01. Unzip the installation package.

[0131] The installer first verifies the installation package format (e.g., it must be ZIP), the naming convention ({namespace}_{version}.zip), and checks the remaining disk space on the deployment node, for example, it must be ≥ 3 times the size of the installation package to avoid decompression failure.

[0132] Then create a temporary directory with the naming convention / tmp / {namespace}_{version}_{timestamp}_{random string} (e.g., / tmp / meeting_1.0.0_20251231_8a3f) to avoid directory conflicts when installing multiple applications.

[0133] Then, use the Python zipfile module (or the system unzip command) to decompress large installation packages (>1GB) in chunks to reduce memory usage.

[0134] After decompression, the system automatically verifies the directory structure: for example, it must contain info.json, and at least one of conf / gateway / data must exist; if a critical file is missing, the installation will terminate, the temporary directory will be cleaned up, and an error message will be displayed indicating that the installation package structure is invalid.

[0135] S02. Read all files in the conf folder and write them into the configuration service according to the contents of the files to provide the corresponding configuration information for application startup.

[0136] First, iterate through all YAML files in the conf directory (only .yml / .yaml files are supported) and parse the content using the PyYAML library; replace the environment placeholders in the configuration (such as ${REDIS_HOST}): read the corresponding values ​​from the environment variables of the deployment node (such as export REDIS_HOST=192.168.1.100) to achieve environment adaptation.

[0137] Then, connect to the configuration center (such as Nacos / Apollo), using {namespace} / {filename} as the configuration ID (e.g., meeting / redis.yml), and submit the configuration content via the configuration center's Open API (e.g., Nacos's POST / nacos / v1 / cs / configs). In this embodiment, AES symmetric encryption (the key is stored in the installer's secure configuration file, with no plaintext exposure) can be used before writing to the configuration service.

[0138] S03. Read all files in the gateway folder and write them into the gateway service according to the contents of the files to provide routing and forwarding services for the application.

[0139] First, iterate through the JSON files in the gateway directory, parse the content using json.load, and supplement metadata (such as application namespace, version, and route creation time); the route ID is uniformly standardized as {namespace}_{business identifier} (such as meeting_book) to ensure global uniqueness.

[0140] Then call the API gateway's management interface (such as Spring Cloud Gateway's POST / admin / routes), carrying Bearer Token authentication (the API Key of the gateway pre-configured in the installer); if the route ID already exists, it will be overwritten if it is the same version, the user will be prompted to confirm if it is a lower version, and overwriting will be prohibited if it is a higher version, to avoid route abnormalities caused by rolling back the version.

[0141] S04. Read all folders and files in the CDN folder and write them to the CDN service in folder / file format to provide file services for the application.

[0142] First, generate the path:

[0143] The CDN directory is recursively traversed using os.walk to generate relative file paths (e.g., person / icon / 1.png); these paths are then concatenated with the CDN base domain name (e.g., https: / / file.com / ) to obtain the complete access path. https: / / file.com / cdn / person / icon / 1.png.

[0144] Then upload the file:

[0145] Calculate the MD5 value of the file (using hashlib.md5) and call the CDN service's file deduplication API; if the MD5 already exists, skip the upload (reduce redundant transmission); large files (>10MB) are uploaded in chunks (each 10MB is one chunk), and resume interrupted uploads are supported; after the upload is complete, call the CDN's file access verification API to verify that the file can be accessed normally.

[0146] S05. Read the basic application information from info.json, create users and passwords in various middleware such as the database and Redis according to the username and create random passwords, and write the user and password information to the configuration service for application use.

[0147] In this embodiment, application accounts for middleware (database, Redis) are automatically generated to avoid the security risks of manual configuration.

[0148] 1) Account generation rules:

[0149] Username: Fixed to {namespace}_app (e.g., meeting_app) to ensure global uniqueness within the middleware;

[0150] Password: A 16-character random string (containing uppercase and lowercase letters, numbers, and special characters) is generated using secrets.token_urlsafe(16), providing high security.

[0151] 2) Middleware account creation:

[0152] Database (e.g., MySQL): Execute the SQL command `CREATE USER IF NOT EXISTS 'meeting_app'@'%' IDENTIFIED BY 'password'; GRANT SELECT,INSERT,UPDATE ON meeting_db.* TO 'meeting_app'@'%';` (grant minimum privileges).

[0153] Redis (6.0+): Execute the ACL command ACL SETUSER meeting_app ON >password~meeting:*+@read +@write (restricts access to the specified key prefix).

[0154] 3) Configuration writing: Store the encrypted account password in the configuration service's {namespace} / auth.yml (e.g., meeting / auth.yml) for the application to read at startup.

[0155] S06. Read the Docker image file in the data directory and load the Docker image.

[0156] Unzip the image package and load it into the Docker environment to prepare for container startup.

[0157] First, unzip the image package: unzip the {namespace}.zip file (e.g., meeting.zip) in the data directory, and extract the Docker image tar package (e.g., meeting.tar) inside.

[0158] Next, load the image: Execute `docker load -i / tmp / meeting_image / meeting.tar` (ensure the installer is running in the docker user group, or configure passwordless sudo).

[0159] If the Docker service is not running, automatically execute `systemctl start docker` to start the service; after loading, verify the existence of the image using `docker images | grep {namespace}:{version}` (e.g., `meeting:1.0.0`).

[0160] S07. Start the Docker service based on the docker-compose.yml file in the data directory. Read the contents of the database upgrade script file and run the database upgrade script file in the Docker container.

[0161] In this embodiment, a Docker container is started to automatically execute the database upgrade script, avoiding the sequential / repetitive issues of manual execution.

[0162] First, start the container:

[0163] Replace the placeholders in docker-compose.yml (e.g., ${MYSQL_PASSWORD} → password in the configuration service); execute docker-compose up -d in the data directory to start the container, and check the container status using docker-compose ps (it must be Up).

[0164] Then execute the database script:

[0165] Script sorting: Sort in ascending order by the numerical sequence of the SQL file name (e.g., 1.sql→2.sql);

[0166] Idempotent execution: Reads the {namespace}_script_executed record (e.g., ["1.sql"]) from the configuration service and executes only scripts not recorded.

[0167] Execution method: Use `docker exec -i {container name} mysql -u root -p"root password" {database name} < {script file}` (e.g., `docker exec -i meeting_mysql mysql -u root -p123456meeting_db < 2.sql`).

[0168] When a container fails to start, error logs (such as database connection failures) are retrieved via docker-compose logs; when SQL execution fails, transactions are automatically rolled back and the container is stopped.

[0169] S08. The Docker container is running normally, and the entire process is complete.

[0170] The application installation process described in this embodiment transforms the traditional application installation process, which requires manual communication and operation, into a streamlined operation without human intervention through a standardized installation package and an automation engine. This reduces maintenance costs and avoids human errors, such as script execution order or configuration omissions.

[0171] The scope of protection of the application installation package installation process control method described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0172] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the application installation package installation process control method provided in any embodiment of this application.

[0173] In this embodiment, any combination of one or more storage media can be used. The storage medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0174] This application also provides an electronic terminal. Figure 8 This is a schematic block diagram of the electronic terminal provided in an embodiment of this application. Figure 8 As shown, the electronic terminal in this embodiment includes at least one processor 401, a memory 402, at least one network interface 403, and a user interface 405. The various components in the device are coupled together via a bus system 404. It is understood that the bus system 404 is used to implement communication between these components. In addition to a data bus, the bus system 404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 The general will label all buses as bus systems.

[0175] The user interface 405 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0176] It is understood that memory 402 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0177] In this embodiment of the invention, the memory 402 is used to store various types of data to support the operation of the electronic terminal 400. Examples of this data include: any executable program for operation on the electronic terminal 400, such as the operating system 4021 and application programs 4022; the operating system 4021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. The application program 4022 may contain various applications, such as a media player, browser, etc., for implementing various application services. The method for implementing the application installation package installation process control method provided in this embodiment of the invention may be included in the application program 4022.

[0178] The methods disclosed in the above embodiments of the present invention can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 401 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 401 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0179] In an exemplary embodiment, the electronic terminal 400 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned method.

[0180] According to the method provided in the embodiments of this application, the embodiments of this application also provide a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute... Figures 1 to 8The method of any of the embodiments shown.

[0181] In summary, this application facilitates the building and installation of application packages by different developers, significantly reduces communication costs between operations and maintenance personnel and developers, minimizes errors caused by manual intervention, standardizes the application package deployment process, ensures developers' accurate expectations of application installation results, and improves deployment efficiency and consistency. Therefore, this application effectively overcomes the various shortcomings of existing technologies and has high industrial application value.

[0182] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for controlling the installation process of an application installation package, characterized in that, include: Build an application installation package, which includes: an info.json service folder that records basic application information, a conf folder that stores configuration information files, a gateway folder that stores routing information, a cdn folder that stores files that need to be stored in the CDN, and a data folder that stores Docker image files and databases; Installing the application installation package includes: Unzip the application installation package; Read the conf folder and write the configuration information in the conf folder into the configuration service; Read the gateway folder and write the routing information in the gateway folder into the gateway service; Read the CDN folder and write the information of the CDN folder to the CDN service; Read the basic application information from the info.json service folder, create account and password information, and write the account and password information to the configuration service; Read the corresponding file in the data folder, start the Docker service, and run the database file in the Docker container.

2. The application installation package installation process control method according to claim 1, characterized in that, In the conf folder, the configuration information to be configured is written to the .yml file in the conf folder according to a preset fixed format; wherein, the variable values ​​in the preset fixed format are configured as placeholders.

3. The application installation package installation process control method according to claim 2, characterized in that, When the application installation package is installed and deployed to different environments, reading the conf folder and writing the configuration information in the conf folder into the configuration service includes: Read the current environment variables; Replace the placeholders in the configuration files in the conf folder with the environment variables of the current environment; Write the configuration information from the replaced conf folder into the configuration service.

4. The application installation package installation process control method according to claim 1, characterized in that, In the gateway folder where routing information is stored, the configuration information for each route is written into a separate JSON file; The step of reading the gateway folder and writing the routing information in the gateway folder into the gateway service includes: Iterate through all JSON files in the gateway folder and parse out the routing configuration information for each file; The automated interface provided by the gateway service is invoked to submit all parsed routing configuration information to the gateway service, thus completing the route registration.

5. The application installation package installation process control method according to claim 1, characterized in that, The CDN folder contains the files that need to be stored in the CDN according to the folder path; The step of reading the CDN folder and writing the information of the CDN folder to the CDN service includes: Read the folder path corresponding to each file; Create a folder corresponding to the folder path, and store the files in the corresponding folder; Generate a file access path to access the folder based on the folder path.

6. The application installation package installation process control method according to claim 1, characterized in that, The Docker image file includes: a Docker image package and an image startup file; the database file includes a database upgrade script file.

7. The application installation package installation process control method according to claim 6, characterized in that, The step of reading the corresponding file in the data folder, starting the Docker service, and running the database file in the Docker container includes: Traverse the directories of the data folder to find and obtain the Docker image package, decompress the Docker image package, and then execute the docker load command to load the image; Locate and retrieve the image startup file within the data folder, and start the Docker container; The database upgrade script file is read and run within the Docker container.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the application installation package installation process control method as described in any one of claims 1 to 7.

9. A computer program product, characterized in that, The computer program product includes computer program code, which, when run on a computer, causes the computer to implement the application installation package installation process control method as described in any one of claims 1 to 7.

10. An electronic terminal, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the application installation package installation process control method as described in any one of claims 1 to 7.

Images