Multi-server deployment method and device

Abstract

The invention discloses a multi-server deployment method and device, and relates to the technical field of software deployment and operation and maintenance, and the method comprises the steps: constructing a local offline mirror image warehouse; establishing an application program resource template library bound with the local offline mirror image warehouse; receiving a deployment demand description object submitted by a user, and generating a deployment configuration file through the deployment demand description object and the application program resource template library; according to the method, automatic deployment is carried out in a multi-server cluster based on a deployment configuration file, an independent offline software warehouse is constructed, an application package, dependency and metadata are completely packaged, consistent application deployment can be executed without the Internet, and through an internal self-established offline warehouse and source-controllable resource management, it is ensured that a software source is reliable; and it is ensured that all the servers pull the consistent software version from the same offline warehouse, efficient and automatic deployment under the multi-server environment is achieved, the manual operation cost is reduced, and the deployment accuracy and consistency are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software deployment and operation and maintenance, and in particular to a multi-server deployment method and device. BACKGROUND

[0002] Multi-server software deployment, that is, efficiently and accurately deploying software applications to each server in a multi-server environment, is a key link to ensure stable operation and high performance of the system.

[0003] Current multi-server software deployment usually adopts the following modes: 1. Direct online pulling mode, that is, each server obtains an installation package from the Internet or an enterprise online source, such as directly installing through an online source such as apt, yum, pip, docker registry, etc.; 2. Manual packaging and manual distribution mode, that is, an operation and maintenance personnel manually downloads an installation package on one device, and then distributes it to other servers through a U disk, file sharing or SCP; 3. Semi-automatic script deployment mode, that is, using an automated script such as Ansible or SaltStack for distribution, but still relying on an Internet source or a temporary package manually constructed. The current multi-server software deployment relies more on online resources and cannot cope with offline network environments, so that the software package cannot be deployed in an offline network environment, and manual downloading and distribution methods cannot guarantee that the versions obtained by each server are completely consistent, resulting in an environment that cannot be repeated and audited. SUMMARY

[0004] The main purpose of the present application is to provide a multi-server deployment method and device, aiming to solve the technical problems in the prior art that multi-server software deployment relies on online resources, cannot cope with offline network environments, and manual downloading and distribution methods cannot guarantee that the versions of the servers are consistent.

[0005] To achieve the above purpose, the present application provides a multi-server deployment method, which comprises: constructing a local offline mirror image warehouse, wherein the local offline mirror image warehouse is obtained by deployment in a preset network environment, and the preset network environment is a network environment isolated from a public network; establishing an application program resource template library bound to the local offline mirror image warehouse; receiving a deployment requirement description object submitted by a user, and generating a deployment configuration file through the deployment requirement description object and the application program resource template library; automatically deploying in a multi-server cluster based on the deployment configuration file.

[0006] In an embodiment, the step of constructing a local offline mirror image warehouse comprises: obtaining a preset network environment isolated from a public network; A centralized open-source container image repository is deployed in the preset network environment, wherein a container orchestration platform cluster is deployed in the open-source container image repository; Deploy a P2P image distribution synchronization network subsystem within the container orchestration platform cluster of the open-source container image repository; Obtain the base image resources, application image resources, and the dependent image resources required by the system; The base image resources, the application image resources, and the dependent image resources required by the system are stored in the open-source container image repository to obtain a local offline image repository.

[0007] In one embodiment, the step of building a local offline image repository includes: Obtain a preset network environment isolated from the public network; A centralized open-source container image repository is deployed in the preset network environment, wherein a container orchestration platform cluster is deployed in the open-source container image repository; Deploy a P2P image distribution synchronization network subsystem within the container orchestration platform cluster of the open-source container image repository; Obtain the base image resources, application image resources, and the dependent image resources required by the system; The base image resources, the application image resources, and the dependent image resources required by the system are stored in the open-source container image repository to obtain a local offline image repository.

[0008] In one embodiment, the step of establishing an application resource template library bound to the local offline image repository includes: Construct an initial application resource template library containing a variety of pre-built resource templates, wherein the pre-built resource templates correspond to different application types and different deployment environments; Bind the preset resource template to the local offline image repository, so that the image reference in the template points to the local offline image repository; The initial application resource template library is updated based on the binding result to obtain the application resource template library.

[0009] In one embodiment, the step of binding the preset resource template to the local offline image repository includes: Obtain the mirror address prefix from each of the preset resource templates; Obtain the address of the local offline image repository; The image address prefix is ​​set to the address of the local offline image repository, so that the image reference in the template points to the local offline image repository, thus completing the binding of the preset resource template with the local offline image repository.

[0010] In one embodiment, the step of receiving a deployment requirement description object submitted by a user and generating a deployment configuration file using the deployment requirement description object and the application resource template library includes: Receive the deployment requirement description object submitted by the user, parse the deployment requirement description object, and obtain the deployment parameters in the deployment requirement description object; Match the target preset resource template corresponding to the deployment parameters from the application resource template library; The deployment parameters are injected into the target preset resource template to generate a deployment configuration file.

[0011] In one embodiment, before the step of injecting the deployment parameters into the target preset resource template and generating the deployment configuration file, the method further includes: The deployment requirement description object is parsed to determine the image reference information; Based on the image reference information, obtain the repository address, project, image name, and image tag; The target metadata query interface provided by the local offline image repository is determined based on the repository address and the project. Call the target metadata query interface to verify whether the image name and the image tag are located in the local offline image repository; When the image name and the image tag are located in the local offline image repository, the step of injecting the deployment parameters into the target preset resource template and generating a deployment configuration file is performed.

[0012] In one embodiment, the step of automatically deploying based on the deployment configuration file in a multi-server cluster includes: Create application deployment nodes in a multi-server cluster based on the aforementioned deployment configuration file; The application deployment nodes are scheduled to preset nodes through the scheduler of the container orchestration platform; Obtain the image cache information detected by the preset node; When the image cache information indicates that the image required for deployment is not cached locally and other nodes in the cluster do not cache the image required for deployment, a pull request is initiated through the P2P image distribution synchronization network subsystem in the local offline image repository to pull the corresponding target image from the local offline image repository and cache the target image locally. After the target image is pulled, start the container instance to complete the application deployment.

[0013] In one embodiment, after the step of obtaining the image cache information detected by the preset node, the method further includes: When the image cache information indicates that the image required for deployment has been cached locally, the node load and network latency are determined through a preset sharding cache distribution mechanism. The target cache node for providing the target image is determined by the node load and the network latency, wherein the preset shard cache distribution mechanism is used to determine the target cache node based on the node load and network latency; The target image is obtained from the target cache node, and a container instance is started to complete the application deployment.

[0014] In one embodiment, the method further includes: Obtain a monitoring toolchain, wherein the monitoring toolchain includes metric monitoring tools, log management tools, and visualization tools; The deployed application is monitored in real time through the monitoring toolchain to obtain monitoring information, which includes the application deployment node status, node resource usage status, log collection information, and event alarm information. The application is processed based on the monitoring information.

[0015] Furthermore, to achieve the above objectives, this application also proposes a multi-server deployment apparatus, which includes: A building module is used to build a local offline image repository, wherein the local offline image repository is deployed in a preset network environment, which is a network environment isolated from the public network; The module is used to create an application resource template library that is bound to the local offline image repository; The receiving and generating module is used to receive the deployment requirement description object submitted by the user, and generate a deployment configuration file through the deployment requirement description object and the application resource template library; The deployment module is used for automatic deployment in a multi-server cluster based on the deployment configuration file.

[0016] In addition, to achieve the above objectives, this application also proposes a multi-server deployment device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-server deployment method as described above.

[0017] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the multi-server deployment method described above.

[0018] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the multi-server deployment method described above.

[0019] One or more technical solutions proposed in this application have at least the following technical effects: 1) This solution supports deployment in a completely offline environment, eliminating the need for public network access for software installation, updates, and maintenance. Unified repository management improves consistency, ensuring version uniformity and environment consistency across all servers. This significantly reduces deployment costs and bandwidth consumption; the offline repository only needs to be synchronized once, and multiple servers can reuse it. Furthermore, the deployment process is automated, automatically generating deployment configuration files and deploying automatically through a multi-server cluster. This not only reduces the possibility of human error but also significantly accelerates the feedback cycle from requirements to actual deployment, reducing human error in batch deployments and improving efficiency and stability. Using a template library ensures that each deployment follows the same configuration and process, reducing problems caused by environmental differences and improving application consistency. All configurations originate from fixed templates, facilitating subsequent tracking and auditing of changes in the deployment environment.

[0020] 2) By deploying the image repository in a controlled network environment isolated from the public network, the risk of unauthorized access or tampering with critical container image resources from external networks is effectively blocked. This meets the requirements of data isolation and independent controllability in high-security scenarios, while also facilitating the implementation of unified security policies and auditing mechanisms. The local offline image repository does not rely on external networks or public cloud services. Even in abnormal situations such as public network outages, unavailability of remote repositories, or attacks, it can still stably provide image pull services, ensuring the continuous deployment and operation of containerized applications and improving overall system availability. Deploying a point-to-point image distribution synchronization subsystem within the container orchestration platform cluster can significantly reduce the bandwidth pressure on the central node and accelerate the concurrent distribution speed of images in large-scale clusters. This is particularly suitable for environments with a large number of nodes or limited network bandwidth, improving deployment efficiency and resource utilization. Storing base images, application images, and dependent images uniformly in the local open-source container image repository facilitates image version management, tagging policies, vulnerability scanning, and lifecycle governance, avoiding image drift issues.

[0021] 3) By constructing an initial template library containing various pre-built resource templates and classifying them for different application types and deployment environments, it ensures that various applications follow unified deployment specifications in different environments, reducing human configuration errors. Image references in templates that might have previously pointed to public network image repositories are uniformly replaced with corresponding image addresses in local offline image repositories. This ensures that applications can still successfully pull the required images and complete deployment based on the templates even in completely offline or restricted network environments, completely resolving the issues of having templates but no images or image pull failures. A clear mapping relationship is established between templates and local image versions. When an image is updated, the version tag of the corresponding template can be maintained synchronously, achieving integrated version management of "template-image," avoiding operational anomalies caused by image-configuration mismatches, and reducing operation and maintenance troubleshooting costs. Attached Figure Description

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

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

[0024] Figure 1 This is a flowchart illustrating an embodiment of the multi-server deployment method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the multi-server deployment method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the multi-server deployment method of this application; Figure 4 A simplified flowchart is provided for one embodiment of the multi-server deployment method of this application; Figure 5 This is a schematic diagram of the module structure of the multi-server deployment device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the multi-server deployment method in this application embodiment.

[0025] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] Because existing technologies rely on internet software sources for multi-server deployment, application installation and updates cannot be completed in isolated, weak, or controlled network environments. Furthermore, traditional manual distribution methods are prone to missing software packages, incomplete dependencies, or different versions used by different nodes, making the environment unreproducible. During installation, it is often necessary to manually log in to multiple servers one by one to execute installation commands, which is cumbersome and error-prone. In addition, obtaining software packages online may carry security risks and is difficult to meet strict audit requirements.

[0029] This application provides a solution that enables controllable, repeatable, and low-risk software deployment and updates across multiple servers by building an independent offline software package repository, a synchronization mechanism, centralized version management, and an automated distribution process. This solves the difficulties of traditional online dependency deployment methods in scenarios with unstable networks, cross-departmental isolation, or strict security controls.

[0030] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or multi-server deployment device capable of performing the above functions. The following description uses a multi-server deployment device as an example to illustrate this embodiment and the subsequent embodiments.

[0031] Based on this, the embodiments of this application provide a multi-server deployment method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-server deployment method of this application.

[0032] In this embodiment, the multi-server deployment method includes steps S10 to S40: Step S10: Build a local offline image repository, wherein the local offline image repository is deployed in a preset network environment, which is a network environment isolated from the public network.

[0033] It should be noted that the local offline image repository is used to store base image resources, application image resources, and the system's required dependency image resources. This provides a unified image source for subsequent deployment work, ensuring that all servers can obtain consistent and complete image files during the deployment process, and avoiding deployment failures caused by missing images or inconsistent versions.

[0034] Specifically, Harbor can be enhanced to support stable operation in offline environments. As an open-source enterprise-grade container image repository, Harbor provides functions such as image storage, access control, signing, scanning, and image replication. By enhancing it, it can better adapt to the needs of offline environments. For example, it can improve the stability and efficiency of image synchronization, ensuring that image synchronization can be completed quickly and accurately in offline environments. At the same time, Harbor can be hardened to prevent malicious attacks in offline environments and ensure the security of the image repository.

[0035] In one feasible implementation, step S10 may include steps A11 to A15: Step A11: Obtain a preset network environment isolated from the public network; It should be noted that when building a local offline image repository, it is first necessary to obtain a preset network environment isolated from the public network to ensure the security of the image repository and prevent unauthorized external access and tampering. A controlled network environment isolated from the public network can include a weak network environment, an offline environment, and a controlled network environment.

[0036] Step A12: Deploy a centralized open-source container image repository in the preset network environment, wherein a container orchestration platform cluster is deployed in the open-source container image repository; In practice, a centralized open-source container image repository can be deployed in this preset network environment, and a container orchestration platform cluster can be deployed in it to provide infrastructure support for image management and distribution.

[0037] Specifically, open-source solutions such as Harbor can be used for open-source container image repositories. These solutions are enterprise-grade proven and offer high availability and scalability. During deployment, network access policies for the repository must be configured to ensure that only authorized nodes are allowed to pull and push images, while unnecessary external ports are closed to reduce security risks. The deployment of the container orchestration platform cluster requires selecting mainstream orchestration tools such as Kubernetes based on the actual server scale and business needs, and configuring appropriate node roles and resource quotas to support subsequent image distribution and application deployment tasks. Kubernetes is an open-source container orchestration platform used for automating the deployment, scaling, and management of containerized applications.

[0038] Step A13: Deploy a P2P image distribution synchronization network subsystem within the container orchestration platform cluster of the open-source container image repository; In practical implementation, Dragonfly2 can be deployed within an offline Kubernetes cluster. Dragonfly2 is a file distribution system based on P2P technology, particularly suitable for large-scale file distribution scenarios. By deploying Dragonfly2, idle bandwidth resources of nodes within the cluster can be utilized to achieve fast and efficient image distribution, effectively reducing bandwidth pressure on the central node and improving overall distribution efficiency. Simultaneously, Dragonfly2 supports breakpoint resumption and intelligent scheduling, ensuring stable operation even in complex network environments and meeting high availability requirements in offline environments. After deploying Dragonfly2, a P2P image distribution synchronization network subsystem can be added. P2P, or peer-to-peer, significantly reduces bandwidth pressure on the central node and accelerates concurrent image distribution in large-scale clusters, especially suitable for environments with a large number of nodes or limited network bandwidth, improving deployment efficiency and resource utilization.

[0039] Step A14: Obtain the base image resources, application image resources, and the system's required dependency image resources; After deploying various functional modules and distribution subsystems in the open-source container image repository, it is necessary to obtain base image resources, application image resources, and dependency image resources required by the system. These image resources are the foundation for subsequent application deployment, and their completeness and accuracy directly affect the success rate and stability of the deployment. Base image resources typically contain the operating system and necessary runtime environment, application image resources are the containerized encapsulation of specific applications, and dependency image resources are the libraries and components that the application depends on to run.

[0040] Step A15: Store the base image resources, the application image resources, and the dependent image resources required by the system to the open-source container image repository to obtain a local offline image repository.

[0041] In practice, these resources can be stored in an open-source container image repository, thereby completing the construction of a local offline image repository.

[0042] Once the local offline image repository is built, its image resources can be regularly updated and maintained to ensure that the resources in the repository are always up-to-date and meet the deployment needs of different applications. To facilitate image resource management, images can be categorized for storage, such as by application type or version number, improving the efficiency of image retrieval and usage. Furthermore, an image backup mechanism can be established to prevent image loss due to unforeseen circumstances, ensuring the stability and reliability of the image repository. During subsequent deployment, multi-server deployment devices can directly pull the required image resources from the local offline image repository without relying on external networks, enabling software deployment and updates in an offline environment.

[0043] Step S20: Establish an application resource template library bound to the local offline image repository.

[0044] After building the local offline image repository, it is necessary to create an application resource template library bound to the repository. This template library contains a variety of pre-built resource templates, which correspond to different application types and deployment environments. By binding these pre-built resource templates to the local offline image repository, it can be ensured that the image references in the templates can accurately point to the corresponding image addresses in the local offline image repository during subsequent deployments. This avoids deployment failures caused by incorrect image references. At the same time, the creation of the template library can also improve the standardization and consistency of deployments and reduce the risk of human configuration errors.

[0045] Step S30: Receive the deployment requirement description object submitted by the user, and generate a deployment configuration file through the deployment requirement description object and the application resource template library.

[0046] When a user has a deployment requirement, they submit a deployment requirement description object. This object contains the user's specific requirements for deployment and specific parameter information, such as application type, deployment environment, and deployment scale. After receiving and parsing the deployment requirement description object, the system can match the target preset resource template corresponding to the deployment parameters from the application resource template library. Then, the deployment parameters are injected into the target preset resource template to generate the final deployment configuration file. This configuration file will serve as the basis for subsequent automatic deployment, ensuring that the deployment process can be executed accurately according to the user's requirements.

[0047] Step S40: Automatically deploy in a multi-server cluster based on the deployment configuration file.

[0048] After generating the deployment configuration file, automatic deployment can be performed on a multi-server cluster based on this file. Specifically, the application deployment node can be scheduled to a preset node through the scheduler of the container orchestration platform. Then, the image cache information detected by the preset node can be obtained. If the image cache information is that the image required for deployment is not cached locally and other nodes in the cluster have not cached the image required for deployment, a pull request can be initiated through the P2P image distribution synchronization network subsystem in the local offline image repository to pull the corresponding target image from the local offline image repository and cache the target image locally. After the target image is pulled, the container instance can be started to complete the application deployment. The entire deployment process is highly automated and requires no manual intervention, which not only improves deployment efficiency but also reduces the possibility of human error.

[0049] In one feasible implementation, step S40 may include steps A21 to A25: Step A21: Create application deployment nodes in the multi-server cluster based on the deployment configuration file; It's important to note that after obtaining the deployment configuration file, the first step is to create application deployment nodes within the multi-server cluster based on this file. These nodes serve as the concrete carriers for application deployment, and their creation process must strictly adhere to the relevant requirements and parameter settings in the deployment configuration file. For example, based on the server specifications and quantity specified in the configuration file, suitable servers must be precisely selected from the cluster to create nodes, ensuring that the nodes possess the computing, storage, and network resources required for application operation. Application deployment nodes are also known as Pod nodes. A Pod is the smallest unit for deploying, managing, and scaling containerized applications in Kubernetes. A Pod can contain one or more tightly coupled containers that share the same network namespace and storage volumes.

[0050] Step A22: Schedule the application deployment node to the preset node using the scheduler of the container orchestration platform; The scheduler of a container orchestration platform is the Kubernetes scheduler (kube-scheduler). This scheduler uses the Kubernetes API or Helm tools to schedule application deployment nodes to preset nodes based on node resource availability. The scheduler considers various factors, such as node resource utilization (including CPU, memory, and storage usage), as well as constraints like node labels and affinity. Through intelligent scheduling algorithms, it selects the most suitable nodes for application deployment, ensuring that applications can run in a resource-sufficient and compliant environment, thus improving application stability and performance.

[0051] Preset nodes are nodes with more abundant resources, such as higher-performance CPUs, larger memory capacities, and faster storage devices. Application dependencies are managed through the Init Container mechanism to control the startup order. Scheduling applications to preset nodes fully utilizes these high-quality resources, meeting the application's computing and storage needs during operation and avoiding performance bottlenecks or operational failures due to insufficient resources.

[0052] Step A23: Obtain the image cache information detected by the preset node; After the application deployment node is scheduled to the preset node, it needs to obtain the image cache information detected by the preset node. This step is crucial because the image cache information reflects whether the current node has already cached the image required for deployment. If the node has already cached the required image, then the locally cached image can be used directly in the subsequent deployment process, without having to pull it from the image repository again, thus greatly saving deployment time and network bandwidth resources.

[0053] In practice, if one or more cached nodes exist, different data shards are requested from multiple source nodes in parallel. The complete image is reassembled through multi-point concurrent download, avoiding repeated access to the central repository.

[0054] In one feasible implementation, after step A23, the method further includes: when the image cache information indicates that the image required for deployment has been cached locally, determining node load and network latency through a preset sharding cache distribution mechanism; determining a target cache node for providing the target image based on the node load and the network latency, wherein the preset sharding cache distribution mechanism is used to determine the target cache node based on the node load and network latency; obtaining the target image from the target cache node and starting the container instance to complete the application deployment.

[0055] It's important to note that node load is a crucial indicator of a node's current operational status, encompassing multiple aspects such as CPU utilization, memory usage, disk I / O, and network bandwidth consumption. Accurately obtaining node load information is a critical step in the pre-defined sharded cache distribution mechanism. By collecting load data from each node in real time, we can clearly understand the current workload of each node. For example, if a node's CPU utilization remains consistently high, it indicates that the node is handling a large number of computational tasks. Assigning it new image fetching tasks at this time may further increase its burden, leading to decreased deployment efficiency or even node failure. Network latency reflects the time required for data to travel through the network. Network latency may vary between different nodes, depending on factors such as their network topology, network device performance, and network traffic conditions. When determining the target cache node, the magnitude of network latency directly affects the image fetching speed. If a node with high network latency is selected as the target cache node, the time to retrieve the target image from that node will be relatively long, thus extending the overall application deployment cycle.

[0056] The pre-defined sharding cache distribution mechanism comprehensively considers two key factors: node load and network latency. It sorts nodes based on collected node load data, prioritizing nodes with lighter loads. Simultaneously, it combines network latency information to further filter out nodes with both low load and low network latency as target cache nodes. This aims to ensure that when acquiring the target image, performance issues caused by excessive node load are avoided, while also guaranteeing fast and stable data transmission. In practical implementation, a comprehensive score for each candidate node can be calculated based on pre-defined weighting coefficients, including... w L and w D ,in,w L + w D =1, calculated as follows: In the above formula, D max The preset maximum allowable network latency, For node load, Due to network latency, For comprehensive scoring, the node with the highest comprehensive score can be selected as the target cache node by calculating the comprehensive score of each candidate node.

[0057] Once the target cache node is identified, the multi-server deployment device sends a request to that node to retrieve the required target image. Upon receiving the request, the target cache node responds quickly and sends the locally cached target image to the requester. After receiving the target image, the multi-server deployment device immediately starts a container instance. The container instance startup process includes loading the target image into the container, configuring the container's runtime environment (such as network settings and storage volume mounting), and finally running the application within the container. With the successful startup of the container instance, application deployment is completed smoothly. The entire deployment process optimizes the image acquisition stage through a pre-defined sharded cache distribution mechanism, which not only improves deployment efficiency but also ensures the stability and reliability of the deployment process.

[0058] Traditional centralized image retrieval methods require each node to independently pull the complete image from its local offline image repository. However, in this solution, the first node must pull the complete image from its local offline image repository, which takes approximately [time missing]. ,in, Let S be the downlink bandwidth of the central offline image repository, and S be the total data volume of the container images to be distributed. The second to Nth nodes can download the images from the cached nodes via P2P parallel fragmentation. Assume the P2P network can provide the equivalent concurrent download capacity of k source nodes (k≤N). 1), then the download time for a single node is: , This represents the average available bandwidth of the inter-node P2P network. The above comparison shows that using a pre-defined fragment caching and distribution mechanism combined with P2P parallel fragment downloading can significantly shorten the overall image fetch time in multi-node deployment scenarios.

[0059] Step A24: When the image cache information is that the image required for deployment is not cached locally and other nodes in the cluster do not cache the image required for deployment, a pull request is initiated through the P2P image distribution synchronization network subsystem in the local offline image repository to pull the corresponding target image from the local offline image repository and cache the target image locally. When it is detected that the preset node and other nodes in its cluster have not cached the required image for deployment, a pull request needs to be initiated through the P2P image distribution synchronization network subsystem in the local offline image repository. The P2P image distribution synchronization network subsystem utilizes a point-to-point transmission method to efficiently pull the target image from the local offline image repository. During the pull process, this subsystem fully leverages its advantages, such as utilizing idle bandwidth resources of nodes within the cluster, to achieve fast and stable image transmission. Simultaneously, the pulled target image is cached locally so that it can be directly used in subsequent deployments, improving deployment efficiency. It is understood that the local cache is a persistent local cache, and it can also register the image's fragment metadata with the P2P network, becoming a source node for subsequent downloads.

[0060] Step A25: After the target image is pulled, start the container instance to complete the application deployment.

[0061] Once the target image is successfully pulled and cached locally, the container instance can be started. Starting the container instance is the final step in application deployment, signifying that the application has been successfully deployed to the multi-server cluster. During the container instance startup process, the container orchestration platform initializes the container according to the relevant settings in the deployment configuration file, such as setting environment variables and mounting storage volumes. Once the container instance starts successfully, the application can run normally within the container, and the entire deployment process is successfully completed. The entire deployment process is highly automated, requiring no manual intervention, which not only improves deployment efficiency but also reduces the possibility of human error, ensuring that the application can run stably and reliably in the multi-server cluster.

[0062] In one feasible implementation, to improve the management effect of the cluster and deployed applications, real-time monitoring of the cluster and deployed applications can also be performed. Therefore, after step S40, steps S41 to S43 are also included: Step S41: Obtain the monitoring toolchain, wherein the monitoring toolchain includes metric monitoring tools, log management tools, and visualization tools; It should be noted that a monitoring toolchain can be deployed in an offline environment, specifically including a metrics monitoring tool, namely Prometheus, a log management tool, namely Loki, and a visualization tool, namely the Grafana data visualization platform.

[0063] Step S42: Monitor the deployed application in real time using the monitoring toolchain to obtain monitoring information, including application deployment node status, node resource usage status, log collection information, and event alarm information. In practical implementation, a monitoring toolchain can be used to monitor deployed applications and clusters in real time, obtaining monitoring information. This information covers the status of application deployment nodes, i.e., Pod status, such as whether Pod nodes are running normally or experiencing faults; node resource usage status, including the usage of resources such as CPU, memory, and storage, to determine whether resources are sufficient and whether there are resource bottlenecks; log collection information, by collecting and analyzing logs, we can understand the application's operation and troubleshoot potential problems; and event alarm information, when anomalies occur or preset thresholds are reached, alarms are issued in a timely manner so that relevant personnel can take rapid action. Through comprehensive and real-time monitoring, we can promptly grasp the operational status of applications and clusters, providing a valuable basis for subsequent management and optimization.

[0064] Step S43: Process the application based on the monitoring information.

[0065] In practice, the deployed applications can be processed using the acquired monitoring information. For example, a management interface or command line interface tool (CLI) can be provided to control application start-up and shutdown, adjust configurations, perform rolling upgrades and troubleshooting, thereby ensuring system stability and maintainability.

[0066] This embodiment provides a multi-server deployment method. This solution supports deployment in a purely offline environment, completely disconnected from the internet, allowing software installation, updates, and maintenance to be completed without public network access. Unified repository management improves consistency, as all servers use the same offline repository, ensuring version uniformity and environment consistency. Deployment costs and bandwidth overhead are significantly reduced; only a one-time synchronization of the offline repository is required, and multiple servers can be reused. Furthermore, the deployment process is automated, automatically generating deployment configuration files and deploying automatically through a multi-server cluster. This not only reduces the possibility of human error but also significantly accelerates the feedback cycle from requirement to actual deployment, reducing human error in batch automatic deployment and improving efficiency and stability. Using a template library ensures that each deployment follows the same configuration and process, thereby reducing problems caused by environmental differences and improving application consistency. All configurations originate from fixed templates, facilitating subsequent tracking and auditing of changes in the deployment environment.

[0067] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to...Figure 2 Step S20 includes steps S201 to S203: Step S201: Construct an initial application resource template library containing a variety of pre-built resource templates, wherein the pre-built resource templates correspond to different application types and different deployment environments.

[0068] It should be noted that the preset resource templates may include resource templates such as Deployment deployment controller, Service service, ConfigMap configuration mapping, Ingress entry controller, and NetworkPolicy network policy resource configuration.

[0069] Specifically, different resource templates can be pre-configured for different types and environments of Kubernetes. Different application types can include Java, Vue, etc., and different deployment environments can include development, testing, production, etc.

[0070] By aggregating various pre-built resource templates, an initial application resource template library is formed, covering the needs of various application types and different deployment environments. These pre-built resource templates not only include basic application configuration information, such as application name, version number, and dependencies, but also feature detailed categorization and customization for different deployment environments, such as development, testing, and production environments. Building such a comprehensive and flexible initial application resource template library can significantly improve the efficiency and accuracy of subsequent deployment work. During the construction process, the characteristics of various application types and the differences in deployment environments must be fully considered to ensure that each pre-built resource template can meet the deployment requirements of specific scenarios. Simultaneously, the templates need to undergo rigorous testing and verification to ensure stable and reliable operation during actual deployment.

[0071] Step S202: Bind the preset resource template to the local offline image repository, so that the image reference in the template points to the local offline image repository.

[0072] In practical implementation, a pre-set resource template and a local offline image repository can be used. Specifically, by using parameterized placeholders for the image fields in each template and stipulating that all injectable image names and versions must correspond to existing entries in the offline image repository, the image audio source in the template can be made to point to the local offline image repository.

[0073] In one feasible implementation, step S202 may include steps B11-B13: Step B11: Obtain the mirror address prefix in each of the preset resource templates; It's important to note that after building the initial application resource template library, each pre-built resource template contains information about the image address. This information is typically in a specific format, including the image address prefix. By parsing the template file or calling relevant interfaces, the image address prefix in each pre-built resource template can be accurately obtained. These prefixes are a crucial component of the image address, identifying the approximate location of the repository or the namespace to which the image belongs. For example, in some cases, the image address prefix might be the domain name of a private repository or the naming prefix of a specific project. Obtaining these prefixes lays the foundation for subsequently uniformly modifying image references to point to the local offline image repository.

[0074] Step B12: Obtain the address of the local offline image repository; In practice, there are several ways to obtain the address of the local offline image repository. It can be read from a pre-configured configuration file, which records detailed address information such as protocol type, IP address, and port number, ensuring accurate location of the local offline image repository. Alternatively, it can be obtained through environment variables. By setting environment variables for the local offline image repository address in the system environment or a specific runtime environment, it can be read directly from the environment variables when needed. Another method is to obtain it by calling a specific interface. If the local offline image repository provides a corresponding interface, a request can be sent to that interface, and the returned data will contain the address of the local offline image repository.

[0075] Step B13: Set the image address prefix to the address of the local offline image repository, so that the image reference in the template points to the local offline image repository, thus completing the binding of the preset resource template with the local offline image repository.

[0076] It's important to note that after obtaining the image address prefixes from each pre-built resource template, the original image address prefixes are replaced with the local offline image repository address. This ensures that the image references in the templates point to the local offline image repository, instead of the original external repository. This step is crucial to ensuring that applications can successfully pull the required image resources in an offline environment. Through this binding operation, whether in development, testing, or production environments, as long as these pre-built resource templates are used for deployment, the system will automatically search for and pull the corresponding images from the local offline image repository, thus eliminating dependence on the public network and achieving true offline deployment. Simultaneously, this binding method also improves deployment flexibility and maintainability. When images in the local offline image repository are updated or changed, only the image references in the template need to be updated accordingly, without modifying the entire deployment process or configuration files.

[0077] Step S203: Update the initial application resource template library according to the binding result to obtain the application resource template library.

[0078] In practice, after binding the pre-built resource templates to the local offline image repository, the binding result can be determined, such as successful or unsuccessful binding. For successfully bound pre-built resource templates, they are added to the updated application resource template library. These templates have established a correct association with the local offline image repository and can be directly used for deployment operations. For pre-built resource templates that fail to bind, the reasons for failure need to be further analyzed. Possible reasons include incorrect image address prefix acquisition, incorrect local offline image repository address configuration, or format problems with the template file itself. Corresponding solutions are taken for different reasons for failure, such as re-acquiring the image address prefix, checking and correcting the local offline image repository address configuration, or repairing the template file format. After resolving the issues, the binding operation is performed again until all pre-built resource templates are successfully bound to the local offline image repository. Finally, all successfully bound pre-built resource templates are aggregated to form an updated application resource template library. The templates in this library can accurately point to the local offline image repository, providing reliable resource template support for subsequent multi-server offline deployment and ensuring that the deployment process can be carried out efficiently and stably.

[0079] This embodiment constructs an initial template library containing various pre-built resource templates and categorizes them for different application types and deployment environments. This ensures that various applications follow unified deployment specifications in different environments, reducing human configuration errors. Image references in the templates that might have originally pointed to public network image repositories are uniformly replaced with corresponding image addresses in local offline image repositories. This ensures that applications can still successfully pull the required images and complete deployment based on the templates even in completely offline or restricted network environments, completely solving the problem of having templates but no images or image pull failures. A clear mapping relationship is formed between templates and local image versions. When the image is updated, the version tag of the corresponding template can be maintained synchronously, realizing integrated version management of "template-image". This avoids operational anomalies caused by image and configuration mismatches and reduces operation and maintenance troubleshooting costs.

[0080] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S30 includes steps S301 to S303: Step S301: Receive the deployment requirement description object submitted by the user, parse the deployment requirement description object, and obtain the deployment parameters in the deployment requirement description object.

[0081] It's important to note that the deployment requirement object is a specific data structure or file created by the user based on the actual deployment scenario and needs, containing various key information related to deployment. The deployment requirement description object can take various forms, such as JSON, XML, or specific custom formats. Upon receiving the deployment requirement description object submitted by the user, the system initiates a parsing process. This parsing process analyzes the object layer by layer according to pre-defined rules and syntax, extracting deployment parameters. These deployment parameters cover multiple aspects, such as application type parameters, explicitly specifying the type of application to be deployed (Java, Vue, or another type); deployment environment parameters, determining whether the deployment will be conducted in a development, testing, or production environment; resource requirement parameters, including the required CPU, memory, and storage resources; and other specific parameters that may affect deployment, such as specific network configuration requirements and security policy requirements. Accurately parsing the deployment requirement description object and obtaining the deployment parameters provides a solid foundation for subsequent precise deployment operations based on these parameters, ensuring that the deployment process meets the user's actual needs and improving the success rate and efficiency of deployment.

[0082] Step S302: Match the target preset resource template corresponding to the deployment parameters from the application resource template library.

[0083] It's important to note that the application resource template library stores a large number of pre-built resource templates, covering various application types and deployment environments. After obtaining the deployment parameters, the system performs a comprehensive and detailed search and matching within the application resource template library based on these parameters. The matching process considers multiple dimensions, such as application type parameters, which filter out templates matching the application type to ensure consistency between the deployed application type and the template's supported types; deployment environment parameters, which find templates suitable for the specified deployment environment, as different deployment environments may have different requirements for resource configuration, network policies, etc.; and resource requirement parameters, which select templates that meet the required CPU, memory, and storage resources. Through this precise matching, the system can identify the target pre-built resource template that best meets the current deployment requirements from among numerous templates, providing an accurate basis for subsequent deployment operations based on this template. This ensures that the deployment process proceeds smoothly according to the user's needs, improving the accuracy and reliability of the deployment. Simultaneously, this matching mechanism reflects the system's intelligence and automation, reducing the workload and error probability of manual template selection and improving overall deployment efficiency.

[0084] In one feasible implementation, before step S303, the method further includes: parsing the deployment requirement description object to determine image reference information; obtaining the repository address, project, image name, and image tag based on the image reference information; determining the target metadata query interface provided by the local offline image repository based on the repository address and the project; calling the target metadata query interface to verify whether the image name and the image tag are located in the local offline image repository; and when the image name and the image tag are located in the local offline image repository, performing the step of injecting the deployment parameters into the target preset resource template to generate a deployment configuration file.

[0085] It's important to note that parsing the deployment requirement description object to determine image reference information is a crucial step in ensuring the accuracy of the deployment process. During parsing, the system carefully analyzes every item in the deployment requirement description object, extracting image-related reference information. This image reference information typically includes key elements such as repository address, project name, image name, and image tags. The repository address indicates the storage location of the image, the project name further specifies the specific project to which the image belongs, the image name clarifies the specific image to be used, and the image tags are used to distinguish different versions of the same image.

[0086] After obtaining this image reference information, the system determines the target metadata query interface provided in the local offline image repository based on the repository address and project name. The purpose of this step is to find the accurate way to query specific image metadata, as different repository addresses and projects may correspond to different metadata query methods. By determining the correct target metadata query interface, the system can ensure that subsequent query operations can accurately locate the required image information.

[0087] Next, the system will call this target metadata query interface to verify the image name and image tag, checking whether they actually exist in the local offline image repository. This prevents deployment failures due to missing images or version mismatches. If the verification result shows that the image name and image tag are both located in the local offline image repository, then the subsequent steps can be performed, namely, injecting deployment parameters into the target pre-built resource template to generate the final deployment configuration file.

[0088] If verification fails, the deployment process can be terminated to avoid deployment failures or environment inconsistencies caused by templates referencing outdated images. This series of operations not only demonstrates the system's refined management of the deployment process but also ensures the accuracy and reliability of the deployment. By automatically parsing deployment requirement description objects, determining image reference information, finding target metadata query interfaces, and verifying image names and tags, the system can maintain efficient deployment capabilities even in offline environments, providing users with stable and reliable deployment services. At the same time, this automated processing method greatly reduces the need for manual intervention, lowers the possibility of human error, and improves overall deployment efficiency.

[0089] Step S303: Inject the deployment parameters into the target preset resource template to generate a deployment configuration file.

[0090] In practice, deployment parameters can be injected into a defined target pre-built resource template. Specifically, using a specific parameter injection tool or script, the parsed deployment parameters, such as application type parameters, deployment environment parameters, and resource requirement parameters, are accurately filled into the corresponding positions in the target pre-built resource template according to predetermined rules and formats. These positions typically exist in the template as parameter placeholders; for example, in a configuration file, different parameter placeholders might be represented by "${APP_TYPE}", "${ENV_TYPE}", and "${CPU_REQUEST}". After the deployment parameters are injected, these placeholders are replaced with actual values, thus transforming the originally generic target pre-built resource template into a personalized deployment configuration file that meets the specific deployment requirements. This deployment configuration file contains all the detailed information required for application deployment, such as the specific type of application, the deployment environment, the required resources, network configuration, security policies, etc. It provides precise guidance for subsequent automatic multi-server deployment, ensuring that each server can be deployed according to a unified and accurate standard, improving deployment consistency and stability, reducing deployment problems and failures caused by configuration differences, and further improving the efficiency and reliability of the entire multi-server deployment process.

[0091] This embodiment improves overall deployment speed by automating the parsing of user-submitted requirement descriptions, reducing manual configuration and pre-setting time. Automated generation of deployment configuration files effectively prevents human error and ensures accurate resource configuration. Using pre-built resource templates guarantees consistent deployment processes across environments. Standardized configurations minimize differences between environments, ensuring stable application operation across various settings. Separating deployment parameters from resource templates allows new application requirements, changes, and extensions to be implemented through simple parameter or template modifications, without requiring large-scale adjustments to the entire configuration process.

[0092] For example, to help understand the implementation process of the multi-server deployment method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 4 , Figure 4 This document provides a simplified flowchart of a multi-server deployment method, specifically: a local offline image repository + Dragonfly2 P2P image distribution system. The local repository stores application images, solving the image retrieval problem in offline environments. The Dragonfly2 P2P image distribution system is a P2P image distribution tool that accelerates image propagation within the cluster through inter-node caching and shard downloading. The initial pull is from the repository, and subsequent nodes download in parallel from cached nodes. A Kubernetes resource configuration manifest, i.e., a YAML file, is dynamically generated based on user deployment requirements, such as image name, number of replicas, and resource limits, along with a pre-built template library. It includes core resource definitions such as Deployment, Service exposure, and ConfigMap configuration management. The automatic deployment and scheduling module for cluster applications automatically creates Pod application instances on cluster nodes based on the Kubernetes resource manifest and allocates Pods to nodes with sufficient resources through the Kubernetes scheduler. It also supports rolling upgrades and fast rollbacks. The monitoring toolchain includes Prometheus, used to collect and store cluster / application metrics data. Loki is used to collect and store application logs, supporting log-metric correlation analysis and the Grafana visualization platform. It displays Prometheus metrics and Loki logs through dashboards and provides an interface for alerting and operations. A multi-server cluster consists of multiple servers. Pod instances run on nodes where applications are deployed, and monitoring toolchains are deployed on other nodes. In practice, monitoring components may be reused with application nodes or deployed independently on dedicated nodes.

[0093] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-server deployment method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0094] This application also provides a multi-server deployment device, please refer to... Figure 5 The multi-server deployment device includes: Module 10 is used to build a local offline image repository, wherein the local offline image repository is deployed in a preset network environment, which is a network environment isolated from the public network; Module 20 is used to create an application resource template library that is bound to the local offline image repository; The receiving and generating module 30 is used to receive the deployment requirement description object submitted by the user, and generate a deployment configuration file through the deployment requirement description object and the application resource template library; Deployment module 40 is used for automatic deployment in a multi-server cluster based on the deployment configuration file.

[0095] The multi-server deployment apparatus provided in this application, employing the multi-server deployment method described in the above embodiments, can solve the technical problems in the prior art where multi-server software deployment relies on online resources, cannot cope with offline network environments, and manual downloading and distribution makes it difficult to ensure server version consistency. Compared with the prior art, the beneficial effects of the multi-server deployment apparatus provided in this application are the same as those of the multi-server deployment method provided in the above embodiments, and other technical features in the multi-server deployment apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0096] This application provides a multi-server deployment device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the multi-server deployment method in Embodiment 1 above.

[0097] The following is for reference. Figure 6 This document illustrates a structural diagram of a multi-server deployment device suitable for implementing embodiments of this application. The multi-server deployment device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The multi-server deployment device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0098] like Figure 6As shown, a multi-server deployment device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the multi-server deployment device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, LCDs (Liquid Crystal Displays), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the multi-server deployment device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a multi-server deployment device with various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0099] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0100] The multi-server deployment device provided in this application, employing the multi-server deployment method described in the above embodiments, can solve the technical problems in the prior art where multi-server software deployment relies on online resources, cannot cope with offline network environments, and manual downloading and distribution makes it difficult to ensure server version consistency. Compared with the prior art, the beneficial effects of the multi-server deployment device provided in this application are the same as those of the multi-server deployment method provided in the above embodiments, and other technical features of this multi-server deployment device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0101] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0102] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0103] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the multi-server deployment method described in the above embodiments.

[0104] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory or Flash Memory), optical fibers, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0105] The aforementioned computer-readable storage medium may be included in a multi-server deployment device; or it may exist independently and not be assembled into a multi-server deployment device.

[0106] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a multi-server deployment device, the multi-server deployment device causes the following actions: It constructs a local offline image repository, wherein the local offline image repository is deployed in a preset network environment, which is a network environment isolated from the public network; it establishes an application resource template library bound to the local offline image repository; it receives a deployment requirement description object submitted by a user, and generates a deployment configuration file using the deployment requirement description object and the application resource template library; and it automatically deploys the application resource template library based on the deployment configuration file within the multi-server cluster.

[0107] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0108] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0109] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0110] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described multi-server deployment method. This solves the technical problems in the prior art where multi-server software deployment relies on online resources, cannot cope with offline network environments, and manual downloading and distribution makes it difficult to ensure server version consistency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multi-server deployment method provided in the above embodiments, and will not be repeated here.

[0111] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-server deployment method described above.

[0112] The computer program product provided in this application can solve the technical problems in the prior art where multi-server software deployment relies on online resources, cannot cope with offline network environments, and manual downloading and distribution makes it difficult to ensure server version consistency. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the multi-server deployment method provided in the above embodiments, and will not be repeated here.

[0113] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A multi-server deployment method, characterized in that, The multi-server deployment method includes: Build a local offline image repository, wherein the local offline image repository is deployed in a preset network environment, which is a network environment isolated from the public network; Establish an application resource template library that is bound to the local offline image repository; Receive the deployment requirement description object submitted by the user, and generate a deployment configuration file through the deployment requirement description object and the application resource template library; Automatic deployment is performed in a multi-server cluster based on the aforementioned deployment configuration file.

2. The method as described in claim 1, characterized in that, The steps for building a local offline image repository include: Obtain a preset network environment isolated from the public network; A centralized open-source container image repository is deployed in the preset network environment, wherein a container orchestration platform cluster is deployed in the open-source container image repository; Deploy a P2P image distribution synchronization network subsystem within the container orchestration platform cluster of the open-source container image repository; Obtain the base image resources, application image resources, and the dependent image resources required by the system; The base image resources, the application image resources, and the dependent image resources required by the system are stored in the open-source container image repository to obtain a local offline image repository.

3. The method as described in claim 1, characterized in that, The step of establishing the application resource template library bound to the local offline image repository includes: Construct an initial application resource template library containing a variety of pre-built resource templates, wherein the pre-built resource templates correspond to different application types and different deployment environments; Bind the preset resource template to the local offline image repository, so that the image reference in the template points to the local offline image repository; The initial application resource template library is updated based on the binding result to obtain the application resource template library.

4. The method as described in claim 3, characterized in that, The step of binding the preset resource template to the local offline image repository includes: Obtain the mirror address prefix from each of the preset resource templates; Obtain the address of the local offline image repository; The image address prefix is ​​set to the address of the local offline image repository, so that the image reference in the template points to the local offline image repository, thus completing the binding of the preset resource template with the local offline image repository.

5. The method as described in claim 1, characterized in that, The step of receiving a deployment requirement description object submitted by the user and generating a deployment configuration file using the deployment requirement description object and the application resource template library includes: Receive the deployment requirement description object submitted by the user, parse the deployment requirement description object, and obtain the deployment parameters in the deployment requirement description object; Match the target preset resource template corresponding to the deployment parameters from the application resource template library; The deployment parameters are injected into the target preset resource template to generate a deployment configuration file.

6. The method as described in claim 5, characterized in that, Before the step of injecting the deployment parameters into the target preset resource template and generating the deployment configuration file, the method further includes: The deployment requirement description object is parsed to determine the image reference information; Based on the image reference information, obtain the repository address, project, image name, and image tag; The target metadata query interface provided by the local offline image repository is determined based on the repository address and the project. Call the target metadata query interface to verify whether the image name and the image tag are located in the local offline image repository; When the image name and the image tag are located in the local offline image repository, the step of injecting the deployment parameters into the target preset resource template and generating a deployment configuration file is performed.

7. The method as described in claim 1, characterized in that, The steps for automatic deployment in a multi-server cluster based on the deployment configuration file include: Create application deployment nodes in a multi-server cluster based on the aforementioned deployment configuration file; The application deployment nodes are scheduled to preset nodes through the scheduler of the container orchestration platform; Obtain the image cache information detected by the preset node; When the image cache information indicates that the image required for deployment is not cached locally and other nodes in the cluster do not cache the image required for deployment, a pull request is initiated through the P2P image distribution synchronization network subsystem in the local offline image repository to pull the corresponding target image from the local offline image repository and cache the target image locally. After the target image is pulled, start the container instance to complete the application deployment.

8. The method as described in claim 1, characterized in that, After the step of obtaining the image cache information detected by the preset node, the method further includes: When the image cache information indicates that the image required for deployment has been cached locally, the node load and network latency are determined through a preset sharding cache distribution mechanism. The target cache node for providing the target image is determined by the node load and the network latency, wherein the preset shard cache distribution mechanism is used to determine the target cache node based on the node load and network latency; The target image is obtained from the target cache node, and a container instance is started to complete the application deployment.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: Obtain a monitoring toolchain, wherein the monitoring toolchain includes metric monitoring tools, log management tools, and visualization tools; The deployed application is monitored in real time through the monitoring toolchain to obtain monitoring information, which includes the application deployment node status, node resource usage status, log collection information, and event alarm information. The application is processed based on the monitoring information.

10. A multi-server deployment device, characterized in that, The device includes: A building module is used to build a local offline image repository, wherein the local offline image repository is deployed in a preset network environment, which is a network environment isolated from the public network; The module is used to create an application resource template library that is bound to the local offline image repository; The receiving and generating module is used to receive the deployment requirement description object submitted by the user, and generate a deployment configuration file through the deployment requirement description object and the application resource template library; The deployment module is used for automatic deployment in a multi-server cluster based on the deployment configuration file.

Images