Plan your own IBM MQ queue manager image using a container

There are several requirements to consider when running an IBM MQ queue manager in a container. The sample container image provides a way to handle these requirements, but if we want to use your own image, we need to consider how these requirements are handled.

Process supervision

When you run a container, we are essentially running a single process (PID 1 inside the container), which can later spawn child processes.

If the main process ends, the container runtime stops the container. An IBM MQ queue manager requires multiple processes to be running in the background.

For this reason, we need to make sure that your main process stays active as long as the queue manager is running. It is good practice to check that the queue manager is active from this process, for example, by performing administrative queries.

Populating /var/mqm

Containers must be configured with /var/mqm as a volume.

When you do this, the directory of the volume is empty when the container first starts. This directory is usually populated at installation time, but installation and runtime are separate environments when using a container.

To solve this, when your container starts, we can use the crtmqdir command to populate /var/mqm when it runs for the first time.

Container security

In order to minimize the runtime security requirements, the samples container images are installed using the IBM MQ unzippable install. This ensures that no setuid bits are set, and that the container doesn't need to use privilege escalation. Some container systems define which user IDs we are able to use, and the unzippable install does not make any assumptions about available operating system users.