preface statement: manageing OpenStack & SoftLayer resource with Jumpgate
1,forward;
Imagine a world of interconnected Clouds capable discovering, coordinating and collaborating in harmony to seamlessly carry out complex workloads in a transparent manner -- the intercloud . While this may be the dream of tomorrow, today's reality is a form of the intercloud called hybrid Cloud . In a hybrid Cloud model organizations manage a number of on-premise resources, but also use off-premise provider services or resources for specific capabilities, in time of excess demand which cannot be fulfilled via on-premise resources, or for cost effectiveness reasons. Both of these Cloud computing models have a common conduit to their realization -- open standardized APIs, formats and protocols which enable interoperability between disparate Cloud deployments.
Enter OpenStack
-- a rapidly growing open source Cloud framework which removes
vendor lock-in by providing open, vendor agnostic APIs. OpenStack
consists of a number of distributed, scale-out ready services which
allow organizations to build Cloud solutions in a more cost effective
manner. Just as the name implies OpenStack is open source, open design
and open teaming / leadership. As shown in a 2013 Forrester study
, collectively OpenStack becoming the most popular private Cloud of choice (see diagram below).
SoftLayer is the premier Data Center and hosting provider in the industry today offering numerous pre-built managed services and solutions to fit many needs -- from web hosting to private hosted Clouds -- SoftLayer is the right choice. Not only does SoftLayer provide soft services, but they also offer fully dedicated bare metal hardware suitable for the most demanding workloads. SoftLayer also supports a comprehensive set of native APIs allowing developers and operators to take programmatic control over their resources. Wouldn't it be great if you could use OpenStack APIs with SoftLayer? As luck would you have it, you now can.
The folks over at the SoftLayer innovation team recently released a new open source project called Jumpgate
. With Jumpgate you can use a number of your favorite OpenStack
tools and APIs to bridge directly into SoftLayer. For example you can
use the OpenStack nova CLI and APIs to boot SoftLayer virtual compute
servers, or the OpenStack glance CLI to manage SoftLayer based images.
You can even use the OpenStack Horizon dashboard to graphically manage a
number of your SoftLayer resources including virtual servers and
images.
In this article we'll cover the following topics:
- An overview of Jumpgate including its high level architecture.
- Step-by-step instructions on how to install and configure Jumpgate including creating an upstart job to manage Jumpgate as a service.
- Detailed instructions on how to install and use the OpenStack nova CLI with Jumpgate.
- A guide to setting up the OpenStack Horizon web-based dashboard with multiple regions so that you can manage SoftLayer resources from a single pane of glass.
2,Introducing softLayer Jumpgate
Jumpgate is an open source project started by the folks over at SoftLayer innovation labs which aims to bridge the gap between OpenStack native APIs and other proprietary vendor APIs -- an API adapter proxy if you will. Jumpgate is implemented in the Python programming language as a WSGI application and thus runs as a web based service. As a fully compliant python WSGI application, Jumpgate can be hosted via a Python server such as gunicorn or fronted by your favorite web server with WSGI support such as Apache with mod WSGI or nginx with NgxWSGIModule .
From an architectural perspective Jumpgate is stateless (no
persistence) and lightweight making it easy to scale out suiting the
needs of many deployment scenarios. Under the covers Jumpgate is
pluggable, allowing you to easily snap-in or snap-out both request and
response middleware "hooks" and service drivers.
Jumpgate request and response hooks permit you to write and
plug-in Python code which can work with requests and responses as they
enter / leave the Jumpgate application. For example you could easily
implement a hook to support API rate limiting or fully featured request
auditing. Out of the box Jumpgate includes a number of pre-built hooks
including logging and authentication.
Jumpgate service drivers provide the functionality needed to
translate OpenStack native API requests into native APIs requests and
back again as OpenStack compliant responses. Think of these drivers as
adapters. These drivers are pluggable per OpenStack service endpoint
supported by Jumpgate -- image, compute, network, identity, etc..
Out of the box Jumpgate provides a set of SoftLayer drivers
which allow you use a number of OpenStack client side tools immediately
with SoftLayer Jumpgate. It's also possible to implement and snap-in
your own drivers to support bridging between OpenStack APIs and your
native API.
From and identity perspective, Jumpgate also includes a number of
other plug points providing maximum flexibility for your solution needs.
For example the Keystone compliant service catalog
served by Jumpgate is based on a template file which look much like the Keystone default catalog
. These endpoints can be modified to suit your needs and you can
also plug in other remote service endpoints you wish Jumpgate to expose
in the service catalog. Jumpgate also includes pluggable token and
authentication drivers allowing you to control how authentication
requests are fulfilled, as well as how tokens are structured, encoded
and decoded.
The diagram below depicts the high level architecture of Jumpgate.
On the left side of the diagram the generic form of Jumpgate is
illustrated whereas on the right the SoftLayer specific drivers which
realize the bridge are shown. You can also check out Nathan Beittenmiller's SoftLayer blog on Jumpgate
.
From a development perspective, Jumpgate is a young active project which is growing / enhanced daily. As such, not each and every OpenStack API is supported with the out of the box SoftLayer drivers today. Instead, the most common OpenStack APIs were selected and initially implemented with additional APIs being added incrementally until the bridge is sufficiently supported. For a more complete list of the APIs supported, see the "compatibility matrix" on the Jumpgate developers page . That being said, please do file issues if you run into any bugs or if you have feature requests. Moreover, we are always looking for contributions so if you are feeling Pythonic please help out by following the contributors guide .
Let's now move to the hands-on instructions and get Jumpgate running.
3,Installing & Setting up Jumpgate
For this guide we'll be setting up Jumpgate and related components on a SoftLayer Cloud Computing Instance (CCI) which is running the Ubunutu 12.04 Operating System. However, you could just as easily provision Jumpgate off-premise SoftLayer as the SoftLayer API (SLAPI) endpoint is public facing and reachable over the public network. Moreover a number of the exact commands shown here are Ubuntu specific (i.e. apt-get , initctl , etc.), but they can easily be translated into your distro of choice.
In the steps that follow I will provide snippets from my
terminal which include my shell prompt, followed by the exact command(s)
run. I will also show an abbreviated section of the command's output
using "
...
" to indicate additional output is removed for brevity. I tend run multiple commands on a single line using the bash
&&
operator. This operator can be used to chain multiple commands on a single line and indicates
bash
should execute the commands left-to-right, one-by-one only
running subsequent commands in the chain if the previous executes
successfully. If a command should fail, you can address the failure and
run the remaining commands one-by-one. Finally I'm performing all steps
in this guide as a non-root user and thus use
sudo
to execute commands as root.
Before you begin
In order to prepare for the Jumpgate installation and setup, take a moment to consider the topology you wish to realize with this solution. In particular consider the following questions:
- Will the components consuming Jumpgate be located on the same host as Jumpgate, or will they be remote?
- If the components consuming Jumpgate are remote, which IP / interface will they be using to communicate with Jumpgate?
- Which port will Jumpgate bind to on your host system? If you are planning to run OpenStack Keystone on the same system using Keystone's default ports, you will need to select a different open port for Jumpgate to bind on.
As a result of the questions above, you will need to determine
the IP address Jumpgate will bind and listen on. If your solution will
always have the Jumpgate consumers on the same host, you may choose to
bind Jumpgate to the loopback IP of your host (localhost, 127.0.0.1) and
thus not expose it externally. However if your Jumpgate consumers will
be remote, you may want to restrict their access to the private IP of
your host in which case Jumpgate would bind to the private IP / network.
The IP address you wish to bind Jumpgate on is referred to as the
JUMPGATE_IP
in the instructions below. Any place you see
JUMPGATE_IP
, substitute the IP Jumpgate will bind to.
Likewise the port you will bind Jumpgate to is referred to as
JUMPGATE_PORT
below. Substitute your selected Jumpgate bind port accordingly.
Install Prerequisites
The first thing we need to do is to install some prerequisites (dependencies) needed by Jumpgate and it's python requirements. Note that NTP is not required by Jumpgate, but my preference is to keep server times in sync and thus I illustrate its setup here.
