fetched at August 14, 2020
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.
Authentication and security
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.
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
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.
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
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
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
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.
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.
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
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:
- OpenShift Container Platform 4.5
- Understanding image builds
- Ten most important differences between OpenShift and Kubernetes
- OpenShift and Kubernetes: What’s the difference?
- Enterprise Kubernetes with OpenShift (Part one)
The post OpenShift for Kubernetes developers: Getting started appeared first on Red Hat Developer.Visit Link