Clive, one of our lead Solution Architects with a lifetime of delivering IBM FileNet solutions, continues his Journey to the Cloud – this time sharing his experience of an IBM Cloud Pak for Business Automation dev setup.
To catch up on his previous blogs – here’s part 1, part 2, part 3 and part 4.
Setting up an IBM Cloud Pak for Business Automation development environment
This update is a little out of sync with what I’d suggested I’d look at at the end of my last blog and hence it will be short.
We have a project that is looking at Content Only (P8) from IBM Cloud Pak for Business Automation (ICP4BA) and we needed a dev environment that would be close to the customer’s final solution that would include Openshift.
Previously, we’ve had small stand-alone development environments running on laptops using a virtual machine, usually Ubuntu, with a system based on the CPIT deployment. This would include containers for LDAP, LDAP Management, Database (DB2), Content Platform Engine (CPE), IBM Content Navigator (ICN), GraphQL and Content Search (CSS). This was a very lean environment usually taking 4 cores and 8GB RAM.
The experiment began to see what was needed for a single node Openshift Deployment and the same P8 containers (CPE, CSS, GraphQL and ICN).
What are the minimum specs?
Reading the suggested minimum specs of a single node Openshift Cluster (See Preparing to install OpenShift on a single node – Installing on a single node | Installing | OpenShift Container Platform 4.10) it was quickly apparent that this is not something for the majority of laptops, so I started to deploy on one of our VMWare ESXi boxes.
I started with the minimum spec. The plan was to connect to the internal Microsoft AD and Database server so it would only need the P8 containers and any of the supporting containers now included by IBM.
The deployment
The cluster started and following the steps to first deploy the IBM Software Catalogue and Cloud Pak Operator everything seemed well.
Once the CP4BA deployment started it soon became apparent that more resources were needed. I shut down the machine running the cluster and started by increasing the memory allocation to 48GB and cores to 16, restarted the machine allowing the deployment to continue.
The Operator picked up where it left off and again stopped. The node was complaining that not enough cores were available to reserve for the deployment. Once again I shut down the machine and increased the cores to 24.
This allowed the P8 environment to deploy but still gave warnings that resources are over-committed on the node.
The system is working but you can see from the screenshot below that what is required to install the system is not what is being used for a single (maybe 2 user) dev environment.
It is clear to see that the standard laptops will not be up to running a development environment as we had previously. Further investigations are needed into options for future dev and demo environments.
Next time
Next time, in Clive’s Journey to the Cloud, he adds some extra functions to the PostgreSQL base deployment and runs through some features and functions.
If you enjoyed this blog, read part 6, the last post!
