Container running method, device and medium based on docker container

Abstract

The application provides a container running method and device based on a docker container, and a medium, and relates to the technical field of docker containers. The method comprises the following steps: in response to the starting of a target container, replacing original execution instructions of the target container with target execution instructions, the execution instructions being used for instructing the execution of a waiting script mounted on the target container, the waiting script being generated based on the dependency relationship between services; executing the waiting script based on the target execution instructions to obtain a health check result of a service corresponding to the waiting script; and controlling the running of the target container based on the health check result. The embodiments of the application can avoid the abnormal problems such as connection failure caused by the starting of the target container when the dependent service is not ready, meanwhile, the application does not need to modify the image of the target container itself, has strong adaptability, is flexible to use, can conveniently realize the health check of service dependency on the basis of not changing the original container configuration logic, and guarantees the stable starting and running of multi-container orchestration applications.

Description

Technical Field

[0001] This application relates to the field of Docker container technology, and more specifically, to a container running method, device, and medium based on Docker containers. Background Technology

[0002] Managing dependencies between services is a core challenge when orchestrating multi-container applications using Docker Compose. For example, a web application service might depend on a database service, and a message consumer service might depend on a message queue service. Since these services start at different times, if a dependent service starts before the service it depends on is ready, connection failures will occur.

[0003] While Docker Compose provides the `depends_on` instruction to declare the service startup order, this instruction only ensures that containers start in the declared order and does not wait for the service processes inside the container to be actually ready. This "pseudo-dependency" mechanism can easily lead to front-end services starting to connect before back-end services have finished initializing, thus triggering race conditions and causing abnormal issues such as connection failures, service crashes, and continuous restarts. Summary of the Invention

[0004] The purpose of this application is to address the shortcomings of existing technologies by providing a container running method, device, and medium based on Docker containers, which can solve the problem that existing front-end services start connecting before the back-end services have completed initialization, resulting in abnormalities such as connection failures, service crashes, and continuous restarts.

[0005] To achieve the above objectives, this application adopts the following technical solution: This application provides a container running method based on Docker containers, the method comprising: In response to the startup of the target container, the original execution instructions of the target container are replaced with the target execution instructions, which are used to instruct the execution of the waiting script mounted on the target container, and the waiting script is generated based on the dependency relationship between services; Execute the waiting script based on the target execution instruction, and obtain the health check result of the service corresponding to the waiting script; The target container is controlled to operate based on the health check results.

[0006] In one embodiment, the generation of the waiting script includes: parsing an executable file to obtain dependency configuration information, the dependency configuration information including dependency information and health check parameters, the executable file being used to indicate execution information for different containers; and generating the waiting script based on the dependency configuration information.

[0007] In one embodiment, mounting the waiting script includes: during the creation phase of the target container, mounting the waiting script in read-only mode to a specified path of the target container.

[0008] In one embodiment, responding to the startup of the target container includes: determining that the startup of the target container has been detected, detecting the waiting script; if the waiting script is determined to be abnormal based on the detection result, then proceeding to the failure handling process.

[0009] In one embodiment, replacing the original execution instructions of the target container with the target execution instructions includes: reading an execution file, obtaining the target execution instructions in the execution file, wherein the target execution instructions are used to instruct the execution of a waiting script; and replacing the original execution instructions of the target container with the target execution instructions when the target container starts.

[0010] In one embodiment, executing the waiting script based on the target execution instruction and obtaining the health check result of the service corresponding to the waiting script includes: accessing the service that the target container depends on according to the waiting script; obtaining the health check parameters corresponding to the service; and cyclically checking the health status of the service according to the health check parameters.

[0011] In one embodiment, the health status of the service is checked cyclically according to the health check parameters, including: if it is determined that there are multiple check types according to the health check parameters, the priority of the check type is obtained, and a health check is performed based on the priority. The check types include at least one of command check, HTTP check, and TCP check.

[0012] In one embodiment, controlling the operation of the target container based on the health check result includes: if the health check result indicates that the check has passed, then replacing the current process with the original execution instruction, and controlling the target container to execute the original execution instruction.

[0013] This application also provides an electronic device, including a processor and a memory, wherein the processor is communicatively connected to the memory, the memory stores program data, and the program data is executed by the processor to implement the method described in any of the above-mentioned embodiments.

[0014] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the above claims.

[0015] The beneficial effects of the technical solutions provided in this application are: The container running method based on Docker containers provided in this application includes: in response to the startup of the target container, replacing the original execution instruction of the target container with the target execution instruction, wherein the execution instruction is used to instruct the execution of a waiting script mounted on the target container, and the waiting script is generated based on the dependency relationship between services; executing the waiting script based on the target execution instruction, and obtaining the health check result of the service corresponding to the waiting script; and controlling the operation of the target container based on the health check result. This application embodiment can keep the target container in a waiting state until the dependent service is truly ready, avoiding abnormal problems such as connection failures caused by starting the target container before the dependent service is ready. Furthermore, this application achieves dependency waiting by replacing the startup instruction and mounting the waiting script, without modifying the target container's image itself. It has strong adaptability and flexible use, and can conveniently implement health checks of service dependencies without changing the original container configuration logic. It effectively solves the problem that the native depends_on mechanism of Docker Compose cannot wait for services to be ready, ensuring the stable startup and operation of multi-container orchestration applications. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0017] Figure 1 A flowchart of a container running method based on Docker containers provided in this application embodiment; Figure 2 A structural diagram of the electronic device provided in the embodiments of this application; Figure 3 This is a structural diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation

[0018] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0019] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” indicates implementation as “A,” or implementation as “A,” or implementation as “A and B.”

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0021] The technical solutions of this application and their effects are described below through several exemplary embodiments. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0022] The container running method, device, and medium based on Docker provided in this application aim to solve at least one technical problem existing in the prior art.

[0023] Optionally, such as Figure 1 As shown, the container running method based on Docker containers in this application can be used on computers, mobile phones, servers, cloud platforms, and other terminals capable of running Docker containers. Here, "container" is an abbreviation for Docker container.

[0024] Optionally, the terminal may include: Configuration parsing module: Used to parse extended configurations in executable files (such as docker-compose.yml), extracting dependencies and health check parameters between services.

[0025] Script mounting module: Used to mount waiting script libraries to a specified target container.

[0026] Health check module: Used to execute specific health check logic, including TCP check, HTTP check, command check, etc.

[0027] Coordination and control module: Used to coordinate the startup order of various services and monitor the health status of dependent services.

[0028] The various modules of the terminal collaborate through data and control flows. The responsibilities of each module are clearly defined, and they communicate through predefined interfaces. Specifically, the names, codes, and core responsibilities of each module are shown in Table 1: Table 1

[0029] Optionally, the configuration parsing module, script mounting module, health check module, and coordination control module can be connected in sequence, and the coordination control module can be connected to the configuration parsing module.

[0030] In one embodiment, the connection relationship between modules is as follows: Configure the parsing module (A) and the script mounting module (B). Connection direction: A -> B (unidirectional data flow). Connection content: The configuration parsing module passes the parsed dependency configuration information (including a list of dependent services, check types, timeout parameters, etc.) to the script mounting module. The script mounting module determines the waiting scripts to be mounted (such as tcp-wait.sh, http-wait.sh, etc.) based on the configuration information and generates the final mounting configuration. This mounting is completed during the container orchestration phase (before docker-compose up).

[0031] Script mounting module (B) and health check module (C) Connection direction: B -> C (unidirectional control flow). Connection content: The script mounting module notifies the health check module of the path to the waiting script mounted to the container (e.g., / wait / wait-for.sh). When the health check module detects container startup, it verifies whether the mounted waiting script is accessible and executable. If the script mounting fails or permissions are insufficient, the health check module marks the container status as abnormal and triggers the failure handling process. This connection is completed during the container startup phase.

[0032] Health check module (C) and coordination control module (D) Connection direction: C<->D (bidirectional data + control flow). Connection content: (1) C -> D: The health check module reports the check results (ready / not ready / timeout / failure) of each dependent service to the coordination and control module in real time; (2) D -> C: The coordination and control module issues check instructions (such as start / pause / terminate check, adjust check interval, etc.) to the health check module according to the global dependency relationship. This connection continues during the container runtime phase.

[0033] Coordination and Control Module (D) and Configuration Resolution Module (A) Connection direction: D -> A (one-way query). Connection content: When the coordination and control module needs to adjust the strategy or handle anomalies, it queries the configuration parsing module to obtain the original dependency configuration information (such as dependency graphs, backup plans, etc.). This connection is used for dynamic strategy adjustment and fault recovery scenarios.

[0034] In one embodiment, the data flow between modules during terminal operation is as follows: Phase 1. Orchestration Phase: The configuration parsing module reads the executable file (such as docker-compose.yml) -> parses the dependency configuration information -> outputs a structured configuration object -> the script mounting module generates a mounting scheme based on the configuration; Phase 2. Startup Phase: The container engine creates the target container -> executes volume mounting (script mounting) -> overrides the entrypoint (executes instructions) -> starts the target container -> the health check module verifies the accessibility of the waiting script; Phase 3. Detection Phase: Waiting for script execution -> Health check module initiates check -> Reports health check results to coordination and control module -> Coordination and control module assesses global status -> Issues next round of check instructions; Phase 4. Readiness Phase: All dependencies are ready -> Coordination and control module confirms global state -> Health check module stops detection -> exec handover is executed (replacing with the original execution instruction) -> The original execution instruction takes over the target container.

[0035] Optionally, when an anomaly occurs in inter-module communication, the handling process is as follows: Configuration parsing failed: The script mounting module continues execution using the default configuration (TCP check only) while waiting for script generation; Script mounting failed: Health check module marked as abnormal, target container enters CrashLoopBackOff state (indicating that the container repeatedly crashes and exits after startup); Health check timeout: The coordination control module triggers a timeout policy (HARD / SOFT) to determine whether to terminate or continue; Coordination and control disconnection: The health check module continues to operate independently according to the default policy.

[0036] Optionally, the container running method based on Docker containers in this application includes: S101: In response to the startup of the target container, replace the original execution instructions of the target container with the target execution instructions.

[0037] Optionally, the execution instruction is used to instruct the execution of a wait script mounted on the target container, which is generated based on the dependencies between services.

[0038] In this embodiment, the generation of the waiting script includes: parsing the executable file to obtain dependency configuration information, which includes dependency information and health check parameters; and generating the waiting script based on the dependency configuration information. The dependency information includes the dependencies between services, and the health check parameters include check type (tcp / http / cmd), check target (port / URL / command), timeout, and other information related to whether the service has started normally.

[0039] Optionally, the executable file can be `docker-compose.yml` or other files that can indicate the execution order of different containers. The executable file can utilize extended fields to declare service dependencies and health check parameters. Dependency information includes: the name of the dependent service, the check type (tcp / http / cmd), the check target (port / URL / command), timeout parameters, etc. Specifically, service dependencies can be declared through labels in `docker-compose.yml` or custom extended fields, enabling centralized management and visualization of dependencies.

[0040] Optionally, the mounting of the waiting script includes: during the creation phase of the target container, mounting the waiting script in read-only mode to a specified path of the target container.

[0041] Alternatively, Docker's volume mounting mechanism can be used to mount the waiting script in read-only mode to the target container (service container) that needs to wait for the dependency. The mount path can be a standard path of the container (such as / usr / local / bin) or a custom path.

[0042] Optionally, the waiting script can provide implementations of various waiting strategies, including: • tcp-wait: A waiting strategy based on TCP port connections; • http-wait: A waiting strategy based on HTTP / HTTPS health check endpoints; • cmd-wait: A waiting strategy based on the result of a custom command execution; •composite-wait: A composite waiting strategy that combines multiple strategies.

[0043] In one embodiment, during container creation, the Docker engine mounts the wait script directory on the host machine to a specified path (e.g., / wait) in read-only (ro) mode. The mount operation is completed during container file system initialization, at which point the / wait directory within the container already contains all the wait script files. Because of the read-only mount, processes within the container cannot modify the script content, ensuring the integrity and security of the scripts.

[0044] Optionally, in response to the startup of the target container, the process includes: confirming that the target container has started, checking the waiting script; if the waiting script is found to be abnormal based on the detection result, then proceeding to the failure handling process. Specifically, when the target container starts, it can check and verify whether the mounted waiting script is accessible and executable. If the check result determines that the waiting script has failed to mount or has insufficient permissions, the health check module marks the container status as abnormal, triggering the failure handling process to mark the target container as abnormal to prevent further execution of the target container's startup, which could lead to connection failures, service crashes, and other problems.

[0045] Optionally, the original execution instructions of the target container are replaced with the target execution instructions, including: reading the execution file, obtaining the target execution instructions in the execution file, the execution file being used to indicate the execution information of different containers, and the target execution instructions being used to indicate the execution of the waiting script; and replacing the original execution instructions of the target container with the target execution instructions when the target container starts.

[0046] In one embodiment, the executable file can be `docker-compose.yml` (the core configuration file of the Docker Compose tool, which allows defining how multiple containers run together in one file, eliminating the need to type commands to start each container individually). The Docker engine reads the entrypoint instructions configured in `docker-compose.yml` (the `ENTRYPOINT` instruction specifies the main command (entry point) that must be executed when the container starts, making the image (target container) behave as an executable program with fixed functionality; its command is not overridden by ordinary parameters after `docker run` (it can only be explicitly replaced by `--entrypoint`, and the passed parameters are passed as append parameters to the command), overriding the original `ENTRYPOINT` settings of the container image. When the container starts, the waiting script specified by the entrypoint (such as " / wait / wait-for.sh db:3306 --. / start-app.sh") is resolved to the container's main process (PID 1). The original image's `ENTRYPOINT` and `CMD` (which sets the default command and its parameters to be executed after the container starts) are completely replaced by the `entrypoint` configuration. By modifying the entrypoint configuration in docker-compose.yml, the startup behavior can be changed without modifying the image.

[0047] S102: Execute the waiting script based on the target execution instruction, and obtain the health check results of the service corresponding to the waiting script.

[0048] Optionally, the waiting script to be executed can be determined based on the target execution instructions, and the waiting script can be designated as the main process of the target container, controlling the target container to execute the waiting script.

[0049] In one embodiment, the wait script can be executed by the ` / bin / sh` interpreter within the target container. The wait script runs within the process context of the target container and can access the container's network namespace. Therefore, it can resolve the service name (e.g., `db`) in the wait script to the internal DNS records automatically configured by Docker Compose (the executable file), thus connecting to the dependent services. The wait script can perform parameter parsing to obtain a list of dependent services (supporting multiple services, comma-separated) to identify services requiring health checks, and to obtain the corresponding check type (tcp / http / cmd), timeout parameter (-t / --timeout), retry interval (-i / --interval), separator (--), and the original startup command (original execution instruction) and its parameters. Parameter parsing supports both short and long options. The parsed dependent service string (e.g., "mysql:3306,redis:6379") can be parsed into a structured array. Each dependency contains: hostname, port, check type, and timeout configuration. DNS pre-resolution verification is performed on each dependency to ensure the service name is resolvable within the Docker network.

[0050] Optionally, during container runtime, the container runtime environment can be checked, including: verifying the availability of ` / bin / sh`, checking nc (netcat) or built-in TCP inspection capabilities, checking curl or wget (for HTTP inspection), and checking the timeout command (for command timeout control). If the environment does not meet the minimum requirements, an error message is output and the process exits immediately.

[0051] Optionally, a waiting script is executed based on the target execution instruction to obtain the health check results of the service corresponding to the waiting script, including: accessing the services that the target container depends on according to the waiting script; obtaining the health check parameters corresponding to the service; and checking the health status of the service in a loop according to the health check parameters.

[0052] Optionally, the health status of services is checked cyclically based on health check parameters, including: if multiple check types are determined based on the health check parameters, the priority of each check type is obtained, and health checks are performed based on the priority. Check types include at least one of command checks, HTTP checks, and TCP checks. During the cyclical check process, a health check can be performed on each service that is not yet ready. The timestamp and result of each check are recorded. The next check interval is calculated based on the fallback policy. The check loop continues until all services are ready or a global timeout is reached.

[0053] Optionally, the examinations performed via health check parameters can include multiple examination types; specifically, three examination types are supported, each of which can be configured independently. Details of the three examination types are shown in Table 2. Table 2

[0054] Optionally, the priority of the three check types, from highest to lowest, can be: command check > HTTP check > TCP check. Command check has the highest priority because it typically targets the business logic of a specific service and most accurately reflects the service's readiness status. HTTP check is next: HTTP health check endpoints are usually provided by the service framework and reflect the application layer status. TCP check has the lowest priority: TCP connections only confirm network reachability and do not guarantee the service logic is ready. Within a single check cycle, checks are executed sequentially in descending order of priority. Lower-priority checks are only executed if a higher-priority check passes. Failure of any check results in the check cycle being deemed a failure.

[0055] Optionally, during each check interval of the loop check, the waiting script can use the sleep command to wait, avoiding CPU idling in the terminal and reducing computational resource consumption.

[0056] Optionally, a corresponding check mode can be executed based on the information configured in the waiting script or health check module, and a health check can be performed based on that check mode. The check mode can include any one of a single check module, a sequential check mode, or a composite check mode.

[0057] In one embodiment, the single-check mode corresponds to scenarios where only one check type is configured. This mode is suitable for scenarios where the dependent service provides an explicit health check interface. For example, configuring only TCP checks (simple scenario) or only HTTP checks (precise scenario). The sequential check mode corresponds to scenarios where multiple check types are configured, and the checks are executed in priority order; all checks must pass. This is suitable for scenarios that need to ensure the service is ready in multiple dimensions. For example, first checking that MySQL's TCP port 3306 is open, then checking that the `mysqladmin ping` command returns a success. The composite check mode configures complex check logic through a "check strategy expression." This mode supports AND (all pass) and OR (any pass) logical combinations. For example, "(tcp:db:3306 AND cmd:mysqladmin ping) OR http:api:8080 / health" means that the database TCP is reachable and `mysqladmin` returns a success, or the API health check endpoint returns a success.

[0058] Optionally, when a health check fails, different handling strategies can be implemented based on the check result. The check result indicating a health check failure can be at least one of the following failure types: connection timeout, connection refused, DNS resolution failure, HTTP status code error, command execution failure, etc. Specifically, the handling strategies corresponding to different failure types are shown in Table 3: Table 3

[0059] In one embodiment, for connection timeout, three levels of timeout configuration can be set: (1) Single check timeout: the maximum waiting time for a single check, default 5 seconds; (2) Service-level timeout: the maximum waiting time for a single dependent service, default 60 seconds; (3) Global timeout: the maximum total waiting time for all dependent services, default 300 seconds.

[0060] Optionally, a backoff strategy can be used for retries in the handling strategy to avoid putting excessive pressure on dependent services. Retry supports three strategies: fixed interval (default 1 second), linear backoff (interval increases by 1 second each time), and exponential backoff (interval increases by 2^n, maximum 30 seconds). A maximum number of retries can also be set, with no limit by default (based on timeout).

[0061] In one embodiment, the waiting script employs a strict exit code design to facilitate status identification by external systems and orchestration tools. The design of this exit code is shown in Table 4. Table 4

[0062] Optionally, when a connection timeout occurs, the waiting script can decide on the behavior according to the timeout policy: (1) HARD timeout: exit immediately, return a non-zero exit code, and the container enters an error state; (2) SOFT timeout: record a warning log, continue to execute the original execution instructions, and return the decision-making power of the dependency waiting to the application layer.

[0063] Optionally, different signals can be output based on the inspection results, and these signals may include: SIGTERM: Sent when the container stops normally. Upon receipt: Stop the detection loop, clean up temporary resources, send a signal to the original startup command (if it has been delegated), and exit with exit code 143; • SIGINT: User interrupt (Ctrl+C). Upon receipt: Handled the same as SIGTERM, exiting with exit code 130; •SIGUSR1: A custom signal used to trigger an immediate re-detection (ignoring the current interval while waiting); •SIGUSR2: A custom signal used to trigger configuration reload (supports dynamic adjustment of timeout and interval).

[0064] Register a signal handler when the script starts. Check the signal flag at each iteration point of the loop check. If a termination signal is received, immediately interrupt the current check, record the termination reason, perform cleanup operations, and then exit. Signal handling ensures that the container does not hang for a long time when stopping (graceful shutdown) and avoids the creation of zombie processes during signal handling. The cleanup operations performed when a signal is triggered include: • Close network connections: Close all ongoing TCP / HTTP connections; • Release file handles: Close log files and temporary files; • Record termination log: Write the termination reason and time to standard error output; • Transmit signal: If the handover phase has been entered, transmit the signal to the original startup command.

[0065] Optionally, if the inspection results determine that all dependent services are ready, the total waiting time is calculated and logged, and the process enters the handover phase. If any service times out, a decision is made according to the timeout policy (HARD / SOFT), which includes: exiting and returning an error code or continuing execution.

[0066] Optionally, the wait script can be written in standard shell, without relying on external tools like bash or netcat. Specifically, the script uses POSIX / bin / sh syntax and avoids bash-specific syntax (such as arrays and associative arrays). TCP checks use the built-in functionality of / dev / tcp / host / port (supported by Bash-compatible shells) and do not rely on nc; HTTP checks use / dev / tcp in conjunction with printf / echo to send raw HTTP requests and do not rely on curl, thus ensuring that health checks do not depend on external tools. All operations in the wait script prioritize POSIX standard built-in commands (printf, echo, test, shift, etc.), thus prioritizing built-in commands.

[0067] S103: Control the operation of the target container based on health check results.

[0068] Optionally, controlling the operation of the target container based on the health check results includes: if the health check results indicate that the check has passed, replacing the current process with the original execution instructions and controlling the target container to execute the original execution instructions. Specifically, the check is considered passed only after the check results determine that all services dependent on the target container are ready.

[0069] In one embodiment, once all dependent services are ready, the waiting script can replace the current process with the original startup command via the `exec` system call (the `exec` command). `exec` replacement (used for process replacement) ensures that the original startup command (the original executed instruction) inherits the same PID (still PID 1), maintaining the integrity of the container's main process. The original startup command (e.g., `. / start-app.sh`) begins execution, and the container enters normal operation. Instruction replacement uses `exec` instead of `fork+exec` to ensure that the original startup command becomes PID 1, avoiding the creation of zombie processes.

[0070] In one embodiment, a web application service (webapp) depends on a MySQL database service (db), and the dependency information is configured as follows: version: '3.8' services: db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: password healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 5s timeout: 3s retries: 10 webapp: image: myapp:latest depends_on: db: condition: service_healthy # Non-intrusive configuration volumes: - . / wait-scripts: / wait:ro entrypoint: [" / wait / wait-for.sh", "db:3306", "--", ". / start-app.sh"] For services that provide HTTP health check endpoints, HTTP detection methods can be used, and the relevant code is as follows: version: '3.8' services: API: image: myapi:latest healthcheck: test: ["CMD", "curl", "-f", "http: / / localhost:8080 / health"] interval: 10s timeout: 5s retries: 5 frontend: image: nginx:alpine depends_on: API: condition: service_healthy volumes: - . / wait-scripts: / wait:ro entrypoint: [" / wait / wait-for-http.sh", "http: / / api:8080 / health","--", "nginx", "-g", "daemon off;"] When the target container depends on multiple other services, multiple wait conditions can be configured. The relevant code is as follows: version: '3.8' services: app: image: myapp:latest volumes: - . / wait-scripts: / wait:ro entrypoint: [" / bin / sh", "-c", " / wait / wait-for.sh db:5432&& / wait / wait-for.sh redis:6379&& / wait / wait-for-http.sh http: / / api:8080 / health -- . / start-app.sh"] When applying the wait script to Nginx and Redis images, the relevant code can be: version: '3.8' services: redis: image: redis:7-alpine nginx: image: nginx:alpine volumes: - . / wait-scripts: / wait:ro - . / nginx.conf: / etc / nginx / nginx.conf:ro entrypoint: [" / wait / wait-for.sh", "redis:6379", "--", "nginx", "-g","daemon off;"] In one embodiment, an e-commerce system comprises three services (Docker containers): (1) webapp: a Python Flask-based web application using the official python:3.11-slim image; (2) mysql: using the official mysql:8.0 image; and (3) redis: using the official redis:7-alpine image. Before starting the web app service, it is necessary to ensure that MySQL and Redis are ready. Traditional solutions require modifying the Dockerfile and rebuilding the image; the relevant code is as follows: # Traditional approach: Dockerfile (must be modified and rebuilt) FROM python:3.11-slim # Install dockerize (Additional step) RUN apt-get update&&apt-get install -y wget &&wget https: / / github.com / jwilder / dockerize / releases / download / v0.7.0 / dockerize-linux-amd64-v0.7.0.tar.gz &&tar -C / usr / local / bin -xzvf dockerize-linux-amd64-v0.7.0.tar.gz &&rm dockerize-linux-amd64-v0.7.0.tar.gz WORKDIR / app Copy requirements.txt. RUN pip install -r requirements.txt COPY. # Enable dockerize to package the startup command (modify ENTRYPOINT / CMD) ENTRYPOINT ["dockerize", "-wait", "tcp: / / mysql:3306", "-wait", "tcp: / / redis:6379", "-timeout", "60s"] CMD ["python", "app.py"] This application's solution directly uses the official image, requiring no modification to the Dockerfile. The relevant code is as follows: # Non-intrusive solution: Dockerfile (no modification required) # The webapp service will use the official image directly, and the Dockerfile will remain unchanged. FROM python:3.11-slim WORKDIR / app Copy requirements.txt. RUN pip install -r requirements.txt COPY. CMD ["python", "app.py"] # Non-intrusive solution: docker-compose.yml version: '3.8' services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: password redis: image: redis:7-alpine webapp: image: myapp:latest # Using the original image, no rebuild required depends_on: mysql: condition: service_healthy redis: condition: service_healthy # Mounting wait scripts via Volume (new) volumes: - . / wait-scripts: / wait:ro # Implementing wait functionality via Entrypoint overriding (new feature) entrypoint: [" / bin / sh", "-c", " / wait / wait-for.sh mysql:3306 redis:6379 -- python app.py"] The comparison results between the traditional solution and this application are shown in Table 5: Table 5

[0071] Compared with the prior art, this application has the following beneficial effects: Non-intrusive design: No Dockerfile modification or image rebuild is required; it can be directly applied to any existing image, including third-party images. This significantly reduces adoption costs, making it particularly suitable for third-party services where source code cannot be modified.

[0072] Zero dependency implementation: The waiting script is written in standard Shell ( / bin / sh), does not depend on external tools such as bash and netcat, and is compatible with almost all Linux container images.

[0073] Multi-dimensional health checks: Supports multiple detection methods such as TCP port detection, HTTP health check endpoints, and custom commands, which can more accurately determine whether the service is truly ready, rather than just whether the port is open.

[0074] Declarative configuration: Dependencies are centrally managed through docker-compose.yml, making the configuration intuitive, clear, easy to maintain, and version control.

[0075] Based on the same inventive concept, this application also proposes an electronic device, please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a structural diagram of an electronic device provided in an embodiment of this application. (In conjunction with...) Figure 2 The electronic device described in this application is described in detail.

[0076] In this embodiment, the smart terminal includes a processor and a memory. The processor and the memory are communicatively connected. The memory stores program data, which is used to execute the method described in the above embodiment.

[0077] In this embodiment, the processor is the control center of the smart terminal. It connects various parts of the smart terminal via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory, and by calling data stored in the memory, thereby providing overall monitoring of the smart terminal. Optionally, the processor may include one or more processing units; preferably, the processor may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor.

[0078] The smart terminal also includes a power supply (such as a battery) to power various components. Preferably, the power supply can be connected to the processor logic through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0079] The memory can be used to store software programs and modules. The processor executes various functional applications and data processing of the smart terminal by running the software programs and modules stored in the memory. The memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area can store data created according to the use of the smart terminal (such as audio data, phone book, etc.). In addition, the memory can include high-speed random access memory, and can also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0080] Based on the same inventive concept, this application also proposes a computer-readable storage medium, please refer to [link to relevant documentation]. Figure 3 , Figure 3 This is a structural diagram of an embodiment of the computer-readable storage medium of this application, in conjunction with... Figure 3 The computer-readable storage medium of this application is described.

[0081] In this embodiment, a computer-readable storage medium stores a computer program that is used to perform the methods described in the above embodiments.

[0082] The computer-readable storage medium may include, but is not limited to, floppy disks, optical disks, CD-ROMs (compact disc-read-only memory), magneto-optical disks, ROMs (read-only memory), RAMs (random access memory), EPROMs (erasable programmable read-only memory), EEPROMs (electrically erasable programmable read-only memory), magnetic cards or optical cards, flash memory, or other types of media / machine-readable media suitable for storing machine-executable instructions. The computer-readable storage medium may be a product not connected to a computer device or a component used in a computer device.

[0083] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the illustrations or text descriptions.

[0084] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0085] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A container running method based on Docker containers, characterized in that, The method includes: In response to the startup of the target container, the original execution instructions of the target container are replaced with the target execution instructions, which are used to instruct the execution of the waiting script mounted on the target container, and the waiting script is generated based on the dependency relationship between services; Execute the waiting script based on the target execution instruction, and obtain the health check result of the service corresponding to the waiting script; The target container is controlled to operate based on the health check results.

2. The container running method based on Docker containers according to claim 1, characterized in that, The generation of the waiting script includes: The executable file is parsed to obtain dependency configuration information, which includes dependency information and health check parameters. The executable file is used to indicate the execution information of different containers. The waiting script is generated based on the dependency configuration information.

3. The container running method based on Docker containers according to claim 1, characterized in that, The mounting of the waiting script includes: During the creation phase of the target container, the waiting script is mounted in read-only mode to a specified path of the target container.

4. The container running method based on Docker containers according to claim 3, characterized in that, The response to the startup of the target container includes: The startup of the target container is detected, and the waiting script is detected; If the waiting script is determined to be abnormal based on the detection results, the process will proceed to the failure handling procedure.

5. The container running method based on Docker containers according to claim 2, characterized in that, Replacing the original execution instructions of the target container with the target execution instructions includes: Read the executable file and obtain the target execution instruction in the executable file, the target execution instruction being used to instruct the execution of the waiting script; When the target container starts, the original execution instructions of the target container are replaced with the target execution instructions.

6. The container running method based on Docker containers according to claim 1, characterized in that, Execute the waiting script based on the target execution instruction, and obtain the health check results of the service corresponding to the waiting script, including: Access the services that the target container depends on according to the waiting script; Obtain the health check parameters corresponding to the service, and check the health status of the service cyclically based on the health check parameters.

7. The container running method based on Docker containers according to claim 6, characterized in that, The health status of the service is checked cyclically based on the health check parameters, including: If multiple check types are determined based on the health check parameters, the priority of the check type is obtained, and a health check is performed based on the priority. The check type includes at least one of command check, HTTP check, and TCP check.

8. The container running method based on Docker containers according to claim 6, wherein the target container is controlled to run based on the health check result, comprising: If the health check results indicate that the check has passed, the current process is replaced with the original execution instruction, and the target container is controlled to execute the original execution instruction.

9. An electronic device, characterized in that, The method includes a processor and a memory, the processor being communicatively connected to the memory, the memory storing program data, and the program data being used to execute the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is used to perform the method as described in any one of claims 1-8.

Images