Chapter 3. OpenShift – Technologies and Working
In Chapter 2, Using OpenShift, we discussed how to use OpenShift from an end user perspective, as a developer or web application administrator who might utilize OpenShift as an auto-scaling hosting environment. This chapter will take a deeper look into the technologies that drive OpenShift from the backend. The material we will cover in the following sections may not interest all parties, but those interested in what makes OpenShift tick should feel encouraged to read on and take a peek behind the curtains. Also, those who aim to deploy or host their own OpenShift Origin or Enterprise infrastructure, are likely find the information within the following sections of interest.
Before we delve too far into OpenShift nomenclature and inner workings, we should be sure and spend some time discussing the technologies that OpenShift relies upon. In the following sections, we cover what OpenShift utilizes in order to deliver its user experience, along...
Pluggable Authentication Modules for Linux
The first technology we're going to discuss is Pluggable Authentication Modules (PAM) for Linux, which is a set of libraries that offers a single point of authentication for Linux-based operating systems. This is effectively the backend upon which privilege escalating utilities within the system will hand over the responsibility of authentication in a dynamic and configurable fashion. System administrators are able to modify the way different sessions and services authenticate the system using module configurations. Through the use of modules, PAM makes each of the following authentication functions separately configurable:
OpenShift uses this mechanism and has developed a custom PAM module that assists in providing the multitenant nature of OpenShift gears.
Note
The source code for the OpenShift PAM module is also available as part of the origin-server Git repository found...
The second technology we will spend some time covering in this chapter is called Security Enhanced Linux (SELinux). This is a security technology originally developed by the United States National Security Agency to bring a heightened level of security capabilities to the Linux kernel. As an overview, this technology, best described as an upstream project at http://www.nsa.gov/research/selinux/index.shtml explains,
"NSA Security-enhanced Linux is a set of patches to the Linux kernel and some utilities to incorporate a strong, flexible mandatory access control (MAC) architecture into the major subsystems of the kernel. It provides an enhanced mechanism to enforce the separation of information based on confidentiality and integrity requirements, which allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications. It includes a set of sample security policy configuration...
The Linux kernel contains a large number of features, one of which is Control Groups (cgroups), which are kernel level constructs that allow for resource constraints. This is the mechanism upon which OpenShift is able to limit resources per application gear, and is combined with SELinux in order to offer the functionality of multitenancy at the Operating System level instead of relying on a form of virtualization or IaaS cloud.
For topics on Linux kernel documentation, there are a few places more authoritative than the official documentation that comes with the kernel source code; therefore, we shall refer to the discussion of cgroups definitions from a definite source:
"Definitions:
A *cgroup* associates a set of tasks with a set of parameters for one or more subsystems.
A *subsystem* is a module that makes use of the task grouping facilities provided by cgroups to treat groups of tasks in particular ways. A subsystem is typically a "resource controller" that schedules a resource or...
When working with GNU/Linux distributions, there are different life cycles of the code base contained in their package set, which can require special considerations for deployment of package sets that deviate from what is shipped in the official repository of our distribution. The examples of Enterprise Linux distributions are Red Hat Enterprise Linux, CentOS, and Scientific Linux, where the core operating system's package set is maintained to be stable, controlled, and predictable for the 10-year lifecycle of the code base. Refer to https://access.redhat.com/support/policy/updates/errata/. This comes with some implications based on how to effectively introduce updated package sets without compromising the stability and consistency of the core platform upon which we rely. This is where Software Collections come in. Software Collections is a system in which we can maintain namespaces for rpm package sets and enable them at will without affecting the system itself. This...
Marionette Collective (MCollective) is an open source framework for server orchestration and parallel job execution across an environment of distributed systems, written and developed by Puppet Labs. It leverages either STOMP compliant or AMQP message-passing mechanisms in the background, and provides an easy-to-use and consistent set of commands, as well as an API that will assist in the facilitation of almost anything needed between a distributed set of servers. More information about MCollective can be found at http://docs.puppetlabs.com/mcollective/index.html.
With an understanding of the background technologies that provide a functionality offered in OpenShift, we need to revisit the notion of applications and gears. When we use command-line client utilities, a web administration console, or IDE integration to create an application, it creates one or many gears for our Application. Remembering that this Gear is a resource container constrained with cgroups and confined by SELinux, we can conceptually think of this as our "slice" of the Operating System; within this slice will be our cartridges. We've covered cartridges previously, but as a reminder, these are effectively the puzzle pieces with which we assemble the platform for our web applications, such as language runtimes, databases, and the plugin functionality. A single OpenShift application can consume multiple OpenShift gears in different scenarios, the most common of which is in the situation of an auto-scaling event. The following diagram demonstrates this relationship...
The OpenShift architecture overview
The preceding diagram offers an overview of the OpenShift architecture. In the following sections, we will be discussing how each component fits together and how they function. At this point, we should travel through a workflow and visit the different points along the path our code travels, and take small detours from the main data flow in order to spend time covering events that occur along the way, as follows:
At the starting point, we would be using some sort of end user interface of the OpenShift service and for the sake of the example, let's assume that choice is the command-line client utilities. When we run an rhc command, the utilities on the backend make a REST API call to Broker as Broker is the central point of orchestration for the service.
Note
We will discuss REST API in a later section.
Let's take a moment to walk through an example of an action we would perform with the rhc command-line utility and discuss what will happen...
In the previous sections, we have mentioned a REST API in passing, but we will now explore the topic. For those not familiar, REST API is an acronym for Representational State Transfer Application Programming Interface. This is a model in which a request of a URL constitutes a state transition, and the response from the server after processing this request is a representation of the resource that exists at the other end of the URL. The REST model is closely related to HTTP capabilities and mirrors its functions, such as GET, POST, PUT, and DELETE. Using this, we are able to interact with our service or resource without a hard requirement on a specific programming language binding, because as long as there's an HTTP capability, we are able to utilize the API. Almost all programming languages have this built-in functionality and it even allows us to utilize resources via command-line utilities that provide HTTP functionalities, such as curl.
We will use the curl utility in order...
In this chapter, we have explored what makes OpenShift tick, covering the technologies upon which it depends, such as SELinux, Cgroups, and in some deployments, Software Collections. From there, we looked at an overview of the OpenShift architecture and broke it down piece by piece to discuss how each component works in its own right, as well as all together in order to make a fully functional platform. This level of understanding will be extremely helpful as we move forward to the next chapter and discuss topics of DevOps and automated deployment.
