Apache Brooklyn: Getting Started Guide

Contents

Running Apache Brooklyn

^ This guide will walk you through deploying an example 3-tier web application to a public cloud, and demonstrate the autoscaling capabilities of the Brooklyn platform. Two methods of deployment are detailed in this tutorial, using virtualisation with Vagrant and an install in your own environment (such as your local machine or in your private/public cloud). The latter assumes that you have a Java Runtime Environment installed (version 7 or later), as Brooklyn is Java under the covers. To get you up-and-running quickly, the Vagrant option will provision four compute nodes for you to deploy applications to. ## Install Apache Brooklyn {::options parse_block_html="true" /}
--- By default, no authentication is required and the web-console will listen on all network interfaces. For a production system, or if Apache Brooklyn is publicly reachable, it is strongly recommended to configure security. Documentation of configuration options include: * [Security](/guide/ops/configuration/brooklyn_cfg.md) * [Persistence](/guide/ops/persistence/) * [Cloud credentials](/guide/locations/) ## Launch Apache Brooklyn
_Notice! Before launching Apache Brooklyn, please check the `date` on the local machine. Even several minutes before or after the actual time could cause problems._
--- ## Control Apache Brooklyn Apache Brooklyn has a web console which can be used to control the application. The Brooklyn log will contain the address of the management interface: 
INFO  Started Brooklyn console at http://127.0.0.1:8081/, running classpath://brooklyn.war
By default it can be accessed by opening [127.0.0.1:8081](http://127.0.0.1:8081){:target="_blank"} in your web browser. The rest of this getting started guide uses the Apache Brooklyn command line interface (CLI) tool, `br`. This tool is both distributed with Apache Brooklyn or can be downloaded {% if site.brooklyn-version contains 'SNAPSHOT' %} from [here](https://repository.apache.org/service/local/artifact/maven/redirect?r=snapshots&g=org.apache.brooklyn&a=brooklyn-client-cli&v={{site.brooklyn-version}}&c=bin&e=zip). {% else %} using the most appropriate link for your OS: * [Windows](https://www.apache.org/dyn/closer.lua/brooklyn/apache-brooklyn-{{site.brooklyn-version}}/apache-brooklyn-{{site.brooklyn-version}}-client-cli-windows.zip) * [Linux](https://www.apache.org/dyn/closer.lua/brooklyn/apache-brooklyn-{{site.brooklyn-version}}/apache-brooklyn-{{site.brooklyn-version}}-client-cli-linux.tar.gz) * [OSX](https://www.apache.org/dyn/closer.lua/brooklyn/apache-brooklyn-{{site.brooklyn-version}}/apache-brooklyn-{{site.brooklyn-version}}-client-cli-macosx.tar.gz) {% endif %} For details on the CLI, see the [Client CLI Reference](/guide/ops/cli/) page. ## Next
The first thing we want to do with Brooklyn is **[deploy a blueprint](/guide/start/blueprints.md)**.

Deploying Blueprints

^ Blueprints are descriptors or patterns which describe how Apache Brooklyn should deploy applications. Blueprints are written in [YAML](https://en.wikipedia.org/wiki/YAML){:target="_blank"} and many of the entities available are defined in the __[Brooklyn Catalog](/website/learnmore/catalog/)__. ## Launching from a Blueprint We'll start by deploying an application with a simple YAML blueprint containing an [Apache Tomcat](https://tomcat.apache.org/){:target="_blank"} server. {% read _blueprints.camp.md %} {% read blueprint_locations/_index.md %} ## Deploying the Application First, log in to brooklyn with the command line interface (CLI) tool by typing: {% highlight bash %} $ br login http://localhost:8081/ {% endhighlight %} To secure the Apache Brooklyn instance, you can add a username and password to Brooklyn's properties file, as described in the User Guide [here](/guide/ops/configuration/brooklyn_cfg.md){:target="_blank"}. If this is configured, the login command will require an additional parameter for the userid and will then prompt for a password. {% read blueprint_locations/_adding_to_catalog.langs.md %} Now you can create the application with the command below: {% highlight bash %} $ br deploy myapp.yaml {% endhighlight %} 
Id:       hTPAF19s   
Name:     Tomcat   
Status:   In progress
Depending on your choice of location it may take some time for the application to start, the next page describes how you can monitor the progress of the application deployment and verify if it was successful. ## Next
Having deployed an application, the next step is **[monitoring and managing](managing.md)** it.

Monitoring and Managing Applications

^ So far we have gone through Apache Brooklyn's ability to *deploy* an application blueprint to a location, but this is just the beginning. Next we will outline how to *manage* the application that has been deployed. ## Applications {% read _br.applications.camp.md %} ## Entities {% read _br.entities.camp.md %} ## Sensors {% read _br.sensors.camp.md %} ## Effectors {% read _br.effectors.camp.md %} ## Activities {% read _br.activities.camp.md %} {::comment} ## Scopes in CLI commands Many commands require a "scope" expression to indicate the target on which they operate. The scope expressions are as follows (values in brackets are aliases for the scope): - ```application``` APP-ID (app, a) Selects an application, e.g. "br application myapp" - ```entity``` ENT-ID (ent, e) Selects an entity within an application scope, e.g. ```br application myapp entity myserver``` - ```effector``` EFF-ID (eff, f) Selects an effector of an entity or application, e.g. ```br a myapp e myserver eff xyz``` - ```config``` CONF-KEY (conf, con, c) Selects a configuration key of an entity e.g. ```br a myapp e myserver config jmx.agent.mode``` - ```activity``` ACT-ID (act, v) Selects an activity of an entity e.g. ```br a myapp e myserver act iHG7sq1``` For example {% highlight bash %} $ br application Tomcat entity tomcatServer config {% endhighlight %} runs the ```config``` command with application scope of ```Tomcat``` and entity scope of ```tomcatServer```. {:/comment} ## Next We will look next at a slightly more complex example, which will illustrate the capabilities of Brooklyn's **[policies](policies.md)** mechanism, and how to configure dependencies between application entities.

Getting Started - Policies

^ ## A Clustered Example We'll now look at a more complex example that better shows the capabilities of Brooklyn, including management of a running clustered application. {% read _policies.camp.md %}

Brooklyn Concepts Quickstart

^ The following section provides a quick summary of the main Brooklyn concepts you will encounter in Getting Started. For further discussion of these concepts see [The Theory Behind Brooklyn](/website/learnmore/theory.html), and the detailed descriptions in [Brooklyn Concepts](/guide/concepts/). ***Deployment and Management*** Brooklyn is built for agile deployment of applications across cloud and other targets, and real-time autonomic management. "Autonomic computing" is the concept of components looking after themselves where possible (self-healing, self-optimizing, etc). ***Blueprints*** A blueprint defines an application by specifying its components, such as processes, or combinations of processes across multiple machines and services. The blueprint also specifies the inter-relationships between the configurations of the components. ***Entities*** The central concept in a Brooklyn deployment is that of an entity. An entity represents a resource under management (individual machines or software processes) or logical collections of these. Entities are arranged hierarchically. They can have events, operations, and processing logic associated with them, and it is through this mechanism that the active management is delivered. ***Applications*** are the top level entities that are the parents of all other entities. ***Configuration*** Entities can have arbitrary configuration values, which get inherited by their child entities. You can set global properties in (``~/.brooklyn/brooklyn.properties``). Common configuration keys have convenient aliases called "flags". ***Sensors*** are the mechanism for entities to expose information for other entities to see. Sensors from an entity can be subscribed to by other entities to track changes in the entity’s activity. Sensors can be updated, potentially frequently, by the entity or associated tasks. ***Effectors*** are the mechanism for entities to expose the operations that can be invoked on it by other entities. The invoker is able to track the execution of that effector with tasks. ***Lifecycle*** The management context of Brooklyn associates a "lifecycle" with Brooklyn entities. Common operations are start, stop, and restart (whose meaning differs slightly for applications and processes; the details are in the concepts guide linked above). Starting an application results in the start() operation being performed recursively (typically in parallel) on the application's children. ***Tasks*** Lifecycle and other operations in Brooklyn are tracked as tasks. This allows current and past processing to be observed by operators, and processing to be managed across multiple management nodes. ***Locations*** can be defined in order to specify where the processes of an application will run. Brooklyn supports different cloud providers and pre-prepared machines (including localhost), known as "BYON" (Bring Your Own Nodes). ***Policies*** Policies perform the active management enabled by Brooklyn. Entities can have Policy instances attached to them, which can subscribe to sensors from other entities or run periodically. When they run they can perform calculations, look up other values, invoke effectors or emit sensor values from the entity with which they are associated. ***Enrichers*** These are mechanisms that subscribe to a sensor, or multiple sensors, and output a new sensor. For example, the enricher which sums a sensor across multiple entities (used to get the total requests-per-second for all the web servers in a cluster), and the enricher which calculates a 60-second rolling average.