A hitchhiker’s guide to OpenShift
As you are working with Red Hat OpenShift on IBM Cloud, just remember: Don't panic!
This document provides a glossary, links, and guides to topics about OpenShift. It is a guide for developers, created by developers who are working with Red Hat® OpenShift® on IBM Cloud™.
OpenShift is described as “The developer and operations friendly Kubernetes distro.” It runs on top of Kubernetes (previous versions of OpenShift handled container orchestration using a different mechanism). OpenShift provides tools that help developers and operations teams run containerized workloads. Under the covers, OpenShift is powered by Origin Kubernetes Distribution (OKD), which includes Kubernetes and other open source projects like Docker and Istio.
The following sections are organized in alphabetical order. In honor of Douglas Adams, author of the Hitchhiker’s Guide to the Galaxy series, we advise you: “Don’t Panic!”
“Application” is becoming something of an overloaded term as OpenShift evolves. Although previously a concrete concept, it no longer represents a single underlying object in the OpenShift world. However, “application” lives on in the console and command line as a kind of convenient grouping of certain features of a workload. The
oc new-app CLI creates multiple components, such as a Deployment and ImageStream, from an existing image or source code location, and a service and route configuration if a port is specified.
CI/CD with Jenkins or Tekton
You have a few options when implementing continuous integration and continuous delivery (CI/CD). A widely used application for setting up continuous delivery, Jenkins is provided as a certified container in OpenShift. You can use it to build packages, run unit and integration tests, and deploy images.
Another up-and-coming open source tool for building pipelines, Tekton provides a cloud-native way to perform many of the same operations.
buildah: buildah is a tool for building CRI-O-based images, much like Podman. buildah is comprised essentially of a superset of the build commands available through Podman, allowing for finer control in creating images.
kubectl: kubectl is the standard command-line tool for controlling Kubernetes clusters. Because OpenShift 3.x and more recent versions are based on Kubernetes,
kubectlis available to use on every OpenShift cluster.
oc: oc is the OpenShift Client CLI that you can use to manipulate OpenShift native constructs as first-class objects (including projects, applications, routes, and ImageStreams). Because OpenShift adds these elements on top of Kubernetes,
ocis required to interface with OpenShift-specific features.
odo: odo is “OpenShift do” – a command-line tool to simplify common operations. It is targeted at developers (as opposed to operations) to allow them to rapidly deploy and iterate on code.
s2i: s2i is a command-line tool to combine a builder image from a source GitHub source code repo. The output is a runnable Docker image. The builder image is like a template with baked-in scripts to take source code and compile it into a runnable application.
Image streams are an abstraction to allow OpenShift to deploy applications from a public image registry, while dynamically deploying new image versions as they make their way into the registry. You can configure builds and deployments to watch image streams and automatically update themselves when new image versions are available.
Internal image registry
Another thing that sets OpenShift apart is its built-in image registry. Why would you want to use an internal registry? It gives you another option instead of deploying images to Docker hub or another online registry. An internal OpenShift registry allows multiple projects within the cluster to access the registry, with fine-grained security though role-based access control (RBAC). Be aware that if an OpenShift cluster is deleted, any images stored in its internal registry are deleted as well.
Kubernetes is an open-source, container-orchestration system for automating application deployment, scaling, and management. It was originally designed by Google, and is now maintained by the Cloud Native Computing Foundation.
Much like Minikube lets you set up a Kubernetes cluster on your local machine for testing, Minishift allows you to run a development instance of OpenShift. It runs a single-node cluster inside a virtual machine, using libmachine for provisioning and OKD for the cluster itself.
OpenShift is powered by Origin Kubernetes Distribution (OKD), which includes Kubernetes and other open source projects like Docker and Istio.
OpenShift developer console
Another feature that sets OpenShift apart from base Kubernetes is its developer console, with rich capabilities. The OpenShift web console provides a central point of control for your OpenShift environment. The web console is made up of the following main views:
Cluster console: The OpenShift web console includes a friendlier view for admin operations. It includes a global view of the OpenShift cluster as a whole, including details of the underlying hardware. You can view metrics on cluster use with built-in Grafana or Promethues dashboards, and you can manage routes and ingresses.
Application console: On the application console, you can create and delete applications and deployments, and you can manage deployments. View logs of all deployed pods in a project on one screen, and see a history of builds.
Service catalog: On the service catalog, you can deploy databases and middleware applications directly from the console. The services in the console are pre-certified to work with OpenShift. You can create pods from base images for many languages and source code in GitHub repositories. Also, you can create Jenkins pipelines.
Operators act a lot like packages: they are a way to install a specific piece of software. In OpenShift, however, operators take software deployment a bit further by constantly checking the state of that software (like version number) and correcting any discrepancies from the desired configuration.
Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux system. You can run Containers either as root or in rootless mode. Simply put:
Projects in OpenShift are similar to the concept of namespaces in Kubernetes, but they existed before namespaces acquired many of their current features. Logically, projects enable multi-tenancy in an OpenShift cluster, allowing multiple teams to safely run isolated workloads in a single cluster, avoiding the extra overhead and costs of provisioning more OpenShift instances than necessary. Cluster administrators can give users permission to create projects and then control access on a per-project basis. In addition, templates can be created with a pre-defined set of objects to use as the basis for new projects.
Routes are the method by which you make your application, or more specifically a particular service (available to the outside world through a URL). The host name is specified by an administrator (that’s you, maybe!) when the cluster is provisioned.
Because OpenShift is intended to be the Kubernetes platform adopted by mature, security conscious enterprises migrating to the cloud, it includes several features meant to ensure the safety of running multi-tenant containerized workloads. Additional layers of security – defense in depth – can stop exploits that are in the realm of the “unknown unknowns”, for example: https://blog.openshift.com/openshift-protects-against-nasty-container-exploit/.
- By default, containers do not run as root. Instead, they are assigned a dynamically allocated user ID.
- Security context constraints control what users’ pods can run in, and what resources they can access.
- SELinux is enabled by default when OpenShift is installed.
OpenShift Source-to-Image (S2I) is a tool for building reproducible Docker images. It produces ready-to-run images by injecting application source into a Docker image and assembling a new Docker image. The new image incorporates the base image (the builder) and the built source. It is ready to use with the
docker run command. S2I supports incremental builds, which re-use previously downloaded dependencies and previously built artifacts.
OpenShift templates are best known as the way in which the OpenShift web console is populated with quick-start applications and other content. However, they are also a very powerful tool that, used thoughtfully, can be the building block of an infrastructure as code solution for managing many aspects of cluster and application state.
We hope this guide helps you on your journey with OpenShift. For tutorials, videos, and code patterns to work with, see the Red Hat OpenShift on IBM Cloud page.
We would love to hear feedback about our set of entries to our Hitchhiker’s Guide to OpenShift. If you have any additions or recommendations for improvement, contact Anton McConville. The Hitchhiker’s Guide to Galaxy was crowdsourced, so ours should be, too!