This is a continuation of our series of blogs about deployment of MAS. In this case, we are going to describe how to configure Automatic Certificate Management via the JetStack Cert Manager or the IBM Cert Manager Operators. Installing either is not part of this Blog Entry and the IBM Cert Manager should come automatically with the MAS Core as a dependency; however, we prefer to use the JetStack Cert Manager as it supports wider use cases than the IBM Cert Manager (such as split horizon DNS setups). We should be also aware of that IBM has officially supported the IBM Cert Manager and made statements that they will support other Cert Managers (RedHat’s or JetStack). In our experience, the JetStack Cert Manager works well with the MAS Core (and applications) up to the latest version at the time of writing 8.11.10.
This is a continuation of our series of blogs about deployment of MAS. In this case, we are going to describe how to configure Automatic Certificate Management via the JetStack Cert Manager or the IBM Cert Manager Operators. Installing either is not part of this Blog Entry and the IBM Cert Manager should come automatically with the MAS Core as a dependency; however, we prefer to use the JetStack Cert Manager as it supports wider use cases than the IBM Cert Manager (such as split horizon DNS setups). We should be also aware of that IBM has officially supported the IBM Cert Manager and made statements that they will support other Cert Managers (RedHat’s or JetStack). In our experience, the JetStack Cert Manager works well with the MAS Core (and applications) up to the latest version at the time of writing 8.11.10.
This is a continuation of our series of blogs about deployment of MAS on Bare Metal or on-premise scenarios. In this case, we are going to describe how to configure the Image Registry in the RedHat OpenShift Cluster, so it is backed up by persistent Shared Storage. Notice that Cloud Deployments will typically have the Cluster Image Registry already configured using one of the Storage options that is provided by the Cloud Provider. However, for Bare Metal scenarios, including SNO, such provisioning is not configured by default.
This is the second part of the two-part blog where we are showing the sequence of specific steps, we followed to install a Local Storage Provider to be used for SNO deployments over Bare Metal. To see important considerations and general discussion, feel free to see previous blog entry.
At Interloc, many of our Maximo consultants are continuously improving upon their MAS functional and technical skills. For those resources focusing on MAS installations, we use the Single Node OpenShift deployment option to create our own, individual environments to replicate issues and probable solutions. Considering these SNO instances are predominantly deployed either in Bare Metal hosts or in Virtualized platforms (like VMware ESXi as VMs) then a solution to have a locally provisioned Storage Class is needed in order to have all MAS and dependencies use it for Shared Storage.
