Brooklyn supports a very wide range of target locations. With deep integration to Apache jclouds, most well-known clouds and cloud platforms are supported. See the Locations guide for details and more examples.
The following example is for Amazon EC2:
name: simple-appserver-with-location location: jclouds:aws-ec2: region: us-east-1 identity: AKA_YOUR_ACCESS_KEY_ID credential: <access-key-hex-digits> services: - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
(You’ll need to replace the
credential with the
“Access Key ID” and “Secret Access Key” for your account,
as configured in the AWS Console.)
Other popular public clouds include
Private cloud systems including
cloudstack are also supported,
although for these you’ll supply an
client/api/ in the case of CloudStack) instead of the
“Bring Your Own Nodes” (BYON) Example
You can also specify pre-existing servers to use – “bring-your-own-nodes”. The example below shows a pool of machines that will be used by the entities within the application.
name: simple-appserver-with-location-byon location: byon: user: brooklyn privateKeyFile: ~/.ssh/brooklyn.pem hosts: - 192.168.0.18 - 192.168.0.19 services: - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
Single Line and Multi Line Locations
A simple location can be specified on a single line. Alternatively, it can be split to have one configuration option per line (recommended for all but the simplest locations).
For example, the two examples below are equivalent:
location: byon(name="my loc",hosts="126.96.36.199",user="bob",privateKeyFile="~/.ssh/bob_id_rsa")
location: byon: name: "my loc" hosts: - "188.8.131.52" user: "bob" privateKeyFile: "~/.ssh/bob_id_rsa"
Specific Locations for Specific Entities
One can define specific locations on specific entities within the blueprint (instead of, or as well as, defining the location at the top-level of the blueprint).
The example below will deploy Tomcat and JBoss App Server to different Bring Your Own Nodes locations:
name: simple-appserver-with-location-per-entity services: - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server location: byon(hosts="192.168.0.18",user="brooklyn",privateKeyFile="~/.ssh/brooklyn.pem") - type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server location: byon(hosts="192.168.0.19",user="brooklyn",privateKeyFile="~/.ssh/brooklyn.pem")
The rules for precedence when defining a location for an entity are:
- The location defined on that specific entity.
- If no location is defined, then the first ancestor that defines an explicit location.
- If still no location is defined, then the location defined at the top-level of the blueprint.
This means, for example, that if you define an explicit location on a cluster then it will be used for all members of that cluster.
Some entities are written to expect a set of locations. For example, a
create a member entity in each location that it is given. To supply multiple locations, simply
locations with a yaml list.
In the example below, it will create a cluster of app-servers in each location. One location is
used for each
DynamicCluster; all app-servers inside that cluster will obtain a machine from
that given location.
name: fabric-of-app-server-clusters locations: - aws-ec2:us-east-1 - aws-ec2:us-west-1 services: - type: org.apache.brooklyn.entity.group.DynamicFabric brooklyn.config: dynamiccluster.memberspec: $brooklyn:entitySpec: type: org.apache.brooklyn.entity.group.DynamicCluster brooklyn.config: cluster.initial.size: 3 dynamiccluster.memberspec: $brooklyn:entitySpec: type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
The entity hierarchy at runtime will have a
DynamicFabric with two children, each of type
DynamicCluster (each running in different locations), each of which initially has three
For brevity, this example excludes the credentials for aws-ec2. These could either be specificed in-line or defined as named locations in the catalog (see below).
Adding Locations to the Catalog
The examples above have given all the location details within the application blueprint. It is also possible (and indeed preferred) to add the location definitions to the catalog so that they can be referenced by name in any blueprint.
For more information see the Operations: Catalog section of the User Guide.
For simplicity, the examples above have included the cloud credentials. For a production system, it is strongly recommended to use Externalized Configuration to retrieve the credentials from a secure credentials store, such as Vault.
Use of provisioning.properties
An entity that represents a “software process” can use the configuration option
provisioning.properties to augment the location’s configuration. For more information, see