In this section we will discuss OpenShift at a very high level, showing certain components of the backend, explaining a little about how everything fits together and how it works, without getting too much in depth with each. That level of granularity will be explored in later sections and might not be applicable to everyone's interests.
OpenShift—a bird's-eye view
Following the preceding diagram, we will walk through the path where traffic will flow, starting with the perspective of a user utilizing the OpenShift Client Tools. From there, we will proceed by stepping through the components so that we can get a basic feel of the way the platform works before diving deeper into the individual levels. Both the DNS server and the MongoDB system will not receive much focus at this time as DNS and database servers are conceptually extremely widespread technologies and this is meant to be a high-level discussion; they will, however, receive focus in later sections. OpenShift is written in the Ruby programming language (http://www.ruby-lang.org) using the very popular Ruby on Rails (http://rubyonrails.org/) web framework. This will be noteworthy for any reader who may be interested in joining the OpenShift Origin upstream development community.
Note
Ruby is an open source, multi-platform, object-oriented programming language that has gained considerable popularity in recent years, especially in the realm of web development in large, thanks to the Ruby on Rails web framework, which is also open source. More information on each of these, respectively, can be found at http://www.ruby-lang.org/en/http://rubyonrails.org/.
The layer where OpenShift users will spend most of their time developing or hosting their web application is the client tools. The client tools will communicate with the server known as a broker, which we will cover shortly. Within the category of client tools, there are a number of options: first is the command-line interface that is distributed as a RubyGem. The Gem itself is distributed on https://rubygems.org/gems/rhc, and more information about it and its code base can be found on GitHub (https://github.com/openshift/rhc/).
Note
A RubyGem is a package management format that is the standard for distributing and consuming software, and software libraries written in the Ruby programming language. These packages are often repackaged into GNU/Linux distribution's native package format such as rpm or deb so that it can be easily deployed and installed. For more information about RubyGems, visit https://rubygems.org/.
Aside from the RubyGem version of the command-line client tools, there are also various Integrated Development Environments (IDEs) that offer integration as well as the Web Console, all of which allow for the developer to utilize the OpenShift platform. At the time of this writing, the Red Hat JBoss Developer Studio, which is an IDE from Red Hat based on Eclipse (https://devstudio.jboss.com), an Eclipse plugin, and the Zend Studio IDEs, offer OpenShift client-integration plugins. However, it should be noted that no matter the utility, all end user tools utilize the Representational State Transfer Application Programming Interface (REST API) on the backend. This will be covered in more detail later.
Interaction with OpenShift happens through the broker. This component of OpenShift can be thought of as the facilitator, as it handles REST API calls and translates them into actions. These actions can be DNS updates, user authentication, or an application action such as creation, deletion, or other state changes. When these actions are sent to the broker, it will make its decisions and utilize a message-passing mechanism to instruct other components within OpenShift to carry out a task. Depending on the task required, the broker will send a message such as the following to a supporting system:
Name server record updates
Application state transition
User authentication
Node tasks: performing actions against a user's application environment
When an OpenShift user creates an application, they do so within a container that has been titled as Gear, and multiple OpenShift gears will live on a single Node. Multiple nodes can exist in an OpenShift environment, but the important point to be observed here, which makes the OpenShift PaaS unique, is that it's multitenant at the operating system level or at the platform layer, which offers high density. These nodes are the work horses. This is where the applications run, the databases run, the Git repositories live, as well as what is known as a Cartridge will execute (more on cartridges later), and the location that we will land at when we SSH into our application or Gear.
