MQ

The IBM MQ operator renders standard MQ container images to be deployed over the OpenShift container platform (OCP).  IBM MQ has provisioned some level of customization of such IBM official container images. It can be achieved by creating a new image layer. This is detailed in this page with an example - building sample image. And the Queue Manager Container images to build on top of are listed here - release history of mq-operator.

But this page gives a simple example where an user can render MQSC and INI changes via the image instead of ConfigMaps. But it does not provide any information about how an image layer can be created inclusive of user exits within it. The blog tries to address this particular use case. 

Exits in the context of an IBM MQ Queue Manager are user-written programs that can be called by the Queue Manager at specific points during message processing. Exits provide a way to customize or extend the behavior of the Queue Manager, such as logging, security checks, or message transformation. Integrating exits with OpenShift enables you to tailor the message processing to your specific requirements.

Before we jump in, some initial details about IBM MQ's handling of user exits are as follows. IBM MQ provides an exitpath stanza in qm.ini. The related stanza details can be found in this link - ExitPath stanza. So keeping our exits in a different location (other than the default location), say /opt/exits& /opt/exits64 and editing the exitpath stanza in qm.ini to point to these folders will make sure our exits are considered and picked up during runtime. 

NOTE: We will take build custom image layer page's steps as a base reference for procedure to achieve the intended goal of this blog post. 

Step 1: Same as reference page's step 1 - Create an ImageStream

Step 2: Create a ConfigMap rendering the SampleExit.so as input. Below is the oc command for the same,

oc create configmap user-exits --from-file=SampleExit.so

NOTE: There are security implications of having binary executable code in a ConfigMap. The user needs to take extra-special care of security permissions, because a bad actor who could write a ConfigMap, could potentially execute code.  It is advisable to exercise some level of precautions in case of sensitive data. Other ways of rendering binaries can be found here - Performing and interacting with builds in OpenShift

Step 3:Similar to reference page's step 2a, create a BuildConfig for your new image. This BuildConfig will allow you run builds for a new image based off the IBM official images. But the YAML file defining the BuildConfig resource in this case is different than the reference page as provided below, 

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: mymqconfig
spec:
  source:
    dockerfile: |-
      FROM ibm-mqadvanced-server-integration:9.3.3.2-r1
      USER root
    COPY exitDestDir /opt/exits
    RUN chmod -R 555 /opt/exits
    RUN printf "DEFINE QLOCAL(foo) REPLACE\n" > /etc/mqm/cust.mqsc \
      && printf "ExitPath:\n\tExitsDefaultPath=/opt/exits\n\tExitsDefaultPath64=/opt/exits64\n" > /etc/mqm/custom.ini
      LABEL summary "My custom MQ image"
    configMaps:
      - configMap:
          name: user-exits
      destinationDir: exitDestDir
  strategy:
    type: Docker
    dockerStrategy:
      from:
        kind: "DockerImage"
        name: "cp.icr.io/cp/ibm-mqadvanced-server-integration:9.3.3.2-r1"
      pullSecret:
      name: ibm-entitlement-key
  output:
    to:
    kind: ImageStreamTag

    name: 'mymq:config'

Here, 

- Important: The line RUN chmod -R 555 /opt/exits is an optional line. It is just to verify that your new image contains the exit file in the intended folder. A polite warning is that this is insecure and this line can be omitted. 

- user-exits - is the name of the ConfiMap name created in step 2.

- ExitPath:\n\tExitsDefaultPath=/opt/exits\n\tExitsDefaultPath64=/opt/exits64 - is the stanza entry which has to go into the qm.ini file.

- For rendering ConfigMaps to image builds in build configs of OCP the following OpenShift Container Platform's documentation page was followed - ConfigMaps to image builds. 

Remaining Steps: You can follow the same steps 2b onwards from the reference page. i.e., Apply the BuildConfig to the server, Run a build to create your image & Deploy a queue manager and using your new image.

Afterwards, the new image will appear in the OCP's web console under ImageStreams as seen in the below screenshot,