A Quick Tour of a Brooklyn Blueprint

Hover over an element to learn more
This message will go away in 3s
Describe your application

Start by giving it a name, optionally adding a version and other metadata. The format is YAML -- a human-friendly extension to JSON -- following the CAMP standard.

Treat it like source code: use comments, version control it, test it with CI.

# java chatroom with ruby chatbot and couchbase backend (example) name: Chatroom with Chatbot services:
Compose blueprints

Choose your building blocks from a large curated catalog, and compose them together to form new blueprints you can deploy and share.

Customize with config keys, such as the initial size and, for Couchbase, the data buckets required.

- type: couchbase-cluster initialSize: 3 createBuckets: [{ bucket: chatroom }] id: chat-couchbase
Run scripts and recipes

Use bash, with variables supplied by Brooklyn; or Chef recipes, with attributes passed from config; or package managers, dockerfiles, etc.

- type: bash-server launch.command: | wget http://example.com/couchbase-chat/chat-bot/{server.rb,Gemfile,install_ruby_and_libs.sh} bash install_ruby_and_libs.sh ruby ./server.rb $COUCHBASE_URL
Inject dependencies

Connect entities with each other using sensors published at runtime to give just-in-time resolution for shell variables, template expansion, REST calls, and any other "happens-before" or "on-change" behaviour.

shell.env: COUCHBASE_URL: $brooklyn:entity("chat-couchbase"). attributeWhenReady("couchbase.cluster.connection.url")
Configure locations

Give generic VM properties or specific images and flavors. Networking topologies and geographic constraints are also supported.

provisioning.properties: osFamily: ubuntu minRam: 4gb
Extend using Java

Create new entities, policies, and "effector" operations using Java or JVM bridges to many languages, workflow systems, or PaaSes.

Add new blueprints to the catalog, dynamically, with versions and libraries handled under the covers automatically with OSGi.

- type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster:1.1.0 war: http://example.com/couchbase-chat/chatroom.war java.sysprops: chat.db.url: $brooklyn:entity("chat-couchbase").attributeWhenReady("couchbase.cluster.connection.url")
Attach management logic

Set up policies which subscribe to real-time metric sensors to scale, throttle, failover, or follow-the-{sun,moon,action,etc}. Cloud should be something that applications consume, not people!

brooklyn.policies: - type: autoscaler brooklyn.config: metric: $brooklyn:sensor("webapp.reqs.perSec.windowed.perNode") metricLowerBound: 400 metricUpperBound: 600
Run across many locations

Blueprints are designed for portability. Pick from dozens of clouds in hundreds of datacenters. Or machines with fixed IP addresses, localhost, Docker on Clocker, etc.

And you're not limited to servers: services, PaaS, even networks can be locations.

location: jclouds:aws-ec2: region: us-east-1 identity: AKA_YOUR_ACCESS_KEY_ID credential: [access-key-hex-digits]