Cloud Native / Sponsored

Cloud Foundry and Apache Brooklyn for Automating PaaS with a Service Broker

11 Mar 2015 8:00am, by

This post originally appeared on the CloudSoft blog to demonstrate how Cloud Foundry integrates with Apache Brooklyn, a platform for integrating services across multiple data centers. It is the first in a series of blog posts that covers how CF is used with a wide range of Brooklyn blueprints, such as Cassandra, Couchbase, ActiveMQ and Kafka, across enterprise and cloud service environments. Part two in the series covered how to use the Brooklyn plugin to integrate Cloud Foundry with Apache Brooklyn.

 

Cloud Foundry is a platform as a service (PaaS), making it easy to deploy, run, and scale applications on top of a host of runtime frameworks.

Apache Brooklyn is an application blueprint and management system which supports a wide range of software and services in the cloud.

In this post we will learn about the service broker in the Cloud Foundry ecosystem. We will explore how this modular component bridges the gap between service providers and the CF tooling. The next post will cover a CF plugin that makes it simple to specify services in your application manifests, so you can create them and bind them to your application with one command. After that, we will give some examples, including a sharded MongoDB instance in your manifest for a truly scalable application and a Riak cluster.

The Service Broker

The Service Broker component in CF allows developers to decouple their apps from the services that they consume. The cf create-service command calls to the broker to create a new instance of a service. You can then include a reference to this service instance in your application’s manifest, or manually issue a bind-service, to associate it to one or more applications. CF will then automatically inject details of the service instance — such as the URL and credentials for consuming it — into your application’s runtime.

v2services-new

Until now, most service brokers have dealt with a single type of service, requiring a lot of up-front investment to make a new service available in CF and limiting the degree to which these services can be customized when needed for applications.

By making Apache Brooklyn available as a service broker, however, you only need one broker to expose the broad catalog of existing Brooklyn blueprints. And adding new services is as simple as POSTing a blueprint to the Brooklyn catalog.

Let’s start by installing the Brooklyn Service Broker. You’ll need Java 8, git and Gradle installed, and then:

This generates a file brooklyn-service-broker.war containing the service broker.

Next we’ll need an Apache Brooklyn server. If you don’t have one, it’s easy to install following the instructions here.

Once that’s running, make a note of the brooklyn-host and brooklyn-password, and install the Brooklyn service broker WAR file to /path/to/broker-war/. Choose a broker-user and broker-password, and in the YAML below replace these five tokens with the real values. Paste the resulting blueprint into the “Add Application” dialog in your Brooklyn server, and within a minute your Service Broker should be running (usually on port 8080, but see the sensors of the Tomcat if that port is already in use).

Adding Brooklyn Services to Cloud Foundry

Next, we’ll register this Broker with Cloud Foundry. If you don’t yet have a running instance of CF, see http://docs.cloudfoundry.org/deploying/, log in to it, and then continue.

First, let’s add a service to the Brooklyn catalog so we have something to access from Cloud Foundry. In the Brooklyn GUI, select the “Catalog” tab and then click the “+” and the “entity” button and add the following service blueprint:

Now register the broker with Cloud Foundry:

The blueprint we added to Brooklyn is now visible in Cloud Foundry. It’s access is none, but all that remains is to make it available in the marketplace.

To create instances of this service, simply:

To deploy to new machines, all you have to do is change the location section of the blueprint. For instance, if we wanted a 5-node 8GB-each Riak cluster in Softlayer instead of a MySQL on localhost, we could add this to the Brooklyn catalog (replacing XXX with your SL username and access key):

Refresh the catalog, and Riak is now at your service.

Binding to Your Applications

You can now bind these service instances to your applications. If your application is already deployed, use:

This will make the following environment variables available to your application runtime:

Or, you can add it to your manifest:

And then do a cf push like normal.

Video

To wrap up this post here is a video recording of our service broker in action:

Pretty cool, eh? But what if we want to specify new services to be added to the marketplace? Well, we have a plugin just for you! Stay tuned!

Service Broker image via Cloud Foundry.

Feature image via Flickr Creative Commons.

CloudSoft is a sponsor of The New Stack.

A newsletter digest of the week’s most important stories & analyses.