Setting Up Single Node Openshift to Deploy Maximo Application Suite

The purpose of this document is to guide you through setting up Red Hat OpenShift and deploying the Maximo Application Suite (MAS) on top of it. This is a bare-bones implementation designed for a single-node, on-premises, bare-metal installation of OpenShift.

If you're looking for instructions on deploying OpenShift in the cloud, this isn't the guide for you. However, if cloud deployment is what you're after, I highly recommend checking out OCPdude’s YouTube channel—he’s an incredible resource for cloud-based OCP implementations.

This deployment journey has been a challenging one for me, filled with lot of trial and error. My hope is that this guide helps you avoid the same pain and confusion I experienced. Throughout the process of implementing MAS, I often found myself wishing for a document like this—something straightforward and honest. Hopefully, this guide becomes that for you. I’ve leaned heavily on my network engineer, Chris Nist, as well as the broader IBM community throughout this process—including solution architects, customer success managers, and generous individuals in the forums who took the time to answer even my most “basic” questions. I’m truly grateful to everyone who supported this project along the way. Think of this document as my way of paying it forward.

Before we dive into the steps, let’s go over the setup.

For this deployment, we're using a VMware-based 64-bit Ubuntu box. OpenShift needs an x86_64 architecture, and this version of Ubuntu meets that requirement. Openshift also supports multi-architecture deployments, but that is well beyond the scope of this demo.

The VM is configured with:

• 16 cores 

• 64 GB of RAM

• Two disks (One to boot the RHCOS. One for MAS storage)
  
  

If anything is set up incorrectly, the OpenShift installer will definitely let you know later in the process.

Important note: Make sure your boot disk is at least 300 GB. If it’s smaller, you’ll likely run into ephemeral storage issues when deploying Manage. Take it from me—I spent countless hours troubleshooting crashes, only to discover that the root cause was insufficient storage. Save yourself the headache and go with at least 300 GB from the start.

Also, you'll need to add two A Record DNS entries for your chosen domain. They should look something like this:

api.<clustername>.<domainname>

and

*.apps.<clustername>.<domainname>

The cluster we'll be using is on premises, so we choose the Bare Metal x86 version located on the Datacenter tab:

We use the Assisted Installer because we don’t have any special requirements— such as an air-gapped environment or other custom configurations—that would necessitate a manual OpenShift installation.

Next, you’ll need to name your cluster and specify the domain where it will be deployed. The final format should look like this: 

<cluster_name>.<your_domain_name>.

You'll also need to select the version of OpenShift you want to deploy. Avoid using the default version provided by the installer—I learned this the hard way when I ran into compatibility issues between the OpenShift APIs and the MAS playbooks.

If you're unsure which version to use, refer to the MAS CLI Catalog and consult the Support Notes section to see what versions of Openshift are compatible with the build you are trying to deploy

Also make sure that you have One Control Plane (Single Node) selected

I prefer to install OpenShift Operators after the initial deployment. In the past, I encountered issues where the LVM Storage Operator bound to the wrong disk, which disrupted the entire installation due to our specific disk setup. One key lesson I've learned is to leave the defaults as they are during installation whenever possible.

That said, if you’d rather add operators before deployment, you certainly can—it just depends on your environment and comfort level.

Next, generate an ISO for the OpenShift platform to discover your cluster. You can change the provisioning type if you prefer a different format, but I usually stick with the default settings.

Once your ISO is generated, you have a few options. You can download it directly and mount it to your VM, or use a wget command in your terminal to retrieve the file. Personally, I just copy the provided URL and send it to my network engineer—he handles downloading the ISO, mounting it to the boot disk, and powering on the VM.

Now you wait for the Openshift console to communicate with your VM that booted the ISO.

Once your VM has booted and RHCOS is online, your screen should look something like this:

As you can see, we are only at Step 3 of the install process.

Step 4: This is a friendly reminder from Red Hat that proceeding will erase all data on the disks. Since this VM and cluster were created specifically for this demo, the disks are already empty—so we’re all set to continue.

In most cases, the default networking settings will be sufficient and require no changes. If you're working with a more advanced network setup, you can customize the CIDR configuration accordingly. For this example, however, we'll proceed with the default options.

You'll also see an option to upload an SSH key to the cluster for debugging purposes. While this is available, it's not strictly necessary—root-level access for debugging can be obtained directly via the command line using: oc debug node/<node-name>

Tip: To find your node name, refer to the Hostname column in the Host Inventory section. For example, you see here 00-50-56-b0-1a-40, that’s the name you’ll use in the command above.

Finally, review your cluster information carefully to ensure everything looks correct. I’ve collapsed the individual menus to save screen space, but each one simply contains a summary of the data you confirmed in the earlier steps. Take a moment to double-check everything—just in case something was missed.

Once you click Install Cluster, the installation will begin. As it progresses, you should see screens similar to the ones shown here.

Once the installation is complete, your cluster is ready to use! However, before logging in, there are a few additional steps to complete in order to prepare for deployment. For the record, it does not have to be done in this order. This is just my prefernece before I start interacting with the cluster.

Create an empty folder in a location you’ll remember, and copy your MAS license file into it.
Then, navigate to that directory using your terminal or command prompt.

For this walkthrough, my directory is located at /Users/brett/sno, and I’ll be working exclusively within the sno folder for this demonstration.

Pull the CLI image and create the Docker container.

In this example, the container will be named sno once the image has been successfully pulled.

docker run -dit --name sno quay.io/ibmmas/cli:13.9.0 bash

The CLI image used here is an older version.
For a more recent or stable release, refer to the official IBM MAS CLI Releases. Personally, I choose a CLI version that closely aligns with IBM’s latest production build.

You can track release dates and see which CLI versions correspond to specific OpenShift builds by visiting the IBM MAS CLI Catalog.

Log in to the sno container you created to run commands using the MAS CLI.

docker exec -it sno bash

Inside the Docker container, create a masconfig directory to store the license file.

mkdir masconfig

Exit the Docker container so you can copy the license file into the masconfig directory from your host machine.

exit

This command copies the license file from your local sno directory into the masconfig folder inside the Docker container you just created.

docker cp license.dat sno:/mascli/masconfig/license.dat

Log back into your Docker container to continue working inside it.

docker exec -it sno bash

Log into your Openshift console to continue the setup.

Once you're logged into your cluster, I recommend reviewing a few key details. The first thing I check is which disk the operating system is bound to. I've encountered some unexpected behavior during OpenShift installations, so I like to verify the OS disk for peace of mind.

This step will also be useful later when we install the LVM Operator to configure storage for Doclinks and other components.

To begin, navigate to the Compute tab and select Nodes.

Click on the name of your node, then navigate to the Terminal section.

In the terminal prompt, type lsblk and press Enter.

Review the output to identify the disk layout and confirm which device the operating system is installed on.

Now that we know which disk we have available, we can go ahead and configure our LVM Storage Class for document storage on our new cluster.

Navigate to the Operators menu on the left side of the screen and go to Operator Hub:

Search for the LVM Operator and install from the operator menu

Once the LVM Operator is installed, proceed to create the LVMCluster resource.

You should now see that the LVMCluster is in a Ready state.

Note: If the cluster initially shows a failed or pending status, wait a few moments. It may take a bit of time for the LVM Operator to reconcile the configuration and bring the cluster to a ready state.

Next, copy the login command from your Openshift console so that we can log into the cluster through the command line:

Copy your login token and paste it into your terminal window and login to your cluster

Now that you're logged into your cluster, it's time to make a few modifications to your newly created StorageClass.

Set the StorageClass as the Default

To set your lvms-lvm-storage StorageClass as the default, run the following command:

oc patch storageclass lvms-lvm-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

This ensures that any new persistent volume claims (PVCs) without an explicitly specified StorageClass will use this one by default.

Creating a PersistentVolumeClaim (PVC) for the Image Registry

In this step, we're creating a PersistentVolumeClaim (PVC) that will be used by the OpenShift Image Registry to store container images persistently.

The PVC is configured as follows:

oc create -f - <<EOF

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

 name: image-registry-pvc

 namespace: openshift-image-registry

spec:

 accessModes:

   - ReadWriteOnce

 resources:

   requests:

     storage: 100Gi

 storageClassName: lvms-lvm-storage

EOF

The last step is patch the image registry to use the persistent volume claim that we created. This command updates the OpenShift image registry to use the custom PersistentVolumeClaim (image-registry-pvc) we created for storage, sets the replica count to 1, and switches the rollout strategy to Recreate. It also ensures the registry is in a Managed state so that the operator actively maintains it.

oc patch configs.imageregistry.operator.openshift.io/cluster \

   --type='json' \

   --patch='[

       {"op": "replace", "path": "/spec/managementState", "value": "Managed"},

       {"op": "replace", "path": "/spec/rolloutStrategy", "value": "Recreate"},

       {"op": "replace", "path": "/spec/replicas", "value": 1},

       {"op": "replace", "path": "/spec/storage", "value": {"pvc":{"claim": "image-registry-pvc" }}}

   ]'

Now we're finally ready to install Maximo Application Suite (MAS). For this demo, we'll focus on installing MAS Core only. Database configurations can be complex and highly specific to each organization, and fortunately we use SQL Server and MAS Core doesn't require any database setup—making it a straightforward and self-contained deployment for this demonstration.

Select Yes to proceed with the cluster you are currently connected to.

For the sake of simplicity, we’ll skip displaying the advanced installation options.

We’ll select the latest catalog update from the CLI.

Next we'll select 9.0 as our release.

Accept the license terms

Since we're using Single Node OpenShift (SNO), our StorageClass must support ReadWriteOnce (RWO) access. In a multi-node cluster, you'd typically use a ReadWriteMany (RWX) StorageClass to allow shared access across nodes—but that's not necessary or supported in a single-node setup.

Configure MAS to reference the license file located in the directory we created earlier inside the container during this demo.

Next, enter your Entitlement Key:

Set up your Instance, Workspace ID and Name

Since this is a demonstration, we’ll configure the installation as non-production—which means no AppPoints will be consumed. 🎉

Now we’ll choose which applications to install. Since we’re only deploying MAS Core, select No for all additional applications.

We'll choose Yes to install the Mongo DB Community Operator

There is no need for advanced configuration. This is a standalone demo, and advanced settings/configurations is beyond the scope of this demonstration.

Finally, review your inputs in the CLI. These values will be passed to the playbooks and used to execute your installation.

It will take a moment for your pipelines to install, but once it does the whole process is automatic.

Back in your OpenShift console, you should now see a Pipelines tab. Click on it, then select Pipelines again. You’ll see a link labeled with the acronym PLR—this represents your PipelineRun, which corresponds to the current installation of MAS Core.

Once your install is finished, your console will hopefully look like this:

Navigate to the last task run labeled suite-verify and click on it.

Scroll all the way to the bottom of the logs, and you’ll find your MAS login details.