Attention to Detail: The GUI

The homemade graphical user interface (GUI) is, according to Red Hat, a unique selling point for OpenShift. No wonder: Kubernetes itself comes without a GUI and once again proves that the coolest software does not help if the learning curve is extremely steep. Red Hat, on the other hand, has agile and uncomplicated administration at the top of its feature list. Whether admin, customer, or developer, Red Hat wants everyone to perceive the OpenShift GUI as a genuine facilitator in everyday life.

The changes to the GUI have been correspondingly widespread. Almost half of the changelogs for the previous versions are full of GUI changes. Starting with the login, if you like, you can now add a branded page to your OpenShift installation, so that users logging in will not be put off by the generic OpenShift interface when logging in to OAuth.

Once you are logged in, you will come across UI innovations in every nook and cranny. For example, Red Hat has built-in search filters in many places that make it far easier to check the content of long lists than before. The search mask reacts while you are entering text: If you want to see the Apache pod, it appears when you type Apa in the search box.

The GUI built by Red Hat for the Docker registry, which is part of OpenShift, is even more useful. Remember, if you want to launch a Kubernetes pod from Docker containers on a host, you need to specify the Docker image you want to use as a basis in the pod definition. In the default configuration, Docker collects the images from the Docker Hub and then runs them locally.

It doesn't work that way with Kubernetes; after all, the overall concept envisages building suitable PaaS containers in OpenShift and rolling them out into production operation. To do so, however, local Docker instances must be able to communicate with a local registry in which the prebuilt images are stored. A registry that fits the bill is included with OpenShift.

In the early 3.x releases of OpenShift, the registry was provided entirely without a GUI. For example, if you wanted to know which images were stored there, you had to go to the command line, where you typically faced an impossibly long image list that you had to sort manually. Those days are over. In the OpenShift GUI, the registry now has its own page, including the previously described search fields. Each image stored in the registry can be examined individually, and the GUI also displays additional details of the images (Figure 3). All in all, the OpenShift GUI is now far more convenient to use than before.

Figure 3: OpenShift's built-in Docker registry now comes with its own GUI, which makes access much more convenient.

Bundled with CloudForms

An ideal situation for software vendors is that different environments can be managed comfortably in a single user interface. Red Hat has at least two candidates in its portfolio for which admins might well want exactly that: OpenShift and CloudForms.

Since OpenShift 3.1, Red Hat has consistently offered the option of integrating CloudForms in such a way that it rolls out its services on OpenShift as pods. Don't expect a single management GUI, though, because CloudForms comes with a convenient GUI of its own. Of course, combining CloudForms and OpenShift makes sense, because the two components work together well (Figure 4).

Figure 4: In the future, CloudForms and OpenShift can be operated so that CloudForms containers launch in OpenShift.

OpenShift and Jenkins

One major motivation for using OpenShift is that you can build your own container infrastructure on the solid foundation of continuous integration (CI) and continuous delivery (CD). To make sure this works, the OpenShift developers connected their software to the Jenkins CI/CD tool through a separate plugin and introduced build pipelines at the same time.

The idea is that you can develop your containers in the form of Git directories or at least manage the Docker files in them. When a developer checks in a change for a container, Jenkins automatically starts to rebuild the Docker image and uploads the finished image to the registry.

Functional checks are also carried out completely automatically. A build pipeline can consist of any number of steps that you define freely. This feature is very useful for image developers (Figure 5).

Figure 5: Pipelines promise a better CI/CD for container images.