http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/clusters-and-policies.md ---------------------------------------------------------------------- diff --git a/guide/yaml/clusters-and-policies.md b/guide/yaml/clusters-and-policies.md deleted file mode 100644 index d40c97f..0000000 --- a/guide/yaml/clusters-and-policies.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Clusters and Policies -layout: website-normal -toc: ../guide_toc.json -categories: [use, guide, defining-applications] ---- - -Now let's bring the concept of the "cluster" back in. -We could wrap our appserver in the same `DynamicCluster` we used earlier, -although then we'd need to define and configure the load balancer. -But another blueprint, the `ControlledDynamicWebAppCluster`, does this for us. -It takes the same `dynamiccluster.memberspec`, so we can build a fully functional elastic 3-tier -deployment of our `hello-world-sql` application as follows: - -{% highlight yaml %} -{% readj example_yaml/appserver-clustered-w-db.yaml %} -{% endhighlight %} - -This sets up Nginx as the controller by default, but that can be configured -using the `controllerSpec` key. In fact, JBoss is the default appserver, -and because configuration in Brooklyn is inherited by default, -the same blueprint can be expressed more concisely as: - -{% highlight yaml %} -{% readj example_yaml/appserver-clustered-w-db-concise.yaml %} -{% endhighlight %} - -The other nicety supplied by the `ControlledDynamicWebAppCluster` blueprint is that -it aggregates sensors from the appserver, so we have access to things like -`webapp.reqs.perSec.windowed.perNode`. -These are convenient for plugging in to policies! -We can set up our blueprint to do autoscaling based on requests per second -(keeping it in the range 10..100, with a maximum of 5 appserver nodes) -as follows: - -{% highlight yaml %} -{% readj example_yaml/appserver-w-policy.yaml %} -{% endhighlight %} - -Use your favorite load-generation tool (`jmeter` is one good example) to send a huge -volume of requests against the server and see the policies kick in to resize it. -
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/clusters.md ---------------------------------------------------------------------- diff --git a/guide/yaml/clusters.md b/guide/yaml/clusters.md deleted file mode 100644 index 4c1312c..0000000 --- a/guide/yaml/clusters.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Clusters, Specs, and Composition -layout: website-normal -toc: ../guide_toc.json -categories: [use, guide, defining-applications] ---- - -What if you want multiple machines? - -One way is just to repeat the `- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess` block, -but there's another way which will keep your powder [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself): - -{% highlight yaml %} -{% readj example_yaml/cluster-vm.yaml %} -{% endhighlight %} - -Here we've composed the previous blueprint introducing some new important concepts, the `DynamicCluster` -the `$brooklyn` DSL, and the "entity-spec". Let's unpack these. - -The `DynamicCluster` creates a set of homogeneous instances. -At design-time, you specify an initial size and the specification for the entity it should create. -At runtime you can restart and stop these instances as a group (on the `DynamicCluster`) or refer to them -individually. You can resize the cluster, attach enrichers which aggregate sensors across the cluster, -and attach policies which, for example, replace failed members or resize the cluster dynamically. - -The specification is defined in the `dynamiccluster.memberspec` key. As you can see it looks very much like the -previous blueprint, with one extra line. Entries in the blueprint which start with `$brooklyn:` -refer to the Brooklyn DSL and allow a small amount of logic to be embedded -(if there's a lot of logic, it's recommended to write a blueprint YAML plugin or write the blueprint itself -as a plugin, in Java or a JVM-supported language). - -In this case we want to indicate that the parameter to `dynamiccluster.memberspec` is an entity specification -(`EntitySpec` in the underlying type system); the `entitySpec` DSL command will do this for us. -The example above thus gives us 5 VMs identical to the one we created in the previous section. http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/configuring-vms.md ---------------------------------------------------------------------- diff --git a/guide/yaml/configuring-vms.md b/guide/yaml/configuring-vms.md deleted file mode 100644 index 7ae341f..0000000 --- a/guide/yaml/configuring-vms.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Configuring VMs -layout: website-normal -toc: ../guide_toc.json -categories: [use, guide, defining-applications] ---- - -Another simple blueprint will just create a VM which you can use, without any software installed upon it: - -{% highlight yaml %} -{% readj example_yaml/simple-vm.yaml %} -{% endhighlight %} - - -*We've omitted the `location` section here and in many of the examples below; -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). -There are many more `provisioning.properties` supported here, -including: - -* a `user` to create (if not specified it creates the same username as `brooklyn` is running under) -* a `password` for him or a `publicKeyFile` and `privateKeyFile` (defaulting to keys in `~/.ssh/id_rsa{.pub,}` and no password, - so if you have keys set up you can immediately ssh in!) -* `machineCreateAttempts` (for dodgy clouds, and they nearly all fail occasionally!) -* and things like `imageId` and `userMetadata` and disk and networking options (e.g. `autoAssignFloatingIp` for private clouds) - -For more information, see [Operations: Locations]({{ site.path.guide }}/ops/locations/index.html). http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/creating-yaml.md ---------------------------------------------------------------------- diff --git a/guide/yaml/creating-yaml.md b/guide/yaml/creating-yaml.md deleted file mode 100644 index 603b0cd..0000000 --- a/guide/yaml/creating-yaml.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: The Basic Structure -layout: website-normal -toc: ../guide_toc.json -categories: [use, guide, defining-applications] ---- - -## A First Blueprint - -The easiest way to write a blueprint is as a YAML file. -This follows the <a href="https://www.oasis-open.org/committees/camp/";>OASIS CAMP</a> plan specification, -with some extensions described below. -(A [YAML reference](yaml-reference.html) has more information, -and if the YAML doesn't yet do what you want, -it's easy to add new extensions using your favorite JVM language.) - -### The Basic Structure - -Here's a very simple YAML blueprint plan, to explain the structure: - -{% highlight yaml %} -{% readj example_yaml/simple-appserver.yaml %} -{% endhighlight %} - -* The `name` is just for the benefit of us humans. - -* The `location` specifies where this should be deployed. - If you've [set up passwordless localhost SSH access]({{ site.path.guide }}/ops/locations/#localhost) - you can use `localhost` as above, but if not, just wait ten seconds for the next example. - -* The `services` block takes a list of the typed services we want to deploy. - This is the meat of the blueprint plan, as you'll see below. - -Finally, the clipboard in the top-right corner of the example plan box above (hover your cursor over the box) lets you easily copy-and-paste into the web-console: -simply [download and launch]({{ site.path.guide }}/start/running.html) Brooklyn, -then in the "Create Application" dialog at the web console -(usually [http://127.0.0.1:8081/](http://127.0.0.1:8081/), paste the copied YAML into the "Yaml" tab of the dialog and press "Finish". -There are several other ways to deploy, including `curl` and via the command-line, -and you can configure users, https, persistence, and more, -as described [in the ops guide]({{ site.path.guide }}/ops/). - -[](web-console-yaml.png) - - - -<!-- -TODO building up children entities - ---> - - - -### More Information - -Topics to explore next on the topic of YAML blueprints are: - -{% include list-children.html %} - -Plenty of examples of blueprints exist in the Brooklyn codebase, -so another starting point is to [`git clone`]({{ site.path.website }}/developers/code/index.html) it -and search for `*.yaml` files therein. - -Brooklyn lived as a Java framework for many years before we felt confident -to make a declarative front-end, so you can do pretty much anything you want to -by dropping to the JVM. For more information on Java: - -* start with a [Maven archetype]({{site.path.guide}}/java/archetype.html) -* see all [Brooklyn Java guide]({{site.path.guide}}/java/) topics -* look at test cases in the [codebase](https://github.com/apache/brooklyn) - -<!-- -TODO -* review some [examples]({{site.path.guide}}/use/examples/index.html) ---> - -You can also come talk to us, on IRC (#brooklyncentral on Freenode) or -any of the usual [hailing frequencies]({{site.path.website}}/community/), -as these documents are a work in progress. http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/custom-entities.md ---------------------------------------------------------------------- diff --git a/guide/yaml/custom-entities.md b/guide/yaml/custom-entities.md deleted file mode 100644 index 88d62ff..0000000 --- a/guide/yaml/custom-entities.md +++ /dev/null @@ -1,269 +0,0 @@ ---- -title: Custom Entities -layout: website-normal -toc: ../guide_toc.json -categories: [use, guide, defining-applications] ---- - -So far we've covered how to configure and compose entities. -There's a large library of blueprints available, but -there are also times when you'll want to write your own. - -For complex use cases, you can write JVM, but for many common situations, -some of the highly-configurable blueprints make it easy to write in YAML, -including `bash` and Chef. - - -### Vanilla Software using `bash` - -The following blueprint shows how a simple script can be embedded in the YAML -(the `|` character is special YAML which makes it easier to insert multi-line text): - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat.yaml %} -{% endhighlight %} - -This starts a simple `nc` listener on port 4321 which will respond `hello` to the first -session which connects to it. Test it by running `telnet localhost 4321` -or opening `http://localhost:4321` in a browser. - -Note that it only allows you connect once, and after that it fails. -This is deliberate! We'll repair this later in this example. -Until then however, in the *Applications* view you can click the server, -go to the `Effectors` tab, and click `restart` to bring if back to life. - -This is just a simple script, but it shows how any script can be easily embedded here, -including a script to download and run other artifacts. -Many artifacts are already packaged such that they can be downloaded and launched -with a simple script, and `VanillaSoftwareProcess` can also be used for them. - - -#### Downloading Files - -We can specify a `download.url` which downloads an artifact -(and automatically unpacking TAR, TGZ, and ZIP archives) -before running `launch.command` relative to where that file is installed (or unpacked), -with the default `launch.command` being `./start.sh`. - -So if we create a file `/tmp/netcat-server.tgz` containing just `start.sh` in the root -which consists of the two lines in the previous example, -we can instead write our example as: - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat-file.yaml %} -{% endhighlight %} - - -#### Port Inferencing - -If you're deploying to a cloud machine, a firewall might block the port 4321. -We can tell Brooklyn to open this port explicitly by specifying `inboundPorts: [ 4321 ]`; -however a more idiomatic way is to specify a config ending with `.port`, -such as: - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat-port.yaml %} -{% endhighlight %} - -The regex for ports to be opened can be configured using -the config `inboundPorts.configRegex` (which has `.*\.port` as the default value). - -Config keys of type `org.apache.brooklyn.api.location.PortRange` (aka `port`) -have special behaviour: when configuring, you can use range notation `8000-8100` or `8000+` to tell Brooklyn -to find **one** port matching; this is useful when ports might be in use. -In addition, any such config key will be opened, -irrespective of whether it matches the `inboundPorts.configRegex`. -To prevent any inferencing of ports to open, you can set the config `inboundPorts.autoInfer` to `false`. - -Furthermore, the port inferencing capability takes in account static `ConfigKey` fields that -are defined on any Entity sub-class. So, `ConfigKey` fields that are based on `PortRanges` type will -be also included as required open ports. - -Note that in the example above, `netcat.port` must be specified in a `brooklyn.config` block. -This block can be used to hold any config (including for example the `launch.command`), -but for convenience Brooklyn allows config keys declared on the underlying type -to be specified up one level, alongside the type. -However config keys which are *not* declared on the type *must* be declared in the `brooklyn.config` block. - - -### Passing custom variables - -Blueprint scripts can be parametrised through environment variables, making them reusable in different use-cases. -Define the variables in the `env` block and then reference them using the standard bash notation: - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat-env.yaml %} -{% endhighlight %} - -Non-string objects in the `env` map will be serialized to JSON before passing them to the script. - - -#### Declaring New Config Keys - -We can define config keys to be presented to the user -using the `brooklyn.parameters` block: - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat-port-parameter.yaml %} -{% endhighlight %} - -The example above will allow a user to specify a message to send back -and the port where netcat will listen. -The metadata on these parameters is available at runtime in the UI -and through the API, and is used when populating a catalog. - -The example also shows how these values can be passed as environment variables to the launch command. -The `$brooklyn:config(...)` function returns the config value supplied or default. -For the type `port`, an attribute sensor is also created to report the *actual* port used after port inference, -and so the `$brooklyn:attributeWhenReady(...)` function is used. -(If `$brooklyn:config("netcat.port")` had been used, `4321+` would be passed as `NETCAT_PORT`.) - -This gives us quite a bit more power in writing our blueprint: - -* Multiple instances of the server can be launched simultaneously on the same host, - as the `4321+` syntax enables Brooklyn to assign them different ports -* If this type is added to the catalog, a user can configure the message and the port; - we'll show this in the next section - - -#### Using the Catalog and Clustering - -The *Catalog* tab allows you to add blueprints which you can refer to in other blueprints. -In that tab, click *+* then *YAML*, and enter the following: - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat-catalog.bom %} -{% endhighlight %} - -This is the same example as in the previous section, wrapped according to the catalog YAML requirements, -with one new block added defining an enricher. An enricher creates a new sensor from other values; -in this case it will create a `main.uri` sensor by populating a `printf`-style string `"http://%s:%s"` -with the sensor values. - -With this added to the catalog, we can reference the type `netcat-example` when we deploy an application. -Return to the *Home* or *Applications* tab, click *+*, and submit this YAML blueprint: - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat-reference.yaml %} -{% endhighlight %} - -This extends the previous blueprint which we registered in the catalog, -meaning that we don't need to include it each time. -Here, we've elected to supply our own message, but we'll use the default port. -More importantly, we can package it for others to consume -- or take items others have built. - -We can go further and use this to deploy a cluster, -this time giving a custom port as well as a custom message: - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat-cluster.yaml %} -{% endhighlight %} - -In either of the above examples, if you explore the tree in the *Applications* view -and look at the *Summary* tab of any of the server instances, you'll now see the URL where netcat is running. -But remember, netcat will stop after one run, so you'll only be able to use each link once -before you have to restart it. You can also run `restart` on the cluster, -and if you haven't yet experimented with `resize` on the cluster you might want to do that. - - -#### Determining Successful Launch - -One requirement of the launch script is that it store the process ID (PID) in the file -pointed to by `$PID_FILE`, hence the second line of the script. -This is because Brooklyn wants to monitor the services under management. -You'll observe this if you connect to one of the netcat services, -as the process exits afterwards and Brooklyn sets the entity to an `ON_FIRE` state. -(You can also test this with a `killall nc` before connecting -or issueing a `stop` command on the server -- but not on the example, -as stopping an application root causes it to be removed altogether!) - -There are other options for determining launch: you can set `checkRunning.command` and `stop.command` instead, -as documented on the javadoc and config keys of the {% include java_link.html class_name="VanillaSoftwareProcess" package_path="org/apache/brooklyn/entity/software/base" project_subpath="software/base" %} class, -and those scripts will be used instead of checking and stopping the process whose PID is in `$PID_FILE`. - -{% highlight yaml %} -{% readj example_yaml/vanilla-bash-netcat-more-commands.yaml %} -{% endhighlight %} - -And indeed, once you've run one `telnet` to the server, you'll see that the -service has gone "on fire" in Brooklyn -- because the `nc` process stops after one run. - - -#### 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: - -{% 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, -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). -Running with this blueprint, you'll see that the service shows as on fire for 15s after a `telnet`, -before the policy restarts it. - - -### Sensors and Effectors - -For an even more interesting way to test it, look at the blueprint defining -[a netcat server and client](example_yaml/vanilla-bash-netcat-w-client.yaml). -This uses `initializers` to define an effector to `sayHiNetcat` on the `Simple Pinger` client, -using `env` variables to inject the `netcat-server` location and -`parameters` to pass in per-effector data: - - env: - TARGET_HOSTNAME: $brooklyn:entity("netcat-server").attributeWhenReady("host.name") - brooklyn.initializers: - - type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector - brooklyn.config: - name: sayHiNetcat - description: Echo a small hello string to the netcat entity - command: | - echo $message | nc $TARGET_HOSTNAME 4321 - parameters: - message: - description: The string to pass to netcat - defaultValue: hi netcat - -This blueprint also uses initializers to define sensors on the `netcat-server` entity -so that the `$message` we passed above gets logged and reported back: - - launch.command: | - echo hello | nc -l 4321 >> server-input & - echo $! > $PID_FILE - brooklyn.initializers: - - type: org.apache.brooklyn.core.sensor.ssh.SshCommandSensor - brooklyn.config: - name: output.last - period: 1s - command: tail -1 server-input - -##### Windows Command Sensor - -Like the blueprint above, the following example also uses brooklyn.initializers to define sensors on the entity, -this time however it is a windows VM and uses `WinRmCommandSensor`. - - - type: org.apache.brooklyn.entity.software.base.VanillaWindowsProcess - brooklyn.config: - launch.command: echo launching - checkRunning.command: echo running - brooklyn.initializers: - - type: org.apache.brooklyn.core.sensor.windows.WinRmCommandSensor - brooklyn.config: - name: ip.config - period: 60s - command: hostname - -#### Summary - -These examples are relatively simple example, but they -illustrate many of the building blocks used in real-world blueprints, -and how they can often be easily described and combined in Brooklyn YAML blueprints. -Next, if you need to drive off-piste, or you want to write tests against these blueprints, -have a look at, for example, `VanillaBashNetcatYamlTest.java` in the Brooklyn codebase, -or follow the other references below. http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/entity-configuration.md ---------------------------------------------------------------------- diff --git a/guide/yaml/entity-configuration.md b/guide/yaml/entity-configuration.md deleted file mode 100644 index 85ed1bf..0000000 --- a/guide/yaml/entity-configuration.md +++ /dev/null @@ -1,548 +0,0 @@ ---- -title: Entity Configuration -layout: website-normal -toc: ../guide_toc.json -categories: [use, guide, defining-applications] ---- - -Within a blueprint or catalog item, entities can be configured. The rules for setting this -configuration, including when composing and extending existing entities, is described in this -section. - - -### Basic Configuration - -Within a YAML file, entity configuration should be supplied within a `brooklyn.config` map. It is -also possible to supply configuration at the top-level of the entity. However, that approach is -discouraged as it can sometimes be ambiguous (e.g. if the config key is called "name" or "type"), -and also it does not work in all contexts such as for an enricher's configuration. - -A simple example is shown below: - -{% highlight yaml %} -services: -- type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer - brooklyn.config: - webapp.enabledProtocols: http - http.port: 9080 - wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-webapp/0.9.0/brooklyn-example-hello-world-webapp-0.9.0.war -{% endhighlight %} - -If no config value is supplied, the default for that config key will be used. For example, -`http.port` would default to 8080 if not explicitly supplied. - -Some config keys also have a short-form (e.g. `httpPort` instead of `http.port` would also work -in the YAML example above). However, that approach is discouraged as it does not work in all contexts -such as for inheriting configuration from a parent entity. - - -### Configuration in a Catalog Item - -When defining an entity in the catalog, it can include configuration values like any other -blueprint (i.e. inside the `brooklyn.config` block). - -It can also explicitly declare config keys, using the `brooklyn.parameters` block. The example -below illustrates the principle: - -{% highlight yaml %} -brooklyn.catalog: - items: - - id: entity-config-example - itemType: entity - name: Entity Config Example - item: - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - brooklyn.parameters: - - name: custom.message - type: string - description: Message to be displayed - default: Hello - brooklyn.config: - shell.env: - MESSAGE: $brooklyn:config("custom.message") - launch.command: | - echo "My example launch command: $MESSAGE" - checkRunning.command: | - echo "My example checkRunning command: $MESSAGE" -{% endhighlight %} - -Once added to the catalog, it can be used with the simple blueprint below (substituting the location -of your choice). Because no configuration has been overridden, this will use the default value -for `custom.message`, and will use the given values for `launch.command` and `checkRunning.command`: - -{% highlight yaml %} -location: aws-ec2:us-east-1 -services: -- type: entity-config-example -{% endhighlight %} - -For details of how to write and add catalog items, see [Catalog]({{ site.path.guide }}/ops/catalog/). - - -#### Config Key Constraints - -The config keys in the `brooklyn.parameters` can also have constraints defined, for what values -are valid. If more than one constraint is defined, then they must all be satisfied. The constraints -can be any of: - -* `required`: deployment will fail if no value is supplied for this config key. -* `regex: ...`: the value will be compared against the given regular expression. -* A predicate, declared using the DSL `$brooklyn:object`. - -This is illustrated in the example below: - -{% highlight yaml %} -brooklyn.catalog: - items: - - id: entity-constraint-example - itemType: entity - name: Entity Config Example - item: - type: org.apache.brooklyn.entity.stock.BasicEntity - brooklyn.parameters: - - name: compulsoryExample - type: string - constraints: - - required - - name: addressExample - type: string - constraints: - - regex: ^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$ - - name: numberExample - type: double - constraints: - - $brooklyn:object: - type: org.apache.brooklyn.util.math.MathPredicates - factoryMethod.name: greaterThan - factoryMethod.args: - - 0.0 - - $brooklyn:object: - type: org.apache.brooklyn.util.math.MathPredicates - factoryMethod.name: lessThan - factoryMethod.args: - - 256.0 -{% endhighlight %} - -An example usage of this toy example, once added to the catalog, is shown below: - -{% highlight yaml %} -services: -- type: entity-constraint-example - brooklyn.config: - compulsoryExample: foo - addressExample: 1.1.1.1 - numberExample: 2.0 -{% endhighlight %} - - -### Inheriting Configuration - -Configuration can be inherited from a super-type, and from a parent entity in the runtime -management hierarchy. This applies to entities and locations. In a future release, this will be -extended to also apply to policies and enrichers. - -When a blueprint author defines a config key, they can explicitly specify the rules for inheritance -(both for super/sub-types, and for the runtime management hiearchy). This gives great flexibilty, -but should be used with care so as not to surprise users of the blueprint. - -The default behaviour is outlined below, along with examples and details of how to explilcitly -define the desired behaviour. - - -#### Normal Configuration Precedence - -There are several places that a configuration value can come from. If different values are -specified in multiple places, then the order of precedence is as listed below: - -1. Configuration on the entity itself -2. Inherited configuration from the super-type -3. Inherited configuration from the runtime type hierarchy -4. The config key's default value - - -#### Inheriting Configuration from Super-type - -When using an entity from the catalog, its configuration values can be overridden. For example, -consider the `entity-config-example` added to the catalog in the section -[Configuration in a Catalog Item](#configuration-in-a-catalog-item). -We can override these values. If not overridden, then the existing values from the super-type will be used: - -{% highlight yaml %} -location: aws-ec2:us-east-1 -services: -- type: entity-config-example - brooklyn.config: - custom.message: Goodbye - launch.command: | - echo "Sub-type launch command: $MESSAGE" -{% endhighlight %} - - - -In this example, the `custom.message` overrides the default defined on the config key. -The `launch.command` overrides the original command. The other config (e.g. `checkRunning.command`) -is inherited unchanged. - -It will write out: `Sub-type launch command: Goodbye`. - - -#### Inheriting Configuration from a Parent in the Runtime Management Hieararchy - -Configuration passed to an entity is inherited by all child entities, unless explicitly overridden. - -In the example below, the `wars.root` config key is inherited by all TomcatServer entities created -under the cluster, so they will use that war: - -{% highlight yaml %} -services: -- type: org.apache.brooklyn.entity.group.DynamicCluster - brooklyn.config: - wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-webapp/0.9.0/brooklyn-example-hello-world-webapp-0.9.0.war - dynamiccluster.memberspec: - $brooklyn:entitySpec: - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer -{% endhighlight %} - -In the above example, it would be better to have specified the `wars.root` configuration in the -`TomcatServer` entity spec, rather than at the top level. This would make it clearer for the reader -what is actually being configured. - -The technique of inherited config can simplify some blueprints, but care should be taken. -For more complex (composite) blueprints, this can be difficult to use safely; it relies on -knowledge of the internals of the child components. For example, the inherited config -may impact multiple sub-components, rather than just the specific entity to be changed. -This is particularly true when using complex items from the catalog, and when using common config -values (e.g. `install.version`). - -An alternative approach is to declare the expected configuration options at the top level of the -catalog item, and then (within the catalog item) explicitly inject those values into the correct -sub-components. Users of this catalog item would set only those exposed config options, rather -than trying to inject config directly into the nested entities. - - -#### DSL Evaluation of Inherited Config - -When writing blueprints that rely on inheritance from the runtime management hierarchy, it is -important to understand how config keys that use DSL will be evaluated. In particular, when -evaluating a DSL expression, it will be done in the context of the entity declaring the config -value (rather than on the entity using the config value). - -For example, consider the config value `$brooklyn:attributeWhenReady("host.name")` -declared on entity X, and inherited by child entity Y. If entity Y uses this config value, -it will get the "host.name" attribute of entity X. - -Below is another (contrived!) example of this DSL evaluation. When evaluating `refExampleConfig`, -it retrievies the value of `exampleConfig` which is the DSL expression, and evaluates this in the -context of the parent entity that declares it. Therefore `$brooklyn:config("ownConfig")` returns -the parent's `ownConfig` value, and the final result for `refExampleConfig` is set to "parentValue": - -{% highlight yaml %} -services: -- type: org.apache.brooklyn.entity.stock.BasicApplication - brooklyn.config: - ownConfig: parentValue - exampleConfig: $brooklyn:config("ownConfig") - - brooklyn.children: - - type: org.apache.brooklyn.entity.stock.BasicEntity - brooklyn.config: - ownConfig: childValue - refExampleConfig: $brooklyn:config("exampleConfig") -{% endhighlight %} - -_However, the web-console also shows other misleading (incorrect!) config values for the child -entity. It shows the inherited config value of `exampleConfig` as "childValue" (because the -REST api did not evaluate the DSL in the correct context, when retrieving the value! -See https://issues.apache.org/jira/browse/BROOKLYN-455._ - - -#### Merging Configuration Values - -For some configuration values, the most logical behaviour is to merge the configuration value -with that in the super-type. This depends on the type and meaning of the config key, and is thus -an option when defining the config key. - -Currently it is only supported for merging config keys of type Map. - -Some common config keys will default to merging the values from the super-type. These config keys -include those below. The value is merged with that of its super-type (but will not be merged with -the value on a parent entity): - -* `shell.env`: a map of environment variables to pass to the runtime shell -* `files.preinstall`: a mapping of files, to be copied before install, to destination name relative to installDir -* `templates.preinstall`: a mapping of templates, to be filled in and copied before pre-install, to destination name relative to installDir -* `files.install`: a mapping of files, to be copied before install, to destination name relative to installDir -* `templates.install`: a mapping of templates, to be filled in and copied before install, to destination name relative to installDir -* `files.runtime`: a mapping of files, to be copied before customisation, to destination name relative to runDir -* `templates.runtime`: a mapping of templates, to be filled in and copied before customisation, to destination name relative to runDir -* `provisioning.properties`: custom properties to be passed in when provisioning a new machine - -A simple example of merging `shell.env` is shown below (building on the `entity-config-example` in -the section [Configuration in a Catalog Item](#configuration-in-a-catalog-item)). -The environment variables will include the `MESSAGE` -set in the super-type and the `MESSAGE2` set here: - -{% highlight yaml %} -location: aws-ec2:us-east-1 -services: -- type: entity-config-example - brooklyn.config: - shell.env: - MESSAGE2: Goodbye - launch.command: | - echo "Different example launch command: $MESSAGE and $MESSAGE2" -{% endhighlight %} - -To explicitly remove a value from the super-type's map (rather than adding to it), a blank entry -can be defined. - - -#### Entity provisioning.properties: Overriding and Merging - -An entity (which extends `SoftwareProcess`) can define a map of `provisioning.properties`. If -the entity then provisions a location, it passes this map of properties to the location for -obtaining the machine. These properties will override and augment the configuration on the location -itself. - -When deploying to a jclouds location, one can specify `templateOptions` (of type map). Rather than -overriding, these will be merged with any templateOptions defined on the location. - -In the example below, the VM will be provisioned with minimum 2G ram and minimum 2 cores. It will -also use the merged template options value of -`{placementGroup: myPlacementGroup, securityGroupIds: sg-000c3a6a}`: - -{% highlight yaml %} -location: - aws-ec2:us-east-1: - minRam: 2G - templateOptions: - placementGroup: myPlacementGroup -services: -- type: org.apache.brooklyn.entity.machine.MachineEntity - brooklyn.config: - provisioning.properties: - minCores: 2 - templateOptions: - securityGroupIds: sg-000c3a6a -{% endhighlight %} - -The merging of `templateOptions` is shallow (i.e. maps within the `templateOptions` are not merged). -In the example below, the `userMetadata` value within `templateOptions` will be overridden by the -entity's value, rather than the maps being merged; the value used when provisioning will be -`{key2: val2}`: - -{% highlight yaml %} -location: - aws-ec2:us-east-1: - templateOptions: - userMetadata: - key1: val1 -services: -- type: org.apache.brooklyn.entity.machine.MachineEntity - brooklyn.config: - provisioning.properties: - userMetadata: - key2: val2 -{% endhighlight %} - - -#### Re-inherited Versus not Re-inherited - -For some configuration values, the most logical behaviour is for an entity to "consume" the config -key's value, and thus not pass it down to children in the runtime type hierarchy. This is called -"not re-inherited". - -Some common config keys that will not re-inherited include: - -* `install.command` (and the `pre.install.command` and `post.install.command`) -* `customize.command` (and the `pre.customize.command` and `post.customize.command`) -* `launch.command` (and the ``pre.launch.command` and `post.launch.command`) -* `checkRunning.command` -* `stop.command` -* The similar commands for `VanillaWindowsProcess` powershell. -* The file and template install config keys (e.g. `files.preinstall`, `templates.preinstall`, etc) - -An example is shown below. Here, the "logstash-child" is a sub-type of `VanillaSoftwareProcess`, -and is co-located on the same VM as Tomcat. We don't want the Tomcat's configuration, such as -`install.command`, to be inherited by the logstash child. If it was inherited, the logstash-child -entity might re-execute the Tomcat's install command! Instead, the `install.command` config is -"consumed" by the Tomcat instance and is not re-inherited: - -{% highlight yaml %} -services: -- type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server - brooklyn.config: - children.startable.mode: background_late - brooklyn.children: - - type: logstash-child - brooklyn.config: - logstash.elasticsearch.host: $brooklyn:entity("es").attributeWhenReady("urls.http.withBrackets") -... -{% endhighlight %} - -"Not re-inherited" differs from "never inherited". The example below illustrates the difference, -though this use is discouraged (it is mostly for backwards compatibility). The `post.install.command` -is not consumed by the `BasicApplication`, so will be inherited by the `Tomcat8Server` which will -consume it. The config value will therefore not be inherited by the `logstash-child`. - -{% highlight yaml %} -services: -- type: org.apache.brooklyn.entity.stock.BasicApplication - brooklyn.config: - post.install.command: echo "My post.install command" - brooklyn.children: - - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server - brooklyn.config: - children.startable.mode: background_late - brooklyn.children: - - type: logstash-child - brooklyn.config: - logstash.elasticsearch.host: $brooklyn:entity("es").attributeWhenReady("urls.http.withBrackets") -... -{% endhighlight %} - - -#### Never Inherited - -For some configuration values, the most logical behaviour is for the value to never be inherited -in the runtime management hiearchy. - -Some common config keys that will never inherited include: - -* `defaultDisplayName`: this is the name to use for the entity, if an explicit name is not supplied. - This is particularly useful when adding an entity in a catalog item (so if the user does not give - a name, it will get a sensible default). It would not be intuitive for all the children of that - entity to also get that default name. - -* `id`: the id of an entity (as supplied in the YAML, to allow references to that entity) is not - inherited. It is the id of that specific entity, so must not be shared by all its children. - - -#### Inheritance Modes: Deep Dive - -The javadoc in the code is useful for anyone who wants to go deep! See -`org.apache.brooklyn.config.BasicConfigInheritance` and `org.apache.brooklyn.config.ConfigInheritances` -in the repo https://github.com/apache/brooklyn-server. - -When defining a new config key, the exact semantics for inheritance can be defined. There are -separate options to control config inheritance from the super-type, and config inheritance from the -parent in the runtime management hierarchy. - -The possible modes are: - -* `NEVER_INHERITED`: indicates that a key's value should never be inherited (even if defined on - an entity that does not know the key). Most usages will prefer `NOT_REINHERITED`. - -* `NOT_REINHERITED`: indicates that a config key value (if used) should not be passed down to - children / sub-types. Unlike `NEVER_INHERITED`, these values can be passed down if they are not - used by the entity (i.e. if the entity does not expect it). However, when used by a child, - it will not be passed down any further. If the inheritor also defines a value the parent's - value is ignored irrespective (as in `OVERWRITE`; see `NOT_REINHERITED_ELSE_DEEP_MERGE` if merging - is desired). - -* `NOT_REINHERITED_ELSE_DEEP_MERGE`: as `NOT_REINHERITED` but in cases where a value is inherited - because a parent did not recognize it, if the inheritor also defines a value the two values should - be merged. - -* `OVERWRITE`: indicates that if a key has a value at both an ancestor and a descendant, the - descendant and his descendants will prefer the value at the descendant. - -* `DEEP_MERGE`: indicates that if a key has a value at both an ancestor and a descendant, the - descendant and his descendants should attempt to merge the values. If the values are not mergable, - behaviour is undefined (and often the descendant's value will simply overwrite). - - -#### Explicit Inheritance Modes - -_The YAML support for explicitly defining the inheritance mode is still work-in-progress. The options -documented below will be enhanced in a future version of AMP, to better support the modes described -above._ - -In a YAML blueprint, within the `brooklyn.parameters` section for declaring new config keys, one can -set the mode for `inheritance.type` and `inheritance.parent` (i.e. for inheritance from the super-type, and -inheritance in the runtime management hierarchy). The possible values are: - -* `deep_merge`: the inherited and the given value should be merged; maps within the map will also be merged -* `always`: the inherited value should be used, unless explicitly overridden by the entity -* `none`: the value should not be inherited; if there is no explicit value on the entity then the default value will be used - -Below is a (contrived!) example of inheriting the `example.map` config key. When using this entity -in a blueprint, the entity's config will be merged with that defined in the super-type, and the -parent entity's value will never be inherited: - -{% highlight yaml %} -brooklyn.catalog: - items: - - id: entity-config-inheritance-example - version: "1.1.0-SNAPSHOT" - itemType: entity - name: Entity Config Inheritance Example - item: - type: org.apache.brooklyn.entity.machine.MachineEntity - brooklyn.parameters: - - name: example.map - type: java.util.Map - inheritance.type: deep_merge - inheritance.parent: none - default: - MESSAGE_IN_DEFAULT: InDefault - brooklyn.config: - example.map: - MESSAGE: Hello -{% endhighlight %} - -The blueprints below demonstrate the various permutations for setting configuration for the -config `example.map`. This can be inspected by looking at the entity's config. The config -we see for app1 is the inherited `{MESSAGE: "Hello"}`; in app2 we define additional configuration, -which will be merged to give `{MESSAGE: "Hello", MESSAGE_IN_CHILD: "InChild"}`; in app3, the -config from the parent is not inherited because there is an explicit inheritance.parent of "none", -so it just has the value `{MESSAGE: "Hello"}`; in app4 again the parent's config is ignored, -with the super-type and entity's config being merged to give `{MESSAGE: "Hello", MESSAGE_IN_CHILD: "InChild"}`. - -{% highlight yaml %} -location: aws-ec2:us-east-1 -services: -- type: org.apache.brooklyn.entity.stock.BasicApplication - name: app1 - brooklyn.children: - - type: entity-config-inheritance-example - -- type: org.apache.brooklyn.entity.stock.BasicApplication - name: app2 - brooklyn.children: - - type: entity-config-inheritance-example - brooklyn.config: - example.map: - MESSAGE_IN_CHILD: InChild - -- type: org.apache.brooklyn.entity.stock.BasicApplication - name: app3 - brooklyn.config: - example.map: - MESSAGE_IN_PARENT: InParent - brooklyn.children: - - type: entity-config-inheritance-example - -- type: org.apache.brooklyn.entity.stock.BasicApplication - name: app4 - brooklyn.config: - example.map: - MESSAGE_IN_PARENT: InParent - brooklyn.children: - - type: entity-config-inheritance-example - brooklyn.config: - example.map: - MESSAGE_IN_CHILD: InChild -{% endhighlight %} - -A limitations of `inheritance.parent` is when inheriting values from parent and grandparent -entities: a value specified on the parent will override (rather than be merged with) the -value on the grandparent. - - -#### Merging Policy and Enricher Configuration Values - -A current limitation is that sub-type inheritance is not supported for configuration of -policies and enrichers. The current behaviour is that config is not inherited. The concept of -inheritance from the runtime management hierarchy does not apply for policies and enrichers -(they do not have "parents"; they are attached to an entity). http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/appserver-clustered-w-db-concise.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/appserver-clustered-w-db-concise.yaml b/guide/yaml/example_yaml/appserver-clustered-w-db-concise.yaml deleted file mode 100644 index 64ed9a0..0000000 --- a/guide/yaml/example_yaml/appserver-clustered-w-db-concise.yaml +++ /dev/null @@ -1,15 +0,0 @@ -name: appserver-clustered-w-db-concise -services: -- type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster - brooklyn.config: - cluster.initial.size: 2 - wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war - http.port: 8080+ - java.sysprops: - brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s", - component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n") -- type: org.apache.brooklyn.entity.database.mysql.MySqlNode - id: db - name: DB HelloWorld Visitors - brooklyn.config: - datastore.creation.script.url: https://github.com/apache/brooklyn-library/blob/master/examples/simple-web-cluster/src/main/resources/visitors-creation-script.sql http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/appserver-clustered-w-db.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/appserver-clustered-w-db.yaml b/guide/yaml/example_yaml/appserver-clustered-w-db.yaml deleted file mode 100644 index a3fa749..0000000 --- a/guide/yaml/example_yaml/appserver-clustered-w-db.yaml +++ /dev/null @@ -1,19 +0,0 @@ -name: appserver-clustered-w-db -services: -- type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster - brooklyn.config: - cluster.initial.size: 2 - dynamiccluster.memberspec: - $brooklyn:entitySpec: - type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server - brooklyn.config: - wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war - http.port: 8080+ - java.sysprops: - brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s", - component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n") -- type: org.apache.brooklyn.entity.database.mysql.MySqlNode - id: db - name: DB HelloWorld Visitors - brooklyn.config: - datastore.creation.script.url: https://github.com/apache/brooklyn-library/raw/master/examples/simple-web-cluster/src/main/resources/visitors-creation-script.sql http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/appserver-configured-in-config.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/appserver-configured-in-config.yaml b/guide/yaml/example_yaml/appserver-configured-in-config.yaml deleted file mode 100644 index 765a8c2..0000000 --- a/guide/yaml/example_yaml/appserver-configured-in-config.yaml +++ /dev/null @@ -1,6 +0,0 @@ -name: appserver-configured-in-config -services: -- type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server - brooklyn.config: - wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war - http.port: 8080 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/appserver-configured.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/appserver-configured.yaml b/guide/yaml/example_yaml/appserver-configured.yaml deleted file mode 100644 index 51bf3ca..0000000 --- a/guide/yaml/example_yaml/appserver-configured.yaml +++ /dev/null @@ -1,5 +0,0 @@ -name: appserver-configured -services: -- type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server - war: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war - httpPort: 8080 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/appserver-w-db-other-flavor.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/appserver-w-db-other-flavor.yaml b/guide/yaml/example_yaml/appserver-w-db-other-flavor.yaml deleted file mode 100644 index 9b648d8..0000000 --- a/guide/yaml/example_yaml/appserver-w-db-other-flavor.yaml +++ /dev/null @@ -1,17 +0,0 @@ -name: appserver-w-db-other-flavor -services: -- type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer - name: AppServer HelloWorld - brooklyn.config: - wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war - http.port: 8080+ - java.sysprops: - brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s", - component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n") -- type: org.apache.brooklyn.entity.database.mariadb.MariaDbNode - id: db - name: DB HelloWorld Visitors - brooklyn.config: - datastore.creation.script.url: https://github.com/apache/brooklyn-library/raw/master/examples/simple-web-cluster/src/main/resources/visitors-creation-script.sql - provisioning.properties: - minRam: 8192 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/appserver-w-db.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/appserver-w-db.yaml b/guide/yaml/example_yaml/appserver-w-db.yaml deleted file mode 100644 index d4bc706..0000000 --- a/guide/yaml/example_yaml/appserver-w-db.yaml +++ /dev/null @@ -1,15 +0,0 @@ -name: appserver-w-db -services: -- type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server - name: AppServer HelloWorld - brooklyn.config: - wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war - http.port: 8080+ - java.sysprops: - brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s", - component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n") -- type: org.apache.brooklyn.entity.database.mysql.MySqlNode - id: db - name: DB HelloWorld Visitors - brooklyn.config: - datastore.creation.script.url: https://github.com/apache/brooklyn-library/raw/master/examples/simple-web-cluster/src/main/resources/visitors-creation-script.sql http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/appserver-w-policy.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/appserver-w-policy.yaml b/guide/yaml/example_yaml/appserver-w-policy.yaml deleted file mode 100644 index 4b10f59..0000000 --- a/guide/yaml/example_yaml/appserver-w-policy.yaml +++ /dev/null @@ -1,27 +0,0 @@ -name: appserver-w-policy -services: -- type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster - brooklyn.config: - cluster.initial.size: 1 - dynamiccluster.memberspec: - $brooklyn:entitySpec: - type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server - brooklyn.config: - wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war - http.port: 8080+ - java.sysprops: - brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s", - component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n") - brooklyn.policies: - - type: org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy - brooklyn.config: - metric: $brooklyn:sensor("brooklyn.entity.webapp.DynamicWebAppCluster", "webapp.reqs.perSec.windowed.perNode") - metricLowerBound: 10 - metricUpperBound: 100 - minPoolSize: 1 - maxPoolSize: 5 -- type: org.apache.brooklyn.entity.database.mysql.MySqlNode - id: db - name: DB HelloWorld Visitors - brooklyn.config: - datastore.creation.script.url: https://github.com/apache/brooklyn-library/raw/master/examples/simple-web-cluster/src/main/resources/visitors-creation-script.sql http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/cluster-vm.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/cluster-vm.yaml b/guide/yaml/example_yaml/cluster-vm.yaml deleted file mode 100644 index e21977a..0000000 --- a/guide/yaml/example_yaml/cluster-vm.yaml +++ /dev/null @@ -1,13 +0,0 @@ -name: cluster-vm -services: -- type: org.apache.brooklyn.entity.group.DynamicCluster - brooklyn.config: - cluster.initial.size: 5 - dynamiccluster.memberspec: - $brooklyn:entitySpec: - type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess - name: VM - provisioning.properties: - minRam: 8g - minCores: 4 - minDisk: 100g http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/fabric-with-multiple-locations.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/fabric-with-multiple-locations.yaml b/guide/yaml/example_yaml/fabric-with-multiple-locations.yaml deleted file mode 100644 index d923025..0000000 --- a/guide/yaml/example_yaml/fabric-with-multiple-locations.yaml +++ /dev/null @@ -1,15 +0,0 @@ -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 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml b/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml deleted file mode 100644 index 7e4c0ca..0000000 --- a/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml +++ /dev/null @@ -1,10 +0,0 @@ -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 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/simple-appserver-with-location-per-entity.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/simple-appserver-with-location-per-entity.yaml b/guide/yaml/example_yaml/simple-appserver-with-location-per-entity.yaml deleted file mode 100644 index a39e27d..0000000 --- a/guide/yaml/example_yaml/simple-appserver-with-location-per-entity.yaml +++ /dev/null @@ -1,8 +0,0 @@ -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") http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/simple-appserver-with-location.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/simple-appserver-with-location.yaml b/guide/yaml/example_yaml/simple-appserver-with-location.yaml deleted file mode 100644 index 764eaac..0000000 --- a/guide/yaml/example_yaml/simple-appserver-with-location.yaml +++ /dev/null @@ -1,8 +0,0 @@ -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 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/simple-appserver.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/simple-appserver.yaml b/guide/yaml/example_yaml/simple-appserver.yaml deleted file mode 100644 index 8e9d76a..0000000 --- a/guide/yaml/example_yaml/simple-appserver.yaml +++ /dev/null @@ -1,4 +0,0 @@ -name: simple-appserver -location: localhost -services: -- type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/simple-vm.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/simple-vm.yaml b/guide/yaml/example_yaml/simple-vm.yaml deleted file mode 100644 index 8f6447c..0000000 --- a/guide/yaml/example_yaml/simple-vm.yaml +++ /dev/null @@ -1,8 +0,0 @@ -name: simple-vm -services: -- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess - name: VM - provisioning.properties: - minRam: 8192mb - minCores: 4 - minDisk: 100gb http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/test-app-with-enrichers-slightly-simpler.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/test-app-with-enrichers-slightly-simpler.yaml b/guide/yaml/example_yaml/test-app-with-enrichers-slightly-simpler.yaml deleted file mode 100644 index 93b6795..0000000 --- a/guide/yaml/example_yaml/test-app-with-enrichers-slightly-simpler.yaml +++ /dev/null @@ -1,58 +0,0 @@ -# -# example showing how enrichers can be set -# -name: test-app-with-enrichers -description: Testing many enrichers -services: -- type: org.apache.brooklyn.entity.group.DynamicCluster - id: cluster - location: localhost - brooklyn.config: - cluster.initial.size: 3 - dynamiccluster.memberspec: - $brooklyn:entitySpec: - type: org.apache.brooklyn.core.test.entity.TestEntity - brooklyn.enrichers: - - type: org.apache.brooklyn.enricher.stock.Transformer - # transform "ip" (which we expect a feed, not shown here, to set) to a URL; - # you can curl an address string to the sensors/ip endpoint an entity to trigger these enrichers - brooklyn.config: - enricher.sourceSensor: $brooklyn:sensor("ip") - enricher.targetSensor: $brooklyn:sensor("url") - enricher.targetValue: $brooklyn:formatString("http://%s/";, $brooklyn:attributeWhenReady("ip")) - - type: org.apache.brooklyn.enricher.stock.Propagator - # use propagator to duplicate one sensor as another, giving the supplied sensor mapping; - # the other use of Propagator is where you specify a producer (using $brooklyn:entity(...) as below) - # from which to take sensors; in that mode you can specify `propagate` as a list of sensors whose names are unchanged, - # instead of (or in addition to) this map - brooklyn.config: - sensorMapping: - $brooklyn:sensor("url"): $brooklyn:sensor("org.apache.brooklyn.core.entity.Attributes", "main.uri") - brooklyn.enrichers: - - type: org.apache.brooklyn.enricher.stock.Aggregator - # aggregate `url` sensors from children into a list - brooklyn.config: - enricher.sourceSensor: $brooklyn:sensor("url") - enricher.targetSensor: $brooklyn:sensor("urls.list") - enricher.aggregating.fromMembers: true - - type: org.apache.brooklyn.enricher.stock.Joiner - # create a string from that list, for use e.g. in bash scripts - brooklyn.config: - enricher.sourceSensor: $brooklyn:sensor("urls.list") - enricher.targetSensor: $brooklyn:sensor("urls.list.comma_separated.max_2") - maximum: 2 - # TODO infer uniqueTag, name etc - uniqueTag: urls.list.comma_separated.max_2 - - type: org.apache.brooklyn.enricher.stock.Joiner - # pick one uri as the main one to use - brooklyn.config: - enricher.sourceSensor: $brooklyn:sensor("urls.list") - enricher.targetSensor: $brooklyn:sensor("org.apache.brooklyn.core.entity.Attributes", "main.uri") - quote: false - maximum: 1 -brooklyn.enrichers: -- type: org.apache.brooklyn.enricher.stock.Propagator - # if nothing specified for `propagating` or `sensorMapping` then - # Propagator will do all but the usual lifecycle defaults, handy at the root! - brooklyn.config: - producer: $brooklyn:entity("cluster") http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-catalog.bom ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-catalog.bom b/guide/yaml/example_yaml/vanilla-bash-netcat-catalog.bom deleted file mode 100644 index 6416ab7..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-catalog.bom +++ /dev/null @@ -1,36 +0,0 @@ -brooklyn.catalog: - id: netcat-example - version: "1.0" - itemType: entity - item: - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Netcat Server - - launch.command: | - echo $MESSAGE | nc -l $NETCAT_PORT & - echo $! > $PID_FILE - - env: - MESSAGE: $brooklyn:config("message") - NETCAT_PORT: $brooklyn:attributeWhenReady("netcat.port") - - brooklyn.parameters: - - name: message - description: a message to send to the caller - default: hello - - name: netcat.port - type: port - description: the port netcat should run on - default: 4321+ - - brooklyn.enrichers: - - type: org.apache.brooklyn.enricher.stock.Transformer - brooklyn.config: - uniqueTag: main-uri-generator - enricher.sourceSensor: $brooklyn:sensor("host.address") - enricher.targetSensor: $brooklyn:sensor("main.uri") - enricher.targetValue: - $brooklyn:formatString: - - "http://%s:%s/"; - - $brooklyn:attributeWhenReady("host.address") - - $brooklyn:attributeWhenReady("netcat.port") http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-cluster.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-cluster.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-cluster.yaml deleted file mode 100644 index 813445f..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-cluster.yaml +++ /dev/null @@ -1,12 +0,0 @@ -name: Netcat Cluster Example -location: localhost -services: -- type: org.apache.brooklyn.entity.group.DynamicCluster - brooklyn.config: - dynamiccluster.memberspec: - $brooklyn:entitySpec: - type: netcat-example - message: hello from cluster member - netcat.port: 8000+ - cluster.initial.size: 3 - restartMode: parallel http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-env.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-env.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-env.yaml deleted file mode 100644 index 061d31b..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-env.yaml +++ /dev/null @@ -1,12 +0,0 @@ -name: Netcat Example with Environment Vars -location: localhost -services: -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Netcat Server - launch.command: | - echo $MESSAGE | nc -l $NETCAT_PORT & - echo $! > $PID_FILE - - env: - MESSAGE: hello - NETCAT_PORT: 4321 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-file.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-file.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-file.yaml deleted file mode 100644 index d768739..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-file.yaml +++ /dev/null @@ -1,6 +0,0 @@ -name: Simple Netcat Example From File -location: localhost -services: -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Netcat Server - download.url: file:///tmp/netcat-server.tgz http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-more-commands.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-more-commands.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-more-commands.yaml deleted file mode 100644 index f4e894f..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-more-commands.yaml +++ /dev/null @@ -1,16 +0,0 @@ -name: Netcat Example with Explicit Check and Stop Commands -location: localhost -services: -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Netcat Server - launch.command: | - echo hello | nc -l 4321 & - echo $! > $PID_FILE - - # The following overrides demonstrate the use of a custom shell environment as well as - # check-running and stop commands. These are optional; default behavior will "do the - # right thing" with the pid file automatically. - - env: { CHECK_MARKER: "checkRunning", STOP_MARKER: "stop" } - checkRunning.command: echo $CHECK_MARKER >> DATE && test -f "$PID_FILE" && ps -p `cat $PID_FILE` >/dev/null - stop.command: echo $STOP_MARKER >> DATE && test -f "$PID_FILE" && { kill -9 `cat $PID_FILE`; rm /tmp/vanilla.pid; } http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-port-parameter.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-port-parameter.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-port-parameter.yaml deleted file mode 100644 index 90f83b4..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-port-parameter.yaml +++ /dev/null @@ -1,21 +0,0 @@ -name: Netcat Example with Parameter -location: localhost -services: -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Netcat Server - launch.command: | - echo $MESSAGE | nc -l $NETCAT_PORT & - echo $! > $PID_FILE - - env: - MESSAGE: $brooklyn:config("message") - NETCAT_PORT: $brooklyn:attributeWhenReady("netcat.port") - - brooklyn.parameters: - - name: message - description: a message to send to the caller - default: hello - - name: netcat.port - type: port - description: the port netcat should run on - default: 4321+ http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-port.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-port.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-port.yaml deleted file mode 100644 index 3ec0212..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-port.yaml +++ /dev/null @@ -1,13 +0,0 @@ -name: Netcat Example with Port Opened -location: localhost -services: -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Netcat Server - launch.command: | - echo hello | nc -l 4321 & - echo $! > $PID_FILE - - brooklyn.config: - # matching the regex `.*\.port` will cause the port to be opened - # if in a cloud where configurable security groups are available - netcat.port: 4321 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-reference.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-reference.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-reference.yaml deleted file mode 100644 index 0f10c55..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-reference.yaml +++ /dev/null @@ -1,5 +0,0 @@ -name: Netcat Type Reference Example -location: localhost -services: -- type: netcat-example - message: hello from netcat using a registered type http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-restarter.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-restarter.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-restarter.yaml deleted file mode 100644 index 47e54ab..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-restarter.yaml +++ /dev/null @@ -1,20 +0,0 @@ -name: Netcat Example with Restarter Policy -location: localhost -services: -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - id: netcat-server - name: Simple Netcat Server - launch.command: | - echo hello | nc -l 4321 & - echo $! > $PID_FILE - brooklyn.enrichers: - - type: org.apache.brooklyn.policy.ha.ServiceFailureDetector - brooklyn.config: - # wait 15s after service fails before propagating failure - serviceFailedStabilizationDelay: 15s - brooklyn.policies: - - type: org.apache.brooklyn.policy.ha.ServiceRestarter - brooklyn.config: - # repeated failures in a time window can cause the restarter to abort, - # propagating the failure; a time window of 0 will mean it always restarts! - failOnRecurringFailuresInThisDuration: 0 http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat-w-client.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat-w-client.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat-w-client.yaml deleted file mode 100644 index 75d2b79..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat-w-client.yaml +++ /dev/null @@ -1,78 +0,0 @@ -name: Netcat Example with Client - -location: localhost - -services: - -# the netcat server instance, running in listener mode (-l) -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - id: netcat-server - name: Simple Netcat Server - launch.command: | - echo hello | nc -l 4321 >> server-input & - echo $! > $PID_FILE - - # a failure detector and a service restarter work together - brooklyn.enrichers: - - type: org.apache.brooklyn.policy.ha.ServiceFailureDetector - brooklyn.config: - # wait 15s after service fails before propagating failure - serviceFailedStabilizationDelay: 15s - - brooklyn.policies: - - type: org.apache.brooklyn.policy.ha.ServiceRestarter - brooklyn.config: - # repeated failures in a time window can cause the restarter to abort, - # propagating the failure; a time window of 0 will mean it always restarts! - failOnRecurringFailuresInThisDuration: 0 - - brooklyn.initializers: - # two sensors, recording the data sent to this netcat server: - - - type: org.apache.brooklyn.core.sensor.ssh.SshCommandSensor - brooklyn.config: - name: output.last - period: 1s - command: tail -1 server-input - - - type: org.apache.brooklyn.core.sensor.ssh.SshCommandSensor - brooklyn.config: - name: output.all - period: 1s - command: cat server-input - -# a client to hit netcat -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Pinger - - # set the hostname of the netcat instance as an env var for the scripts - env: - TARGET_HOSTNAME: - $brooklyn:entity("netcat-server"). - attributeWhenReady("host.name") - - # start/check/stop are no-op - launch.command: "" - checkRunning.command: "" - stop.command: "" - - brooklyn.initializers: - # but there is a sample effector which runs nc in client mode - - - type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector - brooklyn.config: - name: sayHiNetcat - description: Echo a small hello string to the netcat entity - command: | - echo $message | nc $TARGET_HOSTNAME 4321 - parameters: - message: - description: The string to pass to netcat - defaultValue: hi netcat - -# and add an enricher at the root so all sensors from netcat-server are visible on the root -brooklyn.enrichers: -- enricherType: org.apache.brooklyn.enricher.stock.Propagator - brooklyn.config: - enricher.producer: $brooklyn:entity("netcat-server") - enricher.propagating.propagatingAll: true http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/example_yaml/vanilla-bash-netcat.yaml ---------------------------------------------------------------------- diff --git a/guide/yaml/example_yaml/vanilla-bash-netcat.yaml b/guide/yaml/example_yaml/vanilla-bash-netcat.yaml deleted file mode 100644 index df616af..0000000 --- a/guide/yaml/example_yaml/vanilla-bash-netcat.yaml +++ /dev/null @@ -1,8 +0,0 @@ -name: Simple Netcat Server Example -location: localhost -services: -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Netcat Server - launch.command: | - echo hello | nc -l 4321 & - echo $! > $PID_FILE http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/index.md ---------------------------------------------------------------------- diff --git a/guide/yaml/index.md b/guide/yaml/index.md deleted file mode 100644 index def24c1..0000000 --- a/guide/yaml/index.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: YAML Blueprints -layout: website-normal -children: -- creating-yaml.md -- setting-locations.md -- configuring-vms.md -- clusters.md -- multiple-services.md -- entity-configuration.md -- clusters-and-policies.md -- blueprinting-tips.md -- custom-entities.md -- winrm/ -- ansible/ -- chef/ -- salt/ -- test/ -- advanced-example.md -- { path: yaml-reference.md, title: YAML Blueprint Reference } -- { link: 'https://github.com/brooklyncentral/blueprint-library', title: 'GitHub Blueprint Library' } ---- - - -{% include list-children.html %} http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/logstash-snapshot.png ---------------------------------------------------------------------- diff --git a/guide/yaml/logstash-snapshot.png b/guide/yaml/logstash-snapshot.png deleted file mode 100644 index 07ad4bf..0000000 Binary files a/guide/yaml/logstash-snapshot.png and /dev/null differ http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/multiple-services.md ---------------------------------------------------------------------- diff --git a/guide/yaml/multiple-services.md b/guide/yaml/multiple-services.md deleted file mode 100644 index 81ddf07..0000000 --- a/guide/yaml/multiple-services.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Multiple Services and Dependency Injection -layout: website-normal ---- - -We've seen the configuration of machines and how to build up clusters. -Now let's return to our app-server example and explore how more interesting -services can be configured, composed, and combined. - - -### Service Configuration - -We'll begin by using more key-value pairs to configure the JBoss server to run a real app: - -{% highlight yaml %} -{% readj example_yaml/appserver-configured.yaml %} -{% endhighlight %} - -(As before, you'll need to add the `location` info; `localhost` will work for these and subsequent examples.) - -When this is deployed, you can see management information in the Brooklyn Web Console, -including a link to the deployed application (downloaded to the target machine from the `hello-world` URL), -running on port 8080. - -**Tip**: If port 8080 might be in use, you can specify `8080+` to take the first available port >= 8080; -the actual port will be reported as a sensor by Brooklyn. - -It's also worth indicating an alternate, more formal syntax. -Not all configuration on entities is supported at the top level of the service specification -(only those which are defined as "flags" in the underlying blueprint, -e.g. the `@SetFromFlag("war")` in the `WebAppServiceConstants` parent of `JBoss7Server`). -All configuration has a formal qualified name, and this can be supplied even where flags or config keys are not -explicitly defined, by placing it into a `brooklyn.config` section: - -{% highlight yaml %} -{% readj example_yaml/appserver-configured-in-config.yaml %} -{% endhighlight %} - - -### Multiple Services - -If you explored the `hello-world-sql` application we just deployed, -you'll have noticed it tries to access a database. -And it fails, because we have not set one up. Let's do that now: - -{% highlight yaml %} -{% readj example_yaml/appserver-w-db.yaml %} -{% endhighlight %} - -Here there are a few things going on: - -* We've added a second service, which will be the database; - you'll note the database has been configured to run a custom setup script -* We've injected the URL of the second service into the appserver as a Java system property - (so our app knows where to find the database) - -**Caution: Be careful if you write your YAML in an editor which attempts to put "smart-quotes" in. -All quote characters must be plain ASCII, not fancy left-double-quotes and right-double-quotes!** - -There are as many ways to do dependency injection as there are developers, -it sometimes seems; our aim in Brooklyn is not to say this has to be done one way, -but to support the various mechanisms people might need, for whatever reasons. -(We each have our opinions about what works well, of course; -the one thing we do want to call out is that being able to dynamically update -the injection is useful in a modern agile application -- so we are definitively **not** -recommending this Java system property approach ... but it is an easy one to demo!) - -The way the dependency injection works is again by using the `$brooklyn:` DSL, -this time referring to the `component("db")` (looked up by the `id` field on our DB component), -and then to a sensor emitted by that component. -All the database entities emit a `database.url` sensor when they are up and running; -the `attributeWhenReady` DSL method will store a pointer to that sensor (a Java Future under the covers) -in the Java system properties map which the JBoss entity reads at launch time, blocking if needed. - -This means that the deployment occurs in parallel, and if the database comes up first, -there is no blocking; but if the JBoss entity completes its installation and -downloading the WAR, it will wait for the database before it launches. -At that point the URL is injected, first passing it through `formatString` -to include the credentials for the database (which are defined in the database creation script). - - -### An Aside: Substitutability - -Don't like JBoss? Is there something about Maria? -One of the modular principles we follow in Brooklyn is substitutability: -in many cases, the config keys, sensors, and effectors are defined -in superclasses and are portable across multiple implementations. - -Here's an example deploying the same application but with different flavors of the components: - -{% highlight yaml %} -{% readj example_yaml/appserver-w-db-other-flavor.yaml %} -{% endhighlight %} - -We've also brought in the `provisioning.properties` from the VM example earlier -so our database has 8GB RAM. -Any of those properties, including `imageId` and `user`, can be defined on a per-entity basis. http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/f38b9e7b/guide/yaml/salt/about-salt.md ---------------------------------------------------------------------- diff --git a/guide/yaml/salt/about-salt.md b/guide/yaml/salt/about-salt.md deleted file mode 100644 index 78f4d47..0000000 --- a/guide/yaml/salt/about-salt.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: About Salt -title_in_menu: About Salt -layout: website-normal ---- - -## What you need to know about Salt - -Salt is designed to work in either what it calls a 'master/minion' or a 'masterless' topology. - -In the former, the master server acts as a managing controller for any number of client nodes, called 'minions'. -A salt daemon running on the minion connects back to the master server for its operation, and manages the software on -the minion according to a specification of 'states' defined in Salt configuration files. In the latter, there is no -master, and the salt daemon on the minion operates based on the Salt files on the minion node. This is the mode -currently supported by Brooklyn. - -A 'State' in Salt is a specification of a configuration of some aspect of a system, such as what packages are installed, -what system services are running, what files exist, etc. Such states are described in "SLS" files (for SaLt State -file). These files are typically written as templates using the "Jinja" templating engine. The actual SLS files for the -minion are then created by processing the templates using configuration data provided via Salt's "Pillar" system. - -Salt comes with built-in support for many software systems, and has a repository of pre-written Salt states known as -'formulas' on GitHub, at [https://github.com/saltstack-formulas](https://github.com/saltstack-formulas). - -### How Brooklyn interacts with Salt - -Brooklyn provides a Salt entity type. An entity of this type can be specified in a blueprint in order to provision the -node through Salt. The Salt entity will download Salt and install it on the node. The entity type supports the -configuration of Salt formulas and Pillar data to download, and the configuration of what Salt states to apply. -These are managed using Salt in 'masterless' mode, as described on the -[Saltstack site](https://docs.saltstack.com/en/latest/topics/tutorials/quickstart.html#salt-masterless-quickstart), -using the 'salt-call' functionality of Salt. - -The Salt 'highstate' (the collection of states applied to the system) is exposed as a sensor on the entity. An effector - is provided on the entity that supports general purpose Salt instructions. - - -
