So, the idea is to write about things that I have stumbled upon while building an automated build and deployment framework for containerized MQ. The source code for IBM MQ Docker build can be found from GitHub (https://github.com/ibm-messaging/mq-container) and it is quite complete and well-documented. It didn’t take long to create the first build using the GitHub sources and get everything up and running. The basic setup is quite easy and straightforward. Then what? The next logical exercise was to customize the running queue manager and build an image with our own configurations. This step can be found from GitHub documentation. Just place your MQSC scripts under /etc/mqm and off you go.

After I was able to get my queues, channels, etc. objects in place, I needed to get access to the web console. I think that the details on how to customize an embedded web server configuration as part of the build process is not that well documented. Or at least I couldn’t find any details from the GitHub documentation. It turned out that you can modify web server configurations by adding all the necessary files into /etc/mqm/web. Like for example in my case, we have a strict requirement that user management must be handled using LDAP registry and to be more precise, Active Directory. So, in order to fulfill this requirement, I needed to include a customized mqwebuser.xml with AD details in it. I copied the file into /etc/mqm/web/installations/Installation1/servers/mqweb/ and the ready-made Docker build script handled the rest. When I started the newly built queue manager and the embedded web server, I was able to authenticate with my AD credentials.

Another thing I noticed once I started to deploy containerized queue managers into test environments was the fact that I needed to modify queue manager configurations during deployment. Injecting a “static” MQSC script as part of a Docker build was not enough. This was solved by changing Dockerfile ENTRYPOINT ["runmqserver"] row into CMD ["<START SCRIPT NAME>"]. In the script file we’ll then start the queue manager by issuing exec /usr/local/bin/runmqserver <ORIGINAL PARAMS>. This way we are now able to run several start scripts before the queue manager starts and thus modify configuration based on the environment deployment parameters.

I hope that my posting helps your journey into the world of MQ containers. I’ll probably write another posting once we get closer to production and let you know how things have progressed.