Immutability is a double-edged sword in OpenShift 4.X Deployments.
On one hand, it offers significant advantages like enhanced security, consistent configurations, and streamlined automation. On the other hand, it introduces challenges: a rigid, inflexible system that can result in fail-slow outcomes rather than the desired fail-fast behavior during critical deployments.
Nowhere is this more evident than with Red Hat Enterprise Linux CoreOS (RHCOS), the immutable foundation of OpenShift 4.X.
Understanding this trade-off is crucial for successfully navigating OpenShift 4.X Deployments—balancing the stability and predictability of immutability with the need for agility in dynamic, real-world environments.
RHCOS is quite an achievement because allows the consumption of infrastructure in an Infrastructure-as-a-Service (IaaS) fashion without the draconian decision between to-cloud or not-to-cloud, or even opens the door for a Hybrid environment that uses a mix of Public Cloud and On-premises resources seamlessly.
Book a Meeting With Crossvale
RHCOS also allows you to avoid having two separate platforms: OpenShift as the Platform-as-a-Service (PaaS) layer and something like OpenStack as your On-prem IaaS, making life easier as result.
As of today, the current process to deploy OpenShift 4.X is by using the openshift-install binary, which implies the creation of Ignition files in the case of User-Provisioned Infrastructure (UPI) installations, and that’s fine if every pre-req has been applied in a proper way.
Nevertheless, more often than not, pre-reqs are NOT in place for bunch of reasons: The official documentation is not clear enough, each item in the pre-reqs checklist is handled by a different team or company, each customer has a different Load-balancer, Firewall, Proxy server, and so on. In other words, a Consulting Engagement is complex, chaotic, and anything else except boring.
That’s why a DevOps approach for OpenShift deployments is needed. Typically, DevOps is applied extensively for application delivery. You could have DevOps practices for re-building an application deployment after each commit, running your Infrastructure-as-Code (IaC) scripts from your build server, etc.
Even so, it seems that consulting practices are more traditional, like an old software company which deploys its software by visiting each one of its customers to do an installation server-by-server, instead of offering a Software-as-a-Service (SaaS) solution.
Translating an OpenShift deployment to the DevOps approach means that “the code” we apply changes to is the install-config.yaml file, and the build process is to re-create the Ignition files and the VMs.
I will be playing with that idea and doing additional posts. Stay tuned!
Jhon Jairo Murillo Giraldo
Cloud Architect – DevOps Engineer
