My experiments with ‘containerising’​ Maximo

There have been a few articles around containerising IBM Maximo in the recent past. This got me thinking of how an organisation that has a heavy on-premise footprint but a ‘cloud first’ strategy could benefit from staging their move of Maximo.

Disclaimer: This is by no means a comparison of various cloud providers or even comparing the idea to any Maximo SaaS solution. The intent is to float an idea (not a novel one) and explain how I went about approaching it.

The article has 3 areas of exploration namely:

• Running Maximo on a local Docker container
• Running Maximo on an Azure Container Instance (ACI)
• Running Maximo on an Azure Kubernetes Service (AKS)

In each of the above scenarios, Maximo will run on an official IBM WebSphere Liberty image published on the Docker hub.

Before we start, things to note…

• I have always found having Maximo installed on a build machine (call it an origin machine or a seed environment) quite useful. This build machine will house the installation folder along with any add-ons. Obviously this could be a docker image as well, which could be version controlled in the Docker registry. I have chosen an Azure VM based on the CentOS image where Maximo is installed.
• Whilst the database can be containerised, I have chosen an Azure VM running an Oracle 12.2.0.1 Enterprise Edition DB. Note: This is a Bring-Your-Own-License image. This article will not focus on the command line configuration of the Oracle database. If you are interested, please checkout this Github URL to containerise an Oracle SingleInstance Database for Maximo.

Installing Maximo on a Linux Virtual Machine

By default the response xmls provided in the IBM Maximo installer performs a Maximo install as a root user in the /opt/IBM folder. However, most enterprises do not ‘like’ installing software as root.

Luckily IBM Maximo does provide an alternative to performing IBM Maximo installation as a non-root user which is the path chosen here. See Github url: Containerising Maximo

Here, the script maximoUserInstall.sh (Note: Please update the URL to download Maximo gzip in the script) will:

• Download the Maximo installer from a nominated installer
• Create installation response files that will enable Maximo installation as a non-root user. Script createResponseFile.sh creates the custom response file.
• Install IBM Installation Manager .
• Install IBM Maximo Asset Management software version 7.6.1.0.
• Configure Maximo with the Azure Oracle database.
• Build maximo-ui and maximo-cron workloads.

Maximo Image creation

IBM publishes official WebSphere Liberty docker images here. I will be using WebSphere Liberty version 19 which is supported with Maximo 7610 in the product compatibility matrix.

The Docker image for MaximoUI and any other workload will be based on this version of Liberty. The Dockerfile will exist in the maxliberty folder and will look as below:

FROM websphere-liberty:19.0.0.12-full-java8-ibmjava
# Maximo Image
COPY --chown=1001:0 maximo/* /config/
RUN configure.sh

The contents of the maximo folder, will be copied over by the buildMaximoImage.sh script which will create individual images as required. This script performs the following functions:

• Copy the maximo-ui workload into the maxliberty/maximo folder.
• Build a maximo-ui image and tag it appropriately for the docker registry of choice.
• Copy the maximo-cron workload into the maxliberty/maximo folder.
• Build a maximo-cron image and tag it appropriately for the docker registry of choice.

Once the images are created locally, these can be published to the docker registry of choice.

Running Maximo as a local Docker container

A local Maximo UI container can be run with a docker run command in a detached mode as follows:

docker run -h maximo761 --name maximo761 -d -p 80:9080 -d roshdevau/maximo:latest

And the logs of the container can be monitored as below:

docker logs -f maximo761

Docker containers can also be run using a docker-compose command which requires a docker-compose yaml file to specify the services that will be run within a docker network. These containers can be instantiated as below.

docker-compose up -d

Once up, Maximo and the WorkCentre can be accessed on the localhost at http://localhost/maximo and http://localhost/maximo-x respectively.

Running Maximo as an Azure Container Instance (ACI)

Often times, developers are required to have an environment that can be reproduced quite quickly. This is particularly the case, when a number of teams might be working on various different functional areas of Maximo. In this scenario, it becomes important that as soon as a release reaches Production, every other team updates their development environment. In the absence of powerful development laptops this can be a challenge.

Azure Container Instance (ACI) allows users to spin up an environments quickly. The ACI can be configured in Azure to pickup the latest image of maximo-ui which will ensure that the latest version of the published image is always picked up when the ACI starts. See below a screenshot of running Maximo in ACI.

Following screenshot shows the container with features allowing the monitoring of logs and even connecting to the container instance.

Running Maximo on Azure Kubernetes Service (AKS)

With Maximo supporting the creation and running of individual maximo workloads (e.g. maximo-ui, maximo-cron) in a containerised environment, running Maximo on K8s cluster has now become a possibility. While RedHat OpenShift (See: Deploy and run Maximo on RedHat OpenShift) is a clear choice, there are alternatives available with other cloud providers. The self healing attribute of K8s will be particularly attractive to IT Support Managers.

In order to run Maximo on AKS, an AKS cluster must first be created. A screenshot below shows the AKS configurations to run a Maximo UI instance. One thing to note here is that Kubernetes service address range and Kubernetes DNS service IP address should not fall within the range of the Cluster and the Virtual Nodes subnet CIDR block.

Once the K8s cluster is created, connect to the kube cluster using the following commands. Once connected, the Maximo deployment and a public service endpoint can be created by applying the yaml file.

## Set the Account Subscription
az account set --subscription <Subscription ID>
## Set get the credentials for aks
az aks get-credentials --resource-group <resourcegroup> --name <aks cluster name>

## Apply the deployment yaml file
kubectl apply -f kube-deploymentfile.yaml

This brings up the pods as configured in the yaml file. The service endpoint can be exposed to the internet as below:

The public ip for the service can be either be accessed from the AKS portal or via command line as follows:

And voilà the familiar Maximo front end appears. Note: I did install a few more add-ons to mimic a real life installation, but instantiating the Maximo container in any of the above 3 ways will not vary.

Next Steps

This has been a fun journey and I hope to seek your thoughts.

Are organisations out there running Maximo on Kubernetes in a Production setup already ?

Are there teams that have adopted running Maximo on Docker as part of their DevOps processes ?

With enterprises increasingly adopting a ‘cloud first’ strategy, I see a strong push for Maximo and other such enterprise grade solutions moving to an organisation’s choice of cloud provider (if supported).

For me personally, the next steps would be:

• To enable Azure AD based SAML authentication with the maximo-ui workload.
• And to trial running Maximo on RedHat OpenShift.