Example: Supplying MQSC and INI files

This example creates a Kubernetes ConfigMap that contains two MQSC files and one INI file. A queue manager is then deployed that processes these MQSC and INI files.

About this task

MQSC and INI files can be supplied when a queue manager is deployed. The MQSC and INI data must be defined in one or more Kubernetes ConfigMaps and Secrets. These must be created in the namespace (project) where you will deploy the queue manager.

Note: A Kubernetes Secret should be used when the MQSC or INI file contains sensitive data.

Example

The following example creates a Kubernetes ConfigMap that contains two MQSC files and one INI file. A queue manager is then deployed that processes these MQSC and INI files.

Example ConfigMap - apply the following YAML in your cluster:

apiVersion: v1
kind: ConfigMap
metadata:
  name: mqsc-ini-example
data:
  example1.mqsc: |
    DEFINE QLOCAL('DEV.QUEUE.1') REPLACE
    DEFINE QLOCAL('DEV.QUEUE.2') REPLACE
  example2.mqsc: |
    DEFINE QLOCAL('DEV.DEAD.LETTER.QUEUE') REPLACE
  example.ini: |
    Channels:
       MQIBindType=FASTPATH

Example QueueManager - 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: mqsc-ini-qm
spec:
  version: 9.3.5.1-r1
  license:
    accept: false
    license: L-AMRD-XH6P3Q
    use: Production
  web:
    enabled: true
  queueManager:
    name: "MQSCINI"
    mqsc:
    - configMap:
        name: mqsc-ini-example
        items:
        - example1.mqsc
        - example2.mqsc
    ini:
    - configMap:
        name: mqsc-ini-example
        items:
        - example.ini
    storage:
      queueManager:
        type: ephemeral

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

Additional information:

A queue manager can be configured to use a single Kubernetes ConfigMap or Secret (as shown in this example) or multiple ConfigMaps and Secrets.
You can choose to use all of the MQSC and INI data from a Kubernetes ConfigMap or Secret (as shown in this example) or configure each queue manager to use only a subset of the available files.
MQSC and INI files are processed in alphabetical order based on their key. So example1.mqsc will always be processed before example2.mqsc, regardless of the order in which they appear in the queue manager configuration.
If multiple MQSC or INI files have the same key, across multiple Kubernetes ConfigMaps or Secrets, then this set of files is processed based on the order in which the files are defined in the queue manager configuration.
When a queue manager pod is running, any changes to the Kubernetes ConfigMap are not picked up because the IBM MQ Operator is not aware of the change. If you make changes to the ConfigMap, for example changes to the MQSC commands or to the INI files, 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.