There are several requirements an application must satisfy in order to run in a Docker container. The iris-main program was developed by InterSystems to enable the InterSystems IRIS and its other products to meet these requirements.

The main process started by the docker run command, called the entrypoint, is required to block (that is, wait) until its work is complete. In the case of a long-running entrypoint application, this process should block until it's been intentionally shut down.

InterSystems IRIS is typically started using the iris start command, which spawns a number of InterSystems IRIS processes and returns control to the command line. Because it does not run as a blocking process, iris is unsuitable for use as the Docker entrypoint application.

The iris-main program solves this problem by starting InterSystems IRIS and then continuing to run as the blocking entrypoint application. The program also gracefully shuts down InterSystems IRIS when the container is stopped, and has a number of useful options. To use it, add the iris-main binary to a Dockerfile and specify it as the entrypoint application, for example:

ADD host_path/iris-main /iris-main
ENTRYPOINT ["/iris-main"]

Docker imposes these additional requirements on the entrypoint application:

Docker expects the main container process to shut down in response to the docker stop command.

The default behavior of docker stop is to send the SIGTERM signal to the entrypoint application, wait ten seconds, and then send the SIGKILL signal, which is not an acceptable way to stop a database under production workloads. Instead, iris-main intercepts Docker’s signals and invokes the iris stop command.

When a container is stopped by means other than the docker stop command, for example when the Docker daemon is restarted or the host is rebooted, the entrypoint application must carry out whatever tasks are required to bring the container back up to a stable running state in response to the docker start command. As of this writing, iris-main does not have any special handling for an InterSystems IRIS instance that was brought down ungracefully, and instead relies on existing InterSystems IRIS functionality; it does, however, execute all operations specified using the --before and --after options (see the table that follows).

Docker expects the entrypoint application to send output to the console so the docker logs command can display it. The iris-main program does log its own output to the console; some InterSystems IRIS output, however, is still written to log files within the container. The content of these files can be redirected to standard output using the log option. For example, to redirect the InterSystems IRIS messages log for display by the docker logs command when running an InterSystems IRIS container, you would issue a command like the following:

docker run iris --log $ISC_DATA_DIRECTORY/mgr/messages.log

In addition to addressing these issues discussed in the foregoing, iris-main provides a number of options to help tailor the behavior of InterSystems IRIS within a container. The options provided by iris-main are shown in the list that follows; examples of their use are provided in Running InterSystems IRIS Containers.

Options for iris-main appear after the image name in a docker run command, while the Docker options appear before it. As with the docker command, the options have a long form in which two hyphens are used and a short form using only one.

Note:

Options for iris-main appear after the image name in a docker run command, while the Docker options appear before it. As with the docker command, the options have a long form in which two hyphens are used and a short form using only one.