Creating the new queue manager on Red Hat OpenShift

Deploy either a single instance or multi-instance queue manager on Red Hat® OpenShift®.

Before you begin

Important: This task applies only to users on Red Hat OpenShift.

This task assumes that you have created the queue manager resources, and installed the IBM MQ Operator into Red Hat OpenShift.

About this task

As outlined in Selecting the target HA architecture for IBM MQ running in containers, there are three possible deployment topologies. Therefore this topic provides three different templates:

Template 1: Deploy a single instance queue manager.
Template 2: Deploy a multi instance queue manager.
Template 3: Deploy a Native HA queue manager.

Important: Only complete one of the three templates, based on your preferred topology.

Procedure

Template 1: Deploy a single instance queue manager.
The migrated queue manager is deployed to Red Hat OpenShift using a YAML file. Here is a sample, based on the names used in previous topics:

Note: This example 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.
```
 
apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: qm1
spec:
  version: 10.0.0.0-r1
  license:
    accept: true
    license: L-VEMB-RABZSN
    use: "Production"
  pki:
    keys:
    - name: default
      secret:
        secretName: my-tls-migration
        items:
          - tls.key
          - tls.crt
  web:
    enabled: true
  queueManager:
    name: QM1
    mqsc:
      - configMap:
          name: my-mqsc-migrated
          items:
            - backup.mqsc
```
Depending on the steps that you performed, the previous YAML might need to be customized. To help you with this, here is an explanation of this YAML:
```
apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: qm1
```
This defines the Kubernetes object, type and name. The only field requiring customization is the name field.
```
 spec:
  version: 10.0.0.0-r1
  license:
    accept: true
    license: L-VEMB-RABZSN
    use: "Production"
```
This corresponds to the version and license information for the deployment. If you need to customize this, use the information provided in mq.ibm.com/v1beta1: Current license versions.
```
  pki:
    keys:
    - name: default
      secret:
        secretName: my-tls-migration
        items:
          - tls.key
          - tls.crt
```
For the queue manager to be configured to use TLS, it must reference the relevant certificates and keys. The secretName field references the Kubernetes secret created within the Import the IBM MQ TLS resources section, and the list of items (tls.key and tls.crt) are the standard names Kubernetes assigns when using the oc create secret tls syntax. If you have additional certificates to add into the trust store then these can be added in a similar way, but the items are the corresponding file names used during the import. For example, the following code can be used to create the trust store certificates:
```
oc create secret generic my-extra-tls-migration --from-file=trust1.crt,trust2.crt,trust3.crt
```
```
  pki:
    trust:
    - name: default
      secret:
        secretName: my-extra-tls-migration
        items:
          - trust1.crt
          - trust2.crt
          - trust3.crt
```
Important: If TLS is not required, delete the TLS section of the YAML.
```
  web:
    enabled: true
```
This enables the web console for the deployment
```
  queueManager:
    name: QM1
```
This defines the name of the queue manager as QM1. The queue manager is customized based on your requirements, for instance what was the original queue manager name.
```
    mqsc:
      - configMap:
          name: my-mqsc-migrated
          items:
            - backup.mqsc
```
The previous code pulls in the queue manager configuration that was imported in the Import the IBM MQ configuration section. If you used different names, you need to modify my-mqsc-migrated and backup.mqsc.

Note that the sample YAML assumes that the default storage class for the Red Hat OpenShift environment is defined as either a RWX or RWO storage class. If a default is not defined within your environment, then you need to specify the storage class to be used. You can do this by extending the YAML as follows:
```
  queueManager:
    name: QM1
    storage:
      defaultClass: my_storage_class
      queueManager:
        type: persistent-claim
```
Add the highlighted text, with the class attribute customized to match your environment. To discover the storage class names within your environment, run the following command:
```
oc get storageclass
```
Here is sample output returned by this command:
```
NAME          PROVISIONER             RECLAIMPOLICY   
aws-efs       openshift.org/aws-efs   Delete
gp2 (default) kubernetes.io/aws-ebs   Delete
```
The following code shows how to reference the IBM MQ configuration that was imported in the Import the IBM MQ configuration section. If you used different names, you need to modify my-mqsc-migrated and backup.mqsc.
```
    mqsc:
      - configMap:
          name: my-mqsc-migrated
          items:
            - backup.mqsc
```
You have deployed your single instance queue manager. This completes the template. You are now ready to verify the new container deployment.
Template 2: Deploy a multi instance queue manager.
The migrated queue manager is deployed to Red Hat OpenShift using a YAML file. The following sample is based on the names used in previous sections.

Note: This example 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.
```
apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: qm1mi
spec:
  version: 10.0.0.0-r1
  license:
    accept: true
    license: L-VEMB-RABZSN
    use: "Production"
  pki:
    keys:
    - name: default
      secret:
        secretName: my-tls-migration
        items:
          - tls.key
          - tls.crt
  web:
    enabled: true
  queueManager:
    name: QM1
    availability: MultiInstance
    storage: 
      defaultClass: aws-efs
      persistedData:
        enabled: true
      queueManager:
        enabled: true
      recoveryLogs:
        enabled: true
    mqsc:
      - configMap:
          name: my-mqsc-migrated
          items:
            - backup.mqsc
```
Here is an explanation of this YAML. The majority of the configuration follows the same approach as deploying a single instance queue manager, therefore only the queue manager availability and storage aspects are explained here.
```
queueManager:
    name: QM1
    availability: MultiInstance
```
This specifies the queue manager name as QM1, and sets the deployment to be MultiInstance instead of the default single instance.
```
    storage: 
      defaultClass: aws-efs
      persistedData:
        enabled: true
      queueManager:
        enabled: true
      recoveryLogs:
        enabled: true
```
An IBM MQ multi-instance queue manager depends on RWX storage. By default, a queue manager is deployed in single instance mode and therefore additional storage options are required when changing to multi instance mode. In the previous YAML sample, three storage persistent volumes and a persisted volume class are defined. This persisted volume class needs to be a RWX storage class. If you are unsure of the storage class names within your environment, you can run the following command to discover them:
```
oc get storageclass
```
Here is sample output returned by this command:
```
NAME          PROVISIONER             RECLAIMPOLICY   
aws-efs       openshift.org/aws-efs   Delete
gp2 (default) kubernetes.io/aws-ebs   Delete
```
The following code shows how to reference the IBM MQ configuration that was imported in the Import the IBM MQ configuration section. If you used different names, you need to modify my-mqsc-migrated and backup.mqsc.
```
    mqsc:
      - configMap:
          name: my-mqsc-migrated
          items:
            - backup.mqsc
```
You have deployed your multi instance queue manager. This completes the template. You are now ready to verify the new container deployment.
Template 3: Deploy a Native HA queue manager.
For a worked example of creating a Native HA queue manager, see Example: Configuring Native HA using the IBM MQ Operator.