Running local binding applications in separate containers

With the addition of process namespace sharing between containers in Docker. We can now run applications that require a local binding connection to IBM MQ in separate containers from the IBM MQ queue manager. This functionality is supported in IBM MQ Version 9.0.3 and later queue managers.

You must adhere to the following restrictions:

Docker version 1.12 or later must be used.
You must share the containers PID namespace using the --pid argument.
You must share the containers IPC namespace using the --ipc argument.
You 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.
You 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 1.12 or later installed.

The following example uses the sample IBM MQ Docker 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.