Skip to content
Permalink
Browse files
Merge apache-brooklyn/master as at commit f38fb8b
  • Loading branch information
richardcloudsoft committed Feb 25, 2021
2 parents dae7d77 + f38fb8b commit 1e0f1bea680cd0e94eaf1b47578816037ec11656
Show file tree
Hide file tree
Showing 10 changed files with 17 additions and 17 deletions.
@@ -28,7 +28,7 @@ For more about the ELK stack, please see the documentation [here](https://www.el
#### The Blueprints
-----------

There are four blueprints that make up this application. Each of them are used to add one or more catalog items to Brooklyn. You can find them below:
There are four blueprints that make up this application. Each of them is used to add one or more catalog items to Brooklyn. You can find them below:

* [Elasticsearch](example_yaml/brooklyn-elasticsearch-catalog.bom)
* [Logstash](example_yaml/brooklyn-logstash-catalog.bom)
@@ -37,7 +37,7 @@ There are four blueprints that make up this application. Each of them are used t

#### Running the example
First, add all four blueprints to the Brooklyn Catalog. This can be done by going to the "Catalog" module, then clicking the
buttom "Upload to catalog" and selecting the above blueprints (or drag-and-drop them) Once this is done, search for an
button "Upload to catalog" and selecting the above blueprints (or drag-and-drop them). Once this is done, search for an
entity called "ELK Stack". You will be able to deploy it by clicking on the "Deploy" button from the details page.
Note that you can also perform this operation from the quick launch panel on the homepage. Alternatively use the `br` Brooklyn
command line tool and add the files with `br catalog add`.
@@ -99,7 +99,7 @@ customize.command: |
The purpose of this section is to create a YAML file with all of the required configuration. We use the YAML
literal style `|` indicator to write a multi line command. We start our series of commands by using the `rm` command to remove the
previous config file. We then use `echo` and `tee` to create the new config file and insert the config. Part
of the configuration is a list of all hosts that is set on the parent entity- this is done by using a combination
of the configuration is a list of all hosts that is set on the parent entity this is done by using a combination
of the `component` and `attributeWhenReady` DSL commands. More on how this is generated later.

##### Check running
@@ -63,11 +63,11 @@ The following configuration keys can be specified for dynamic cluster:

### Effectors

Dynamic cluster has a set of effectors which allow it's members to be manipulated, these are detailed below.
Dynamic cluster has a set of effectors which allow its members to be manipulated, these are detailed below.

| Effector Name | Parameters | Description |
|---------------|-------------|-----------------------------------------------------------------|
| replaceMember | memberId | Replaces a specific member of the cluster given by it's ID |
| replaceMember | memberId | Replaces a specific member of the cluster given its ID |
| resize | desiredSize | Resizes the cluster to a `desiredSize` |
| resizeByDelta | delta | Resizes the cluster by a `delta` |

@@ -12,13 +12,13 @@ Another simple blueprint will just create a VM which you can use, without any so
{% endhighlight %}


*We've omitted the `location` section here and in many of the examples below;
*We've omitted the `location` section here and in many of the examples elsewhere;
add the appropriate choice when you paste your YAML. Note that the `provisioning.properties` will be
ignored if deploying to `localhost` or `byon` fixed-IP machines.*

This will create a VM with the specified parameters in your choice of cloud.
In the GUI (and in the REST API), the entity is called "VM",
and the hostname and IP address(es) are reported as [sensors]({{ site.path.guide }}/concepts/entities.html).
and the hostname and IP address(es) are reported as [sensors]({{ site.path.guide }}/concepts/configuration-sensor-effectors.html).
There are many more `provisioning.properties` supported here,
including:

@@ -204,15 +204,15 @@ and if you haven't yet experimented with `resize` on the cluster you might want
### Attaching Policies

Besides detecting this failure, Brooklyn policies can be added to the YAML to take appropriate
action. A simple recovery here might just to automatically restart the process:
action. A simple recovery here might be just to restart the process automatically:

{% highlight yaml %}
{% readj example_yaml/vanilla-bash-netcat-restarter.yaml %}
{% endhighlight %}

Autonomic management in Brooklyn often follows the principle that complex behaviours emerge
from composing simple policies.
The blueprint above uses one policy to triggering a failure sensor when the service is down,
The blueprint above uses one policy to trigger a failure sensor when the service is down,
and another responds to such failures by restarting the service.
This makes it easy to configure various aspects, such as to delay to see if the service itself recovers
(which here we've set to 15 seconds) or to bail out on multiple failures within a time window (which again we are not doing).
@@ -26,7 +26,7 @@ Validation test entities include:
number of different formats: a string in the form of `ip:port` or URI format; or a
`com.google.common.net.HostAndPort` instance; or a `java.net.URI` instance; or a `java.net.URL` instance.

TargetableTestComponents can be chained together, with the target being inherited by the components children. For example, a ParallelTestCase could be created that has a TestHttpCall as a child. As long as the TestHttpCall itself does not have a target, it will use the target of it's parent, ParallelTestCase. Using this technique, we can build up complex test scenarios.
TargetableTestComponents can be chained together, with the target being inherited by the components children. For example, a ParallelTestCase could be created that has a TestHttpCall as a child. As long as the TestHttpCall itself does not have a target, it will use the target of its parent, ParallelTestCase. Using this technique, we can build up complex test scenarios.

The following sections provide details on each test entity along with examples of their use.

@@ -218,7 +218,7 @@ concise DSL defined here:
* `parent`: returns the parent entity (ignores the `ID`)
* `this`: returns this entity (ignores the `ID`)
* `$brooklyn:root()` will return the topmost entity (the application)
* `$broopklyn:scopeRoot()` will return the root entity in the current plan scope.
* `$brooklyn:scopeRoot()` will return the root entity in the current plan scope.
For catalog items it's the topmost entity in the plan, for application plans it is the same as
`$brooklyn:root()`.
* `$brooklyn:formatString("pattern e.g. %s %s", "field 1", "field 2")` returns a future which creates the formatted string
@@ -250,7 +250,7 @@ elements for more information:
which use `bash` commands to install and the PID to stop and restart
* **Chef** in `ChefSoftwareProcess`: makes it easy to use Chef cookbooks to build entities,
either with recipes following conventions or with configuration in the `ServiceSpecification`
to use artibitrary recipes
to use arbitrary recipes
* `DynamicCluster`: provides resizable clusters given a `dynamiccluster.memberspec` set with `$brooklyn.entitySpec(Map)` as described above
* `DynamicFabric`: provides a set of homogeneous instances started in different locations,
with an effector to `addLocation`, i.e. add a new instance in a given location, at runtime
@@ -34,7 +34,7 @@ Sensors can be updated by the entity or associated tasks, and sensors from an en

Effectors can be invoked by an entity's parent remotely, and the invoker is able to track the execution of that effector. Effectors can be invoked by other entities, but use this functionality with care to prevent too many managers!

An entity consists of a Java interface (used when interacting with the entity) and a Java class. For resilience. it is recommended to store
An entity consists of a Java interface (used when interacting with the entity) and a Java class. For resilience, it is recommended to store
the entity's state in attributes (see `getAttribute(AttributeKey)`). If internal fields are used then the data will be lost on brooklyn
restart, and may cause problems if the entity is to be moved to a different brooklyn management node.

@@ -27,7 +27,7 @@ and manipulated by the `config:` commands, see the [Karaf documentation](https:/
To configure the Brooklyn runtime create an `etc/brooklyn.cfg` file. If you have previously used `brooklyn.properties` it follows the same
file format. Values can be viewed and managed dynamically via the OSGI configuration admin commands in Karaf,
e.g. `config:property-set`. The global `~/.brooklyn/brooklyn.properties` is still supported and has higher
priority for duplicate keys, but it's values can't be manipulated with the Karaf commands, so its use is
priority for duplicate keys, but its values can't be manipulated with the Karaf commands, so its use is
discouraged.

You can use the standard `~/.brooklyn/brooklyn.properties` file to configure Brooklyn. Alternatively
@@ -13,7 +13,7 @@ children:



So far we have gone through Apache Brooklyn's ability to *deploy* an application blueprint to a location, but this just
So far we have gone through Apache Brooklyn's ability to *deploy* an application blueprint to a location, but this is just
the beginning. Next we will outline how to *manage* the application that has been deployed.

## Applications
@@ -263,7 +263,7 @@ stop Stop the process/service represented by an ent
undeploy Undeploys the given context/artifact targetName
</pre>
To view the details for a specific effector, append it's name to the command:
To view the details for a specific effector, append its name to the command:
{% highlight bash %}
$ br application Tomcat entity tomcatServer effector deploy
@@ -283,7 +283,7 @@ The `DynamicCluster` can dynamically increase or decrease the number of members.
cluster can either be carried out manually via effectors or automatically by attaching an
`AutoScalerPolicy`.

It is configured with a `dynamiccluster.memberspec`, which defines the type and configurtion of members
It is configured with a `dynamiccluster.memberspec`, which defines the type and configuration of members
in the cluster. In our example, each is a Tomcat server with a WAR deployed at the root URL.

Deploy the app:

0 comments on commit 1e0f1be

Please sign in to comment.