Immutability is a two-edged sword. It could brings you a lot of nice things like security, standardisation, and automation. However, it also means inflexibility and Fail-slow outcomes when doing an OpenShift deployment (as opposed to a nice-to-have Fail-fast system): Yes! I’m talking about Red Hat Enterprise Linux CoreOS (RHCOS) if you haven’t guess yet!
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.
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
