Example: Supplying additional files to a queue manager

This example creates a Kubernetes ConfigMap that contains two files. A queue manager is then deployed that mounts these files into the IBM® MQ container in the specified locations.

About this task

Additional files can be supplied when a queue manager is deployed. These files must be defined in one or more Kubernetes ConfigMaps and Secrets. These must be created in the namespace (project) where you are deploying the queue manager. A Kubernetes Secret should be used when the files contain sensitive data.

Example

The following example creates a Kubernetes ConfigMap that contains two files. A queue manager is then deployed that mounts these files into the IBM MQ container in the specified locations.

ConfigMap

Apply the following YAML in your cluster.

apiVersion: v1
kind: ConfigMap
metadata:
  name: files-example
data:
  file1.txt: |
    Test File 1
  file2.txt: |
    Test File 2

QueueManager

Note: The following YAML uses an IBM MQ Advanced license, though you can also use an IBM MQ license. For more information, see Configuring Queue Managers with IBM MQ license annotations by using the IBM MQ Operator.

Important: If you accept the IBM MQ Advanced license agreement, change accept: false to accept: true. See mq.ibm.com/v1beta1: Current license versions for details on the license.

Example QueueManager for Red Hat® OpenShift®

Deploy your queue manager with the following configuration, using the command line or using the Red Hat OpenShift Container Platform web console.

apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: files-qm
spec:
  version: 10.0.0.0-r1
  license:
    accept: false
    license: L-CXDB-XTZ9J8
    use: Production
  queueManager:
    files:
    - configMap:
        name: files-example
        defaultMountPath: "/etc/mqm/myfiles"
        items:
        - item: file1.txt
        - item: file2.txt
          mountPath: "/etc/mqm/otherfiles"
    storage:
      queueManager:
        type: ephemeral

Example QueueManager for Amazon EKS

Deploy your queue manager with the following configuration on an Amazon EKS cluster.

apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: files-qm
spec:
  version: 10.0.0.0-r1
  license:
    accept: false
    license: L-CXDB-XTZ9J8
    use: Production
  queueManager:
    files:
    - configMap:
        name: files-example
        defaultMountPath: "/etc/mqm/myfiles"
        items:
        - item: file1.txt
        - item: file2.txt
          mountPath: "/etc/mqm/otherfiles"
    storage:
      queueManager:
        type: ephemeral
    route:
      enabled: false
    metrics:
      serviceMonitor:
        enabled: false
  web:
    enabled: false
    route:
      enabled: false

spec.queueManager.route.enabled, spec.queueManager.metrics.serviceMonitor.enabled, and spec.web.route.enabled are set to false because these are Red Hat OpenShift specific features that are enabled by default. These features must be disabled explicitly on Amazon EKS.

File locations:

The file file1.txt is mounted into location /etc/mqm/myfiles/file1.txt, which is the defaultMountPath specified for this ConfigMap.
The file file2.txt is mounted into location /etc/mqm/otherfiles/file2.txt, which is the mountPath override for this specific file.

Additional information:

When defaultMountPath is unset (for a ConfigMap or Secret) and the mountPath override is unspecified, then files are mounted by default into location /etc/mqm/customfiles
If you change the contents of any of the files in the ConfigMap or Secret, then you must manually restart the queue managers to pick up those changes. For single instance queue managers, delete the pod to trigger the required restart. For Native HA deployments, restart the stand-by pods first by deleting them. When they are again in a running state, delete the active pod to restart it. This order of restarts ensures minimum downtime for the queue manager.