IBM Cloud Private Deployment Scenarios – IIB, MQ, WAS Liberty, NodeJS

This article and associated collateral captures a journey of adoption for middleware on IBM Cloud Private (ICP) from the point of view of the Integration Developer. Since the launch of ICP in late 2017, I have been exploring integration, messaging and application deployment scenarios on the platform. I started with some simple WAS and NodeJS application workloads and then applied the approaches I learned to IBM Integration Bus and IBM MQ middleware products.

Beyond looking at running up simple runtimes, I have explored using ICP’s DevOps tools for continuous delivery and leveraging Helm Charts and Docker image builds from my own custom repositories. Having gained a reasonable knowledge of the ICP Platform (Kubernetes (K8s)) and Helm I went on to model a traditional, active/active, highly available IIB/MQ ESB integration pattern as a Helm release, stored the collateral on Github and used ICP DevOps tools (Jenkins) to build the ESB on ICP. It comes up ready to transact with all cluster channels running and IIB nodes connect and running in approximately 1 minute.

Featured Workloads and Deployment Scenarios

This article will walk you through the 6 scenarios outlined below with video demos and links to collateral on GitHub so you can work through them yourself.

Scenario 1: Deploy and Test JEE application using WAS Liberty from ICP Catalogue

The scenario shown above has these coarse grained steps:

1. Self service provisioning of a WAS Liberty runtime via Helm from the ICP catalogue
2. Deploy a CloudTrader application by moving a WAR file to an ICP persistent volume (NFS mount)
3. Test the deployed application.

Now take a look at the video demonstrating the scenario end to end

Scenario 2: Continuous Delivery of NodeJS Web App using Jenkins and Github

The scenario shown above has these coarse grained steps:

1. A developer has written a financial services NodeJS WebApp in an Eclipse toolkit project
2. Git push the project to a Public Github repository
3. WebHook fires, calling oAuth enabled, Micro Service Builder (Jenkins) on ICP
4. Jenkins builds a docker image for the WebApp and performs a Helm release to deploy a container
5. Test the WebApp
6. Developer updates the WebApp, pushes to Github to trigger a replacement build. Then retests

Now take a look at the video demonstrating the scenario end to end

Now review the collateral on Github at:
https://github.com/DAVEXACOM/WAS-LIB-HW

Scenario 3: IBM Integration Bus Self Service via ICP Catalogue

The scenario shown above has these coarse grained steps:

1. Explore the ICP Catalogue and use it to deploy a Helm release of IBM Integration Bus
2. Review the ICP Events and Logs for the deployment
3. Connect the IIB WebUI and IIB Toolkit
4. Deploy and test an HTTP message flow.

Now take a look at the video demonstrating the scenario end to end

Scenario 4: Continuous Delivery of IIB and MQ using Jenkins and Github

The scenario shown above demonstrates how multiple developers can continuously deliver their latest integration artifacts to a common System Integration Test environment on ICP such that automated socialization and regression tests could be run. It has these coarse grained steps:

1. IIB Developer or Developers make changes to IIB applications they are working on
2. Developers push their updated IIB applications to a Public GitHub repository
3. The Github repository includes docker image files, helm charts and IIB deployable code
4. WebHook fires, calling oAuth enabled, Micro Service Builder (Jenkins) on ICP
5. An IIB v10 and MQ v9 image is built, and deployed as a helm release by Jenkins on ICP
6. Connect the MQ Web Console, IIB WebUI and execute some tests using test tools.

Now take a look at the video demonstrating the scenario end to end

Now review the collateral on Github at:
https://github.com/DAVEXACOM/IIB-MQ

Scenario 5: Upgrading MQ in IIB/MQ Developer runtimes using Jenkins and Github

The scenario shown above shows how a Standard Operating Environment for integration developers can be maintained and administered central saving individual developers from having to maintain their own runtimes. It has these coarse grained steps:

1. An administrator uses Micro Service Builder(Jenkins) on ICP to build an IIBv10 / MQv903 Standard Operating Environment (SoE) for developers
2. The IIB Developer deploys his message flows and tests
3. Administrator changes the docker file and pushes to Public GitHub to initiate a rebuild of the SoE at IIBv10 / MQv904
4. The SoE is rebuilt by Micro Service Builder(Jenkins) on ICP
5. The IIB Developer reconnects his IIB Tookit, MQ Console and test tools and continues working.

Now take a look at the video demonstrating the scenario end to end

Now review the collateral on Github at:
https://github.com/DAVEXACOM/IIB-MQ

Scenario 6: Delivery Complex integration and messaging pattern on ICP using Helm, Jenkins and Github

The scenario shown above explores using a single Helm Release on IBM Cloud Private to deploy a 4 Way MQ cluster with 2 active/active Gateway queue managers and active/active back office application queue managers each with a locally connected IBM Integration Bus node. The docker images and helm charts are stored on Public Github and the ICP Devops tooling, Micro Service Builder (Jenkins) is used to build the images and deploy the Helm Release. This 4 container deployment initializes on ICP with all IBM MQ channels resolved and started plus IBM Integration Bus message flows deployed, started and ready to service messages for back office.

This scenario is explored in greater detail along with video tutorials and full build and setup instructions in the following article.

IBM Cloud Private – Foundational Use Case – Traditional IIB/MQ based ESB on ICP

The following two diagrams show how the MQ Cluster and IIB nodes process inbound (receipt) and outbound (emission) messages.

A video walk through of the collateral and solution for this scenario is under construction
However, you can review the collateral on Github at:
https://github.com/DAVEXACOM/MQ4WAYCLUS-LCIIB

https://github.com/DAVEXACOM/IIB-MQ-SPLIT-HELM

The MQ4WAYCLUS-LCIIB repository delivers the MQ Docker Image build used by GWQM1 and GWQM2 containers plus the Helm charts for the full GWQM1, GWQM2, APPQM1(with IIB) and APPQM2(with IIB) helm release.

The IIB-MQ-SPLIT-HELM respository delivers the MQ+IIB Docker Image build used by APPQM1 and APPQM2 in the helm charts in MQ4WAYCLUS-LCIIB. IIB-MQ-SPLIT-HELM does container helm charts such that this repository can also be used standalone to deliver a single MQ+IIB container build.

It should be noted that I am in the early stages of teaching myself about K8s and Helm and this collateral therefore lacks the elegance that a more experienced user of the technology might produce. It is my intention to continue to evolve the techniques I use as my knowledge in this space grows.

For those other ICP, Github, Jenkins and Helm novices out there if you were want to set up your own instance of ICP to run these scenarios I captured all my original set up work for getting IIB and MQ working with Jenkins via webhooks and oAuth on github in this earlier article.

IIB and MQ with Micro Services Builder on IBM Cloud Private