A Quick Tour of an AMP Blueprint

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 AMP; 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 Amazon or Azure or any of dozens of clouds. Or containers, VMware, physical servers, 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]