My GSoC 2016
Guest blog post by: Jose Carrasco
This year, I applied for the Google Summer of Code (GSoC) 2016 program with a project called Adding PaaS support to Brooklyn. I had the pleasure to work with Apache Brooklyn Community during the summer. Through these posts, I will introduce my project and the obtained results.
Apache Brooklyn is a top-level project of the Apache Software Foundation. Brooklyn is a framework for modeling, monitoring, and managing applications through autonomic blueprints. It is able to manage provisioning and application deployment, monitor an application’s health and metrics, understand the dependencies between components and apply complex policies to manage the application. The tool provides a REST API and a GUI, and allows the autonomic blueprints to be treated as an integral part of the application.
The objective of my GSoC project is to add to Brooklyn the required capabilities to enable the management of Platform as a Service (PaaS) offerings such as CloudFoundry, Openshift, Google App Engine, AWS services, Heroku.
Once GSoC application was accepted I started to work closely with my mentor, Andrea Turli, to who I am specially grateful, while we received full support of the rest of the community.
After an initial study figuring out about different PaaS approaches, I identified CloudFoundry as the first candidate to integrate PaaS in Brooklyn for the following reasons:
It is a open source project.
It provides a most of capabilities expected by a PaaS.
It provides a clear API and a set of clients to manage them.
Several providers have built their platforms on Cloud Foundry project, Pivotal WS, IBM BlueMix, etc.
Brooklyn Community was already working with the Cloud Foundry project.
Although different from the other locations supported by Brooklyn, Cloud Foundry Service can be modelled as a Brooklyn location.
Based on PaasLocation interface, which allows a Platform-as-a-Service to be specified, we have built CloudFoundryPaasLocation to represent Cloud Foundry Platform, see Figure
location: cloudfoundry: provider: <provider name> identity: <user's account> credential: <user's password> org: <an user's organization> space: <an organization's space> endpoint: <provider api endpoint>
Each configuration corresponds to a Cloud Foundry login parameter, as you can see in the official documentation.
provider: represents the name of the provider, such as pivotal or bluemix
identity: the user name
credential: the user’s password
org: the organization where you want to deploy your apps
space: the space in the org where applications will be deployed
endpoint: this is your API endpoint, the URL of the Cloud Controller in your Cloud Foundry instance.
So, each Cloud Foundry platform provides its own endpoint.
Here is a CloudFoundryPaasLocation example that references Pivotal Web Services:
location: cloudfoundry: provider: pivotal-ws identity: <pivotal-user-name> credential: <user's password> org: <an pivotal organization> space: <an organization's space> endpoint: api.run.pivotal.io
and another example to point to IBM BlueMix:
location: cloudfoundry: provider: bluemix identity: <bluemix-user-name> credential: <user's password> org: <an user's bluemix organization> space: <an organization's space> endpoint: https://api.eu-gb.bluemix.net
Note that the endpoint is fixed for each provider, representing the Cloud Controller of each platform, Pivotal offers its controller in api.run.pivotal.io and bluemix by means of https://api.eu-gb.bluemix.net
Once location was ready, we thought about how to represent the applications in Cloud Foundry using Apache Brooklyn. Once again, we decided to go step by step, and I developed a first generic entity to represent a Cloud Foundry application, VanillaCloudFoundryApplication similar to VanillaSoftwareProcess, which provides a generic and configurable entity for representing software process. This entity allows an simple application to be described using a couple of parameters, application name, buildpack and application artifact and it requires a CloudFoundryPaasLocation to specify the target Cloud Foundry platform where the application will be deployed. Below, you can find a yaml blueprint which contains a VanillaCloudFoundryApplication sample that represents a java application that will be deployed on Pivotal Web Services.
name: Cloud Foundry Application location: cloudfoundry: provider: pivotal identity: email@example.com credential: password org: gsoc endpoint: api.run.pivotal.io space: development services: - type: org.apache.brooklyn.cloudfoundry.entity.VanillaCloudFoundryApplication id: vanilla-cf brooklyn.config: path: https://github.com/kiuby88/brooklyn-cloudfoundry/blob/master/src/test/resources/brooklyn-example-hello-world-sql-webapp-in-paas.war?raw=true buildpack: https://github.com/cloudfoundry/java-buildpack.git
This entity allows an application to be deployed, started, restarted, and removed, offering a total management of its lifecycle.
Conclusions and Next
I think the proposal opens up some interesting questions about the platform’s services integration, user's account management, the add-ons support, etc. Furthermore, the acquired knowledge would allow different technologies to be dealt with, such as Kubernetes or similar.
In the next post we are going to look at the fully Cloud Foundry manifest support for VanillaCloudFoundryApplication. Moreover, we will offer more details about the entity development, explaining used patterns and the ongoing work.
I would like to thank to GSoC organization, Apache Software Foundation and Apache Brooklyn community the opportunity and for the trust placed in me as student. Specially,I would also use this opportunity to sincerely thank to Andrea Turli his effort and help during this period.