Search The New Stack
 
Cloud Native Ecosystem / Sponsored

The Apache Brooklyn Plugin for Cloud Foundry to Add Services Such as MongoDB

23 Mar 2015 8:03am, by
Apache Brooklyn is a platform for integrating services across multiple data centers. Cloud Foundry is a platform as a service (PaaS) for to deploy, run and scale applications. In part one of the series, the Cloudosft team showed how a user creates and use services for Cloud Foundry using the Brooklyn Service Broker for Cloud Foundry. In this post, Cloudsoft demonstrates how the Brooklyn Plugin for Cloud Foundry lets the developer create and manage services directly using cf. Part one and part two of this multi-part series originally appeared on the Cloudsoft blog.  The series will continue with how to use Apache Brooklyn and Cloud Foundry to deploy a wide range of Brooklyn blueprints, such as Cassandra, Couchbase, ActiveMQ and Kafka.  

The Brooklyn plugin allows you to:

  • Add new Brooklyn blueprints to the service catalog.
  • Create new services as part of your application’s manifest.
  • Get information and invoke effectors on running service instances.

If you are using CLI version 6.10+ you can install the plugin using plugin discovery with the community repository:

Otherwise, you can get a binary with your web browser from the community site and follow the post-build install instructions below.

You can also compile from the source code. To begin, set up your environment to develop Cloud Foundry plugins as described here, then build the plugin:

Next install the plugin in Cloud Foundry:

Good! Now let’s do something cool.

Adding Catalog Items

Recall that in part 1 we added catalog items to Brooklyn through the Brooklyn Web console and then instantiated them through Cloud Foundry, but with our plugin we can submit catalog items through the Broker using cf. So, let’s make a Brooklyn catalog blueprint for MongoDB and save it in, say, catalog.yml:

And add it with the add-catalog command:

Good, now when we refresh the Brooklyn service broker the service will be available:

Nice. All you need to do is enable it as before.

To delete catalog items, simply use delete-catalog:

Specifying Services in the Application’s Manifest

Until now, creating services and binding them, even with the Brooklyn service broker, is still way too manual, right? Some services are an integral part of your application; for these, we can automate creating a service and binding by just specifying it in the manifest.yml file:

With this manifest, Cloud Foundry with Brooklyn will create a new MongoDB instance and bind it with the instance id mongodb as if it had been created prior and added to the services section of a traditional manifest:

We can do even better. We can automate adding to the broker’s catalog, too, by specifying Brooklyn blueprints directly in the manifest:

That’s pretty cool. We no longer need to have the service broker advertising its catalog, just give it a blueprint for what you want, Brooklyn will create it, and the service broker will bind it to your application.

N.B. When you push your app in this way, it can occur that the binding is performed before the service is ready to use. This is a known issue we are working on. In the meantime, if this happens you can unbind the service and push again so your application can access the updated VCAP_SERVICES variable which contains sensor data that your application may need:

How do we know when our service is ready to bind? We can look at the sensor output using the plugin.

Viewing Sensors

You can find out about your running services by getting sensor data from Brooklyn with the following command:

There are a number of sensors that are unique to the type of service deployed, but, in this case, we are mostly interested in service.process.isRunning. Your application will also have used host.address and mongodb.server.port which will have become available once the service is running.

Effectors

Likewise you can view effectors:

And of course you can invoke these effectors! Notice that they are listed hierarchically with the indentation showing to which entity the effector belongs, using the Brooklyn ID so that you can unambiguously invoke them:

Parameters can be passed simply by prepending “–” to each parameter name, followed by the desired parameter value.

Video

To wrap up this post, once again, here is a video of our plugin in action:


Sneak Peak

Running and restarting a single MongoDB instance isn’t that exciting, but the exact same process works for any blueprint, from a Hadoop-Storm-Kafka platform to a set of Couchbase clusters replicated across multiple clouds.

In part 3 we will demonstrate much more interesting service topologies using the service broker and plugin building blocks you’ve just installed and discuss next steps for this work.

Feature image via Flickr Creative Commons.

Cloudsoft is a sponsor of The New Stack.