Make the Shift

If you were looking to place a bet on a piece of software that would still be popular in a few years time, you couldn't go far wrong by choosing Kubernetes [1].

Following the public explosion of interest in containers – courtesy of Docker over the past five years or so – the tool of choice to organize, scale, and add resilience to those containers has been firmly voted as Kubernetes. Along with varying DevOps methodologies, the rapid rise in its adoption has been eye-watering, surpassed only by the interest shown for Docker initially.

Among other contenders in the container orchestrator space, Docker offers "swarm mode" (or Docker Swarm), which enables users to manage the orchestration of containers across a cluster of machines that are running Docker Engine. Red Hat also offer an enterprise solution that has provided some symbiosis with feature developments in Kubernetes, because Red Hat's product OpenShift [2] and its various incarnations are firmly based on it.

OpenShift and its additional features, along with the enterprise-level Red Hat support services, is based on the open source version of Kubernetes. Additionally, a community version, formerly called Origin, which then became OKD [3] in the second half of 2018 [4], is described as "The Origin Community Distribution of Kubernetes that powers Red Hat OpenShift."

An online platform called OpenShift Container Platform [5] allows you to run your applications directly, in a supported manner, in a way that can alleviate much of the overhead of running Kubernetes clusters in-house.

In this article, I install OKD by one of the available methods, namely Minishift [6]. OKD calls Minishift an "all-in-one" virtual machine, which is fully functioning and even boasts its own, private container image registry.

Once you're up and running, you will access the GUI, or console, from a browser followed by the command line with a view to setting up and launching an application. This demonstration should help whet your appetite about what's possible with OpenShift and OKD.

Pick It, Pack It, Fire It Up

To start, I'll be using the well-known KVM [7] Linux virtualization technology to install OKD locally. To use the required virtualization, you will need a compatible machine running the, now relatively standard, CPU extensions called Intel VT or AMD V. If your machine offers one of these features, you need to check that your BIOS has them enabled. The command

$ egrep "(svm|vmx)" /proc/cpuinfo

should return svm or vmx in colored text. On my Ubuntu 18.04 laptop, I see vmx in red text, because Intel VT is available on my machine.

As the root user, you will install KVM:

$ apt install qemu-kvm libvirt-daemon libvirt-daemon-system

In my case, I see about 70MB of files added after running the command. You should really be running many of the OKD commands that follow as the non-root user for extra security. For ease, however, I'll focus on using the root user.

If you want to use another user instead of superuser, you can add your username to the libvirt group:

$ usermod -a -G libvirt $(whoami)

Having done so, you could then log in to the libvirt group for this session with:

$ newgrp libvirt

Now back to the installation. For the next task, you need to download a compatible Docker driver for KVM:

$ curl -L https://github.com/dhiltgen/docker-machine-kvm/releases/download/v0.10.0/docker-machine-driver-kvm-ubuntu16.04 -o /usr/local/bin/docker-machine-driver-kvm

The eagle-eyed among you will spot the 16.04 driver being downloaded and not 18.04. For the purposes here, that should be fine, because it's the latest Ubuntu version currently available. However, you should navigate to the GitHub page for the latest release of the KVM driver for docker-machine and the MD5 checksums [8].

For safety, you should not just blindly install the software. The MD5 checksum is shown as abc34ba69fbdc6c6aea3f59d99962310 for docker-machine-driver-kvm-ubuntu16.04. To check that, enter:

$ md5sum /usr/local/bin/docker-machine-driver-kvm
abc34ba69fbdc6c6aea3f59d99962310

That looks like a good match, so you can proceed knowing the file is probably as the publisher intended and hasn't been tampered with during the download.

Next, enter:

$ chmod +x /usr/local/bin/docker-machine-driver-kvm

to make that file executable.

Window Within a Window

Once you have installed the software to run on a virtual machine, you can begin to set it up. To start, make sure KVM is happy by using the concatenated command:

$ systemctl start libvirtd; systemctl enable libvirtd.service; systemctl status libvirtd

Assuming the phrase active (running) is returned by systemd, you are ready to go. Just hit the q key to quit.

One last thing worth checking is that you have a "default" network configured correctly in KVM. To check the configuration, use the virsh command:

$ virsh net-list --all

Figure 1 shows the output, which in my case, shows that the network exists but is not running – unfortunately.

Potentially, you might have to fix two issues that show in the output of Figure 1. First, make sure that the Autostart column states yes; if it does not, change it with the command:

$ virsh net-autostart default

Second, make sure the change has taken hold with the net-list command used earlier.

Third, check that inactive is not visible in the State column. If that's what you see, you can change it with the command:

$ virsh net-start default

If you get a nasty looking error at this stage, fear not. The error I got was:

error: Failed to start network default
error: internal error: Failed to initialize a valid firewall backend

Thankfully, this can be fixed by installing and enabling firewalld. Simply enter the command:

$ apt install firewalld

You can start up and check firewalld, as you did with libvirt, by combining some simple commands in one line:

$ systemctl enable firewalld; systemctl start firewalld; systemctl status firewalld

Check that it's running as expected – you should see active (running). To keep libvirt happy, you'll restart its service with the command:

$ systemctl restart libvirtd

If it didn't automatically start up, you can now try to start up the default network as follows:

$ virsh net-start default

At this stage, you should see an error saying something like network is already active, which is good news. Otherwise, you've started the network for this session, which will suffice in the short term; however, do check that you've set Autostart properly, as mentioned above.

To double-check that the networking is functioning as expected, look once more at using the net-list command:

$ virsh net-list --all

Following your recent efforts, you should see something like Figure 2 if you're up and running.

If you don't have the same output, then rinse and repeat the previous steps or check the KVM documentation to see if you are having issues with your Linux distribution.

Shifting Sands

The next task is to download Minishift from the latest releases page [9]. In my case, I'll choose the minishift-1.33.0-linux-amd64.tgz tarball, which is compiled for Linux. You can download it with the command:

$ wget -O minishift-1.33.0-linux-amd64.tgz https://github.com/minishift/minishift/releases/download/v1.33.0/minishift-1.33.0-linux-amd64.tgz

At this point, you should make sure the checksum matches the file, but instead of using the MD5 tool as in the previous example, you should use the SHA256 tool:

$ wget https://github.com/minishift/minishift/releases/download/v1.33.0/minishift-1.33.0-linux-amd64.tgz.sha256

You can see the hash inside the downloaded file with the cat command:

$ cat minishift-1.33.0-linux-amd64.tgz.sha256
e47232e638d66d133d577739cd26b053d0453f5dcf3318dc237b6e792ccd218d

Now look at what sha256sum offers by running it against the tarball you downloaded:

$ sha256sum minishift-1.33.0-linux-amd64.tgz
e47232e638d66d133d577739cd26b053d0453f5dcf3318dc237b6e792ccd218dminishift-1.33.0-linux-amd64.tgz

Excellent. The file is much more likely to be in the state its author intended and have not been tampered with during the download. Next, uncompress the tarball and enter the resulting directory:

$ tar xvfz minishift-1.33.0-linux-amd64.tgz
$ cd minishift-1.33.0-linux-amd64

If you run the ls command, you can see a 27MB binary called minishift. You'll want to move that file into the /usr/local/bin directory:

$ mv minishift /usr/local/bin/

Now go back to your home directory (/root in my case) with the cd command. You can check that the minishift binary is available from within your user's path by entering the following command from your home directory:

$ minishift version
minishift v1.33.0+ba29431

The results look promising, so you should proceed.

On Your Marks

Finally, you're ready to run OKD and dig into OpenShift. You can ask Minishift to weave its magic by running the following super-simple command:

$ minishift start

You'll see that an ISO is downloaded, and a number of KVM-related tests are being performed. Keep a close eye on the startup operations, because you'll spot Docker images being pulled down from Docker Hub [10], too.

Depending on the capabilities of your hardware, you might need to be a bit patient and wait for Minishift to complete. The final stage (Starting OpenShift cluster…) takes my laptop a few minutes to complete. You should eventually be welcomed with a URL that correlates with your shiny, new OpenShift cluster. It will consist of an IP address and TCP port 8443.

If all goes well, you'll be told that you're logged in as the "developer" user, and you'll be instructed how to log in as an administrator with the command:

$ ## oc login -u system:admin

(If you wanted to run it, you'd eliminate the two comment hashes at the start. The line is commented here so that you stick to using the developer user in the tasks that follow.)

Incidentally, if you want to stop Minishift dead in its tracks, you can use the simple command:

$ ## minishift stop

However, leave it running for now. (Again, the line is commented so you don't accidentally stop the cluster at this stage.)

Gooey

Next, you'll enter the URL you were offered – the one showing TCP port 8443 – in a browser. In my case, the URL is https://192.168.42.78:8443/console. I'll accept the warning in my browser that this is an unsafe site, so I can to continue, and click Advanced and then Proceed. To log in, I'll use developer for both the login and password. Figure 3 shows a very welcome dashboard, which is brimming with options.

I'll leave you to explore and plunder some of the treats in store with OKD and focus on getting an application set up to get you started on your OpenShift journey.

Project X

If you look on the right-hand side of Figure 3, you can see My Project, which has been automatically built for your user developer. Click that link and, in Figure 4, you can see the most common dashboard you would use to operate an application in OpenShift, courtesy of OKD in this instance. For those of you familiar with Kubernetes, note that OpenShift "projects" are "namespaces" in Kubernetes. Projects are effectively used in some use cases to split up customers or departments logically.

I'll move away from the GUI for now and deploy a Node.js application from the command line. Although this can be achieved from the GUI, I'll demonstrate how to get started with the command-line interface.

Rather than using the kubectl command, as you would with Kubernetes, the base command for OpenShift is oc. To access the oc command, you'll need to set up your shell to connect to your virtual machine. A clever minishift command helps you out:

$ minishift oc-env
export PATH="/root/.minishift/cache/oc/v3.11.0/linux:$PATH"
# Run this command to configure your shell:
# eval $(minishift oc-env)

This command has run an export command and output two bits of information prepended by comments. If you do as you're told, you run the following command:

$ eval $(minishift oc-env)

Next, you should test that this step worked as you hoped and check the output:

$ oc version
oc v3.11.0+0cbc58b
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO
Server https://192.168.42.78:8443
kubernetes v1.11.0+d4cacc0

That's good news. To continue, create a Node.js application by logging in as the developer user on the command line as follows:

$ oc login -u developer

On a freshly built local machine, you might need to install Git before proceeding:

$ apt install git

Now you can create a new application called nodejs-ex, and you'll use the new-app command in OpenShift:

$ oc new-app https://github.com/sclorg/nodejs-ex -l name=myapp

Run the command

$ oc status

to check the status of the application. The output is shown in Listing 1. Try that command a few times to see what OKD is doing behind the scenes as the application comes up.

$ oc status
In project My Project (myproject) on server https://192.168.42.78:8443
http://nodejs-ex-myproject.192.168.42.78.nip.io to pod port 8080-tcp (svc/nodejs-ex)
  dc/nodejs-ex deploys istag/nodejs-ex:latest <-
    bc/nodejs-ex source builds https://github.com/sclorg/nodejs-ex on openshift/nodejs:10
    deployment #1 deployed 1 hour ago - 1 pods
2 infos identified, use 'oc status --suggest' to see details.

You can also track the logs of that application with the command:

$ oc logs -f bc/nodejs-ex

which has functionality similar to the tail -f command. Next, you can open a port and expose the networking:

$ oc expose svc/nodejs-ex
route.route.openshift.io/nodejs-ex exposed

There's no doubt that OKD has been busy behind the scenes. If you run the command

$ minishift openshift service nodejs-ex

to check on which URL the new service is being presented, you'll see the output in Figure 5.

Now pop that URL into a browser: excellent news. As you can see, Figure 6 denotes success!

One final test will make sure you can configure your project inside the dashboards of the GUI. In my case, the URL is https://192.168.42.78:8443/console/project/myproject/overview. Simply change the IP address to suit your needs. Figure 7 shows the console has updated itself with live data, without the need for a page refresh.

To get a feel for how OpenShift can be operated, I attempted a basic test as, shown in Figure 7. To try this for yourself, simply increase the number of pods on the right-hand side to scale up the number of containers that will be available for your application.

After a moment, you'll see a second pod running, which means you can easily accept more traffic. This functionality is pretty clever by anybody's measure, I'm sure you'll agree. For help, see the "Troubleshooting" box.

The End Is Nigh

OpenShift and Kubernetes are fantastic pieces of software with an ever-growing feature list. I've barely scratched the surface of how to operate OpenShift here, but I've looked at a simple crossover or two between the command line and the GUI to get you started.

If you are not familiar with image streams (abstractions for referencing Docker images from within OpenShift) because you've only looked at Kubernetes in the past, or you are new to OpenShift, they are well worth trying out, because they offer very valuable and sophisticated functionality [13].

OpenShift has additional security policies and benefits that might be new to you, so pay close attention to those once you have the basics mastered.

Having come this far, I trust that you are now suitably intrigued with OKD and will try running your own applications in a test cluster. I think you'll find OpenShift's upstream parent is a powerful orchestrator well worth investigating.