Docker container dependencies
Dependencies can be defined between containers in the same pod, where the dependencies are specified by container names.
Docker containers are started and stopped according to user-defined dependencies, or in arbitrary order if no dependencies are defined. For example, when a client application container is defined as dependent on a database container, to prevent the client application from attempting to connect to an unready database during pod startup, the client container is started after the database container has been started and is determined to be ready. During pod shutdown, the client container is stopped before the database container is stopped, to prevent loss of connection.
Pod startup
During pod startup, containers are started in order of dependency. For a container to start, all the containers that it depends on must be ready. The ready state is evaluated based on user-defined ready conditions. All ready conditions must be met for a container to be considered ready. All containers in the pod must be ready for the pod start up to be considered successful. If pod startup is not successful before the start pod timeout is reached, a timeout error is triggered and all containers are automatically removed.
- required container processes
IBM® Spectrum Conductor uses the docker top command to check running processes in the Docker container, and considers the container to be ready when the specified processes in the list are running. Process names must be the same as entries in the 'COMMAND” column from Lhe linux ps command. For example, if you configure the Docker container to run a background script after the container is fully started, IBM Spectrum Conductor checks for the existence of that script by process name.
- required container port(s)
IBM Spectrum Conductor uses the Python built-in socket module to connect to a socket listening on the specified container port. This module determines whether a service is listening for connections at the specified container port. The container is considered to be ready if the service is listening on the correct port number.
- ready check script
The ready check script is a user-defined script on the host machine that returns with either exit code 0 if a Docker container is ready, or a non-zero exit code if a Docker container is not ready. The script serves as a brief check that is called multiple times, and must return quickly rather than blocking and waiting for the Docker container to be in the ready state. The ready check script must be defined as the script location or the execution command; such as python /opt/username/script.py or /opt/username/script.exe. If a ready check script is defined for a Docker container, the script is executed to confirm that the container is ready.
Pod shutdown
During pod shutdown, containers are stopped in reverse order of dependency. A container is stopped before any of its dependencies are stopped. If graceful stop is defined as true for a container, Docker gives the container an opportunity to stop cleanly by sending a SIGTERM to the main process inside the container. If graceful stop is not defined, the main process in the container is sent a SIGKILL without delay. If the stop pod timeout parameter defined for the pod is reached before successful pod shutdown, all remaining containers are sent SIGKILL without delay.