http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-dist/downstream-parent/pom.xml ---------------------------------------------------------------------- diff --cc brooklyn-dist/downstream-parent/pom.xml index 0000000,6580281..c1731fd mode 000000,100644..100644 --- a/brooklyn-dist/downstream-parent/pom.xml +++ b/brooklyn-dist/downstream-parent/pom.xml @@@ -1,0 -1,506 +1,519 @@@ + <?xml version="1.0" encoding="UTF-8"?> + <!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + --> + <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn</artifactId> + <version>0.9.0-SNAPSHOT</version> <!-- BROOKLYN_VERSION --> + <relativePath>../../pom.xml</relativePath> + </parent> + + <artifactId>brooklyn-downstream-parent</artifactId> + <packaging>pom</packaging> + <name>Brooklyn Downstream Project Parent</name> + <description> + Parent pom that can be used by downstream projects that use Brooklyn, + or that contribute additional functionality to Brooklyn. + </description> + + <properties> + <!-- Compilation --> + <java.version>1.7</java.version> + <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> + <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> + + <!-- Testing --> + <testng.version>6.8.8</testng.version> + <surefire.version>2.18.1</surefire.version> + <includedTestGroups /> + <excludedTestGroups>Integration,Acceptance,Live,Live-sanity,WIP</excludedTestGroups> + + <!-- Dependencies --> + <brooklyn.version>0.9.0-SNAPSHOT</brooklyn.version> <!-- BROOKLYN_VERSION --> + <jclouds.groupId>org.apache.jclouds</jclouds.groupId> <!-- JCLOUDS_GROUPID_VERSION --> + + <!-- versions should match those used by Brooklyn, to avoid conflicts --> + <jclouds.version>1.9.1</jclouds.version> <!-- JCLOUDS_VERSION --> + <logback.version>1.0.7</logback.version> + <slf4j.version>1.6.6</slf4j.version> <!-- used for java.util.logging jul-to-slf4j interception --> + <guava.version>17.0</guava.version> + <xstream.version>1.4.7</xstream.version> + <jackson.version>1.9.13</jackson.version> <!-- codehaus jackson, used by brooklyn rest server --> + <fasterxml.jackson.version>2.4.5</fasterxml.jackson.version> <!-- more recent jackson, but not compatible with old annotations! --> + <jersey.version>1.19</jersey.version> + <httpclient.version>4.4.1</httpclient.version> + <commons-lang3.version>3.1</commons-lang3.version> + <groovy.version>2.3.7</groovy.version> <!-- Version supported by https://github.com/groovy/groovy-eclipse/wiki/Groovy-Eclipse-2.9.1-Release-Notes --> + <jsr305.version>2.0.1</jsr305.version> + <snakeyaml.version>1.11</snakeyaml.version> + </properties> + + <dependencyManagement> + <dependencies> + <dependency> + <!-- this would pull in all brooklyn entities and clouds; + you can cherry pick selected ones instead (for a smaller build) --> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-all</artifactId> + <version>${brooklyn.version}</version> + </dependency> + </dependencies> + </dependencyManagement> + + <dependencies> + <dependency> + <!-- this gives us flexible and easy-to-use logging; just edit logback-custom.xml! --> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-logback-xml</artifactId> + <version>${brooklyn.version}</version> + <!-- optional so that this project has logging; dependencies may redeclare or supply their own; + provided so that it isn't put into the assembly (as it supplies its own explicit logback.xml); + see Logging in the Brooklyn website/userguide for more info --> + <optional>true</optional> + <scope>provided</scope> + </dependency> + <dependency> + <!-- includes testng and useful logging for tests --> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-test-support</artifactId> + <version>${brooklyn.version}</version> + <scope>test</scope> + </dependency> + <dependency> + <!-- includes org.apache.brooklyn.test.support.LoggingVerboseReporter --> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-utils-test-support</artifactId> + <version>${brooklyn.version}</version> + <scope>test</scope> + </dependency> + </dependencies> + + <build> + <testSourceDirectory>src/test/java</testSourceDirectory> + <testResources> + <testResource> + <directory>src/test/resources</directory> + </testResource> + </testResources> + + <pluginManagement> + <plugins> + <plugin> + <artifactId>maven-assembly-plugin</artifactId> + <version>2.5.4</version> + <configuration> + <tarLongFileMode>gnu</tarLongFileMode> + </configuration> + </plugin> + <plugin> + <artifactId>maven-clean-plugin</artifactId> + <version>2.6.1</version> + </plugin> + <plugin> + <artifactId>maven-compiler-plugin</artifactId> + <version>3.3</version> + <configuration> + <source>${java.version}</source> + <target>${java.version}</target> + </configuration> + </plugin> + <plugin> + <artifactId>maven-deploy-plugin</artifactId> + <version>2.8.2</version> + </plugin> + <plugin> + <artifactId>maven-eclipse-plugin</artifactId> + <version>2.10</version> + </plugin> + <plugin> + <artifactId>maven-enforcer-plugin</artifactId> + <version>1.4</version> + </plugin> + <plugin> + <artifactId>maven-failsafe-plugin</artifactId> + <version>2.18.1</version> + </plugin> + <plugin> + <artifactId>maven-gpg-plugin</artifactId> + <version>1.6</version> + </plugin> + <plugin> + <artifactId>maven-jar-plugin</artifactId> + <version>2.6</version> + </plugin> + <plugin> + <artifactId>maven-javadoc-plugin</artifactId> + <version>2.10.3</version> + </plugin> + <plugin> + <artifactId>maven-resources-plugin</artifactId> + <version>2.7</version> + </plugin> + <plugin> + <artifactId>maven-source-plugin</artifactId> + <version>2.4</version> + </plugin> + <plugin> + <artifactId>maven-surefire-plugin</artifactId> + <version>2.18.1</version> + </plugin> + <plugin> + <groupId>org.apache.felix</groupId> + <artifactId>maven-bundle-plugin</artifactId> + <version>2.3.4</version> + </plugin> + <!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.--> + <plugin> + <groupId>org.eclipse.m2e</groupId> + <artifactId>lifecycle-mapping</artifactId> + <version>1.0.0</version> + <configuration> + <lifecycleMappingMetadata> + <pluginExecutions> + <pluginExecution> + <pluginExecutionFilter> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-assembly-plugin</artifactId> + <versionRange>[2.4.1,)</versionRange> + <goals> + <goal>single</goal> + </goals> + </pluginExecutionFilter> + <action> + <ignore /> + </action> + </pluginExecution> + <pluginExecution> + <pluginExecutionFilter> + <groupId>org.codehaus.mojo</groupId> + <artifactId>build-helper-maven-plugin</artifactId> + <versionRange>[1.7,)</versionRange> + <goals> + <goal>attach-artifact</goal> + </goals> + </pluginExecutionFilter> + <action> + <ignore /> + </action> + </pluginExecution> + <pluginExecution> + <pluginExecutionFilter> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-enforcer-plugin</artifactId> + <versionRange>[1.3.1,)</versionRange> + <goals> + <goal>enforce</goal> + </goals> + </pluginExecutionFilter> + <action> + <ignore /> + </action> + </pluginExecution> + <pluginExecution> + <pluginExecutionFilter> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-remote-resources-plugin</artifactId> + <versionRange>[1.5,)</versionRange> + <goals> + <goal>process</goal> + </goals> + </pluginExecutionFilter> + <action> + <ignore /> + </action> + </pluginExecution> + <pluginExecution> + <pluginExecutionFilter> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-dependency-plugin</artifactId> + <versionRange>[2.8,)</versionRange> + <goals> + <goal>unpack</goal> + <goal>copy</goal> + </goals> + </pluginExecutionFilter> + <action> + <ignore /> + </action> + </pluginExecution> + <pluginExecution> + <pluginExecutionFilter> + <groupId>com.github.skwakman.nodejs-maven-plugin</groupId> + <artifactId>nodejs-maven-plugin</artifactId> + <versionRange>[1.0.3,)</versionRange> + <goals> + <goal>extract</goal> + </goals> + </pluginExecutionFilter> + <action> + <ignore /> + </action> + </pluginExecution> + <pluginExecution> + <pluginExecutionFilter> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-war-plugin</artifactId> + <versionRange>[2.4,)</versionRange> + <goals> + <goal>exploded</goal> + </goals> + </pluginExecutionFilter> + <action> + <ignore /> + </action> + </pluginExecution> + </pluginExecutions> + </lifecycleMappingMetadata> + </configuration> + </plugin> + </plugins> + </pluginManagement> + + <plugins> + <plugin> + <artifactId>maven-clean-plugin</artifactId> + <configuration> + <filesets> + <fileset> + <directory>.</directory> + <includes> + <include>brooklyn*.log</include> + <include>brooklyn*.log.*</include> + <include>stacktrace.log</include> + <include>test-output</include> + <include>prodDb.*</include> + </includes> + </fileset> + </filesets> + </configuration> + </plugin> + + <plugin> + <artifactId>maven-resources-plugin</artifactId> + </plugin> + + <plugin> + <artifactId>maven-eclipse-plugin</artifactId> + <configuration> + <additionalProjectnatures> + <projectnature>org.maven.ide.eclipse.maven2Nature</projectnature> + </additionalProjectnatures> + </configuration> + </plugin> + + <plugin> + <artifactId>maven-surefire-plugin</artifactId> + <configuration> + <argLine>-Xms256m -Xmx512m -XX:MaxPermSize=512m</argLine> + <properties> + <property> + <name>listener</name> + <value>org.apache.brooklyn.test.support.LoggingVerboseReporter</value> + </property> + </properties> + <enableAssertions>true</enableAssertions> + <groups>${includedTestGroups}</groups> + <excludedGroups>${excludedTestGroups}</excludedGroups> + <testFailureIgnore>false</testFailureIgnore> + <systemPropertyVariables> + <verbose>-1</verbose> + <net.sourceforge.cobertura.datafile>${project.build.directory}/cobertura/cobertura.ser</net.sourceforge.cobertura.datafile> + <cobertura.user.java.nio>false</cobertura.user.java.nio> + </systemPropertyVariables> + <printSummary>true</printSummary> + </configuration> + </plugin> + </plugins> + </build> + + <profiles> + + <profile> + <id>Tests</id> + <activation> + <file> <exists>${basedir}/src/test</exists> </file> + </activation> + <build> + <plugins> + <plugin> + <artifactId>maven-jar-plugin</artifactId> + <inherited>true</inherited> + <executions> + <execution> + <id>test-jar-creation</id> + <goals> + <goal>test-jar</goal> + </goals> + <configuration> + <forceCreation>true</forceCreation> + <archive combine.self="override" /> + </configuration> + </execution> + </executions> + </plugin> + </plugins> + </build> + </profile> + + <!-- run Integration tests with -PIntegration --> + <profile> + <id>Integration</id> + <properties> + <includedTestGroups>Integration</includedTestGroups> + <excludedTestGroups>Acceptance,Live,Live-sanity,WIP</excludedTestGroups> + </properties> + </profile> + + <!-- run Live tests with -PLive --> + <profile> + <id>Live</id> + <properties> + <includedTestGroups>Live,Live-sanity</includedTestGroups> + <excludedTestGroups>Acceptance,WIP</excludedTestGroups> + </properties> + </profile> + + <!-- run Live-sanity tests with -PLive-sanity --> + <profile> + <id>Live-sanity</id> + <properties> + <includedTestGroups>Live-sanity</includedTestGroups> + <excludedTestGroups>Acceptance,WIP</excludedTestGroups> + </properties> + <build> + <plugins> + <plugin> + <artifactId>maven-jar-plugin</artifactId> + <executions> + <execution> + <id>test-jar-creation</id> + <configuration> + <skip>true</skip> + </configuration> + </execution> + </executions> + </plugin> + </plugins> + </build> + </profile> + + <profile> + <id>Bundle</id> + <activation> + <file> + <!-- NB - this is all the leaf projects, including logback-* (with no src); + the archetype project neatly ignores this however --> + <exists>${basedir}/src</exists> + </file> + </activation> + <build> + <plugins> + <plugin> + <groupId>org.apache.felix</groupId> + <artifactId>maven-bundle-plugin</artifactId> + <extensions>true</extensions> + <!-- configure plugin to generate MANIFEST.MF + adapted from http://blog.knowhowlab.org/2010/06/osgi-tutorial-from-project-structure-to.html --> + <executions> + <execution> + <id>bundle-manifest</id> + <phase>process-classes</phase> + <goals> + <goal>manifest</goal> + </goals> + </execution> + </executions> + <configuration> + <supportedProjectTypes> + <supportedProjectType>jar</supportedProjectType> + </supportedProjectTypes> + <instructions> - <!-- OSGi specific instruction --> + <!-- - By default packages containing impl and internal - are not included in the export list. Setting an - explicit wildcard will include all packages - regardless of name. - In time we should minimize our export lists to - what is really needed. ++ Exclude packages used by Brooklyn that are not OSGi bundles. Including any ++ of the below may cause bundles to fail to load into the catalogue with ++ messages like "Unable to resolve 150.0: missing requirement [150.0] ++ osgi.wiring.package; (osgi.wiring.package=com.maxmind.geoip2)". ++ --> ++ <Import-Package> ++ !com.maxmind.geoip2.*, ++ !io.airlift.command.*, ++ !io.cloudsoft.winrm4j.*, ++ !javax.inject.*, ++ !org.apache.felix.framework.*, ++ !org.apache.http.*, ++ !org.jclouds.googlecomputeengine.*, ++ !org.osgi.jmx, ++ !org.python.*, ++ !org.reflections.*, ++ !org.w3c.tidy.*, ++ * ++ </Import-Package> ++ <!-- ++ Brooklyn-Feature prefix triggers inclusion of the project's metadata in the ++ server's features list. + --> - <Export-Package>brooklyn.*,org.apache.brooklyn.*</Export-Package> - <!-- Brooklyn-Feature prefix triggers inclusion of the project's metadata in the server's features list. --> + <Brooklyn-Feature-Name>${project.name}</Brooklyn-Feature-Name> + </instructions> + </configuration> + </plugin> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-jar-plugin</artifactId> + <configuration> + <archive> + <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile> + </archive> + </configuration> + </plugin> + </plugins> + </build> + </profile> + + <!-- different properties used to deploy to different locations depending on profiles; + default is cloudsoft filesystem repo, but some sources still use cloudsoft artifactory as source + and soon we will support artifactory. use this profile for the ASF repositories and + sonatype-oss-release profile for the Sonatype OSS repositories. + --> + <!-- profile> + <id>apache-release</id> + <activation> + <property> + <name>brooklyn.deployTo</name> + <value>apache</value> + </property> + </activation> + <distributionManagement> + <repository> + <id>apache.releases.https</id> + <name>Apache Release Distribution Repository</name> + <url>https://repository.apache.org/service/local/staging/deploy/maven2</url> + </repository> + <snapshotRepository> + <id>apache.snapshots.https</id> + <name>Apache Development Snapshot Repository</name> + <url>https://repository.apache.org/content/repositories/snapshots</url> + </snapshotRepository> + </distributionManagement> + </profile --> + </profiles> + + </project>
http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-docs/guide/dev/env/ide/eclipse.include.md ---------------------------------------------------------------------- diff --cc brooklyn-docs/guide/dev/env/ide/eclipse.include.md index 0000000,1b663d1..c3a7a06 mode 000000,100644..100644 --- a/brooklyn-docs/guide/dev/env/ide/eclipse.include.md +++ b/brooklyn-docs/guide/dev/env/ide/eclipse.include.md @@@ -1,0 -1,6 +1,6 @@@ + - Groovy Plugin: GRECLIPSE from + [dist.springsource.org/snapshot/GRECLIPSE/e4.5/](http://dist.springsource.org/snapshot/GRECLIPSE/e4.5/); + Be sure to include Groovy 2.3 compiler support and Maven-Eclipse (m2e) support. - More details including download sites for other versions can be found at the [Groovy Eclipse Plugin site](http://groovy.codehaus.org/Eclipse+Plugin). ++ More details including download sites for other versions can be found at the [Groovy Eclipse Plugin site](http://docs.groovy-lang.org/latest/html/documentation/#section-groovyeclipse). + + - TestNG Plugin: beust TestNG from [beust.com/eclipse](http://beust.com/eclipse) http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-docs/guide/ops/brooklyn_properties.md ---------------------------------------------------------------------- diff --cc brooklyn-docs/guide/ops/brooklyn_properties.md index 0000000,cb00ceb..e8335f1 mode 000000,100644..100644 --- a/brooklyn-docs/guide/ops/brooklyn_properties.md +++ b/brooklyn-docs/guide/ops/brooklyn_properties.md @@@ -1,0 -1,213 +1,236 @@@ + --- + title: brooklyn.properties + layout: website-normal + children: + - { section: Quick Setup } + - { section: Locations } + - { section: Java } + - { section: Authentication } + - { section: Entitlements } + - { section: HTTPS Configuration } + --- + + {% include fields.md %} + + The file `~/.brooklyn/brooklyn.properties` is read when Brooklyn starts + to load server configuration values. + A different properties file can be specified either additionally or instead + through [CLI options](launch.html#configuration-files). + + A template [brooklyn.properties]({{brooklyn_properties_url_path}}) file is available, + with abundant comments. + + + ## Quick Setup + + The most common properties set in this file are for access control. + Without this, Brooklyn will bind only to localhost or will create a random + password written to the log for use on other networks. + The simplest way to specify users and passwords is: + + {% highlight properties %} + brooklyn.webconsole.security.users=admin,bob + brooklyn.webconsole.security.user.admin.password=AdminPassw0rd + brooklyn.webconsole.security.user.bob.password=BobPassw0rd + {% endhighlight %} + + The properties file *must* have permissions 600 + (i.e. readable and writable only by the file's owner), + for some security. + + In many cases, it is preferable instead to use an external credentials store such as LDAP + or at least to have passwords in this file. + Information on configuring these is [below](#authentication). + + If coming over a network it is highly recommended additionally to use `https`. + This can be configured with: + + {% highlight properties %} + brooklyn.webconsole.security.https.required=true + {% endhighlight %} + + More information, including setting up a certificate, is described [further below](#https-configuration). + + ++## Camp YAML Expressions ++ ++Values in `brooklyn.properties` can use the Camp YAML syntax. Any value starting `$brooklyn:` is ++parsed as a Camp YAML expression. ++ ++This allows [externalized configuration](externalized-configuration.html) to be used from ++brooklyn.properties. For example: ++ ++{% highlight properties %} ++brooklyn.location.jclouds.aws-ec2.identity=$brooklyn:external("vault", "aws-identity") ++brooklyn.location.jclouds.aws-ec2.credential=$brooklyn:external("vault", "aws-credential") ++{% endhighlight %} ++ ++If for some reason one requires a literal value that really does start with `$brooklyn:` (i.e. ++for the value to not be parsed), then this can be achieved by using the syntax below. This ++example returns the property value `$brooklyn:myexample`: ++ ++{% highlight properties %} ++example.property=$brooklyn:literal("$brooklyn:myexample") ++{% endhighlight %} ++ ++ + ## Locations + + Information on defining locations in the `brooklyn.properties` file is available [here](locations/). + + + ## Java + + Arbitrary data can be set in the `brooklyn.properties`. + This can be accessed in java using `ManagementContext.getConfig(KEY)`. + + + ## Authentication + + **Security Providers** are the mechanism by which different authentication authorities are plugged in to Brooklyn. + These can be configured by specifying `brooklyn.webconsole.security.provider` equal + to the name of a class implementing `SecurityProvider`. + An implementation of this could point to Spring, LDAP, OpenID or another identity management system. + + The default implementation, `ExplicitUsersSecurityProvider`, reads from a list of users and passwords + which should be specified as configuration parameters e.g. in `brooklyn.properties`. + This configuration could look like: + + {% highlight properties %} + brooklyn.webconsole.security.users=admin + brooklyn.webconsole.security.user.admin.salt=OHDf + brooklyn.webconsole.security.user.admin.sha256=91e16f94509fa8e3dd21c43d69cadfd7da6e7384051b18f168390fe378bb36f9 + {% endhighlight %} + + The `users` line should contain a comma-separated list. The special value `*` is accepted to permit all users. + + To generate this, the brooklyn CLI can be used: ++ + {% highlight bash %} + brooklyn generate-password --user admin + + Enter password: + Re-enter password: + + Please add the following to your brooklyn.properies: + + brooklyn.webconsole.security.users=admin + brooklyn.webconsole.security.user.admin.salt=OHDf + brooklyn.webconsole.security.user.admin.sha256=91e16f94509fa8e3dd21c43d69cadfd7da6e7384051b18f168390fe378bb36f9 + {% endhighlight %} + + Alternatively, in dev/test environments where a lower level of security is required, + the syntax `brooklyn.webconsole.security.user.<username>=<password>` can be used for + each `<username>` specified in the `brooklyn.webconsole.security.users` list. + + Other security providers available include: + + ### No one + + `brooklyn.webconsole.security.provider=org.apache.brooklyn.rest.security.provider.BlackholeSecurityProvider` + will block all logins (e.g. if not using the web console) + + ### No security + + `brooklyn.webconsole.security.provider=org.apache.brooklyn.rest.security.provider.AnyoneSecurityProvider` + will allow logins with no credentials (e.g. in secure dev/test environments) + + ### LDAP + + `brooklyn.webconsole.security.provider=org.apache.brooklyn.rest.security.provider.LdapSecurityProvider` + will cause Brooklyn to call to an LDAP server to authenticate users; + The other things you need to set in `brooklyn.properties` are: + + * `brooklyn.webconsole.security.ldap.url` - ldap connection url + * `brooklyn.webconsole.security.ldap.realm` - ldap dc parameter (domain) + * `brooklyn.webconsole.security.ldap.ou` *optional, by default it set to Users* - ldap ou parameter + + **brooklyn.properties example configuration:** + + ``` + brooklyn.webconsole.security.provider=org.apache.brooklyn.rest.security.provider.LdapSecurityProvider + brooklyn.webconsole.security.ldap.url=ldap://localhost:10389/????X-BIND-USER=uid=admin%2cou=system,X-BIND-PASSWORD=secret,X-COUNT-LIMIT=1000 + brooklyn.webconsole.security.ldap.realm=example.com + ``` + + After you setup the brooklyn connection to your LDAP server, you can authenticate in brooklyn using your cn (e.g. John Smith) and your password. + `org.apache.brooklyn.rest.security.provider.LdapSecurityProvider` searches in the LDAP tree in LDAP://cn=John Smith,ou=Users,dc=example,dc=com + + If you want to customize the ldap path or something else which is particular to your LDAP setup you can extend `LdapSecurityProvider` class or implement from scratch the `SecurityProvider` interface. + + ## Entitlements + + In addition to login access, fine-grained permissions -- including + seeing entities, creating applications, seeing sensors, and invoking effectors -- + can be defined on a per-user *and* per-target (e.g. which entity/effector) basis + using a plug-in **Entitlement Manager**. + + This can be set globally with the property: + + {% highlight properties %} + brooklyn.entitlements.global=<class> + {% endhighlight %} + + The default entitlement manager is one which responds to per-user entitlement rules, + and understands: + + * `root`: full access, including to the Groovy console + * `readonly`: read-only access to almost all information + * `minimal`: access only to server stats, for use by monitoring systems + + These keywords are also understood at the `global` level, so to grant full access to `admin` + but limited access to other authenticated users and `readonly, + you can write: + + {% highlight properties %} + brooklyn.entitlements.global=readonly + brooklyn.entitlements.perUser.admin=root + brooklyn.entitlements.perUser.support=readonly + brooklyn.entitlements.perUser.metrics=minimal + {% endhighlight %} + + Under the covers this invokes the `PerUserEntitlementManager`, + with a `default` set (and if not specified `default` defaults to `minimal`); + so the above can equivalently be written: + + {% highlight properties %} + brooklyn.entitlements.global=org.apache.brooklyn.core.mgmt.entitlement.PerUserEntitlementManager + brooklyn.entitlements.perUser.default=readonly + brooklyn.entitlements.perUser.admin=root + brooklyn.entitlements.perUser.support=readonly + brooklyn.entitlements.perUser.metrics=minimal + {% endhighlight %} + + For more information, see + [Java: Entitlements]({{ site.path.guide }}/java/entitlements.html). + or + {% include java_link.html class_name="EntitlementManager" package_path="org/apache/brooklyn/api/mgmt/entitlement" project_subpath="api" %}. + + + + ## HTTPS Configuration + + To enable https, you will need a server certificate in a java keystore. To create a self-signed certificate, you can use the + following command: + + {% highlight bash %} + % keytool -genkey -keyalg RSA -alias brooklyn -keystore <path-to-keystore-directory>/server.key -storepass mypassword -validity 360 -keysize 2048 + {% endhighlight %} + + You will then be prompted to enter you name and organization details. This will create a keystore with the password `mypassword` + - you should use your own secure password, which will be the same password used in your brooklyn.properties (below). + You will also need to replace `<path-to-keystore-directory>` with the full path of the folder where you wish to store your + keystore. + + The certificate generated will be a self-signed certificate and will not have a CN field identifying the website server + name, which will cause a warning to be displayed by the browser when viewing the page. For production servers, a valid signed + certificate from a trusted certifying authority should be used instead + + To enable HTTPS in Brooklyn, add the following to your brooklyn.properties: + + {% highlight properties %} + brooklyn.webconsole.security.https.required=true + brooklyn.webconsole.security.keystore.url=<path-to-keystore-directory>/server.key + brooklyn.webconsole.security.keystore.password=mypassword + brooklyn.webconsole.security.keystore.certificate.alias=brooklyn + {% endhighlight %} http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-docs/guide/ops/externalized-configuration.md ---------------------------------------------------------------------- diff --cc brooklyn-docs/guide/ops/externalized-configuration.md index 0000000,3a80499..ea6c63c mode 000000,100644..100644 --- a/brooklyn-docs/guide/ops/externalized-configuration.md +++ b/brooklyn-docs/guide/ops/externalized-configuration.md @@@ -1,0 -1,225 +1,236 @@@ + --- + title: Externalized Configuration + layout: website-normal + --- + + Sometimes it is useful that configuration in a blueprint, or in Brooklyn itself, is not given explicitly, but is instead + replaced with a reference to some other storage system. For example, it is undesirable for a blueprint to contain a + plain-text password for a production system, especially if (as we often recommend) the blueprints are kept in the + developer's source code control system. + + To handle this problem, Apache Brooklyn supports externalized configuration. This allows a blueprint to refer to + a piece of information that is stored elsewhere. `brooklyn.properties` defines the external suppliers of configuration + information. At runtime, when Brooklyn finds a reference to externalized configuration in a blueprint, it consults + `brooklyn.properties` for information about the supplier, and then requests that the supplier return the information + required by the blueprint. + + Take, as a simple example, a web app which connects to a database. In development, the developer is running a local + instance of PostgreSQL with a simple username and password. But in production, an enterprise-grade cluster of PostgreSQL + is used, and a dedicated service is used to provide passwords. The same blueprint can be used to service both groups + of users, with `brooklyn.properties` changing the behaviour depending on the deployment environment. + + Here is the blueprint: + + {% highlight yaml %} + name: MyApplication + services: + - type: brooklyn.entity.webapp.jboss.JBoss7Server + name: AppServer HelloWorld + brooklyn.config: + wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war + http.port: 8080+ + java.sysprops: + brooklyn.example.db.url: $brooklyn:formatString("jdbc:postgresql://%s/myappdb?user=%s\\&password=%s", + external("servers", "postgresql"), external("credentials", "postgresql-user"), external("credentials", "postgresql-password")) + {% endhighlight %} + + You can see that when we are building up the JDBC URL, we are using the `external` function. This takes two parameters: + the first is the name of the configuration supplier, the second is the name of a key that is stored by the configuration + supplier. In this case we are using two different suppliers: `servers` to store the location of the server, and + `credentials` which is a security-optimized supplier of secrets. + + Developers would add lines like this to the `brooklyn.properties` file on their workstation: + + {% highlight properties %} + brooklyn.external.servers=org.apache.brooklyn.core.config.external.InPlaceExternalConfigSupplier + brooklyn.external.servers.postgresql=127.0.0.1 + brooklyn.external.credentials=org.apache.brooklyn.core.config.external.InPlaceExternalConfigSupplier + brooklyn.external.credentials.postgresql-user=admin + brooklyn.external.credentials.postgresql-password=admin + {% endhighlight %} + + In this case, all of the required information is included in-line in the local `brooklyn.properties`. + + Whereas in production, `brooklyn.properties` might look like this: + + {% highlight properties %} + brooklyn.external.servers=org.apache.brooklyn.core.config.external.PropertiesFileExternalConfigSupplier + brooklyn.external.servers.propertiesUrl=https://ops.example.com/servers.properties + brooklyn.external.credentials=org.apache.brooklyn.core.config.external.vault.VaultAppIdExternalConfigSupplier + brooklyn.external.credentials.endpoint=https://vault.example.com + brooklyn.external.credentials.path=secret/enterprise-postgres + brooklyn.external.credentials.appId=MyApp + {% endhighlight %} + + In this case, the list of servers is stored in a properties file located on an Operations Department web server, and the + credentials are stored in an instance of [Vault](https://www.vaultproject.io/). + + ## Defining Suppliers + + External configuration suppliers are defined in `brooklyn.properties`. The minimal definition is of the form: + + brooklyn.external.*supplierName* = *className* + + This defines a supplier named *supplierName*. Brooklyn will attempt to instantiate *className*; it is this class which + will provide the behaviour of how to retrieve data from the supplier. Brooklyn includes a number of supplier + implementations; see below for more details. + + Suppliers may require additional configuration options. These are given as additional properties in + `brooklyn.properties`: + + {% highlight properties %} + brooklyn.external.supplierName = className + brooklyn.external.supplierName.firstConfig = value + brooklyn.external.supplierName.secondConfig = value + {% endhighlight %} + + ## Referring to External Configuration in Blueprints + + Externalized configuration adds a new function to the Brooklyn blueprint language DSL, `$brooklyn:external`. This + function takes two parameters: + + 1. supplier + 2. key + + When resolving the external reference, Brooklyn will first identify the *supplier* of the information, then it will + give the supplier the *key*. The returned value will be substituted into the blueprint. + + You can use `$brooklyn:external` directly: + + {% highlight yaml %} + name: MyApplication + brooklyn.config: + example: $brooklyn:external("supplier", "key") + {% endhighlight %} + + or embed the `external` function inside another `$brooklyn` DSL function, such as `$brooklyn:formatString`: + + {% highlight yaml %} + name: MyApplication + brooklyn.config: + example: $brooklyn:formatString("%s", external("supplier", "key")) + {% endhighlight %} + ++ ++## Referring to External Configuration in brooklyn.properties ++ ++The same blueprint language DSL can be used from `brooklyn.properties`. For example: ++ ++{% highlight properties %} ++brooklyn.location.jclouds.aws-ec2.identity=$brooklyn:external("mysupplier", "aws-identity") ++brooklyn.location.jclouds.aws-ec2.credential=$brooklyn:external("mysupplier", "aws-credential") ++{% endhighlight %} ++ ++ + ## Suppliers available with Brooklyn + + Brooklyn ships with a number of external configuration suppliers ready to use. + + ### In-place + + **InPlaceExternalConfigSupplier** embeds the configuration keys and values as properties inside `brooklyn.properties`. + For example: + + {% highlight properties %} + brooklyn.external.servers=org.apache.brooklyn.core.config.external.InPlaceExternalConfigSupplier + brooklyn.external.servers.postgresql=127.0.0.1 + {% endhighlight %} + + Then, a blueprint which referred to `$brooklyn:external("servers", "postgresql")` would receive the value `127.0.0.1`. + + ### Properties file + + **PropertiesFileExternalConfigSupplier** loads a properties file from a URL, and uses the keys and values in this + file to respond to configuration lookups. + + Given this configuration: + + {% highlight properties %} + brooklyn.external.servers=org.apache.brooklyn.core.config.external.PropertiesFileExternalConfigSupplier + brooklyn.external.servers.propertiesUrl=https://ops.example.com/servers.properties + {% endhighlight %} + + This would cause the supplier to download the given URL. Assuming that the file contained this entry: + + {% highlight properties %} + postgresql=127.0.0.1 + {% endhighlight %} + + Then, a blueprint which referred to `$brooklyn:external("servers", "postgresql")` would receive the value `127.0.0.1`. + + ### Vault + + [Vault](https://www.vaultproject.io) is a server-based tool for managing secrets. Brooklyn provides suppliers that are + able to query the Vault REST API for configuration values. The different suppliers implement alternative authentication + options that Vault provides. + + For *all* of the authentication methods, you must always set these properties in `brooklyn.properties`: + + {% highlight properties %} + brooklyn.external.supplierName.endpoint=<Vault HTTP/HTTPs endpoint> + brooklyn.external.supplierName.path=<path to a Vault object> + {% endhighlight %} + + For example, if the path is set to `secret/brooklyn`, then attempting to retrieve the key `foo` would cause Brooklyn + to retrieve the value of the `foo` key on the `secret/brooklyn` object. This value can be set using the Vault CLI + like this: + + {% highlight bash %} + vault write secret/brooklyn foo=bar + {% endhighlight %} + + #### Authentication by username and password + + The `userpass` plugin for Vault allows authentication with username and password. + + {% highlight properties %} + brooklyn.external.supplierName=org.apache.brooklyn.core.config.external.vault.VaultUserPassExternalConfigSupplier + brooklyn.external.supplierName.username=fred + brooklyn.external.supplierName.password=s3kr1t + {% endhighlight %} + + #### Authentication using App ID + + The `app_id` plugin for Vault allows you to specify an "app ID", and then designate particular "user IDs" to be part + of the app. Typically the app ID would be known and shared, but user ID would be autogenerated on the client in some + way. Brooklyn implements this by determining the MAC address of the server running Brooklyn (expressed as 12 lower + case hexadecimal digits without separators) and passing this as the user ID. + + {% highlight properties %} + brooklyn.external.supplierName=org.apache.brooklyn.core.config.external.vault.VaultAppIdExternalConfigSupplier + brooklyn.external.supplierName.appId=MyApp + {% endhighlight %} + + If you do not wish to use the MAC address as the user ID, you can override it with your own choice of user ID: + + {% highlight properties %} + brooklyn.external.supplierName.userId=server3.cluster2.europe + {% endhighlight %} + + #### Authentication by fixed token + + If you have a fixed token string, then you can use the *VaultTokenExternalConfigSupplier* class and provide the token + in `brooklyn.properties`: + + {% highlight properties %} + brooklyn.external.supplierName=org.apache.brooklyn.core.config.external.vault.VaultTokenExternalConfigSupplier + brooklyn.external.supplierName.token=1091fc84-70c1-b266-b99f-781684dd0d2b + {% endhighlight %} + + This supplier is suitable for "smoke testing" the Vault supplier using the Initial Root Token or similar. However it + is not suitable for production use as it is inherently insecure - should the token be compromised, an attacker could + have complete access to your Vault, and the cleanup operation would be difficult. Instead you should use one of the + other suppliers. + + ## Writing Custom External Configuration Suppliers + + Supplier implementations must conform to the brooklyn.config.external.ExternalConfigSupplier interface, which is very + simple: + + {% highlight java %} + String getName(); + String get(String key); + {% endhighlight %} + + Classes implementing this interface can be placed in the `lib/dropins` folder of Brooklyn, and then the supplier + defined in `brooklyn.properties` as normal. http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-docs/guide/yaml/advanced-example.md ---------------------------------------------------------------------- diff --cc brooklyn-docs/guide/yaml/advanced-example.md index 0000000,b55fdf5..326feb7 mode 000000,100644..100644 --- a/brooklyn-docs/guide/yaml/advanced-example.md +++ b/brooklyn-docs/guide/yaml/advanced-example.md @@@ -1,0 -1,177 +1,180 @@@ + --- + title: YAML BLueprint Advanced Example + layout: website-normal + --- + + By this point you should be familiar with the fundamental concepts behind both Apache Brooklyn and YAML blueprints. This section of the documentation is intended to show a complete, advanced example of a YAML blueprint. + -The intention is that this example is used to learn the more in-depth concepts, but also to serve as a reference point when writing your own blueprints. This page will first explain what the example is and how to run it, then it will spotlight interesting features. ++The intention is that this example is used to learn the more in-depth concepts, and also to serve as a reference when writing your own blueprints. This page will first explain what the example application is and how to run it, then it will spotlight interesting features. + + -### The Example ++### ELK Stack Example + -The example itself is a deployment of an ELK stack. ELK stands for Elasticsearch, Logstash and Kibana- and this blueprint deploys, installs, runs and manages all three. Briefly, the component parts are: ++This example demonstrates the deployment of an ELK Stack (Elasticsearch, Logstash and Kibana), using the provided blueprint to deploy, install, run and manage all three. Briefly, the component parts are: + + * Elasticsearch: A clustered search engine -* Logstash: Collects, parses and stores logs. For our application it will store logs in Elasticsearch -* Kibana: A front end to Elasticsearch ++* Logstash: Collects, parses and stores logs. For our example it will store logs in Elasticsearch ++* Kibana: A web front end to Elasticsearch ++ ++We also deploy a simple webserver whose logs will be collected. ++ ++* Tomcat 8: Web server whose logs will be stored in Elasticsearch by Logstash. + + For more about the ELK stack, please see the documentation [here](https://www.elastic.co/webinars/introduction-elk-stack). + -In our example, we will be creating the ELK stack, and a Tomcat8 server which sends its logs using Logstash to Elasticsearch. + + #### 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: + + * [Elasticsearch](example_yaml/brooklyn-elasticsearch-catalog.bom) + * [Logstash](example_yaml/brooklyn-logstash-catalog.bom) + * [Kibana](example_yaml/brooklyn-kibana-catalog.bom) + * [ELK](example_yaml/brooklyn-elk-catalog.bom) + + #### Running the example -First, add all four blueprints to the Brooklyn Catalog. This can be done by clicking the 'Catalog' tab, clinking the '+' symbol and pasting the YAML. Once this is done, click the 'Application' tab, then the '+' button to bring up the add application wizard. A new Catalog item will be available called 'ELK Stack'. Using the add application wizard, you should be able to deploy an ELK stack to a location of your choosing. ++First, add all four blueprints to the Brooklyn Catalog. This can be done by clicking the 'Catalog' tab, clicking the '+' symbol and pasting the YAML. Once this is done, click the 'Application' tab, then the '+' button to bring up the add application wizard. A new Catalog application will be available called 'ELK Stack'. Using the add application wizard, you should be able to deploy an ELK stack to a location of your choosing. + + #### Exploring the example -After the example has been deployed, you can ensure it is working as expected by checking the following: ++After the application has been deployed, you can ensure it is working as expected by checking the following: + -* There is a Kibana sensor called "main.uri", the value of which points to the Kibana front end. You can explore this front end, and observe the logs stored in Elasticsearch. Many Brooklyn applications have a "main.uri" set to point you in the right direction. -* You can also use the Elasticsearch REST API to explore further. The ES entity has an "urls.http.list" sensor. Choosing an url from there you will be able to access the REST API. The following URL will give you the state of the cluster "{es-url}/\_cluster/health?pretty=true". As you can see the number_of_nodes is currently 2, indicating that the Elasticsearch nodes are communicating with each other. ++* There is a Kibana sensor called `main.uri`, the value of which points to the Kibana front end. You can explore this front end, and observe the logs stored in Elasticsearch. Many Brooklyn applications have a `main.uri` set to point you in the right direction. ++* You can also use the Elasticsearch REST API to explore further. The Elasticsearch Cluster entity has a `urls.http.list` sensor. Using a host:port from that list you will be able to access the REST API. The following URL will give you the state of the cluster `http://<host:port>/_cluster/health?pretty=true`. As you can see the `number_of_nodes` is currently 2, indicating that the Elasticsearch nodes are communicating with each other. + + ### Interesting Feature Spotlight -We will mainly focus on the Elasticsearch blueprint, and will be clear when another blueprint is being discussed. This blueprint is a cluster of Elasticsearch nodes. Clustering is a useful technique that is explained in more depth [here](../clusters.html). ++We will mainly focus on the Elasticsearch blueprint, and will be clear when another blueprint is being discussed. This blueprint describes a cluster of Elasticsearch nodes. Clustering is a useful technique that is explained in more depth [here](../clusters.html). + + #### Provisioning Properties -Our Elasticsearch blueprint has a few requirements of the location in which it is run. Firstly, it must be run on an Ubuntu machine to simplify installation. Secondly, there are two ports that need to be opened to ensure that the entities can be accessed from the outside world. These are configured on the provisioning.properties as follows: ++Our Elasticsearch blueprint has a few requirements of the location in which it is run. Firstly, it must be run on an Ubuntu machine as the example has been written specifically for this OS. Secondly, two ports must opened to ensure that the entities can be accessed from the outside world. Both of these requirements are configured via provisioning.properties as follows: + + ~~~yaml + provisioning.properties: + osFamily: ubuntu + inboundPorts: + - $brooklyn:config("elasticsearch.http.port") + - $brooklyn:config("elasticsearch.tcp.port") + ~~~ + + #### VanillaSoftwareProcess -When composing a YAML blueprint, the VanillaSoftwareProcess is a very useful entity to be aware of. A VanillaSoftwareProcess will instruct Brooklyn to provision an instance, and run a series of shell commands to setup, run, monitor and teardown your program. The commands are specified as configuration on the VanillaSoftwareProcess and there are several available. We will spotlight a few now. To simplify this blueprint, we have specified ubuntu only installs so that our commands can be tailored to this system (E.G. use apt-get rather than YUM). ++When composing a YAML blueprint, the VanillaSoftwareProcess is a very useful entity to be aware of. A VanillaSoftwareProcess will instruct Brooklyn to provision an instance, and run a series of shell commands to setup, run, monitor and teardown your program. The commands are specified as configuration on the VanillaSoftwareProcess and there are several available. We will spotlight a few now. To simplify this blueprint, we have specified ubuntu only installs so that our commands can be tailored to this system (e.g. use apt-get rather than yum). + + ##### Customize Command + The Customize Command is run after the application has been installed but before it is run. It is the perfect place to create and amend config files. Please refer to the following section of the Elasticsearch blueprint: + + ~~~yaml + customize.command: | + $brooklyn:formatString(" + sudo rm -fr sudo tee /etc/elasticsearch/elasticsearch.yml; + echo discovery.zen.ping.multicast.enabled: false | sudo tee -a /etc/elasticsearch/elasticsearch.yml; + echo discovery.zen.ping.unicast.enabled: true | sudo tee -a /etc/elasticsearch/elasticsearch.yml; + echo 'discovery.zen.ping.unicast.hosts: %s' | sudo tee -a /etc/elasticsearch/elasticsearch.yml; + echo http.port: %s | sudo tee -a /etc/elasticsearch/elasticsearch.yml; + echo transport.tcp.port: %s | sudo tee -a /etc/elasticsearch/elasticsearch.yml; + ", + $brooklyn:component("parent", "").attributeWhenReady("urls.tcp.withBrackets"), + $brooklyn:config("elasticsearch.http.port"), + $brooklyn:config("elasticsearch.tcp.port") + ) + ~~~ -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 then use $brooklyn:formatString notation to build the string from configuration. 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 "component" and "attributeWhenReady" DSL commands. More on how this is generated later. ++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 then use `$brooklyn:formatString` notation to build the string from configuration. 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 `component` and `attributeWhenReady` DSL commands. More on how this is generated later. + + ##### Check running -After an app is installed and run, this command will be run regularly and used to populate the "service.isUp" sensor. If this command is not specified, or returns an exit code of anything other than zero, then Brooklyn will assume that your entity is broken and will display the fire status symbol. Please refer to the following section of the Elasticsearch blueprint: ++After an app is installed and run, this command is scheduled to run regularly and used to populate the `service.isUp` sensor. If this command is not specified, or returns an exit code of anything other than zero, then Brooklyn will assume that your entity has failed and will display the fire status symbol. Please refer to the following section of the Elasticsearch blueprint: + + ~~~yaml + checkRunning.command: | + $brooklyn:formatString("counter=`wget -T 15 -q -O- %s:%s | grep -c \"status. : 200\"`; if [ $counter -eq 0 ]; then exit 1; fi", + $brooklyn:attributeWhenReady("host.address"), + $brooklyn:config("elasticsearch.http.port")) + ~~~ -There are many different ways to implement this command. For this example, we are querying the REST API to get the status. This command creates a variable called counter, and populates it by performing a "WGET" call to the status URL or the Elasticsearch node, grepping for a 200 status OK code. We then check the counter is populated (I.E. that the end point does return status 200) and exit with an error code of one if not. ++There are many different ways to implement this command. For this example, we are querying the REST API to get the status. This command creates a variable called counter, and populates it by performing a `wget` call to the status URL or the Elasticsearch node, grepping for a 200 status OK code. We then check the counter is populated (i.e. that the end point does return status 200) and exit with an error code of one if not. + + #### Enrichers + + ##### Elasticsearch URLS + To ensure that all Elasticsearch nodes can communicate with each other they need to be configured with the TCP URL of all other nodes. Similarly, the Logstash instances need to be configured with all the HTTP URLs of the Elasticsearch nodes. The mechanism for doing this is the same, and involves using Transformers, Aggregators and Joiners, as follows: + + ~~~yaml + brooklyn.enrichers: + - type: org.apache.brooklyn.enricher.stock.Transformer + brooklyn.config: + enricher.sourceSensor: $brooklyn:sensor("host.address") + enricher.targetSensor: $brooklyn:sensor("url.tcp") + enricher.targetValue: $brooklyn:formatString("%s:%s", $brooklyn:attributeWhenReady("host.address"), $brooklyn:config("elasticsearch.tcp.port")) + ~~~ + -In this example, we take the host.address and append the TCP port, outputting the result as url.tcp. After this has been done, we now need to collect all the URLs into a list in the Cluster entity, as follows: ++In this example, we take the host.address and append the TCP port, outputting the result as `url.tcp`. After this has been done, we now need to collect all the URLs into a list in the Cluster entity, as follows: + + ~~~yaml + brooklyn.enrichers: + - type: org.apache.brooklyn.enricher.stock.Aggregator + brooklyn.config: + enricher.sourceSensor: $brooklyn:sensor("url.tcp") + enricher.targetSensor: $brooklyn:sensor("urls.tcp.list") + enricher.aggregating.fromMembers: true + + ~~~ -In the preceding example, we aggregate all of the TCP urls generated in the early example. These are then stored in a sensor called urls.tcp.list. This list is then joined together into one long string: ++In the preceding example, we aggregated all of the TCP URLs generated in the early example. These are then stored in a sensor called `urls.tcp.list`. This list is then joined together into one long string: + + ~~~yaml + - type: org.apache.brooklyn.enricher.stock.Joiner + brooklyn.config: + enricher.sourceSensor: $brooklyn:sensor("urls.tcp.list") + enricher.targetSensor: $brooklyn:sensor("urls.tcp.string") + uniqueTag: urls.quoted.string + ~~~ + + Finally, the string has brackets added to the start and end: + + ~~~yaml + - type: org.apache.brooklyn.enricher.stock.Transformer + brooklyn.config: + enricher.sourceSensor: $brooklyn:sensor("urls.tcp.string") + enricher.targetSensor: $brooklyn:sensor("urls.tcp.withBrackets") + enricher.targetValue: $brooklyn:formatString("[%s]", $brooklyn:attributeWhenReady("urls.tcp.string")) + ~~~ + -The resulting sensor will be called urls.tcp.withBrackets and will be used by all Elasticsearch nodes during setup. ++The resulting sensor will be called `urls.tcp.withBrackets` and will be used by all Elasticsearch nodes during setup. + + ##### Kibana URL + Kibana also needs to be configured such that it can access the Elasticsearch cluster. However, Kibana can only be configured to point at one Elasticsearch instance. To enable this, we use another enricher in the cluster to select the first URL from the list, as follows: + + ~~~yaml + - type: org.apache.brooklyn.enricher.stock.Aggregator + brooklyn.config: + enricher.sourceSensor: $brooklyn:sensor("host.address") + enricher.targetSensor: $brooklyn:sensor("host.address.first") + enricher.aggregating.fromMembers: true + enricher.transformation: + $brooklyn:object: + type: "org.apache.brooklyn.util.collections.CollectionFunctionals$FirstElementFunction" + ~~~ + -Similar to the above Aggregator, this Aggregator collects all the URLs from the members of the cluster. However, this Aggregator specifies a transformation. In this instance a transformation is a Java class that implements a Guava Function\<? super Collection\<?\>, ?\>\>, I.E. a function that takes in a collection and returns something. In this case we specify the FirstElementFunction from the CollectionFunctionals to ensure that we only get the first member of the URL list. ++Similar to the above Aggregator, this Aggregator collects all the URLs from the members of the cluster. However, this Aggregator specifies a transformation. In this instance a transformation is a Java class that implements a Guava Function `<? super Collection<?>, ?>>`, i.e. a function that takes in a collection and returns something. In this case we specify the FirstElementFunction from the CollectionFunctionals to ensure that we only get the first member of the URL list. + + #### Latches + In the ELK blueprint, there is a good example of a latch. Latches are used to force an entity to wait until certain conditions are met before continuing. For example: + + ~~~yaml + - type: kibana-standalone + ... - name: kibana ++ name: Kibana Server + customize.latch: $brooklyn:component("es").attributeWhenReady("service.isUp") + ~~~ + + This latch is used to stop Kibana customizing until the Elasticsearch cluster is up. We do this to ensure that the URL sensors have been setup, so that they can be passed into Kibana during the customization phase. + + #### Child entities + The ELK blueprint also contains a good example of a child entity. + + ~~~yaml + - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server + brooklyn.config: + children.startable.mode: background_late + ... + brooklyn.children: + - type: logstash-child + ~~~ + -In this example, a logstash-child is started as a child of the parent Tomcat server. The tomcat server needs to be configured with a "children.startable.mode" to inform Brooklyn when to bring up the child. In this case we have selected background so that the child is disassociated from the parent entity, and late to specify that the parent entity should start before we start the child. ++In this example, a logstash-child is started as a child of the parent Tomcat server. The Tomcat server needs to be configured with a `children.startable.mode` to inform Brooklyn when to bring up the child. In this case we have selected background so that the child is disassociated from the parent entity, and late to specify that the parent entity should start before we start the child. http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elk-catalog.bom ---------------------------------------------------------------------- diff --cc brooklyn-docs/guide/yaml/example_yaml/brooklyn-elk-catalog.bom index 0000000,ffca3df..6fc11f4 mode 000000,100644..100644 --- a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elk-catalog.bom +++ b/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elk-catalog.bom @@@ -1,0 -1,35 +1,35 @@@ + brooklyn.catalog: + version: 1.0 + iconUrl: https://avatars0.githubusercontent.com/u/6764390?v=3&s=400 + license: Apache-2.0 + issues_url: https://github.com/Graeme-Miller/brooklyn-elk/issues + itemType: template + item: + type: org.apache.brooklyn.entity.stock.BasicApplication + name: ELK Stack + id: ELK-Stack + description: | - Simple ELK stack deployment: it installs ES, Kibana and lostash as a child of Apache Tomcat 8 ++ Simple ELK stack deployment: provisions Elasticsearch, Kibana and Logtash as a child of Apache Tomcat 8 + services: + - type: elasticsearch + id: es - name: es ++ name: Elasticsearch Cluster + brooklyn.config: + install.version: 1.4.4 + - type: kibana-standalone + id: kibana - name: kibana ++ name: Kibana Server + customize.latch: $brooklyn:component("es").attributeWhenReady("service.isUp") + brooklyn.config: + kibana.elasticsearch.ip: $brooklyn:component("es").attributeWhenReady("host.address.first") + kibana.elasticsearch.port: $brooklyn:component("es").config("elasticsearch.http.port") + - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server - id: jboss ++ id: tomcat + customize.latch: $brooklyn:component("es").attributeWhenReady("service.isUp") + brooklyn.config: + children.startable.mode: background_late + brooklyn.children: + - type: logstash-child - name: logstash-child ++ name: Logstash Child + brooklyn.config: + logstash.elasticsearch.host: $brooklyn:component("es").attributeWhenReady("urls.http.withBrackets") http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml ---------------------------------------------------------------------- diff --cc brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml index 0000000,633716f..8e9c951 mode 000000,100644..100644 --- a/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml +++ b/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml @@@ -1,0 -1,12 +1,12 @@@ + 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.jboss.JBoss7Server + location: - byon: { hosts: [ 127.0.0.1 ] } ++ byon:(hosts="127.0.0.1") http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-library/qa/pom.xml ---------------------------------------------------------------------- diff --cc brooklyn-library/qa/pom.xml index 0000000,fd0266d..35ba6ec mode 000000,100644..100644 --- a/brooklyn-library/qa/pom.xml +++ b/brooklyn-library/qa/pom.xml @@@ -1,0 -1,108 +1,123 @@@ + <?xml version="1.0" encoding="UTF-8"?> + <!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + --> + <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> + <modelVersion>4.0.0</modelVersion> + <artifactId>brooklyn-qa</artifactId> + <packaging>jar</packaging> + <name>Brooklyn QA</name> + <description> + This project contains QA-style tests (e.g. longevity and stress tests). + </description> + + <parent> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-parent</artifactId> + <version>0.9.0-SNAPSHOT</version> <!-- BROOKLYN_VERSION --> + <relativePath>../../parent/pom.xml</relativePath> + </parent> + + <dependencies> + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-all</artifactId> + <version>${project.version}</version> + </dependency> + + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-dist</artifactId> + <classifier>dist</classifier> + <type>tar.gz</type> + <version>${project.version}</version> + </dependency> + + <dependency> + <groupId>net.sf.jopt-simple</groupId> + <artifactId>jopt-simple</artifactId> + </dependency> + <dependency> + <groupId>org.apache.httpcomponents</groupId> + <artifactId>httpclient</artifactId> + </dependency> + <dependency> + <groupId>com.google.guava</groupId> + <artifactId>guava</artifactId> + </dependency> + <dependency> + <groupId>org.slf4j</groupId> + <artifactId>slf4j-api</artifactId> + </dependency> + + <dependency> + <groupId>org.testng</groupId> + <artifactId>testng</artifactId> + <scope>test</scope> + </dependency> + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-test-support</artifactId> + <version>${project.version}</version> + <scope>test</scope> + </dependency> + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-core</artifactId> + <version>${project.version}</version> + <classifier>tests</classifier> + <scope>test</scope> + </dependency> ++ <dependency> ++ <groupId>org.apache.maven.shared</groupId> ++ <artifactId>maven-verifier</artifactId> ++ <version>1.5</version> ++ <scope>test</scope> ++ </dependency> + </dependencies> + + <build> + <plugins> + <plugin> + <artifactId>maven-dependency-plugin</artifactId> + <executions> + <execution> + <phase>install</phase> + <goals> + <goal>copy-dependencies</goal> + </goals> + <configuration> + <outputDirectory>${project.build.directory}/lib</outputDirectory> + <excludeArtifactIds>brooklyn-dist</excludeArtifactIds> + </configuration> + </execution> + </executions> + </plugin> ++ <plugin> ++ <groupId>org.apache.rat</groupId> ++ <artifactId>apache-rat-plugin</artifactId> ++ <configuration> ++ <excludes combine.children="append"> ++ <exclude>src/test/projects/downstream-parent-test/README</exclude> ++ </excludes> ++ </configuration> ++ </plugin> + </plugins> + </build> + </project> - ++v http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/018a0e15/brooklyn-library/sandbox/nosql/pom.xml ---------------------------------------------------------------------- diff --cc brooklyn-library/sandbox/nosql/pom.xml index 0000000,d62be44..5b15536 mode 000000,100644..100644 --- a/brooklyn-library/sandbox/nosql/pom.xml +++ b/brooklyn-library/sandbox/nosql/pom.xml @@@ -1,0 -1,98 +1,79 @@@ + <?xml version="1.0" encoding="UTF-8"?> + <!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + --> + <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> + <modelVersion>4.0.0</modelVersion> + + <groupId>org.apache.brooklyn.sandbox</groupId> + <artifactId>brooklyn-sandbox-software-nosql</artifactId> + <packaging>jar</packaging> + <name>Brooklyn NoSQL Software Entities</name> + <description> + Brooklyn entitites for NoSQL software processes + </description> + + <parent> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-parent</artifactId> + <version>0.9.0-SNAPSHOT</version> <!-- BROOKLYN_VERSION --> + <relativePath>../../parent/pom.xml</relativePath> + </parent> + + <dependencies> + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-software-base</artifactId> + <version>${project.version}</version> + </dependency> + + <dependency> + <groupId>org.testng</groupId> + <artifactId>testng</artifactId> + <version>${testng.version}</version> + <scope>test</scope> + </dependency> + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-core</artifactId> + <version>${project.version}</version> + <classifier>tests</classifier> + <scope>test</scope> + </dependency> + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-software-base</artifactId> + <version>${project.version}</version> + <scope>test</scope> + <classifier>tests</classifier> + </dependency> + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-test-support</artifactId> + <version>${project.version}</version> + <scope>test</scope> + </dependency> + <dependency> + <groupId>org.apache.brooklyn</groupId> + <artifactId>brooklyn-locations-jclouds</artifactId> + <version>${project.version}</version> + <scope>test</scope> + </dependency> + </dependencies> - - <build> - <plugins> - <plugin> - <groupId>org.apache.rat</groupId> - <artifactId>apache-rat-plugin</artifactId> - <configuration> - <excludes combine.children="append"> - <!-- - Configuration artifacts (for installations) are based on templated defaults for - the given components. These are files "without any degree of creativity" from the - perspective of the Brooklyn/Apache contribution. - --> - <exclude>src/main/resources/org/apache/brooklyn/entity/nosql/hazelcast/hazelcast-brooklyn.xml</exclude> - </excludes> - </configuration> - </plugin> - </plugins> - </build> + </project>
