Cloud code deployment system

Abstract

The invention relates to the technical field of automatic deployment, in particular to a cloud code deployment system which comprises a resource monitoring module, a task scheduling module, a path construction module, a log analysis module and a container repair module. According to the method, by collecting the node load and dynamically collecting the node load, the bandwidth and the storage capacity, accurate comparison of the resource request and the surplus is achieved, the high-matching-degree task node relation is established, the resource allocation scientificity is improved, the scheduling priority and the mirror image dependency sequence are extracted, and the deployment sequence is optimized in combination with conflict task sorting; the scheduling adaptability in a multi-task environment is enhanced, the port and environment configuration is compared in a path construction link, the deployment compatibility is improved, the dependency relationship between deployment log analysis and fusion timestamp and exception identifier verification is improved, the diagnosis precision is improved, re-deployment is carried out based on state and frequency linkage in an exception processing stage, accurate node positioning is replaced, a closed-loop mechanism is formed, and the reliability of the system is improved. And the system stability and the self-adjusting capability are enhanced.

Description

Technical Field

[0001] The present invention relates to the field of automated deployment technology, and in particular to a cloud code deployment system. Background Art

[0002] The field of automated deployment encompasses various technical solutions for automatically configuring, transferring, installing, and executing application code across diverse computing environments. The core of this technology area is the use of automated tools or platforms to seamlessly migrate code from development environments to testing, pre-production, and production environments, reducing manual operations and improving deployment efficiency and accuracy. Automated deployment encompasses multiple aspects, including source code management, build process control, environment configuration management, deployment strategy development, and release process management. This area also involves support and adaptation for diverse operating systems, virtualization platforms, container technologies, and cloud computing platforms to achieve cross-platform deployment capabilities.

[0003] Among them, the cloud code deployment system refers to a system based on cloud computing architecture, which remotely uploads local or other source application codes to the specified environment of the cloud platform through the network and automatically deploys them in the environment. The system mainly focuses on technical matters such as code uploading, dependency environment identification and construction, deployment process orchestration, and post-deployment code status verification. It completes code extraction through the source code collection interface, completes the required compilation and dependency loading by building task control logic, realizes the target environment deployment action through deployment instruction mapping logic, and completes post-deployment status identification through log collection and instruction verification. The entire system relies on the virtual resource scheduling capabilities of the cloud platform and combines task scheduling mechanism and file distribution mechanism to realize automated process.

[0004] Existing technologies rely heavily on static resource configuration and pre-set processes during deployment, lacking sensitivity to dynamic changes in node resources. This leads to resource redundancy or bottlenecks during task allocation, preventing efficient real-time matching of resources and requests. Regarding task scheduling strategies, existing solutions often rely on fixed priorities or manual rule settings. This can lead to deployment order imbalances in the face of task conflicts or complex image dependencies, reducing overall execution efficiency. During deployment path construction, node port usage status and container environment differences are often ignored, which can easily lead to path configuration incompatibility, container deployment failures, or operational anomalies. Regarding log parsing, traditional deployment methods often rely on manual analysis or single-dimensional log analysis for anomaly detection. They lack multi-dimensional indicator linkage and dependency order comparison mechanisms, resulting in delayed anomaly identification or misjudgment. Responses to container deployment failures often rely on manual restarts or system-preset policies, failing to intelligently identify and locate replacement nodes based on operational status and anomaly frequency. This reduces the recovery efficiency and adaptability of the deployment system. This issue is particularly prominent in scenarios with cross-node deployments, high image dependencies, or high task concurrency, directly impacting deployment quality and service stability. Summary of the Invention

[0005] The purpose of the present invention is to solve the shortcomings of the existing technology and propose a cloud code deployment system.

[0006] In order to achieve the above objectives, the present invention adopts the following technical solutions: A cloud code deployment system includes:

[0007] The resource monitoring module obtains the deployment node load indicators, network bandwidth usage and container storage capacity values, collects the resource request list of the cloud deployment task, compares the resource items in the resource request list with the current node resource remaining, selects the corresponding relationship between the node and task that meets the request, and generates a task node mapping table;

[0008] The task scheduling module calls the task and node distribution data in the task node mapping table, extracts the scheduling priority of the task and the container image dependency order, identifies the deployment conflicting tasks and extracts the priority tags of the conflicting tasks, readjusts the scheduling order by priority sorting, and generates a deployment priority task sequence;

[0009] The path construction module calls the task items in the deployment priority task sequence, identifies the container operating environment configuration and port dependencies, compares the available ports of the deployment nodes, screens compatible nodes and analyzes the container path, and generates a deployment path configuration list;

[0010] The log parsing module extracts the container startup timestamp, resource usage and exception identification according to the container deployment result log in the deployment path configuration list, compares the startup sequence with the dependency, counts the task names and frequencies of startup timing exceptions, and generates a deployment sequence exception list.

[0011] As a further solution of the present invention, the task node mapping table includes node load information matching items, network bandwidth allocation labels, and container storage capacity indicators; the deployment priority task sequence includes a scheduling priority label, an image dependency order identifier, and a conflicting task identification code; the deployment path configuration list includes an environment configuration parameter item, a port allocation list, and a path dependency relationship identifier; and the deployment sequence exception list includes an abnormal task name item, a startup timing deviation label, and a dependency verification result code.

[0012] As a further solution of the present invention, the resource monitoring module includes:

[0013] The node status acquisition submodule obtains the deployment node load indicators, network bandwidth utilization, and container storage capacity values. It monitors the node CPU utilization, network bandwidth utilization, and container storage capacity values, compares them with the corresponding load, bandwidth, and capacity thresholds, determines whether the indicators meet the preset tolerance range, and generates node resource remaining data.

[0014] The resource list comparison submodule collects the resource request list of the cloud task based on the node resource remaining amount data, extracts the CPU, bandwidth and storage request values ​​of the task, compares them with the remaining resources of the node, selects the corresponding relationship between the node and the task that meets the request conditions, and generates the distribution of optional nodes for the task;

[0015] The task mapping generation submodule sorts the resources of the nodes based on the distribution of the optional nodes of the task, selects nodes with low resource load as deployment nodes of the task, and generates a task node mapping table.

[0016] As a further solution of the present invention, the task scheduling module includes:

[0017] The scheduling factor extraction submodule calls the task-bound node and container image dependency information in the task node mapping table, extracts the scheduling priority field and the image loading order value, performs sequential processing based on the image pull path and loading level, and generates the image scheduling sort value;

[0018] The conflict tag identification submodule classifies and compares the image loading path intersection or resource lock duplicate tasks in the same node according to the image scheduling sort value, extracts the scheduling priority label and node position, marks the conflicting task group, and generates a deployment conflict label set;

[0019] The deployment sequence rearrangement submodule calls the deployment conflict label set, extracts the node IO bandwidth, image loading delay and task execution time, builds a task deployment sorting model, calculates the deployment priority value of the task, and uses the priority value as a benchmark to adjust the scheduling order and generate a deployment priority task sequence.

[0020] As a further solution of the present invention, the path construction module includes:

[0021] The environment configuration extraction submodule calls the task items in the deployment priority task sequence, parses the container image configuration, extracts the operation type, kernel version, middleware dependency and port mapping, compares them with the node environment, determines the environment compatibility, and generates an environment compatibility label set;

[0022] The port compatibility judgment submodule retrieves the port resources and dependencies of the compatible task node pairs according to the environment compatibility tag set, compares the port occupancy item by item, counts the valid mappings, excludes nodes with port overlap exceeding a threshold, and obtains an available port mapping list;

[0023] The path feasibility evaluation submodule calls the task and node combinations in the port mapping available list, processes the communication distance, delay and number of dependent paths between tasks between network paths, calculates the feasibility value of the task deployment path, screens out combinations that do not meet the path deployment requirements according to the feasibility value, and generates a deployment path configuration list.

[0024] As a further solution of the present invention, the log parsing module includes:

[0025] The log extraction submodule reads the container deployment result log in the deployment path configuration list one by one, extracts the startup timestamp, CPU and memory usage, identifies the abnormal status code, and generates a startup and resource information set;

[0026] The timing comparison submodule calls the timestamp data in the startup and resource information set, compares the real-time startup time according to the container dependency order, and records a timing anomaly if the dependent container starts later than the dependent container. The timing offset value is calculated, and the offset degree of the container startup sequence is quantified in numerical form. The container startup pairs with an offset degree higher than the deployment benchmark threshold are selected to obtain the startup timing offset set.

[0027] The exception statistics submodule accumulates and counts the occurrence frequency of container names according to the exception records in the startup timing offset set, extracts the container task names whose frequency is greater than the deployment exception statistics threshold, arranges them in descending order of frequency, and generates a deployment order exception list.

[0028] As a further solution of the present invention, the system also includes a container repair module:

[0029] The container repair module calls the deployment sequence exception list, monitors the current running status and exception count of the corresponding container, identifies containers with abnormal status and anomaly frequency higher than the tolerance threshold, performs task redeployment operations and locates replacement nodes, and obtains a cloud deployment replacement record data table;

[0030] The cloud deployment replacement record data table includes a replacement container number, a redeployment node identifier, and abnormal container statistics.

[0031] As a further solution of the present invention, the container repair module includes:

[0032] The abnormal state identification submodule calls the current running state and the number of abnormal state counts of the containers in the deployment order abnormality list, determines whether the running state is inconsistent with the set normal state code, filters out abnormal state containers and records their identifiers, status codes and abnormal counts, and generates a cloud abnormal state container list;

[0033] The tolerance screening submodule obtains a list of abnormal containers in the cloud, extracts the number of container anomalies, compares them item by item with the set tolerance threshold, determines the set of containers whose anomalies exceed the threshold, extracts the running image and configuration parameters, and obtains the parameter set of the container that needs to be redeployed;

[0034] The node deployment scheduling submodule identifies the current resource occupancy rate and network communication delay of the node based on the parameter set of the container to be redeployed, analyzes the deployment matching degree, selects the node with the best deployment matching degree, synchronizes the container image and configuration, records the replacement path and execution time, and obtains a cloud deployment replacement record data table.

[0035] Compared with the prior art, the advantages and positive effects of the present invention are:

[0036] In the present invention, by dynamically collecting the deployment node load, network bandwidth utilization and container storage capacity, it is possible to achieve an accurate comparison between the deployment resource request and the remaining amount of node resources, effectively screen out the optimal node, establish a highly matched task and node correspondence, and enhance the scientific nature of resource allocation. By extracting the scheduling priority and the dependency order of the container image, combined with the identification and sorting of conflicting tasks, the scheduling execution process has a stronger adaptability, can optimize the deployment order in task-intensive or conflict-prone environments, and improve the execution efficiency in a multi-tasking environment. In the process of deploying the path, the two-way comparison strategy based on port dependency and operating environment configuration can refine the compatibility verification dimension of the deployment path and ensure the operability of the container on the target node. During the deployment log parsing phase, multi-dimensional extraction of startup timestamps, resource usage, and exception identifiers is performed, and synchronous verification is performed with dependencies. This allows timely identification of startup sequence problems and marking of tasks with frequent exceptions, thereby improving the granularity of problem diagnosis and the accuracy of traceability. In terms of deployment exception response, task redeployment is performed through a linkage mechanism between status judgment and exception frequency, and combined with the precise positioning of alternative nodes, the container recovery process is made more flexible and fault-tolerant. The overall process consists of a progressive closed-loop mechanism from resource evaluation to task scheduling, path construction, deployment verification, and exception repair. There is a clear causal chain between each processing step, which improves the transparency of the deployment process, the stability of container operation, and the self-regulation ability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 is a system flow chart of the present invention;

[0038] Figure 2 This is a flow chart of the resource monitoring module in the present invention;

[0039] Figure 3 This is a flowchart of the task scheduling module in the present invention;

[0040] Figure 4 This is a flow chart of the path construction module in the present invention;

[0041] Figure 5 This is a flow chart of the log parsing module in the present invention;

[0042] Figure 6 This is a flow chart of the container repair module in the present invention. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0044] In the description of the present invention, it should be understood that the terms "length," "width," "up," "down," "front," "back," "left," "right," "vertical," "horizontal," "top," "bottom," "inside," "outside," and the like, indicating positions or relationships, are based on the positions or relationships shown in the accompanying drawings and are intended only to facilitate the description of the present invention and simplify the description. They do not indicate or imply that the devices or elements referred to must have a specific orientation, be constructed, or operate in a specific orientation. Therefore, they should not be construed as limiting the present invention. Furthermore, in the description of the present invention, "plurality" means two or more, unless otherwise expressly and specifically defined.

[0045] See also Figure 1 , a cloud code deployment system includes:

[0046] The resource monitoring module obtains the deployment node load indicators, network bandwidth usage and container storage capacity values, collects the resource request list of the cloud deployment task, compares the resource items in the resource request list with the current node resource remaining, selects the corresponding relationship between the node and task that meets the request, and generates a task node mapping table;

[0047] The task scheduling module calls the task and node distribution data in the task node mapping table, extracts the task scheduling priority and container image dependency order, identifies deployment conflicting tasks and extracts the priority tags of the conflicting tasks, readjusts the scheduling order through priority sorting, and generates a deployment priority task sequence;

[0048] The path building module calls the task items in the deployment priority task sequence, identifies the container runtime environment configuration and port dependencies, compares the available ports of the deployment nodes, screens compatible nodes, analyzes the container path, and generates a deployment path configuration list;

[0049] The log parsing module extracts the container startup timestamp, resource usage, and exception identifiers based on the container deployment result logs in the deployment path configuration list, compares the startup sequence with dependencies, counts the task names and frequencies of startup sequence anomalies, and generates a deployment sequence anomaly list.

[0050] The container repair module calls the deployment sequence exception list, monitors the current running status and number of exceptions of the corresponding container, identifies containers with abnormal status and exception frequency higher than the tolerance threshold, performs task redeployment operations and locates replacement nodes, and obtains the cloud deployment replacement record data table.

[0051] The task node mapping table includes node load information matching items, network bandwidth allocation labels, and container storage capacity indicators. The deployment priority task sequence includes scheduling priority labels, image dependency order identifiers, and conflicting task identification codes. The deployment path configuration list includes environment configuration parameter items, port allocation list, and path dependency identifiers. The deployment sequence exception list includes abnormal task name items, startup timing deviation labels, and dependency verification result codes. The cloud deployment replacement record data table includes replacement container numbers, redeployment node identifiers, and abnormal container statistics items.

[0052] See also Figure 2 , the resource monitoring module includes:

[0053] The node status acquisition submodule obtains the deployment node load indicators, network bandwidth utilization, and container storage capacity values. It monitors the node CPU utilization, network bandwidth utilization, and container storage capacity values, compares them with the corresponding load, bandwidth, and capacity thresholds, determines whether the indicators meet the preset tolerance range, and generates node resource remaining data.

[0054] Node management collects resource usage information for each node, including CPU utilization, network bandwidth utilization, and storage capacity. For each node, sensors or monitoring systems obtain values ​​representing the node's resource consumption at the current moment. Each collected metric is compared against pre-set thresholds, which are set based on raw data or system requirements. For example, if a node's CPU utilization exceeds 80%, network bandwidth utilization exceeds 70%, and container storage utilization exceeds 90%, the node is considered heavily loaded. At this point, remaining resource data for the node is generated, including remaining CPU capacity, remaining bandwidth capacity, and remaining storage capacity. This data is calculated using simple subtraction: remaining CPU capacity = 100% - current CPU utilization. Similarly, bandwidth and storage capacity are calculated. This generates remaining node resource data, which aids in subsequent resource allocation and task scheduling decisions.

[0055] The resource list comparison submodule collects the resource request list of the cloud task based on the node resource remaining data, extracts the CPU, bandwidth and storage request values ​​of the task, compares them with the remaining resources of the node, selects the corresponding relationship between the node and the task that meets the request conditions, and generates the distribution of optional nodes for the task;

[0056] The task's resource request list is collected from the cloud. When each task is created, the required CPU, bandwidth, and storage resources are specified. For example, a task requests 10 CPU cores, 50MB of bandwidth, and 100GB of storage space. The request data is obtained from the task management platform and compared with the remaining node resources generated in the previous step. The comparison process is to check whether the remaining resources of each node can meet the task requirements one by one. For example, if a node has remaining resources of 15 CPU cores, 80MB of bandwidth, and 120GB of storage, it matches the task's request of 10 CPU cores, 50MB of bandwidth, and 100GB of storage. The node is considered to meet the conditions. Through this item-by-item comparison, all nodes that meet the task request conditions are screened out, and a node selection list is generated for each task, recording the distribution of optional nodes for each task. The node passes the candidate deployment node data to the next step.

[0057] The task mapping generation submodule sorts the node resources based on the distribution of optional nodes for the task, selects nodes with low resource load as the deployment nodes for the task, and generates a task node mapping table;

[0058] Based on the distribution of available nodes for a task, all eligible nodes are ranked. Ranking is based on factors such as remaining resources and current load. For example, nodes with the most remaining resources or the lightest load are prioritized. For example, suppose node A has 15 remaining CPU cores, 80MB of bandwidth, and 120GB of storage, node B has 12 remaining CPU cores, 70MB of bandwidth, and 100GB of storage, and node C has 18 remaining CPU cores, 90MB of bandwidth, and 130GB of storage. In this case, node C will be prioritized. The node ranking criteria can be set as follows: remaining CPU resources first, bandwidth second, and storage last. After ranking is complete, the node with the lowest resource load is selected for task deployment. Deployment node selection considers not only resource availability but also factors such as node health and network connection quality. After the deployment nodes are determined, a task-node mapping table is generated, recording the node corresponding to each task. This mapping table is used for subsequent task scheduling and resource allocation decisions.

[0059] See also Figure 3 , the task scheduling module includes:

[0060] The scheduling factor extraction submodule calls the task-bound node and container image dependency information in the task node mapping table, extracts the scheduling priority field and image loading order value, combines the image pull path and loading level for sequential processing, and generates the image scheduling sort value;

[0061] According to the task scheduling record log, the unique identifier of the task, the node number where the task is located, and the corresponding container image path are extracted. Combined with the node resource topology information allocated in the cloud code deployment architecture, the actual deployment location of each task and the accessible image warehouse address are confirmed. Then, by extracting the scheduling priority field, the numerical level of the task setting in the scheduling strategy is obtained. The level is an integer from 1 to 5, where 1 represents the highest priority. Through the example task A, if its scheduling priority is 3, it means that it needs to be executed in a medium order. Then, the image loading order value is extracted. The order is determined by the number of dependency levels in the image structure. It can be determined by parsing the number of layers in the image manifest list. For example, if the image corresponding to task A contains 4 layers, the loading order value is 4. Combined with the image pull path, this path affects the loading time. For example, it takes 300ms to pull from the warehouse in region A and 800ms from region B. If task A is configured with a path in region B, its loading time delay will be even greater. Therefore, a loading delay parameter can be introduced and further multiplied by the loading level to obtain the pulling order cost value. Then, the comprehensive image loading order is calculated based on the scheduling priority, loading level, and image pulling path delay. The setting is as follows: Image scheduling ranking value = scheduling priority value × image loading level + image pulling path delay (milliseconds). Taking task A as an example, its scheduling priority is 3, loading level is 4, and path delay is 800ms. Then: Image scheduling ranking value = 3 × 4 + 800 = 812. The same calculation process is performed on all tasks in this way. Based on the scheduling configuration items and image structure items, structured extraction and weighted combination processing are completed to finally generate the image scheduling ranking value.

[0062] The conflict tag identification submodule classifies and compares the image loading path intersections or resource lock duplicate tasks within the same node based on the image scheduling sort value, extracts the scheduling priority labels and node positions, marks the conflicting task groups, and generates a deployment conflict tag set.

[0063] When marking task conflicts based on image scheduling ranking values, we first need to compare multiple tasks distributed on the same node one by one. Inter-task conflicts mainly arise from image file access overlap and node resource contention. For example, if Task B and Task C are deployed simultaneously on Node X, with scheduling ranking values ​​of 812 and 805, respectively, their corresponding image pull paths are both from Repository B, resulting in a high degree of load time overlap. Conflict is determined by calculating the similarity of the image pull paths and the intersection of the pull time windows. The determination condition is set as follows: if the pull paths of the two tasks are exactly the same and the ranking value difference is less than 10, the task is considered a conflicting task. Furthermore, if the resources required by the container bound to the task exceed 70% of the total CPU usage of the node, the task is considered a resource contention conflict task. The benchmark value for resource conflict determination is set to 70% of the total node resources. This value can be derived from the average maximum resource usage of the originally deployed tasks. For example, if Node X has 8 CPU cores, 70% is 5.6 cores. If Task B occupies 3 cores and Task C occupies 3 cores, the total usage is 6 cores, and if the usage exceeds 5.6 cores, a resource conflict is determined. Mark the above task records as conflicting tasks and extract their scheduling priority labels. The label values ​​are set to integers corresponding to the scheduling priority parameters. For example, if task B is 3 and task C is 2, the conflict label set is {B: 3, C: 2}. Finally, the node position and conflict type are combined and labeled to generate the deployment conflict label set.

[0064] The deployment sequence reordering submodule calls the deployment conflict label set, extracts the node IO bandwidth, image loading delay and task execution time, and builds a task deployment sorting model using the formula:

[0065]

[0066] Calculate the deployment priority value of the task, and use the priority value as a benchmark to adjust the scheduling order and generate a deployment priority task sequence;

[0067] Among them, S represents the deployment priority value of the task, P i Represents the scheduling priority value of task i, I i Represents the image loading order value of task i, L i represents the number of image loading levels for task i, B i represents the IO bandwidth value of the node where task i is located, C ij represents the conflict judgment weight between task i and conflicting task j, T j represents the execution time of conflicting task j, D j represents the image pull delay of conflicting task j, and m is the total number of conflicting tasks involved in task i;

[0068] The deployment priority value of a task is a comprehensive indicator that measures the degree to which a task should be prioritized for execution during cloud deployment. It comprehensively considers multiple factors, including the scheduling priority of the task itself, the complexity of the image loading structure, the task dependency level, the node IO bandwidth status, the degree of resource competition between the task and conflicting tasks, and the impact of execution interference. It is numerically calculated using a unified dimension and weighted combination. The higher the value, the more suitable the task is for priority deployment under the current node resource conditions, and the earlier its execution time should be. This value can be used to adjust the deployment order based on the quantitative results when scheduling tasks, ensuring that high-priority tasks are executed first under limited resource conditions, thereby building an efficient and dynamically scheduled cloud deployment strategy.

[0069] When calling the deployment conflict label set and the image scheduling sort value to perform the deployment priority value calculation operation, it is necessary to perform numerical deduction based on the current task node deployment status and the dynamic characteristics of the relevant conflicting task group. Combined with the actual IO conditions of the node, the image layered structure and the conflicting task intensity, a deployment priority index system is constructed. First, task 4 is taken as the analysis object. Its configuration scheduling priority is 4. This value comes from the task level label field of the scheduling configuration file. The image loading order value is 3, and the corresponding image consists of a 3-layer structure. This value can be obtained by analyzing the number of Layer fields in the Manifest list of the container image it references. The loading level is 2, that is, the task depends on the second layer in the image to complete the decompression instruction preprocessing. The node IO bandwidth is 100MB / s. This value comes from the bandwidth detection results of the scheduler and monitoring. Task 4 has a conflict relationship with tasks 2 and 3. Task 2 executes for 80 seconds. The task running log is used to calculate the actual start and end time difference. The image pull delay is 100ms, the execution time of Task 3 is 60 seconds, and the delay is 200ms. The delay value comes from the scheduler's end-to-end time monitoring of the image pull time period from the main warehouse. The conflict judgment weight is constructed by the path duplication and time overlap. When the paths are completely consistent and the scheduling time difference is less than 15 seconds, the weight is defined as 1. When only the paths are similar but the scheduling difference is greater than 30 seconds, the weight is defined as 0.5. Here, Task 2 meets the weight of 1 and Task 3 meets the weight of 0.5. All parameters must be calculated under the same dimension, among which the time unit must be unified in seconds. The delay values ​​100ms and 200ms must be converted to 0.1s and 0.2s, and the node bandwidth must be converted to a unified unit of MB / s. No conversion is required. The loading order difference is calculated as |3-2|=1, which is used to reflect the difference in the loading logic and structural depth of the current task image.

[0070] Substitute the parameter values ​​from Task 4:

[0071] P4=4 (scheduling priority of task 4), I4=3, L4=2 (image layer difference is 1), B4=100MB / s;

[0072] Task 2: C 42 =1, T2=80 seconds, D2=0.1 seconds;

[0073] Task 3: C 43 =0.5, T3=60 seconds, D3=0.2 seconds;

[0074] The calculation process is as follows:

[0075] Item 1:

[0076] The second term expands to a sum:

[0077] The final calculation is: S = 0.0396 + 97.73 ≈ 97.77;

[0078] Finally, the deployment priority value of Task 4 is 97.77, which is much higher than the priority value of ordinary tasks in the reference benchmark value range [0, 10]. This indicates that Task 4 should be marked as a very high deployment priority object and should be prioritized in the cloud node resource allocation process to avoid image delays and resource congestion affecting its execution efficiency.

[0079] P i : The scheduling priority value of task i, which usually ranges from 1 to 5 and is defined by the task configuration item;

[0080] I i : Image loading order value, representing the number of layers of the image structure;

[0081] L i : Image loading layer number, indicating the lowest image layer number that the task depends on to start running;

[0082] B i : The node's I / O bandwidth, in MB / s, collected by the monitoring module;

[0083] C ij : The conflict intensity weight between task i and conflicting task j, with a value range of [0.1, 1], is set based on the resource contention and time overlap between tasks;

[0084] T j : The running time of conflicting task j, in seconds;

[0085] D j : image pull delay of conflicting task j, in seconds;

[0086] m: the number of conflicting tasks for task i;

[0087] By aggregating the impact of scheduling priority, loading structure complexity, bandwidth resource status, and conflicting tasks, the deployment priority is quantified, pushing the scheduling towards a more adaptive cloud code deployment behavior. The results show that the deployment priority value of 97.77 far exceeds the upper limit of the set reference range, and has obvious priority deployment conditions. It needs to be prioritized in task sorting to form the final cloud deployment task queue.

[0088] See also Figure 4 , the path building modules include:

[0089] The environment configuration extraction submodule calls the task items in the deployment priority task sequence, parses the container image configuration, extracts the operation type, kernel version, middleware dependency and port mapping, compares it with the node environment, determines the environment compatibility, and generates an environment compatibility label set;

[0090] First, parse the container image configuration file bound to the task, which contains the operation type field (such as image identifiers based on labels such as alpine and debian), kernel version field (such as Linux5.15.0), and middleware dependency version (such as Java11, Python3.9, etc.). At the same time, extract the port mapping content explicitly marked in the configuration, such as the port mapping defined in the form of "EXPOSE8080" or "ports:443:443". This operation is achieved by reading the "Config" field in the image layer for field matching, and then obtain the current cloud node operating environment parameters. The parameters are collected in real time by the cloud platform monitoring, and the content includes the basic image, kernel version, and middleware support version run by the node. The container image configuration items are compared with the node parameters one by one. The comparison method is field consistency judgment. For example, the container requires a Linux kernel version ≥ 5.10, and the current node is 5.15, which is considered compatible. , otherwise it is incompatible. For middleware version requirements, if the container requires Java 11 and above, and the node is installed with Java 8, it is considered incompatible. At the same time, the port definition is type-checked to determine whether the container port is an explicitly defined port. Undefined ports will not be included in the port compatibility detection scope. The comparison operation forms a Boolean value structure, compatible is 1, incompatible is 0. After generating the result matrix, it is labeled. The label structure is {task ID, node ID, operating system compatibility: 1 / 0, kernel compatibility: 1 / 0, middleware compatibility: 1 / 0}. Taking task 1 on node A as an example, if the image is debian 11 and the node system is debian 10, the operating system type compatibility value is 1, but the kernel is lower than the image requirement, then the compatibility value is 0, and the middleware version is consistent with the compatibility value. The combined result is {task 1, node A: 1, 0, 1}. Finally, a task-level label set is generated according to the node group, which is used as the input for the next step of deployment adaptation to obtain the environment compatibility label set.

[0091] The port compatibility judgment submodule retrieves the port resources and dependencies of compatible task node pairs based on the environment compatibility tag set, compares the port occupancy item by item, counts the valid mappings, excludes nodes with port overlap exceeding the threshold, and obtains a list of available port mappings;

[0092] For the task node combination marked as compatible with all three items: operation, kernel and middleware, the port resource table of the node is called. The table is periodically collected and updated in real time by cloud management. The content includes the occupied ports, released ports and port occupying process PID of the current node. The task container port dependencies are matched one by one. For example, if the task 2 container declares ports 8080 and 8443, the node resource table is checked to see if the two items are idle. If the port is occupied by the task, it is determined to be a conflict. For conflict handling, the maximum port conflict tolerance threshold is introduced. The value is calculated and set by the number of CPU cores of the node and the average concurrency of the task. For example, if the node has 8 cores and each core allows two ports to communicate with containers concurrently, the threshold is set to 16 port conflicts. If the number of conflicting ports on the node where the current task is located exceeds 16, it is judged as undeployable. Conflict statistics are implemented using a list aggregation method. If each port is successfully matched, it is counted in the success list, and if it conflicts, it is counted in the failure list. Whether to filter out a node is determined based on whether the number of conflicts exceeds the set threshold. Combining the port matching results with the threshold judgment logic, node combinations that cannot meet the communication requirements are eliminated. Finally, the task and node pairing structure that meets the complete port resource matching is recorded. The structure style is as follows: {Task ID: Task 2, Node ID: Node C, Port Mapping Status: Matched, Number of Conflicts: 0}. In this way, all task node combinations that meet the port conditions are obtained, and the port mapping available list is obtained.

[0093] The path feasibility evaluation submodule calls the task and node combination in the port mapping available list, processes the communication distance, delay and number of dependent paths between tasks between network paths, and uses the formula:

[0094]

[0095] Calculate the feasibility value of the task deployment path, filter out combinations that do not meet the path deployment requirements based on the feasibility value, and generate a deployment path configuration list;

[0096] Among them, Z represents the feasibility value of the task deployment path, a represents the communication path distance between nodes, b represents the network communication delay value, and q k represents the number of cross-node hops of the k-th container dependency path, h represents the number of containers that the task needs to communicate with simultaneously, d represents the node communication congestion value, and n is the number of container dependency paths;

[0097] The feasibility value of a task deployment path is a quantitative indicator that measures whether the network communication structure and resource load of a specific task are within an acceptable range when deployed on a specific node. This value is calculated by integrating key factors such as the communication path distance between nodes, network transmission delay, the complexity of the container path structure on which the task depends, the number of concurrent communications, and the current network congestion level of the target node. The smaller the value, the shorter the deployment path in terms of topology, the lower the communication delay, the simpler the dependency relationship, and the lighter the node load, indicating that the path is more suitable for cloud code deployment. If the value exceeds the preset benchmark threshold, it means that the path has a communication bottleneck or is too complex in structure, making it unsuitable as a deployment link, thereby providing a deployment screening basis based on path quality for task scheduling;

[0098] After calling the task and node combination in the available list of port mapping, it is first necessary to parse the communication link structure between the combination, extract the physical distance of the communication path, network delay, inter-container dependency path information, the number of container communications and the network bandwidth usage of the current node, and all indicators are uniformly calculated with the numerical value after dimension normalization. The path distance is expressed as "number of hops" (each time crossing a switching device is considered a jump), the delay is recorded in milliseconds, the number of cross-node hops of the inter-container dependency path is expressed in integer form, the number of communication containers is an integer value, and the congestion level is expressed as the ratio of the current network throughput to the total bandwidth (normalized to between 0-1). For example, taking task 3 deployed on node B as an example, the task is extracted from the network topology diagram of the cloud control platform. The average path distance from the task to the node where the primary container is located is 6 hops. The average transmission delay of the current link is calculated using link detection records to be 12ms. There are three direct dependency paths between containers, involving physical cross-node communication of 3, 2, and 4 hops, respectively. The corresponding parameters are q1 = 3, q2 = 2, and q3 = 4. The total number of dependency paths is n = 3. After deployment, task 3 needs to communicate concurrently with 5 containers. This value is obtained from the number of containers under the "linked_containers" field in the task configuration template. The network bandwidth utilization monitored by the current node is 70%. The ratio of the current node's bandwidth usage to the maximum bandwidth value is calculated by the network bandwidth monitoring configuration and is normalized to 0.7. This is the parameter d.

[0099] All parameters have been unified into standard units and normalized to a calculable state;

[0100] Substitute specific parameter values: a = 6 (inter-node communication path distance, number of hops), b = 12 (communication network delay, in milliseconds), q1 = 3, q2 = 2, q3 = 4 (number of inter-node hops of the container dependency path), h = 5 (number of concurrently communicating containers, unitless), d = 0.7 (current communication congestion value of the node, a decimal in the range 0-1);

[0101] The calculation process is as follows: a+b=6+12=18,

[0102] Substitute into the calculation:

[0103] The deployment path feasibility Z = 31.06 was obtained. This result is the load quantification value of the deployment path under the current network structure and node communication status. It represents a comprehensive evaluation indicator of the impact of network resistance and structural complexity on the path during the deployment process. The deployment path screening baseline value is set to 25. Any path combination with a Z value exceeding this value will be judged as unsuitable for deployment. This value can be dynamically adjusted according to different regional deployment strategies. For example, the acceptable baseline for public network deployment scenarios is raised to 30, while the threshold is maintained at a lower level in high-density private network deployment areas. The generation of Z values ​​can guide task scheduling to filter high-communication load path combinations to avoid deployment failures or node congestion caused by excessive deployment path load. By uniformly normalizing and integrating path delay, distance, structural complexity, and communication congestion, a dynamically variable deployment path evaluation standard is constructed, which enables cloud-based deployment path screening with accurate judgment capabilities. The results indicate that Z = 31.06 exceeds the baseline value of 25, and this task and node combination should be eliminated and excluded from the deployment path configuration list.

[0104] See also Figure 5 , the log parsing module includes:

[0105] The log extraction submodule reads the container deployment result logs in the deployment path configuration list one by one, extracts the startup timestamp, CPU and memory usage, identifies the abnormal status code, and generates the startup and resource information set;

[0106] Read each container deployment log file one by one. The specific fields to be extracted should be the startup timestamp field, CPU usage field, memory usage field, and exception identification field. During the execution process, it is necessary to identify each log record with identifiers such as "StartTime", "CPUUsage", "MemUsage", and "ErrorFlag" for positioning. For example, if a container log contains "StartTime: 05-10T08:15:23Z", the timestamp can be recorded as the startup time of the container. Continue to search for CPU and memory usage fields, such as "CPUUsage: 27%" and "MemUsage: 560MB," to record the resource load level of the corresponding container at the moment of startup. If the "ErrorFlag: 1" field exists in the log, it is necessary to identify this field as the activation status of the exception flag, where "1" indicates an exception and "0" indicates normal. In a specific execution scenario, if the deployed Redis container log shows "StartTime: 05-10T08:15:23Z, CPUUsage: 13%, MemUsage: 256MB, ErrorFlag: 1", extract its startup time as 08:15:23, record the CPU and memory values, and mark the container as abnormal. It should be noted that if the record formats of various log items in the deployment platform are different, the field formats must be standardized before execution, and different formats must be unified into recognizable field names, such as converting fields such as "StartedAt", "CPU%", and "Memory(MB)" into unified field names; after the collection is completed, the startup timestamps, resource load indicators, and exception identification data of all containers are organized into a table or mapping structure in a structured manner. For example, with the container ID as the primary key, a four-tuple structure with record items of timestamp, CPU usage, memory usage, and exception status value is established. Each row stores the complete startup record of a single container, which is convenient for subsequent comparison and screening operations, and finally generates a startup and resource information set.

[0107] The timing comparison submodule calls the timestamp data of the startup and resource information sets, and compares the real-time startup time according to the container dependency order. If the dependent container starts later than the dependent container, it is recorded as a timing anomaly, using the formula:

[0108]

[0109] Calculate the timing offset value to numerically quantify the offset degree of the container startup sequence. Filter container startup pairs whose offset degree exceeds the deployment benchmark threshold to obtain the startup timing offset set.

[0110] Among them, E represents the timing offset value, t x and t y Indicates the startup timestamp of container x and container y, Rx and R y Indicates the resource usage of container x and container y, U x and U y Indicates the abnormal identification quantization value of container x and container y;

[0111] The timing skew value indicates the degree of deviation between the startup order of two dependent containers during actual deployment and their configured dependency order. This value is formed by multiplying the square of the container startup time difference by their normalized resource usage. It measures the impact of startup timing misalignment on the resource level. The average value of container anomaly flags is added as a compensation term. This indicator not only reflects the error in startup sequence but also comprehensively assesses whether the deviation is accompanied by high resource pressure or anomaly risks. This forms a multi-dimensional integrated quantitative indicator. A larger value indicates a more serious violation of the startup sequence dependency logic.

[0112] Extract the startup time data of each container one by one according to the container dependency order set in the deployment path configuration list. The acquisition method is to traverse the startup records of each container in the structured log information set, read the field "StartTime", and convert it to an absolute second value as the timestamp basis. For example, if the startup time of container A is 08:10:02 and that of container B is 08:09:50, they are converted to t x = 29402 seconds, t y = 29390 seconds, calculate the time difference t y -t x = -12 seconds, then obtain the container's resource usage data. The fields "CPUUsage" and "MemUsage" represent the CPU usage and memory usage respectively. To unify the dimensions, the CPU percentage and the memory MB value must be normalized. Assuming the normalized reference value is 100% CPU full load and the memory limit is 1024MB, the CPU usage is normalized to a proportional value: if the CPU x =15%, then after normalization it is If Mem x =250MB, then normalized to Similarly, we can get the resource usage of container A. CPU in container B y =18%, Mem y

[0113] =300MB, after normalization R y =0.18+0.293=0.473; In the abnormal identification field "ErrorFlag", the value 1 represents that the container has an abnormality, and the value 0 represents that no abnormality has occurred. This field is recorded in the form of an integer. Container A is normal (U x =0), container B is abnormal (U y=1);

[0114] Now substitute the formula for calculation:

[0115]

[0116] The final calculated result is a timing skew degree E = 12.508. Assume that the startup sequence skew tolerance threshold set by the deployment system is 10. This value is derived from the statistical average of the startup time errors between containers in the past 50 deployments plus double the standard deviation. In this example, the maximum allowable skew is set to 10 seconds. Therefore, 12.508 exceeds this threshold and is recorded as a startup skew anomaly. The skew pair between container A and container B is finally included in the startup timing skew set. In subsequent steps, the skew frequency will be counted and a list of abnormal containers will be constructed based on this.

[0117] Parameter description: E represents the startup sequence offset of the container, t x With t y is the startup timestamp of container x and y (in seconds), R x With R y Indicates the container resource usage (the sum of normalized resource values, in units of proportional values, ranging from 0 to 2), U x with U y The error is the container anomaly flag (0 indicates normal, 1 indicates anomaly). All parameters are obtained by parsing each field in the deployment log, extracting values, and converting dimensions. This does not rely on model estimation. The squared time difference term and the resource cross-product term are combined to form an offset strength evaluation function. Introducing the anomaly flag as a correction term can incorporate resource pressure and anomalies into a unified measurement indicator, effectively improving the sensitivity of deployment sequence verification. The result shows that the startup sequence of container B does not meet the deployment requirements that container A depends on. The offset has exceeded the system tolerance threshold and should therefore be recorded in the subsequent anomaly statistics process.

[0118] The exception statistics submodule accumulates and counts the frequency of container name occurrences based on the exception records in the startup timing offset set, extracts the container task names whose frequency exceeds the deployment exception statistics threshold, sorts them in descending order by frequency, and generates a deployment sequence exception list.

[0119] Using container name as the index field, count the frequencies of all containers appearing in offset records. A hash table structure can be used to extract the statistical frequency. Each time a container name appears in an offset pair, the container's occurrence count is accumulated. For example, in an offset pair consisting of "Redis→Nginx" and "Postgres→Redis," Redis appears twice, Nginx appears once, and Postgres appears once, resulting in frequencies of 2, 1, and 1, respectively. A deployment anomaly statistics threshold of 1.5 is set. Any container with a frequency exceeding this threshold is recorded as an abnormally high-incidence container. The frequency threshold is set based on the average container offset frequency statistics in the original deployment, plus the maximum frequency deviation allowed during deployment debugging as a floating value. In this example, the average abnormal container frequency in the first 100 deployments is 1.3, and the threshold is set to 1.5. Containers that meet the criteria are sorted in descending order of frequency to form a dictionary or list structure. Each row in the list contains the container name and the corresponding offset frequency value. Finally, container task names with a frequency greater than 1.5 are filtered to obtain a list of deployment order anomalies.

[0120] See also Figure 6 , the container repair module includes:

[0121] The abnormal status identification submodule calls the current running status and abnormal status count of the container in the deployment order abnormality list to determine whether the running status is inconsistent with the set normal status code, screens the abnormal status containers and records their identifiers, status codes and abnormal counts, and generates a cloud abnormal status container list;

[0122] Call the task allocation log and container operation status record in the cloud deployment scheduling, extract the unique identification field, allocation timestamp and scheduling node number of all containers in the list, and then obtain the real-time status value of each container on the corresponding node. The status value can be obtained by querying the container monitoring module, including fields such as operation code, fault interruption record and restart count. If the container operation code field is inconsistent with the preset standard status code field, the container is judged to be in an abnormal operation state. For example, the status code "0" is normal operation, "1" is not started, and "2" is interrupted operation. When the actual status code is "2", it is listed as an abnormal container, and then its abnormal number field value is counted. This field is based on the cumulative number of status abnormalities in the continuous status recording period. For example, set every 10 minutes as a status recording period. If it occurs 3 times within 1 hour Status "2", then its abnormality count is 3. This value is obtained by directly accumulating the abnormal status time points marked in the monitoring log field, and comparing with the set threshold items to determine whether there are frequent abnormalities. The abnormality count field and the running status field should be batch read and automatically extracted and generated by the cloud log analysis middle platform. Further, the identification, corresponding node, running code, and abnormality count fields of all abnormal containers are unified and output to generate structured data items. The specific fields include container ID, status code, abnormality count, and node number to which it belongs, and the output timestamp is recorded for subsequent comparison and tracking. For example, container C001 has status code "2" for a total of 5 consecutive times on node N03, and it accumulates more than 3 times within the set period. It is identified as an abnormal container. The data will be written into the abnormal identification list to form a cloud status abnormal container list.

[0123] The tolerance screening submodule obtains a list of abnormal containers in the cloud, extracts the number of container anomalies, compares them item by item with the set tolerance threshold, determines the set of containers whose anomalies exceed the threshold, extracts the running image and configuration parameters, and obtains the parameter set of the container that needs to be redeployed;

[0124] The abnormal number field of each container is extracted one by one and compared with the set abnormal tolerance threshold value. The tolerance threshold value is set according to the container operation type. For example, the tolerance value of the high-frequency communication container is set to 2 times, and the tolerance value of the low-frequency storage container is set to 4 times. The threshold value has been parameterized in the container configuration template and can be directly extracted by matching the container type field with the configuration template parameter. Then, the abnormal number field and its corresponding threshold value field are compared with the container as a unit. If the abnormal number field value is greater than the corresponding tolerance threshold value field value, the container is determined to be an abnormal frequency exceeding limit container and its image is extracted. The path, required CPU and memory resource values, container volume information, and port occupancy range constitute its complete deployment configuration parameter set, which will be used for subsequent node resource scheduling and replacement deployment operations. For example, container C001 belongs to the high-frequency class, with a set threshold value of 2 times. If the number of exceptions is 5, it is judged as an over-limit container. Its image path is "registry / comm / c001:v2", the required CPU is 1.5 Core, the memory is 2048 MB, and the port occupancy is in the range of 9001 to 9003. Its complete configuration information is recorded in the parameter set to form the parameter set of the container that needs to be redeployed.

[0125] The node deployment scheduling submodule identifies the node's current resource usage and network communication delay based on the parameter set of the container to be redeployed, analyzes the deployment matching degree, selects the node with the best deployment matching degree, synchronizes the container image and configuration, records the replacement path and execution time, and obtains a cloud deployment replacement record data table;

[0126] Extract the resource requirement fields of each container, including the number of CPU cores, memory requirement value, occupied port range, etc., then call the real-time resource monitoring data of each deployment node in the current cloud resource pool, extract the current remaining CPU, memory remaining amount and network communication delay value of each node, and calculate the difference between the container resource requirement field and the node remaining resource field item by item to obtain the initial value of the satisfiability of each node. Nodes with a CPU and memory resource difference greater than or equal to zero and a communication delay value lower than the set network delay baseline value are regarded as optional node sets, and the network delay baseline value is set to 30ms. When the communication delay field is less than this baseline value, it is included in the range of schedulable nodes, and then the node with the highest deployment matching degree is selected from the optional node set as the replacement deployment target node. In the process of deployment matching degree calculation, the CPU difference ratio, memory difference ratio and The weighted sum of the inverse of network delay is used as the total matching value, and the weight is set according to the resource intensity. For example, when the overall CPU utilization of the node exceeds 70%, the CPU difference weight is set to 0.5, and the remaining resource items are reduced proportionally. The top-ranked node is then selected based on the matching degree, and the scheduling command is called to synchronize the container image and configuration file to the target node, starting the container deployment process. At the same time, the deployment time, original node number, new node number, replacement status field and image path are recorded, and finally a structured record field set is formed. For example, the CPU required by container C001 is 1.5 Cores, the remaining CPU of the current node N01 is 2.2 Cores, the remaining memory is 4096MB, and the latency is 25ms. All conditions are met and the matching degree is the largest. In this case, it is selected as the replacement node and the deployment is completed, generating a cloud deployment replacement record data table.

[0127] The above are merely preferred embodiments of the present invention and do not limit the present invention in any other form. Any technician familiar with the profession may use the technical content disclosed above to change or modify it into an equivalent embodiment with equivalent changes and apply it to other fields. However, any simple modification, equivalent change and modification made to the above embodiment based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of protection of the technical solution of the present invention.

Claims

1. A cloud code deployment system, characterized in that: The system comprises: The resource monitoring module obtains the deployment node load indicators, network bandwidth usage and container storage capacity values, collects the resource request list of the cloud deployment task, compares the resource items in the resource request list with the current node resource remaining, selects the corresponding relationship between the node and task that meets the request, and generates a task node mapping table; The task scheduling module calls the task and node distribution data in the task node mapping table, extracts the scheduling priority of the task and the container image dependency order, identifies the deployment conflicting tasks and extracts the priority tags of the conflicting tasks, readjusts the scheduling order by priority sorting, and generates a deployment priority task sequence; The path construction module calls the task items in the deployment priority task sequence, identifies the container operating environment configuration and port dependencies, compares the available ports of the deployment nodes, screens compatible nodes and analyzes the container path, and generates a deployment path configuration list; The log parsing module extracts the container startup timestamp, resource usage and exception identification according to the container deployment result log in the deployment path configuration list, compares the startup sequence with the dependency, counts the task names and frequencies of startup timing exceptions, and generates a deployment sequence exception list.

2. The cloud code deployment system according to claim 1, characterized in that: The task node mapping table includes node load information matching items, network bandwidth allocation labels, and container storage capacity indicators; the deployment priority task sequence includes a scheduling priority label, an image dependency order identifier, and a conflicting task identification code; the deployment path configuration list includes an environment configuration parameter item, a port allocation list, and a path dependency relationship identifier; the deployment sequence exception list includes an abnormal task name item, a startup timing deviation label, and a dependency verification result code.

3. The cloud code deployment system according to claim 1, characterized in that: The resource monitoring module includes: The node status acquisition submodule obtains the deployment node load indicators, network bandwidth utilization, and container storage capacity values. It monitors the node CPU utilization, network bandwidth utilization, and container storage capacity values, compares them with the corresponding load, bandwidth, and capacity thresholds, determines whether the indicators meet the preset tolerance range, and generates node resource remaining data. The resource list comparison submodule collects the resource request list of the cloud task based on the node resource remaining amount data, extracts the CPU, bandwidth and storage request values ​​of the task, compares them with the remaining resources of the node, selects the corresponding relationship between the node and the task that meets the request conditions, and generates the distribution of optional nodes for the task; The task mapping generation submodule sorts the resources of the nodes based on the distribution of the optional nodes of the task, selects nodes with low resource load as deployment nodes of the task, and generates a task node mapping table.

4. The cloud code deployment system according to claim 3, characterized in that: The task scheduling module includes: The scheduling factor extraction submodule calls the task-bound node and container image dependency information in the task node mapping table, extracts the scheduling priority field and the image loading order value, performs sequential processing based on the image pull path and loading level, and generates the image scheduling sort value; The conflict tag identification submodule classifies and compares the image loading path intersection or resource lock duplicate tasks in the same node according to the image scheduling sort value, extracts the scheduling priority label and node position, marks the conflicting task group, and generates a deployment conflict label set; The deployment sequence rearrangement submodule calls the deployment conflict label set, extracts the node IO bandwidth, image loading delay and task execution time, builds a task deployment sorting model, calculates the deployment priority value of the task, and uses the priority value as a benchmark to adjust the scheduling order and generate a deployment priority task sequence.

5. The cloud code deployment system according to claim 4, characterized in that: The path construction module includes: The environment configuration extraction submodule calls the task items in the deployment priority task sequence, parses the container image configuration, extracts the operation type, kernel version, middleware dependency and port mapping, compares them with the node environment, determines the environment compatibility, and generates an environment compatibility label set; The port compatibility judgment submodule retrieves the port resources and dependencies of the compatible task node pairs according to the environment compatibility tag set, compares the port occupancy item by item, counts the valid mappings, excludes nodes with port overlap exceeding a threshold, and obtains an available port mapping list; The path feasibility evaluation submodule calls the task and node combinations in the port mapping available list, processes the communication distance, delay and number of dependent paths between tasks between network paths, calculates the feasibility value of the task deployment path, screens out combinations that do not meet the path deployment requirements according to the feasibility value, and generates a deployment path configuration list.

6. The cloud code deployment system according to claim 5, characterized in that: The log parsing module includes: The log extraction submodule reads the container deployment result log in the deployment path configuration list one by one, extracts the startup timestamp, CPU and memory usage, identifies the abnormal status code, and generates a startup and resource information set; The timing comparison submodule calls the timestamp data in the startup and resource information set, compares the real-time startup time according to the container dependency order, and records a timing anomaly if the dependent container starts later than the dependent container. The timing offset value is calculated, and the offset degree of the container startup sequence is quantified in numerical form. The container startup pairs with an offset degree higher than the deployment benchmark threshold are selected to obtain the startup timing offset set. The exception statistics submodule accumulates and counts the occurrence frequency of container names according to the exception records in the startup timing offset set, extracts the container task names whose frequency is greater than the deployment exception statistics threshold, arranges them in descending order of frequency, and generates a deployment order exception list.

7. The cloud code deployment system according to claim 1, characterized in that: The system also includes a container repair module: The container repair module calls the deployment sequence exception list, monitors the current running status and exception count of the corresponding container, identifies containers with abnormal status and anomaly frequency higher than the tolerance threshold, performs task redeployment operations and locates replacement nodes, and obtains a cloud deployment replacement record data table; The cloud deployment replacement record data table includes a replacement container number, a redeployment node identifier, and abnormal container statistics.

8. The cloud code deployment system according to claim 7, characterized in that: The container repair module includes: The abnormal state identification submodule calls the current running state and the number of abnormal state counts of the containers in the deployment order abnormality list, determines whether the running state is inconsistent with the set normal state code, filters out abnormal state containers and records their identifiers, status codes and abnormal counts, and generates a cloud abnormal state container list; The tolerance screening submodule obtains a list of abnormal containers in the cloud, extracts the number of container anomalies, compares them item by item with the set tolerance threshold, determines the set of containers whose anomalies exceed the threshold, extracts the running image and configuration parameters, and obtains the parameter set of the container that needs to be redeployed; The node deployment scheduling submodule identifies the current resource occupancy rate and network communication delay of the node based on the parameter set of the container to be redeployed, analyzes the deployment matching degree, selects the node with the best deployment matching degree, synchronizes the container image and configuration, records the replacement path and execution time, and obtains a cloud deployment replacement record data table.

Images