Installation

If you want to run OpenShift's Enterprise edition in your own data center, you first have to deal with the installation. Again, Red Hat has done its homework. The atomic-openshift-installer utility puts the program on the individual nodes of a setup if they are pre-installed with RHEL 7. The program requires a configuration file with values like the participating nodes and their IP addresses. In this file, the admin defines who is the Kubernetes master and which nodes can later become regular Kubernetes nodes so that even unsupervised installations pose no problems.

If that is too much effort, a "containerized" installation is available that involves several containers that start locally and hold the components relevant for OpenShift. It could hardly be easier than that.

Scripting Languages, Databases, Web

Once OpenShift is set up, the potential PaaS applications occupy center stage. Red Hat still refers to these as gears – think container when you hear "gear." Red Hat is noticeably going flat out when it comes to images. The company has created a clone of the Docker Hub in the form of the OpenShift Hub. On it are various cartridges with which environments (e.g., for PHP, Ruby, or Java) and many other technologies can be started in OpenShift with a mouse click. Cartridges are available for all relevant scripting and programming languages. Virtual machines can start directly from the Hub [7] in Red Hat's public OpenShift Cloud (Figure 4).

Figure 4: On the OpenShift Hub, Red Hat provides applications that can be rolled out as add-ons.

If you instead want to operate a container in your own OpenShift instance, you will find the sources on GitHub. If a cartridge for the framework needed can be found from neither Red Hat nor the community, you could possibly write it yourself. You will find various instructions for how to go about this online. Because a separate API service executes cartridges in OpenShift, its documentation [8] is also recommended reading.

Alongside containers for development environments, Red Hat provides containers for databases, such as MySQL 5.6 or PostgreSQL 9.4. On the basis of these templates, the admin can roll out the database along with the application containers so that all the required services work immediately after startup.

The gold standard is a container that has been certified by Red Hat [9]. This means that Red Hat has not only checked to ensure that it meets technical standards, but that the provider will provide support and security updates. Red Hat also provides their own certified containers; the same promises apply.

Through its Marketplace, where suppliers sign up to sell their products, OpenShift incorporates services that cannot be rolled out as gears in an OpenShift installation. These services will typically be of interest to businesses backing other "as a service" offers; for example, ElephantSQL offers PostgreSQL as a service, and Clear DB has a similar offering for MySQL.

Both providers operate the services themselves and individually release the credentials through which the service can ultimately be reached.

If a module is available for the Marketplace from OpenShift, the respective service can be incorporated directly into your own PaaS, as well as via the OpenShift tools, in a seamless process.

The Marketplace is therefore a sensible addition to OpenShift, not least because plenty of exotic services are available, such as RabbitMQ as a Service (CloudAMQP) or Keen IO, which offers Analytics as a Service for the cloud.

High Availability for Controllers

A typical Kubernetes setup has obvious weaknesses, particularly when it comes to the master node, which is a single point of failure. That said, its failure does not automatically lead to all containers crashing or losing their connection to the Internet. However, it might well be impossible to manage existing containers or create new ones with a failed master node.

Red Hat has therefore extended Kubernetes in OpenShift to include a high-availability solution. Because the company employs, or used to employ, all the developers who designed the Linux-HA stack, choosing it was only logical: Pacemaker and Corosync in tandem ensure that the failure of a master node in OpenShift is compensated for within a few seconds by launching the required services on another host.

OpenShift offers its own API and thereby fulfills the minimum requirement for an application in the context of clouds. If you want to use the platform's services, you have the option of using your own web interface, the web console, or the command-line client rhc. The functional range of both approaches is practically identical, making personal preference the sole decider.