What’s new in OpenShift 4
Red Hat OpenShift 4, that’s what. There was a big emphasis on the new version of OpenShift at the Red Hat Partner Conference, and rightly so. There have been some fairly major changes since OpenShift 3, the highlights of which are below (actually some of these changes have been filtering through since the last versions of OpenShift 3, but let’s not be too picky).
Firstly, and probably the most impressive, is the improved installation process. Rather than several days’ work, you can now get an OpenShift cluster running with a single command. In less than ten minutes Amazon will be billing you for a fully operational environment! The default set-up creates three control plane machines (the masters) and three compute machines (the workers). It is fully HA, spread across availability zones in the specified region. Obviously this can all be customised and scripted if you wish. A warning for your wallet though: the minimum number of control plane machines is now three, rather than one as it was in OpenShift 3.
The next big change is that Docker has gone! It has been replaced by CRI-O, together with CLI tools Buildah and Podman. OK, now you’ve picked yourself up off the floor, it’s actually not such a big deal, at least from a project point of view. Since the introduction of the Open Container Initiative in 2015 and the Container Runtime Interface for Kubernetes in 2016, the container world has been standardising, and there are a number of ways to run containers other than just using Docker. And, since we now follow standards, existing projects with Dockerfiles can still be deployed. From an operational standpoint, CRI-O is a huge improvement over Docker as it is more lightweight, aligns with Kubernetes releases (making maintenance and upgrading simpler), and, crucially, is much easier to secure.
The other big buzz word is Operators. The purpose of Operators is to take human knowledge and automate it, specifically to manage Kubernetes objects via the Kubernetes APIs. They continuously compare the current state of an object with the desired state, and act to ensure that the desired state is achieved. Operators have been used extensively in OpenShift itself, which has led (amongst other things) to the simplified installation process, and also gives a much nicer upgrade process too. You can apply the same approach by writing Operators for your own applications, and there are many available on the Operator Hub. Operators were originally developed by CoreOS, so it’s no coincidence that CoreOS has replaced Atomic Host as the base OS of choice for machines in an OpenShift cluster.
Please get in touch with the team to find out more about our Openshift services.
