OpenShift for Kubernetes developers: Getting started

OpenShift for Kubernetes developers: Getting started

If you are familiar with containers and Kubernetes, you have likely heard of the enterprise features that Red Hat OpenShift brings to this platform. In this article, I introduce developers familiar with Kubernetes to OpenShift’s command-line features and native extension API resources, including build configurations, deployment configurations, and image streams.

OpenShift’s command-line interface

We’ll start by looking at how OpenShift’s oc command-line utility builds on the Kubernetes kubectl utility in a couple of critical areas.

Everything you need to grow your career.

With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.

SIGN UP

Authentication and security

The kubectl command requires you to create a kubeconfig file to log in to your cluster. With the oc utility, you can simply log in using your credentials:

$ oc login -u <user_name>  <cluster_url>

Note: If you have access to the Red Hat CloudForms Management Engine, you can provision a shared cluster for learning purposes.

Besides logging into your cluster, you can use your credentials to log into other components that you installed through OpenShift, such as Jenkins and the Red Hat Registry.

While Kubernetes does not require role-based access control (RBAC), RBAC is an integral and mandatory part of OpenShift, along with basic authentication. Security is essential, especially at the enterprise level.

Project management

Once you are logged in, you can easily switch between OpenShift projects and namespaces from the oc command line. Just enter the following:

$ oc project <project-name-to-switch-to>

In Kubernetes, you can use the kubectl utility to switch between projects and namespaces, but it requires additional tools such as kubens and kubectx.

Application workflows

Simplifying workflows is the most essential feature that OpenShift brings to Kubernetes. To get started with developing an application inside your project, OpenShift supports templates. A template is a blueprint that you can use to develop your app. Modifying a quickstart template is an easy and quick way to create a new application.

As described in this article, OpenShift also supports Helm charts. A Kubernetes Helm chart is an application manager that packages applications and their dependencies into a .zip file. You can use Helm charts to deploy an application or a component of a larger application in OpenShift.

Example: OpenShift Django quickstart

Now consider an example. Let’s say that we are using OpenShift’s Django quickstart template to deploy an application in a GitHub repository. I have created a Hello World application for Django, which I will use for the example. You can find the example application here.

We start with the following command:

$ oc new-app <template> --param=SOURCE_REPOSITORY_URL=<git_url>

By default, the oc new-app command automatically creates all of the OpenShift resources required for any application.

Note: You might need to remove the OpenShift health checks readiness probe if your application is as simple as mine, and does not take any user requests.

Build configuration

Next, we’ll look at the build configuration. To start, run the command:

$ oc get bc

This command returns the application’s build configuration. A build configuration describes a single build definition and a set of triggers for creating a new build. The Red Hat OpenShift Container Platform (OCP) uses Kubernetes to create containers from build images and push them to a container image registry. It provides support for additional build strategies that are based on selectable types, which are specified in the build API. The key build strategies are:

  • Docker build
  • Source-to-Image (S2I) build
  • Custom build
  • Pipeline

For more information about each of these build strategies, see the OpenShift documentation for image builds. To find out what build strategy an application is using, run the following command:

$ oc describe bc django-ex | grep Strategy

Deployment configuration

When you run the command:

$ oc get dc

you will see the deployment configurations (configs) that were created for the app when you entered the new-app command.

A deployment is a way to manage the application. Deployment objects in Kubernetes and DeploymentConfigs in OpenShift manage applications by defining the desired state of a pod in a template. The two platforms use slightly different methods and API objects for this process. I will introduce a couple of useful features that OpenShift adds to the Kubernetes workflow.

Lifecycle hooks

You can use lifecycle hooks to add custom behavior to a deployment strategy. For instance, you might use Git hooks to automatically deploy an application every time an update is pushed to GitHub. All you have to do is copy the Git hook URL from your OpenShift cluster and paste it in the settings -> webhooks section of your repository. Use the following command to get the webhook URL:

$ oc describe bc <build-config-name>

In the webhook, replace the <secret> using the secret from the following command:

$ oc get bc <build-config-name> -o yaml

Now, when you push an update to your project, you can see OpenShift automatically starting a new deployment.

Image streams

Another difference between DeploymentConfigs and deployment objects in Kubernetes is that OpenShift supports image streams as a way to conveniently manage container images.

In Kubernetes, you use external tools such as skopeo to manage container images. Without skopeo, you have to download the whole image, update it locally, and push it back like you would any application in Git. You also have to update the container tags and the deployment object definition.

With image streams, you upload a container image once, and then you manage its virtual tags in OpenShift. Based on the project’s development stage, you change the tag to track the version of the image usually setting the newest version to latest. When using ImageStream with a DeploymentConfig, you can set a trigger to start the deployment when a new image appears or when a tag changes its reference. This way, the app deploys whenever a new version is built.

You can get the imageStreams in your project using the command:

$ oc get is

Conclusion

I hope you found this article helpful for understanding the differences between development on Kubernetes and OpenShift, and also for getting started with application deployment in OpenShift. See the OpenShift documentation and the following references to learn more about image streams tags and other OpenShift features discussed in this article:

Share