Laying the Foundation: Broker Back End Services

An OpenShift Origin service depends on a number of moving parts to work.  The broker in particular requires four different back end services to be in place and configured before the broker itself can be set up and tested.

This post is the first of a series that will detail how to set up the back end services needed by an OpenShift Origin service.

Background

The purpose of an OpenShift Origin service is to provide a means for application developers to quickly create and deploy web applications (loosely defined).  The service can have multiple users who must be given the resources they need, but not the ability to effect other user's information or applications.  The user and application information must be stored and accessed by the OpenShift Origin service.  The controlling part of the Openshift Origin service (the broker) must be able to communicate with the parts that actually contain the user's application processes and data (the nodes).  Finally the Openshift Origin service must be able to publish the locations of the user applications as they are created.

This means that the broker must have the means to perform these abstract functions:

• User Identification and Authentication
• Data Storage
• Messaging
• Publication (DNS)

These functions are performed on behalf of the OpenShift Origin service by external or back end services. All of these services must be prepared before the OpenShift Origin broker can be configured.

The broker service integrates with each of these services through a plugin for the service.  As of the writing of this post each back end service has only one plugin.  Over time additional plugins can be added to allow integration with different back end service implementations.

Information Gathering

The Openshift Origin components and back end services can reside on different hosts on your network or even across the internet.  For this series I'm going to work with a single RFC1918 network segment.  I'm going to use two DNS domains, or more properly a top level domain and a sub-domain.  The top level domain will contain the DNS names for the service hosts.  The sub-domain will be used to publish the applications.

For this demonstration each of the services will reside on a different host.  This is to make the boundaries of each service clear.  They can co-exist on fewer hosts or even all on a single host if that suits your needs.

Openshift Origin Service Hosts

Function	Hostname	IP Address	Implementation
Broker	broker1.example.com	192.168.5.11
Name Service	ns1.example.com	192.168.5.2	Bind 9
Data Store	data1.example.com	192.168.5.5	MongoDB
Messaging	msg1.example.com	192.168.5.8	ActiveMQ/Stomp
Node	node1.example.com	192.168.5.21
	node2.example.com	192.168.5.22

You don't see a host there for authentication because the authentication is done by an apache mod-auth-* module which is configured in the apache server on the broker. Configuring the various mod-auth modules is already well documented. For this demonstration we'll use Basic-Auth and an htpasswd file on the broker host.

We're going to install the back end services first, beginning in the next post with the Bind 9 name service.