OpenShift Kubernetes Platform
In the age of cloud and containers, Kubernetes holds a central place in the vocabulary of developers that want to stay current and to get an advantage over their competitors. In its base, Kubernetes is a container cluster orchestration platform that allows developers to manage their application infrastructure more easily.
Red Hat has been a huge contributor to Kubernetes as an open source project since the second day of Kubernetes’ release to the public. After Google, Red Hat is the company with the most contribution to the open source project. Clayton Coleman, who has been a guest of Software Engineering Daily, is one of the top contributors in Kubernetes’ repository. As a consequence, Red Hat has quite a lot of insight of Kubernetes’ inner mechanisms and has been building on top of Kubernetes to bring OpenShift to life.
OpenShift by Red Hat is a PaaS (platform-as-a-service) aimed to automate the build, deployment, and management of applications. OpenShift is built upon containers and Kubernetes and integrates other services to create a convenient bundle for developers and operational managers.
Why OpenShift?
Kubernetes has a steep learning curve and is difficult for developers to get used to. OpenShift provides an easier interface to Kubernetes along with some level of abstraction on top of Kubernetes. While Kubernetes by itself has great features that ease container management and orchestration, it lacks some of the necessities of an enterprise application, even if these necessities are available as external add-ons to the cluster. By adding these capabilities directly to its stack, OpenShift achieves a more integrated developer experience with less overhead of managing tools.
OpenShift is built on top of Kubernetes, so it retains the basic structures of Kubernetes such as pods, replication controllers, and services. To add to these, OpenShift has some structures of its own, such as projects, routers, and container registry.
OpenShift uses projects to contain the application. A project is a Kubernetes namespace with added developer access controls. Routers are used to expose a service in our cluster to be used from a hostname, i.e. a website. The router is optional and can be plugged in as a layer on OpenShift architecture.
OpenShift has 4 flavors, suited to different needs of developers and enterprises:
- OKD: The Origin Community Distribution of Kubernetes: The open source project behind OpenShift.
- OpenShift Container Platform: An enterprise-grade distribution of Kubernetes that can be deployed in a customers data center or on the public cloud.
- OpenShift Dedicated: Private OpenShift cluster built and maintained by Red Hat.
- OpenShift Online: Public OpenShift cluster built and maintained by Red Hat, geared towards the everyday developer.
Some core advantages OpenShift provides to its users are:
- Ease of Use
- CI/CD: Automated continuous delivery and continuous deployment.
- Security
Ease of Use
Even though it abstracts away some complications of Kubernetes and container management, OpenShift is still a big platform with numerous different features and sides to think about. Since the command line may be unfamiliar to some people and can be generally hard to use, OpenShift provides a single interface that covers all aspects.
This dashboard, also called the web-based console, lets users easily create and manage applications, scale their services with a single click, and review their application state in different charts.
The dashboard allows users to see applications pane for managing deployments and pods, builds pane for image streams, resources pane for checking quota consumption, storage for managing persistent volume usages and requests. Also embedded is the monitoring tab with logs for builds, pods, and deployments.
CI/CD and Automation
Continuous integration and continuous deployment pipelines are one of the main features of OpenShift. OpenShift leverages Jenkins to help users build deployment pipelines and automate their operations.
OpenShift allows specifying Jenkins triggers. Whenever source code that powers the applications or the ImageStream that specifies the images to build the applications changes, Jenkins jobs can be triggered. This automates the process of continuous integration and deployment to a higher level.
For image builds, OpenShift provides Docker build and Source-to-Image options. While Docker build is the conventional way of creating images, S2I presents an easier, automated, more secure way.
Source-to-Image (S2I)
S2I is a very exciting feature that OpenShift provides. It’s a tool integrated into OpenShift that enables building reproducible Docker images from source without creating Dockerfiles. S2I provides high performance and secure Docker images, which would require some effort on the developer side to ensure via Dockerfiles.
Well, how does it work? For S2I to take your source code and create a Docker image, you have to specify a builder image, that consists of the language runtime and tools that you need, and an assemble script that injects your source code into the application.
With S2I, you can create builder images that have all your dependencies, and use these images for creating new Docker images, so that you have shorter periods of building as the dependencies are already within the builder image that you’re using.
With S2I, any existing Docker image can be adapted into the workflow. This enables an ecosystem of reusable builder images that can be further used for creating new Docker images.
Security
Security solutions are built into OpenShift clusters by design.
Containers are isolated processes that run on the same host. Just as with process security, a principle of least privileges is vital. Containers should not run as root. OpenShift combines this principle with other tools that ensure container security inside the host: Linux namespaces that gives the level of abstraction to containers to make it seem as they are running inside their own OS, Cgroups that regulates resource usage for containers, SELinux for ensuring isolation, and seccomp to restrict system calls for containers.
As mentioned before, encompassing Kubernetes namespaces as projects adds a layer of security by enforcing an additional authentication step. This step depends on user or group authorizations. Projects provide multi-tenancy and allow for specific privileges for certain users or groups.
Inside one’s own cluster, OpenShift provides its own private container registry for controlling access to containers, while also supporting integrations with other private registry tools.
As discussed before, using S2I during container build also ensures security in the resulting containers. Either when using builder images to build on top of, or when duplicating outside images, OpenShift points the way with certified images that are marked as secure by Red Hat.
Conclusion
OpenShift brings together numerous tools and best practices to deliver an easy container application platform to developers. OpenShift, both as an open source project and as an enterprise solution, is on its way to becoming a fixture in the era of container-based development.
If you want to start experimenting with OpenShift, you can check out Minishift, or OpenShift’s interactive learning portal.
Further Reading:
OpenShift for Developers – A Guide for Impatient Beginners
