Abnormality processing method

Abstract

The invention discloses an exception handling method, which comprises the following steps: detecting the running state of a Docker container in response to a detection instruction; if the running state is abnormal, determining abnormal information based on a running log of the Docker container; the abnormal information comprises at least one of running log damage, running file abnormity, system resource overload and port occupation; and correspondingly performing recovery processing according to the abnormal information. Therefore, when the running state of the Docker container is abnormal, the corresponding abnormal information is determined, and recovery processing is carried out in time based on the abnormal information, so that normal running of a service system is guaranteed.

Description

Technical Field

[0001] The present application relates to the field of computer software technology, and in particular to an exception handling method. Background Art

[0002] In the current business environment, microservice deployment has become a common practice. To achieve this goal, the basic operating environment is generally packaged by building images. As a powerful underlying tool, Docker containers provide a reliable platform for the operation of these images. It can be said that Docker containers are the key to the normal operation of the entire microservice system, so it is crucial to ensure its stable operation.

[0003] However, in actual edge scenarios, users may encounter various unpredictable operations, such as frequent and random power outages and other abnormal situations. These factors may cause the Docker container to fail to start normally, thus affecting the operating status of the business system. Summary of the invention

[0004] The purpose of this application is to provide an exception handling method. When the running status of a Docker container is abnormal, the corresponding exception information is determined, and recovery processing is performed in a timely manner based on the exception information, which helps to ensure the normal operation of the business system.

[0005] To achieve the above objectives:

[0006] In a first aspect, an embodiment of the present application provides an exception handling method, including:

[0007] In response to the detection instruction, detecting the running status of the Docker container;

[0008] If the running state is abnormal, abnormal information is determined based on the running log of the Docker container; the abnormal information includes at least one of a damaged running log, abnormal running file, overloaded system resources, and occupied ports;

[0009] According to the abnormal information, corresponding recovery processing is performed.

[0010] In one embodiment, detecting the running status of the Docker container in response to the detection instruction includes:

[0011] Based on the received detection instruction, obtain the running status of the Docker container;

[0012] If the running state of the Docker container meets the preset condition, determining that the running state is abnormal;

[0013] If not, determining that the operating state is normal;

[0014] The preset condition includes at least one of the following: the Docker container is in an inactive state; the daemon process of the Docker container is unavailable; the Docker container has a network connection problem.

[0015] In one implementation, determining the abnormal information based on the running log of the Docker container includes:

[0016] If the running log of the Docker container cannot be obtained, or the obtained running log is empty, it is determined that the abnormal information includes damage to the running log.

[0017] In one implementation, the performing recovery processing according to the abnormal information includes:

[0018] If the abnormal information includes a damaged operation log, deleting the operation log and restarting the Docker container; and / or,

[0019] If the abnormal information includes a damaged operation log, the target operation files in the Docker container are updated in sequence based on the file update order until the operation status of the Docker container returns to normal, or all the target operation files in the Docker container are updated.

[0020] In one embodiment, the updating process of the target running files in the Docker container in sequence based on the file update order includes:

[0021] Determine the target running file in the Docker container and the file update order of the target running file;

[0022] Determine the target backup file corresponding to the target running file, and replace the target running file with the corresponding target backup file in sequence.

[0023] In one implementation, based on the file update sequence, updating the target running files in the Docker container in sequence includes:

[0024] Obtaining, in the Docker container, an operation file whose historical abnormal frequency is higher than a preset frequency threshold as the target operation file;

[0025] The target operation files are sorted from high to low according to the historical abnormal frequencies of the target operation files to determine the file update sequence of the target operation files.

[0026] In one embodiment, based on the file update order, the target running files in the Docker container are updated in sequence until the running state of the Docker container returns to normal, or after all the target running files in the Docker container are updated, the method further includes:

[0027] If the running state of the Docker container has not been restored to normal, and the target running files in the Docker container have been updated, the Docker container is initialized to deploy the preset backup files corresponding to each running file in the Docker container into the Docker container.

[0028] In one implementation, the performing recovery processing according to the abnormal information includes:

[0029] If the abnormal information includes an operation file abnormality, determining an abnormal file corresponding to the operation file abnormality;

[0030] A preset backup file corresponding to the abnormal file is determined, and the abnormal file is updated according to the backup file.

[0031] In one embodiment, the running file abnormality includes a file type abnormality and / or a configuration file abnormality;

[0032] The determining a preset backup file corresponding to the abnormal file, and updating the abnormal file according to the backup file, includes:

[0033] When the running file abnormality includes the file type abnormality, determining a first preset backup file corresponding to the abnormal file, and replacing the abnormal file with the first preset backup file; and / or,

[0034] When the running file abnormality includes the configuration file abnormality, a second preset backup file corresponding to the abnormal file is determined, and the abnormal file is replaced with the second preset backup file.

[0035] In one implementation, the performing recovery processing according to the abnormal information includes:

[0036] When the abnormal information includes a system resource overload, updating the operating parameters of the system resource of the Docker container and restarting the Docker container, and if the abnormal information also includes the system resource overload after a preset time, closing a first application, wherein the first application is a non-essential application in a running state; and / or,

[0037] When the abnormal information includes that the port is occupied, an unoccupied target port is detected, and a startup configuration parameter of the Docker container is modified based on the target port, and the Docker container is restarted according to the modified startup configuration parameter.

[0038] The exception handling method provided in the embodiment of the present application includes: responding to the detection instruction, detecting the running state of the Docker container; if the running state is abnormal, determining the abnormal information based on the running log of the Docker container; the abnormal information includes at least one of the following: the running log is damaged, the running file is abnormal, the system resource is overloaded, and the port is occupied; according to the abnormal information, corresponding recovery processing is performed. In this way, when the running state of the Docker container is abnormal, the corresponding abnormal information is determined, and recovery processing is performed in time based on the abnormal information, which helps to ensure the normal operation of the business system. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 Schematic diagram of the process of the exception handling method provided by the embodiment of the present invention Figure 1 ;

[0040] Figure 2 The following is a flow chart of the exception handling method provided by the embodiment of the present invention. Figure 2 ;

[0041] Figure 3 A schematic diagram of the structure of a computing device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0042] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0043] It should be noted that, in this article, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element. In addition, components, features, and elements with the same name in different embodiments of the present application may have the same meaning or different meanings, and their specific meanings need to be determined by their explanation in the specific embodiment or further combined with the context of the specific embodiment.

[0044] It should be understood that, although the terms first, second, third, etc. may be used to describe various information in this article, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this article, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein can be interpreted as "at the time of..." or "when..." or "in response to determination". Furthermore, as used in this article, the singular forms "one", "one" and "the" are intended to also include plural forms, unless there is an opposite indication in the context. It should be further understood that the terms "comprising", "including" indicate that there are described features, steps, operations, elements, components, projects, kinds, and / or groups, but do not exclude the existence, occurrence or addition of one or more other features, steps, operations, elements, components, projects, kinds, and / or groups. The terms "or" and "and / or" used herein are interpreted as inclusive, or mean any one or any combination. Thus, “A, B, or C” or “A, B and / or C” means “any of the following: A; B; C; A and B; A and C; B and C; A, B, and C.” An exception to this definition will occur only when a combination of elements, functions, steps, or operations are inherently mutually exclusive in some manner.

[0045] It should be understood that, although the various steps in the flowchart in the embodiment of the present application are displayed in sequence according to the indication of the arrows, these steps are not necessarily performed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and it can be performed in other orders. Moreover, at least a portion of the steps in the figure may include a plurality of sub-steps or a plurality of stages, and these sub-steps or stages are not necessarily performed at the same time, but can be performed at different times, and their execution order is not necessarily performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0046] It should be noted that in this article, step codes such as S101, S102, etc. are used for the purpose of expressing the corresponding content more clearly and concisely, and do not constitute a substantial limitation on the sequence. When implementing the step, those skilled in the art may execute S102 first and then S101, etc., but these should all be within the scope of protection of this application.

[0047] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application, and have no specific meanings. Therefore, "module", "component" or "unit" can be used in a mixed manner.

[0049] See also Figure 1 The embodiment of the present application provides an exception handling method, which can be implemented in software and / or hardware. In this embodiment, the exception handling method is applied to a computing device as an example. The exception handling method provided in this embodiment includes:

[0050] Step S101: In response to a detection instruction, detect the running status of the Docker container.

[0051] Optionally, the running status of the Docker container is monitored based on the detection program of the deployed Docker container. Specifically, a scheduled task can be set, such as sending a detection instruction every two seconds to detect the running status of the Docker container. In other embodiments, the running status of the Docker container can also be detected directly based on the detection instruction issued by the administrator.

[0052] In one embodiment, in response to the detection instruction in step S101, detecting the running status of the Docker container includes:

[0053] Based on the received detection instructions, obtain the running status of the Docker container;

[0054] If the running status of the Docker container meets the preset conditions, it is determined that the running status is abnormal;

[0055] If not, it is determined that the operating status is normal;

[0056] The preset conditions include at least one of the following: the Docker container is inactive; the daemon process of the Docker container is unavailable; and the Docker container has a network connection problem.

[0057] The detection instructions include instructions for "determining the Docker activity status" and instructions for "availability of the Docker daemon process". Optionally, based on the instruction for "determining the Docker activity status", it is determined whether the Docker container is in an active state. If the Docker container is not in an active state, that is, in an inactive state, or there is a network connection problem with the Docker container, it is determined that the running state of the Docker container is abnormal. If the Docker container is in an active state, the daemon process status of the Docker container is further determined based on the instruction for "availability of the Docker daemon process". If it is impossible to connect to the daemon process of the Docker container, that is, the daemon process of the Docker container is unavailable, it is determined that the running state of the Docker container is abnormal. Otherwise, it is determined that the running state of the Docker container is normal.

[0058] Exemplarily, the activity status of the Docker container is detected by the systemctl is-active docker command (also known as determining the activity status of the Docker container). If the return value is active, the command docker ps-a|grep-q "Cannot connect to the Docker daemon" (also known as being unable to connect to the Docker daemon) is used to detect whether the Docker container is available. If the return value is non-empty, it indicates that the running status of the Docker container is abnormal; if the return value is empty, it indicates that the running status of the Docker container is normal and exits directly. Here, when the activity status of the Docker container is detected by the systemctl is-activedocker command, if the return value is not active, the systemctlrestart docker command (also known as restarting the Docker service) is executed, and after sleeping for 3s, the systemctl is-active docker command is used again to detect the activity status of the Docker container. If the return value is active, exit; otherwise, it is determined that the running status of the Docker container is abnormal.

[0059] Step S102: If the running state is abnormal, abnormal information is determined based on the running log of the Docker container; the abnormal information includes at least one of a damaged running log, abnormal running files, overloaded system resources, and occupied ports.

[0060] In one implementation, determining the abnormal information based on the running log of the Docker container in step S102 includes:

[0061] If the running log of the Docker container cannot be obtained, or the obtained running log is empty, or the running log is incomplete, it is determined that the abnormal information includes damage to the running log.

[0062] Optionally, since the log driver of the operation log is abnormal, the operation log cannot be collected or displayed normally, so it can be confirmed whether the operation log of the Docker container cannot be obtained by confirming whether the log driver of the operation log of the Docker container is working properly. In this way, if it is confirmed that the log driver of the operation log of the Docker container is not working properly, it can be determined that the operation log of the Docker container is damaged. Here, if the content of the operation log is empty, it may be caused by the application not recording the log correctly, or by a problem with the log rotation setting.

[0063] Among them, when it is confirmed that the log file of the operation log is damaged or incomplete due to disk failure, unexpected system shutdown, etc., it can also be determined that the abnormal information includes the damage of the operation log of the Docker container. When the operation file of the Docker container is modified or deleted by mistake, the container cannot run normally, resulting in the inability to find the operation file or errors and other information, it is determined that the operation file of the Docker container is abnormal. When the Docker container cannot run normally because the resources such as the CPU, memory or disk space of the host machine have reached their limits, resulting in insufficient resources or performance degradation, it is determined that the system resources of the Docker container are overloaded. Since the Docker container needs to use specific ports, but if these ports are occupied by other applications, it will cause the container to fail to start, resulting in port conflicts or error messages that the port cannot be listened to, and it is determined that the port of the Docker container is occupied.

[0064] Optionally, since the running log of the Docker container records all activities and error information during the running process of the container, the specific cause of the abnormality and the corresponding location of the abnormality can be determined by viewing the running log of the Docker container. This helps to quickly locate the abnormal problem and improve the efficiency and accuracy of troubleshooting.

[0065] Step S103: Perform recovery processing according to the abnormal information.

[0066] Optionally, when detecting an abnormality in the running state of a Docker container, the various reasons for the abnormality are taken into consideration, and thus the location of the current abnormality and the specific reason for the abnormality can be determined based on the obtained abnormal information. In this way, different recovery processing strategies can be executed based on different abnormal information. Here, due to the different abnormal information, the corresponding recovery processing strategies are different.

[0067] In one embodiment, the recovery process is performed according to the abnormal information in step S103, including:

[0068] If the abnormal information includes a corrupted running log, delete the running log and restart the Docker container; and / or,

[0069] If the abnormal information includes damaged operation logs, the target operation files in the Docker container are updated in sequence based on the file update order until the operation status of the Docker container returns to normal or all the target operation files in the Docker container are updated.

[0070] Optionally, the target running files in the Docker container are updated in sequence, and after each update of the target running files is completed, the running state of the Docker container is detected to determine whether the running state of the Docker container has returned to normal. If the running state of the Docker container is still in an abnormal state, the next target running file is updated based on the file update sequence until the running state of the Docker container returns to normal, and the update process step is terminated.

[0071] Here, if all target running files in the file update sequence have been updated and the running state of the Docker container is still in an abnormal state, the update process step is also terminated.

[0072] In one embodiment, based on the file update order, the target running files in the Docker container are updated in sequence until the running state of the Docker container returns to normal, or after all the target running files in the Docker container are updated, the method further includes:

[0073] If the running status of the Docker container has not returned to normal, and the target running files in the Docker container have been updated, the Docker container is initialized to deploy the preset backup files corresponding to each running file in the Docker container into the Docker container.

[0074] Optionally, before initialization, the preset backup files corresponding to the various running files in the Docker container can be mirrored and saved as an image data package based on the Docker save command. In this way, when the Docker container is initialized, the preset backup files corresponding to the various running files in the image data package are deployed to the Docker container based on the Docker load command to ensure that the running state of the Docker container can be restored to normal.

[0075] In one implementation, based on the file update sequence, the target running files in the Docker container are updated in sequence, including:

[0076] Determine the target running file in the Docker container and the file update order of the target running file;

[0077] Determine the target backup file corresponding to the target running file, and replace the target running file with the corresponding target backup file in sequence.

[0078] The file update order is used to determine the priority of updating the target running file. In this way, based on the highest priority to the lowest priority, the target running file is replaced with the corresponding target backup file in sequence. This can be based on the target backup file to replace part of the target running file, or directly replace the entire target running file with the corresponding target backup file.

[0079] In one implementation, based on the file update sequence, the target running files in the Docker container are updated in sequence, including:

[0080] Obtain the running files in the Docker container whose historical abnormal frequency is higher than the preset frequency threshold as the target running files;

[0081] The target running files are sorted from high to low according to their historical abnormal frequencies to determine a file update sequence of the target running files.

[0082] First, obtain the historical data of Docker container anomalies, including the operating files with abnormalities in the historical data and the corresponding historical abnormal frequencies. Secondly, compare the historical abnormal frequencies corresponding to each operating file with the preset frequency threshold, and determine the operating files with abnormal frequencies higher than the preset frequency threshold as target operating files. Finally, sort the target operating files from high to low according to the historical abnormal frequencies of the target operating files to determine the order of file updates. In this way, when a Docker container is abnormal, the target operating files that are most likely to have abnormal problems can be processed first, which helps the operating status of the Docker container return to normal faster.

[0083] In one implementation, performing recovery processing according to the abnormal information in step S103 may include:

[0084] If the abnormal information includes an operation file abnormality, determining an abnormal file corresponding to the operation file abnormality;

[0085] Determine the preset backup file corresponding to the abnormal file, and update the abnormal file according to the backup file.

[0086] Here, when the abnormal file is updated according to the backup file, the abnormal file may be updated based on the abnormal part of the abnormal file, or the backup file may be directly replaced with the abnormal file.

[0087] Optionally, when the abnormality of the running file is determined through the running log, the abnormal file with the abnormality is determined, and further, the damaged abnormal file in the current container is replaced and updated with the backup file, that is, it is achieved by copying the backup file to the corresponding location in the Docker container, ensuring that the restored file permissions and owners match the original settings to avoid new access rights issues. Here, the backup file is a normal file that is backed up in advance and stored in a fixed directory of the edge node. In this way, by identifying and processing the abnormality of the running file and effectively using the backup file for recovery, not only can the recovery capability and data security of the Docker container be improved, but also the stability of the system can be further improved and maintenance work can be simplified.

[0088] In one embodiment, the abnormality of the running file in step S103 includes abnormality of the file type and / or abnormality of the configuration file;

[0089] Determine the preset backup file corresponding to the abnormal file, and update the abnormal file according to the backup file, including:

[0090] When the running file abnormality includes a file type abnormality, determining a first preset backup file corresponding to the abnormal file, and replacing the abnormal file with the first preset backup file; and / or,

[0091] When the running file abnormality includes the configuration file abnormality, a second preset backup file corresponding to the abnormal file is determined, and the abnormal file is replaced with the second preset backup file.

[0092] Optionally, if the file type is determined to be a directory type through the running log of the Docker container, it is determined that the file type of the abnormal file is abnormal. In this way, the abnormal file is deleted, and then the first preset backup file backed up in advance is used to replace the abnormal file. Here, the first backup file is a preset backup file corresponding to the current abnormal file.

[0093] Exemplarily, take the abnormal file as a socket file. In the Linux system, / run / docker.sock is a Unix socket file used for communication between the Docker daemon and the client. In the Linux system, you can use the ls-l command to view the type of the socket file, because the permission mode of the socket file will be displayed as srwxr-xr-x or other similar formats, where the first character s indicates that this is a socket file. In this way, you can check whether / run / docker.sock has been modified to a directory type by checking the first character of its permission mode. For example, if the first character of its permission mode is d, it means that the file has been modified to a directory type, thereby determining that the file type is abnormal.

[0094] Optionally, when the running file exception is detected as a configuration file exception, the integrity and accessibility of the / etc / docker / daemon.json file is generally checked based on Linux commands. For example, you can use the ls and cat commands to check whether the abnormal file exists and whether the content is readable. If the abnormal file is inaccessible or the content is displayed abnormally (such as garbled characters or permission errors), it indicates that there may be damage or configuration errors, thereby determining that the configuration file of the Docker container is abnormal. In this way, after determining that the configuration file is abnormal, the abnormal file corresponding to the configuration file exception is deleted, and the abnormal file is replaced by the pre-backed up second preset backup file. Here, the second backup file is the preset backup file corresponding to the current abnormal file.

[0095] Here, after updating the abnormal file through the backup file, you can also check the service status of the Docker container to ensure the normal operation status of the Docker container.

[0096] In one embodiment, the recovery process is performed according to the abnormal information in step S103, including:

[0097] When the abnormal information includes a system resource overload, the operating parameters of the system resources of the Docker container are updated and the Docker container is restarted. If the abnormal information also includes a system resource overload after a preset time, the first application is closed, wherein the first application is a non-essential application in a running state.

[0098] Optionally, the resource usage is determined based on the running log of the Docker container, that is, the memory and CPU usage of the Docker container is determined, whether there is a problem of excessive resource consumption, or whether a specific process occupies a large amount of resources, which can be achieved by viewing the resource usage of each process. If it is detected that the memory or CPU usage is too high, the operating parameters of the system resources of the Docker container are updated based on the minimum CPU and memory resources set when the Docker container is started, and the Docker container is restarted.

[0099] Here, if after restarting the Docker container or within a preset time after restarting the Docker container, it is detected that the Docker container still has a system resource overload problem, it can be determined that the current system resources are still insufficient to support the operation of more applications. At this time, it is necessary to further release system resources, including: shutting down unnecessary applications and services, that is, first applications, especially those that consume a lot of resources. This can be done through the system's service management tools (such as systemctl, service command) to stop or disable unnecessary services. In this way. After releasing resources, check the system resource usage of the Docker container again to confirm that resource usage has been reduced to a safe level.

[0100] In one embodiment, the recovery process is performed according to the abnormal information in step S103, and further includes:

[0101] When the abnormal information includes that the port is occupied, an unoccupied target port is detected, and a startup configuration parameter of the Docker container is modified based on the target port, and the Docker container is restarted according to the modified startup configuration parameter.

[0102] Optionally, based on the running log of the Docker container, after detecting that the port is occupied, the occupied port number is incremented by 1 to determine other new ports, and the netstat command is executed in the program to detect whether the new port is occupied. In this way, the new port that is not occupied is determined as the target port, and the startup configuration of the Docker container is modified based on the port information of the target port.

[0103] In other embodiments, when an abnormal running state of a Docker container is detected and the Docker container meets a preset initialization condition, an initialization operation is performed on the Docker container, and backup files for preset backups of various files of the Docker container are added to the Docker container to ensure that the running state of the Docker container returns to normal.

[0104] Here, the preset initialization conditions include any of the following: the running status of the Docker container is abnormal; at least one abnormal information is detected, and after the recovery processing is performed based on the detected abnormal information, the running status of the Docker container is still abnormal; multiple abnormal information is detected in the Docker container; when the Docker container is detected to be abnormal, no abnormal information is found based on the running log of the Docker container; receiving a Docker container initialization instruction, etc.

[0105] Here, when adding the preset backup files to the Docker container, first use the docker save command to save the images of edge components and services into a large image package. After the Docker container is initialized, reload the image package based on the Docker load command to ensure that the service can run normally.

[0106] In this way, when an abnormal running status of a Docker container is detected, the normal operation of the Docker container is guaranteed in many aspects by setting up a variety of recovery strategies, thereby ensuring the normal operation of business microservices, reducing business system abnormalities caused by force majeure or human factors, and improving the reliability and robustness of the entire system.

[0107] In summary, in the exception handling method provided in the above embodiment, when the running status of the Docker container is abnormal, the corresponding exception information is determined, and recovery processing is performed in time based on the exception information, which helps to ensure the normal operation of the business system.

[0108] See also Figure 2 The embodiment of the present invention also provides an exception handling method, which specifically includes:

[0109] Step S201: Detect the running status of the Docker container.

[0110] In one embodiment, the running state of the Docker container can be monitored based on the detection program of the deployed Docker container. Specifically, a timed task can be set, such as sending a detection instruction every two seconds to detect the running state of the Docker container.

[0111] Step S202: Determine whether the running status of the Docker container is normal.

[0112] Specifically, it is possible to determine whether the Docker container is in an active state based on the instruction of "determining the Docker activity state". If the Docker container is not in an active state, that is, in an inactive state, or if there is a network connection problem with the Docker container, it is determined that the running state of the Docker container is abnormal. If the Docker container is in an active state, the daemon state of the Docker container is further determined based on the instruction of "availability of the Docker daemon process". If it is impossible to connect to the daemon process of the Docker container, that is, the daemon process of the Docker container is unavailable, it is determined that the running state of the Docker container is abnormal. Otherwise, it is determined that the running state of the Docker container is normal.

[0113] Specifically, in one embodiment, whether the running status of the Docker container is normal can be confirmed by determining whether some files of the Docker container are damaged due to problems such as sudden power outages or improper human operations (for example, the virtual machine carrying the operating system is forced to restart or shut down).

[0114] If the running status of the Docker container is normal, return to step S201 to detect the running status of the Dockers container.

[0115] If the running state of the Docker container is abnormal, the process proceeds to step S203 to determine whether all high-frequency abnormal files have been replaced;

[0116] The high-frequency abnormality file may be a target operation file confirmed based on historical operation data, or may be a target operation file preset by the system or the user.

[0117] If all high-frequency files have not been replaced, the process proceeds to step S204 to replace high-frequency abnormal files.

[0118] Optionally, in one embodiment, when replacing high-frequency abnormal files, the high-frequency abnormal files are generally replaced in order from high to low based on the frequency of abnormalities in the Docker container. Alternatively, the high-frequency abnormal files can be replaced in order based on a preset priority sorting order. In this way, when replacing the running files in the Docker container, the high-frequency abnormal files with the highest priority in the sorting are replaced with the pre-backed-up normal files first.

[0119] Step S205: Determine whether the Docker container has returned to normal.

[0120] Optionally, after each replacement is completed, it can be checked whether the running status of the Docker container has recovered to normal operation;

[0121] If the Docker container does not return to normal, the process returns to step S203 to determine whether all high-frequency abnormal files have been replaced.

[0122] In this embodiment, when the Docker container has not returned to normal and only a partial replacement of high-frequency exception files has been completed, the replacement process can be continued from high to low based on priority sorting (such as historical exception frequency), that is, each file replacement is retained, and so on. By giving priority to replacing high-frequency exception files with high historical exception frequencies, the recovery efficiency of the Docker container can be improved.

[0123] If all high-frequency abnormal files have been replaced, the process proceeds to step S206 to initialize the Docker container. After executing step S206, the process returns to step S201 to detect the running status of the Docker container.

[0124] Optionally, if all replaceable high-frequency abnormal files have been replaced after multiple consecutive attempts, and the running state of the Docker container is still in an abnormal state, the Docker component is initialized. In this process, the backup files corresponding to the running files in the Docker container are deployed to the Docker container to increase the probability that the Docker component can be restored to a normal state before the abnormality occurs.

[0125] In summary, in the exception handling method provided in this embodiment, the efficiency of exception handling can be improved by automatically detecting and replacing high-frequency exception files to repair the running files of the Docker container.

[0126] Based on the same inventive concept as the above embodiments, an embodiment of the present invention provides a computing device, such as Figure 3 As shown, the computing device includes: a processor 310 and a memory 311 storing a computer program; wherein, Figure 3 The processor 310 shown in the figure is not used to indicate that the number of the processor 310 is one, but is only used to indicate the positional relationship of the processor 310 relative to other devices. In actual applications, the number of the processor 310 may be one or more; similarly, Figure 3 The memory 311 shown in the figure has the same meaning, that is, it is only used to refer to the position relationship of the memory 311 relative to other devices. In practical applications, the number of memories 311 can be one or more. When the processor 310 runs the computer program, the above exception handling method is implemented.

[0127] The computing device may also include: at least one network interface 312. The various components in the computing device are coupled together via a bus system 313. It is understood that the bus system 313 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 313 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the bus system 313 is not used in the example above. Figure 3 Various buses are labeled as bus system 313.

[0128] The memory 311 may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memories. The nonvolatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM); the magnetic surface memory may be a disk memory or a tape memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM, SyncLink Dynamic Random Access Memory), and direct RAM bus random access memory (DRRAM, Direct Rambus Random Access Memory).The memory 311 described in the embodiments of the present invention is intended to include but is not limited to these and any other suitable types of memories.

[0129] The memory 311 in the embodiment of the present invention is used to store various types of data to support the operation of the computing device. Examples of these data include: any computer program used to operate on the computing device, such as an operating system and an application; contact data; phone book data; messages; pictures; videos, etc. Among them, the operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks. The application program may include various applications, such as a media player, a browser, etc., which are used to implement various application services. Here, the program that implements the method of the embodiment of the present invention may be included in the application program.

[0130] Based on the same inventive concept as the above-mentioned embodiment, this embodiment further provides a computer-readable storage medium, in which a computer program is stored. The computer-readable storage medium may be a ferromagnetic random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); it may also be various devices including one or any combination of the above memories, such as a mobile phone, a computer, a tablet device, a personal digital assistant, etc. When the computer program stored in the computer-readable storage medium is executed by the processor, the exception handling method applied to the above-mentioned computing device is implemented. For the specific steps implemented when the computer program is executed by the processor, please refer to Figure 1 The description of the illustrated embodiment will not be repeated here.

[0131] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0132] In this document, the terms "comprises," "comprising," or any other variations thereof, are intended to cover a non-exclusive inclusion of elements other than those listed and may also include additional elements not expressly listed.

[0133] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. An exception handling method, characterized in that: include: In response to the detection instruction, detecting the running status of the Docker container; If the running state is abnormal, determining the abnormal information based on the running log of the Docker container; The abnormal information includes at least one of a damaged operation log, abnormal operation files, overloaded system resources, and occupied ports; According to the abnormal information, corresponding recovery processing is performed.

2. The method according to claim 1, characterized in that The step of detecting the running status of the Docker container in response to the detection instruction includes: Based on the received detection instruction, obtain the running status of the Docker container; If the running state of the Docker container meets the preset condition, determining that the running state is abnormal; If not, determining that the operating state is normal; The preset condition includes at least one of the following: the Docker container is in an inactive state; the daemon process of the Docker container is unavailable; the Docker container has a network connection problem.

3. The method according to claim 1, characterized in that The determining of abnormal information based on the running log of the Docker container includes: If the running log of the Docker container cannot be obtained, or the obtained running log is empty, it is determined that the abnormal information includes damage to the running log.

4. The method according to claim 3, characterized in that The corresponding recovery process according to the abnormal information includes: If the abnormal information includes a damaged operation log, deleting the operation log and restarting the Docker container; and / or, If the abnormal information includes a damaged operation log, the target operation files in the Docker container are updated in sequence based on the file update order until the operation status of the Docker container returns to normal, or all the target operation files in the Docker container are updated.

5. The method according to claim 4, characterized in that The updating process of the target running files in the Docker container in sequence based on the file update sequence includes: Determine the target running file in the Docker container and the file update order of the target running file; Determine the target backup file corresponding to the target running file, and replace the target running file with the corresponding target backup file in sequence.

6. The method according to claim 4, characterized in that Based on the file update sequence, the target running files in the Docker container are updated in sequence, including: Obtaining, in the Docker container, an operation file whose historical abnormal frequency is higher than a preset frequency threshold as the target operation file; The target operation files are sorted from high to low according to the historical abnormal frequencies of the target operation files to determine the file update sequence of the target operation files.

7. The method according to claim 4, characterized in that Based on the file update order, the target running files in the Docker container are updated in sequence until the running state of the Docker container returns to normal, or after all the target running files in the Docker container are updated, the method further includes: If the running state of the Docker container has not been restored to normal, and the target running files in the Docker container have been updated, the Docker container is initialized to deploy the preset backup files corresponding to each running file in the Docker container into the Docker container.

8. The method according to claim 1, characterized in that The corresponding recovery process according to the abnormal information includes: If the abnormal information includes an operation file abnormality, determining an abnormal file corresponding to the operation file abnormality; A preset backup file corresponding to the abnormal file is determined, and the abnormal file is updated according to the backup file.

9. The method according to claim 8, characterized in that The running file abnormality includes file type abnormality and / or configuration file abnormality; The determining a preset backup file corresponding to the abnormal file, and updating the abnormal file according to the backup file, includes: When the running file abnormality includes the file type abnormality, determining a first preset backup file corresponding to the abnormal file, and replacing the abnormal file with the first preset backup file; and / or, When the running file abnormality includes the configuration file abnormality, a second preset backup file corresponding to the abnormal file is determined, and the abnormal file is replaced with the second preset backup file.

10. The method according to claim 1, characterized in that The corresponding recovery process according to the abnormal information includes: When the abnormal information includes a system resource overload, updating the operating parameters of the system resource of the Docker container and restarting the Docker container, and if the abnormal information also includes the system resource overload after a preset time, closing a first application, wherein the first application is a non-essential application in a running state; and / or, When the abnormal information includes that the port is occupied, an unoccupied target port is detected, and a startup configuration parameter of the Docker container is modified based on the target port, and the Docker container is restarted according to the modified startup configuration parameter.

Images