Running local binding applications in separate containers
With process namespace sharing between containers in Docker, we can run applications that require a local binding connection to IBM MQ in separate containers from the IBM MQ queue manager.
About this task
This functionality is supported in IBM MQ Version 9.0.3 and later queue managers.
We must adhere to the following restrictions:- We must share the containers PID namespace using the --pid argument.
- We must share the containers IPC namespace using the --ipc argument.
- We must either:
- Share the containers UTS namespace with the host using the --uts argument, or
- Ensure the containers have the same hostname using the -h or --hostname argument.
- We must mount the IBM MQ data directory in a volume that is available to the all containers under the /var/mqm directory.
We can try this functionality out, by completing the following steps on a Linux system that already has Docker installed.
The following example uses the sample IBM MQ container image. We can find details of this image on Github.
Procedure
-
Create a temporary directory to act as your volume, by issuing the following command:
mkdir /tmp/dockerVolume
-
Create a queue manager (QM1) in a container, with the name
sharedNamespace, by issuing the following command:
docker run -d -e LICENSE=accept -e MQ_QMGR_NAME=QM1 --volume /tmp/dockerVol:/mnt/mqm --uts host --name sharedNamespace ibmcom/mq
-
Start a second container called secondaryContainer, based off
ibmcom/mq, but do not create a queue manager, by issuing the following
command:
docker run --entrypoint /bin/bash --volumes-from sharedNamespace --pid container:sharedNamespace --ipc container:sharedNamespace --uts host --name secondaryContainer -it --detach ibmcom/mq
-
Run the dspmq command on the second container, to see the status for both
queue managers, by issuing the following command:
docker exec secondaryContainer dspmq
-
Run the following command to process MQSC commands against the queue manager running on the
other container:
docker exec -it secondaryContainer runmqsc QM1
Results
You now have local applications running in separate containers, and we can now successfully run commands like dspmq, amqsput, amqsget, and runmqsc as local bindings to the QM1 queue manager from the secondary container.
If we do not see the result you expected, see Troubleshooting your namespace applications for more information.
- Troubleshooting your namespace applications
When using shared namespaces, we must ensure that you share all namespaces (IPC, PID and UTS/hostname) and mounted volumes, otherwise the applications will not work.
Parent topic: Building your own IBM MQ container