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:
    1. Share the containers UTS namespace with the host using the --uts argument, or
    2. 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

  1. Create a temporary directory to act as your volume, by issuing the following command:
    mkdir /tmp/dockerVolume
  2. 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
  3. 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
  4. 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
  5. 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.

Parent topic: Building your own IBM MQ container