CN-122019055-A - Docker single-container multi-service management method based on super
Abstract
The application provides a Docker single-container multi-service management method based on a super. According to the method, a Supervisor process is started in a target container by a non-privileged user identity as a PID1 process in the target container, then after the Supervisor process is started, pre-configured service information is acquired, a dependency graph of services in the target container is constructed, so that multiple services in the target container are managed based on the service dependency graph, on the premise that the advantage of single container deployment is maintained, the dependency relationship and priority among the services are accurately represented in the container, further, the dependency graph realizes orderly and reliable starting and running management, and when abnormality or resource pressure occurs, a differentiated control strategy is implemented according to the service type and priority, and therefore the deployment success rate and running reliability of the single container in a multiple service environment are improved.
Inventors
- LIU SHUANG
- MIN JIHAI
- SUN CHAO
Assignees
- 南京天创智能科技股份有限公司
Dates
- Publication Date
- 20260512
- Application Date
- 20260129
Claims (10)
- 1. The Docker single container multi-service management method based on the super is characterized by comprising the following steps of: In a target container, starting a Supervisor process with a non-privileged user identity as a PID1 process in the target container; After the super process is started, obtaining pre-configured service information, wherein the service information at least comprises service types, service dependency relations, service priorities, retry strategies and resource limiting parameters of all services in the target container so as to construct a dependency graph of the services in the target container; And managing the multiple services in the target container based on the service dependency graph.
- 2. The method of claim 1, wherein the managing of the multiple services within the target container comprises: And carrying out hierarchical management on the basic service, the Java service and the application service in the target container, wherein the hierarchical management comprises the steps of distributing a first priority interval for the basic service, distributing a second priority interval for the Java service, distributing a third priority interval for the application service, and setting differentiated restarting and retrying strategies and resource thresholds based on the priority intervals.
- 3. The method as recited in claim 1, further comprising: and respectively constructing a base layer mirror image, a dependent layer mirror image and an application layer mirror image according to hierarchical division structures of the base layer, the dependent layer and the application layer in the mirror image of the target container, and presetting configuration and script adapted to the Supervisor management and control in each layer to form a collaboration mechanism of hierarchical construction and service management and control.
- 4. A method according to claim 3, wherein said launching a Supervisor process with a non-privileged user identity as a PID1 process within the target container comprises: When the base layer mirror image is constructed, a preset non-privileged user account is created, a user identifier of the non-privileged user account is set as a preset value, and the access range of the non-privileged user account to a container file system is limited; and when the target container is started, executing a Supervisor process by the non-privileged user account, so that the Supervisor process operates as a PID 1 process in the container and is used for receiving a container-level signal and recovering a zombie process.
- 5. The method of claim 3, wherein the constructing the base layer mirror image, the dependent layer mirror image, and the application layer mirror image according to the hierarchical division structure of the base layer, the dependent layer, and the application layer, and presetting configuration and script adapted to the Supervisor management in each layer, respectively, includes: installing a minimized operating system running environment in the base layer mirror image, creating a non-privileged user and configuring a file system authority model to limit the accessible directory range of each service process, and providing a base environment support for the operation of the super with the non-privileged user; Installing a basic service of a preset version and a Supervisor component in the dependency layer mirror image, and pre-arranging a basic service running state checking script in the dependency layer mirror image, wherein the running state checking script is used for executing basic service ready detection through the Supervisor later; And in the application layer mirror image, java service, business application programs and a management and control script which interacts with the Supervisor are deployed, wherein the management and control script comprises dependency check logic and event monitoring logic, and intermediate files and development tools generated in the construction process are removed from the final mirror image in a multi-stage construction mode so as to reduce the mirror image volume.
- 6. The method of claim 5, wherein the removing the intermediate files and development tools generated during the build process from the final image by a multi-stage build to reduce the image volume comprises: In a first construction stage, pulling a complete construction basic mirror image, installing a compiling dependency, a construction tool and a debugging tool, and compiling and packaging Java service and application service to generate a target product; In the second construction stage, based on the base layer mirror image and the dependent layer mirror image as base mirror images, only the target product and configuration files, dependent libraries and management scripts necessary for running are copied into the final application layer mirror image, so that a compiling tool, a debugging tool and intermediate construction files are prevented from being packed into the final mirror image, and the total volume of the original multi-service mirror image is reduced to be within the range of the target volume.
- 7. The method of claim 1, further comprising, after said managing the multiple services within the target container: In the service operation process, based on preset service types, priorities and resource limiting parameters, carrying out differential control on retry times, restarting strategies and resource occupation conditions of each service; And when the occupation of the resources of any service exceeds the corresponding threshold, executing the corresponding resource limiting strategy and/or service processing strategy.
- 8. The method of claim 7, wherein said constructing a dependency graph for services within said target container comprises: Analyzing the basic services at least comprising MySQL service, redis service and EMQX service, and the service dependency relations of Java service and application service in the target container, and determining a first dependency relation and a second dependency relation between the services; Generating a service dependency graph based on the first dependency relationship and the second dependency relationship, wherein the service dependency graph is used for representing the dependency condition of at least one downstream service on at least one upstream service; Dividing the basic service into a first priority interval, dividing the Java service into a second priority interval, dividing the application service into a third priority interval according to the roles of the services in the service dependency graph, wherein the numerical ranges of the different priority intervals are not overlapped; And generating a corresponding Supervisor configuration file for each service based on the service dependency graph and each priority interval, wherein the Supervisor configuration file comprises a service starting command, a priority, an automatic restarting strategy, retry times, resource limiting parameters and log configuration.
- 9. The method of claim 8, wherein the resource restriction parameters include a CPU utilization threshold and/or a memory occupancy threshold, and the performing differential control on retry times, a restart policy, and resource occupancy of each service based on preset service types, priorities, and resource restriction parameters includes: configuring an automatic restarting strategy for the basic service, and triggering automatic restarting under the condition that the preset retry times are not exceeded when abnormal exit of the core basic service is detected; Configuring authority verification operation before starting for the Java service, and prohibiting starting of the corresponding Java service and recording abnormal information when the authority verification fails; Configuring an abnormal non-restarting strategy for the application service, and when the abnormal exit of the application service is detected, only recording log information and not executing automatic restarting operation; And monitoring the CPU utilization rate and the memory occupation of each service in the running process of the super, and executing resource limiting strategies including reducing the restarting frequency, limiting the concurrency and/or stopping the low-priority service when the resource utilization of any service exceeds the corresponding threshold value.
- 10. The method of claim 7, further comprising, after differentially controlling the number of retries, the restart policy, and the resource occupancy of each service based on the preset service type, priority, and resource restriction parameters: performing persistent storage on basic service configuration, java service running state and the service dependency graph in the target container through a restart strategy of a Docker and data volume mounting; when the target container is restarted, the persistence data is loaded by the Supervisor process, and service recovery is performed based on the service dependency graph.
Description
Docker single-container multi-service management method based on super Technical Field The application relates to a service management technology, in particular to a doser single-container multi-service management method based on a superior. Background With the wide application of the Docker containerization technology in an integrated service system, a single-container multi-service deployment mode is greatly adopted in practical engineering because the overhead of a cross-container network can be reduced and the communication path between components can be simplified. In this mode, a plurality of basic services such as Java service and MySQL, redis, EMQX and business application services are often deployed in the same Docker container at the same time. However, existing single-container multi-service schemes rely on fixed startup sequences or simple script control, lack system modeling and dynamic verification capabilities of dependency relationships between services within a container, and do not provide differentiated restart, retry, and resource control policies for different service types and priorities. Therefore, in the actual deployment, operation and fault recovery processes, the problems of disordered service start-up dependence time sequence, serious resource competition, disjoint of a container and service life cycle and the like frequently occur, and the deployment success rate and the operation stability of the system are seriously affected. Disclosure of Invention The application provides a Docker single-container multi-service management method based on a super, which is used for solving the technical problem of disordered service starting dependent time sequence in single-container multi-service deployment. In a first aspect, the present application provides a method for managing multiple services in a single container of a doser based on a superirsor, including: In a target container, starting a Supervisor process with a non-privileged user identity as a PID1 process in the target container; After the super process is started, obtaining pre-configured service information, wherein the service information at least comprises service types, service dependency relations, service priorities, retry strategies and resource limiting parameters of all services in the target container so as to construct a dependency graph of the services in the target container; And managing the multiple services in the target container based on the service dependency graph. In a second aspect, the present application provides a doser single container multi-service management system based on a superiors, including: the starting module is used for starting a Supervisor process in a target container by using a non-privileged user identity as a PID1 process in the target container; the construction module is used for acquiring pre-configured service information after the super process is started, wherein the service information at least comprises service types, service dependency relationships, service priorities, retry strategies and resource limiting parameters of all services in the target container so as to construct a dependency graph of the services in the target container; and the management module is used for managing the multiple services in the target container based on the service dependency graph. In a third aspect, the present application provides an electronic device comprising: Processor, and A memory for storing executable instructions of the processor; wherein the processor is configured to perform any one of the possible methods described in the first aspect via execution of the executable instructions. In a fourth aspect, the present application provides a computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out any one of the possible methods described in the first aspect. According to the method for managing the multiple services of the Docker single container based on the superiors, the superiors process is started in the target container by the non-privileged user identity to serve as the PID1 process in the target container, then after the superiors process is started, the pre-configured service information is obtained, and the dependency graph of the services in the target container is constructed, so that the multiple services in the target container are managed based on the service dependency graph, the dependency relationship and the priority among the services are accurately represented in the container on the premise that the advantage of single container deployment is maintained, the orderly and reliable starting and running management is realized by the dependency graph, and when abnormal or resource pressure occurs, the differentiated control strategy is implemented according to the service type and the priority, and the deployment success rate and the running reliability under the single containe