Introduction
As applications modernize by moving to hybrid cloud deployments, you are probably starting to see a need to modernize your IBM MQ estate to align with that same enterprise application modernization strategy. IBM MQ has kept pace with many platform developments over the past 30 years and continues to do so by embracing the current trend to move to container-based platforms such as Red Hat OpenShift. The shift to move to a container-based platform offers IBM MQ an opportunity to leverage things such as standardised deployment processes, faster deployment, easier management, high availability, scalability, common tooling and much more.
In this blog I am going to show you how to take IBM MQ for a spin on a trial version of Red Hat Openshift running on AWS, I will provide you with step-by-step instructions to get IBM MQ developer edition deployed with a sample producer and consumer Java application in just 15 minutes!
To make things easier, we will be using the ROSA “Hands-On” Experience available on Redhat.com and IBM MQ developer edition samples that are available on GitHub, both are available for free. I have split the instructions into two parts, part one gets you a trial OpenShift cluster, part two deploys IBM MQ and the sample programs. A video demonstration (~9 minutes) for part one will shortly be available here, https://www.youtube.com/@IBMDeveloperAdvocates/videos
Why ROSA for IBM MQ in AWS?
Red Hat OpenShift Service on AWS (ROSA) is a fully managed, turnkey application platform that allows you to focus on deploying applications and accelerate innovation by off-loading the cluster lifecycle management to Red Hat and AWS. ROSA is jointly developed and jointly supported by AWS and Red Hat. It is native in the AWS console and integrates with other commonly used AWS services.
ROSA provides a managed Red Hat OpenShift cluster and is a supported configuration for IBM MQ. This means that customers don’t have to create, manage, and maintain their own Red Hat OpenShift clusters for IBM MQ. Using ROSA allows customers to focus their resources on delivering business value rather than spending valuable time on the undifferentiated management of the underlying platform.
Part 1 - Provision an OpenShift cluster
The first thing to do is to request a free trial of Red Hat Openshift Service on AWS (ROSA), this will get you an OpenShift cluster that you can use to deploy IBM MQ and the sample producer and consumer applications.
1. Go to the ROSA OpenShift trial website, copy and paste the “Try Red Hat OpenShift” web page URL below into your browser.
https://www.redhat.com/en/technologies/cloud-computing/openshift/try-it
2. Log in with your Red Hat ID, if you don’t have one use the link below to create one.
Register for a RH account, https://www.redhat.com/wapps/ugc/register.html
3. Request a cluster, click on the “Try it” button, the tile that also has “Red Hat | AWS” on it and then click on the “Request experience” button, this will provision a ROSA cluster for you that will last for 8 hrs.
This may take a little time, but when the cluster is ready you will get an email with a link to access the cluster.
4. Use the link provided in the email to access the cluster experience website, click the link and then click the “Access experience” button, clicking this button will give you a split pane with a text panel on the left and a terminal window on the right.
5. In the left-hand panel click “Explore the ROSA environment”
6. Access the OpenShift console, you can follow steps 1-6 in the left-hand panel but for this exercise you can jump straight to step 4 and get the URL for the OpenShift console, copy and paste this command into the terminal window,
rosa describe cluster --cluster rosa-$GUID --output json | jq -r .console.url
The command will return a publicly available URL for the OpenShift console, copy the console URL and paste it into the address bar in your browser, the username is ‘cluster-admin’ and the password can be found in the instructions in the left-hand text panel (step 5).
You are now ready to follow the steps in the IBM MQ GitHub repository, part two provides an overview of the detailed steps in the GitHub repository.
Part 2 – Deploy IBM MQ
The next thing is to follow the step-by-step guide in the README in the IBM MQ GitHub repository by following the link below, but before heading over there I recommend you read the overview I have provided here.
After reading the overview in this section, head over to the GitHub repository and follow the step-by-step instructions in the README. The README has copy buttons for the commands you need to run by pasting into the web terminal window, and sample YAML files that you can paste into the OpenShift console after clicking the ‘+’ button at the top of the OpenShift console.
Overview
You must configure some dependencies to prepare your OpenShift cluster for an IBM MQ queue manager deployment. The dependencies are the IBM Operator catalog, the IBM MQ Queue Manager Operator, a certificate manager, the Web Terminal Operator and two sample Java programs. The Java programs can be used to demonstrate sending and receiving messages, this is a great way to explore some of the new IBM MQ 9.4 console features for observing applications.
You will install these prerequisites from OpenShift’s “Operator Hub” which is a catalog of community and commercial software that has been specially packaged for simpler deployment on OpenShift. The first thing to deploy is The Web Terminal Operator, this is a great tool that allows you to run command line utilities from your browser – absolutely nothing to install on your machine.
Next, you’ll to install a certificate manager, you can deploy a queue manager without this, but it is a great demonstration of how easy it is to manage queue manager keystores and it will allow you to make an IBM MQ client connection from outside of the cluster if you want to. As of IBM MQ version 9.4 you can tell the IBM MQ client connection to ignore the authenticity of a certificate during testing, this works well with the self-signed certificate that the certificate manager will generate but should not be used in production environments.
The last dependency is the IBM MQ Operator. In the guide you will see how simple it is to add additional items to the OpenShift Operator Hub and then install IBM MQ with just a few clicks.
If you follow this guide closely, you will be able to deploy a functioning IBM MQ environment, generate messages and visualize them in the IBM MQ Web Console in about 15 minutes.
The README in the IBM MQ GitHub repository can be found here,
https://github.com/ibm-messaging/mq-gitops-samples/tree/main/queue-manager-basic-deployment
Once your queue manager is running, click on “Installed Operators”, click “Queue Manager” under the IBM MQ Operator”, click the “qmdemo” queue manager deployment and you will get a link to the IBM MQ Console, the username and password are set in the steps to deploy so you should have those. That’s it you have now deployed IBM MQ on Red Hat OpenShift.
Some notes on the Java samples and client connectivity:
The Java samples in this exercise leverage the Source 2 Image (S2I) capability of OpenShift. The S2I build takes the Maven project’s pom.xml file and the Java source code from the repository, it uses that to build a container image and then deploys it in the OpenShift cluster in the same NameSpace as the demo queue manager.
Connecting to a queue manager from outside of the cluster using the default OpenShift Route created by the IBM MQ Operator requires TLS and makes use of an SNI header. Deploying the samples in the same cluster/project gives us a quick and easy way to get an application up and running because we can use the OpenShift/k8s Service which will allows us to route based on the just the IP address of the service.
If you want to run the Java samples from outside of the cluster you will need to compile them in your own environment and use TLS. For a quick and simple way to connect, there is a TLS enabled MQ channel in the dev-config MQSC, and you can leverage the certificate validation options in IBM MQ v9.4 to remove the need to add the queue manager’s root CA or certificate to your own trust store on the client side. You will also need to tell the MQ client to use SNI for routing.
To get the external facing hostname for your queue manager run,
oc get route qmdemo-ibm-mq-qm -n mq-demo -o jsonpath="{.spec.host}"
Example Java code for external TLS and SNI:
// this tells the MQ client to put the hostname in the SNI header,
// used by the OpenShift Route to route to the k8s Service
System.setProperty("com.ibm.mq.cfg.SSL.outboundSNI","HOSTNAME");
// this tells the MQ client not to validate the queue manager’s certificate – test only,
// do not use in production environments
System.setProperty("com.ibm.mq.cfg.SSL.certificateValPolicy","NONE");
The Java samples have these code examples and an example of enabling a TLS cipher as comments.
To set validation options see,
https://www.ibm.com/docs/en/ibm-mq/9.4?topic=mq-configuring-certificate-validation-policies-in
For details on SNI see,
https://www.ibm.com/docs/en/ibm-mq/9.4?topic=programs-outboundsni-property