Live Cell Therapy

My last look at OpenShift [1] was mid-year 2017. The sobering results of a close inspection: The product, which Red Hat was pushing like a re-invention of the wheel, was actually no more than a commercial distribution of the Kubernetes container orchestration [2].

However, things have changed. In version 3.0, Red Hat shifted the product onto the new Kubernetes underpinnings and has since made continuous improvements in many parts of the software. What features will administrators running an OpenShift cloud benefit from most? What is the greatest benefit for users? From which innovations will developers reap the greatest benefits? I'll answer those questions in this article.

New Brooms

Since version 3.4, a noticeable change has been made in naming the individual products in the OpenShift series. OpenShift is a kind of umbrella term for several products of differing versions. OpenShift Origin refers to the original open source product on which the commercial variants of OpenShift are based. The open source version is of interest if you don't want to pay money to Red Hat. In return, you will not receive any support.

If you need support, you can choose between Red Hat's public OpenShift installation as a kind of public cloud – an OpenShift installation hosted by Red Hat on behalf of customers – and a private OpenShift installation in your own data center, previously called OpenShift Enterprise, but now renamed OpenShift Container Platform.

However, the manufacturer is in a hurry to clarify that nothing has changed except the name of the product. The motivation for the name change is thus likely to be that Red Hat wants to mesh OpenShift with other components in its portfolio in a more meaningful way, including improving integration with CloudForms, which I discuss later in this article.

Kubernetes and Docker Updates

Because the OpenShift release cycle is quite short, Red Hat is keeping pace with the development of Kubernetes and Docker [3]. The resulting innovations are not immediately visible to users, because the purpose of OpenShift is to offer an integrated product with a GUI and all the modern conveniences. As in the past, this will only be possible almost exclusively on Red Hat Enterprise Linux (RHEL) or CentOS systems.

If you use OpenShift Origin in combination with a commercial OpenShift version, you have to use Red Hat Linux. You can choose between the normal or the absolute minimum RHEL Atomic Host version. No matter which variant you choose, for OpenShift 3.6 (the latest version when this went to press), an up-to-date Docker from the Docker Extras directory is required on the hosts.

Simpler Installation

Red Hat continues to offer two ways to launch its own OpenShift deployment: with a normal RHEL OpenShift installed via RPM and with a prebuilt OpenShift installed in the form of a Docker container. However, in the latest OpenShift versions, Red Hat has simplified and accelerated the container-based setup significantly. Based on a Docker image from Red Hat's Docker Hub, a complete and working OpenShift environment can now be rolled out with a single command in a few seconds [4].

However, such an all-in-one setup is only of limited suitability for production operations. Red Hat also admits this without hesitation and recommends the Ansible-based RPM installation for larger, more complex setups. However, for developers who want to experiment and test in a clean OpenShift environment, the new deployment mechanism is a real blessing.

These are the facts: The RPM variant is well suited for large setups, but people who only want to test OpenShift or base developments on it are well served by the containerized installation (Figure 1).

Figure 1: OpenShift Origin can be started as an all-in-one installation using a single command.