Thursday, November 15, 2012

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.


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
FunctionHostnameIP AddressImplementation
Name Servicens1.example.com192.168.5.2Bind 9
Data Storedata1.example.com192.168.5.5MongoDB

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.

No comments:

Post a Comment