|author||Aled Sage <email@example.com>||Wed May 28 00:05:33 2014 +0100|
|committer||Aled Sage <firstname.lastname@example.org>||Wed May 28 00:05:33 2014 +0100|
Merge pull request #1419 from aledsage/fix/policy-persistence-20140527 Fixes in policy persistence (against branch feature/policy-persistence)
Brooklyn is a library and control plane for deploying and managing distributed applications.
See brooklyncentral.github.com for details and examples.
Brooklyn's main emphasis is managing live applications (e.g auto-scaling, exception handling, auto recovery from failure, and working across multiple clouds). Brooklyn considers deployment part of management, like the opening move in a game of chess. (Distributed-application-management-chess, no less).
Brooklyn enables single-click deployment of complex applications, while tying-in with other great tools, and reusing and complementing existing workflows.
Use Brooklyn to create an Application Blueprint, instructing Brooklyn how to wire together your applications and components, customizing and extending them as needed. Share the blueprint with others (optionally using Brooklyn's Web Service Catalog) to allow them to single-click deploy your application onto the infrastructure of their choice.
In DevOps fashion, Brooklyn allows applications and roll-outs to be version controlled, tested programatically, and reused across locations and contexts. Develop on localhost, then reuse the same application descriptor to deploy to QA, and then to your production environment.
Brooklyn enables autonomic management of applications. (i.e. many small, local, distributed control loops).
Management policies can be attached to every component part in an application, and to logical groupings of components (clusters, fabrics). Policies can implement both technical and non-technical (business) requirements.
At runtime, policies have access to all aspects of the deployment, including deployment topology (hierarchical) and locations (machines, PaaSes, and jurisdictions), as well as scripts, instrumentation, and operational goals and constraints. This means that once the application is launched, the policies are all set to keep the application running optimally, based on whatever optimally means in that context.
These deployment patterns and management policies are expressed as Java (or Groovy) classes, open-sourced here and giving you full control over what you want to happen. More importantly, however, this code can be shared, improved, and extended.
Import Brooklyn into your application to natively use its distributed management smarts. e.g. Cloudera's Certification Cluster Builder Tool.
Alternatively, use Brooklyn as an integrated-stand-alone management node for your application or bespoke platform.
Three quick start options are available:
git clone git://github.com/brooklyncentral/brooklyn.gitthen
mvn clean install.
irc.freenode.netserver, in the
Have a bug or a feature request? Please open a new issue.
Your input will be welcomed.
See the full guide to contributing on brooklyncentral.github.com.
© 2011 - 2013 Cloudsoft Corporation Limited.
Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. The licence is provided in LICENSE.md, and you may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
brooklyn is a registered trademark of Cloudsoft Corporation.