http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/learnmore/theory.md ---------------------------------------------------------------------- diff --git a/website/learnmore/theory.md b/website/learnmore/theory.md deleted file mode 100644 index eddb2f8..0000000 --- a/website/learnmore/theory.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -layout: website-normal -title: The Theory behind Brooklyn -children: -- { section: "Why Brooklyn?" } -- { section: Blueprints } -- { section: Benefits } -- { section: Standards } ---- - -<div class="jumobotron" markdown="1"> - -Brooklyn is a framework for modeling, monitoring, and managing applications -through autonomic blueprints. - -</div> - -## Why Brooklyn? - -Building and deploying applications in the cloud computing era has changed many -things. Provision a bare server just-in-time, and use automated tools to install -an application. Use APIs to add the server to a load balancer. When load goes -up, provision another server; when load drops, kill a server to save money. - -Many new tools have appeared that take advantage of this new era. However each -of them only solve part of the problem and don't consider the big picture. For -example, configuration management tools such as Chef can, in a single command, -provision a new cloud server then install and configure an application -- but -they require extra programming to reconfigure an load balancer whenever the pool -of web servers changes. Amazon Auto Scaling can provision new servers and update -load balancers, but it is dependent on CloudWatch -- this means either using -proxy metrics such as average response time, or writing more code to expose an -application's real metrics. A dedicated monitoring tool may be able to easily -monitor the key metrics with little effort, but its alerts will need to be -integrated it into the server provisioning process. - -So all the tools are there to to create and manage a cloud-scale application -that can adapt to demand to meet user expectations without wasting money on -superfluous services - but you will need several such tools and it is up to you -to integrate them into your deployment plan. Some of these tools -- such as the -Amazon Web Services web of EC2, CloudWatch, AutoScaling and CloudFormation -- -mean that you may suffer from lock-in. Related projects in OpenStack (Heat, -Ceilometer, Murano, Solum, etc) provide similar functionality but again for a -restricted target. The most common policies (such as minimising request latency) -may be easy, but less common policies such as follow-the-sun and follow-the-moon -may be up to you to implement. Your scaling policies may understand that -"high demand = add another server", but may not understand requirements such as -some clustered services requiring an odd number of instances to prevent voting -deadlocks. - - -## How Brooklyn Can Help - -In this context the advantage of Brooklyn becomes apparent: a single tool is -able to manage provisioning and application deployment, monitor an application's -health and metrics, understand the dependencies between components (such as -knowing that adding a new web server means that the load balancer needs -reconfiguration) and apply complex policies to manage the application. The tool -provides a REST API and a GUI, and allows the autonomic blueprints to be treated -as an integral part of the application. With Brooklyn, these policies become -modular components which can be reused and easily added to blueprints. - -Brooklyn is about deploying and managing applications: composing a full stack -for an application; deploying to cloud and non-cloud targets; using monitoring -tools to collect key health/performance metrics; responding to situations -such as a failing node; and adding or removing capacity to match demand. - - -## Blueprints - -A Brooklyn blueprint defines an application, using a declarative YAML syntax -supporting JVM plugins. A basic blueprint might comprise a single process, -such as a web-application server running a WAR file or a SQL database and -its associated DDL scripts. More complex blueprints encompass combinations -of processes across multiple machines and services, such as a load-balancing -HTTP server or SDN controller fronting a cluster of J2EE application -servers, in turn connected to a resilient cluster of SQL database servers. -Even larger clustered application running in multiple regions can be -described, with features such as message buses with resilient brokers, -cacheing tiers of NoSQL key-value store servers, a high-availability -database cluster and multiple application components connected across these -layers. - -One main benefit of these blueprints is that they are composable: -best-practice blueprints for one process or pattern (e.g. a Cassandra -cluster) can be incorporated in other blueprints (e.g. an application with a -Cassandra cluster as one component). Another major benefit is that the -blueprints can be treated as source code as part of an applications -codebase: tested, tracked, versioned, and hardened as an integral part of -the devops process. In some ways, Brooklyn is to run-time what Maven is to -build-time. - - -### Blueprints Turn into Deployments - -Brooklyn knows about Chef, Salt, and similar tools, and APT and Yum and -plain old shell scripts, for deploying application components. Blueprints -are built from a mixture of both off-the-shelf packages such as Tomcat, -MySQL, Cassandra, and many more from our library; and components that are -bespoke to individual applications; together with policies that allow the -application to be self-managing. - -Brooklyn is built for the cloud, and will take a blueprint and deploy it to -one of many supported clouds or even to multiple different clouds, or to -private infrastructure (bring-your-own-node), or to other platforms. It will -dynamically configure and connect all the different components of an -application, e.g. so load balancers know where the web servers are and the -web applications know where the database is. - -Brooklyn collects key metrics to monitor the health of applications; for -example, by sending a request and measuring latency, or installing -monitoring tools and using those to read a server's management interface to -determine the request queue length. These metrics can be fed into policies, -which automatically take actions such as restarting a failed node, or -scaling out the web tier if user demand exceeds capacity. This allows an -application to be self-managing: to recover itself from simple failures, to -scale out when demand increases and meet capacity; then scale in as demand -drops and stop paying for spare capacity. - -In short, Brooklyn blueprints allow the best practices for deploying and -managing complex software to be codified as part of the software development -process. - - - -### <a id="benefits"></a> Agile and Flexible - -Brooklyn is a product built from the ground up for application agility. This -includes portability across non-cloud, cloud, and PaaS targets; devops-style -infrastructure-as-code applied to applications; and real-time autonomic -management based on promise theory. Some introductions to these concepts, -associated tools, and open specifications may be useful. - -Cloud computing at its core is about provisioning resources on-demand. The most -widely known aspect is IaaS (infrastructure-as-a-service) such as Amazon EC2, -Softlayer, Google Cloud Platform, Apache CloudStack, or OpenStack. By leveraging -the Apache jclouds project (and contributing heavily to it), the Brooklyn -project is able to work with a large number of such providers. Higher up the -stack, however, there is an increasingly diverse set of platform targets, from -PaaS (platform-as-a-service) such as Cloud Foundry and Apache Stratos, through -to myriad containers and runtime fabrics such as LXC/Docker, Apache Mesos, -Apache Karaf, Apache Hadoop, and Apache Usergrid and other backend-as-a-service -environments. Brooklyn is based on the premise that applications may need to run -in any or all of these, and the model must be flexible and open enough to -support this. - -The buzzword-compliant trends of agile and devops have reinforced many important -lessons: - -- The truth is in the code (not any ancillary documents) -- If it isn't tested then assume it isn't working -- Toolchain integration and APIs are key to a project's success -- Even more critical is empowering all stakeholders to a project -- Brooklyn's focus on blueprinting and modeling as code and APIs serves these -principles. - -### Autonomic Computing - -Another major influence on the design of Brooklyn are the ideas of autonomic -computing and promise theory. It is not necessary to have a thorough -understanding of these to use Brooklyn, but contributors tend to become versed -in these ideas quickly. Essentially, autonomics is based on the concept of -components looking after themselves where possible (self-healing, -self-optimizing, etc), and exposing a sensor (data outputs) and effector -(operations) API where they may need to controlled by another element. Promise -theory extends this approach by introducing the idea that communicating intent -(through promises) is a more reliable basis for complex cooperating systems than -obligation-based effectors. Tools such as CF Engine, Chef, Puppet, Ansible, and -Salt apply promise theory to files and processes on machines; Brooklyn can -leverage all of these tools, complementing it with an application-oriented -model. - -### Standards - -Finally we note some emerging standards in this area. OASIS CAMP -(<a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=camp#technical";>Cloud Application Management for Platforms</a>) -and TOSCA -(<a href="https://www.oasis-open.org/committees/tosca/";>Topology and Orchestration Specification for Cloud Applications</a>) -both define YAML application models similar to Brooklyn's. -CAMP focuses on the REST API for interacting with such a -management layer, and TOSCA focuses on declarative support for more -sophisticated orchestration. Currently Brooklyn uses a YAML which complies with -CAMP's syntax and exposes many of the CAMP REST API endpoints. We would like to -support the hot-off-the-press TOSCA YAML and expand the CAMP REST API coverage.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/meta/license.md ---------------------------------------------------------------------- diff --git a/website/meta/license.md b/website/meta/license.md deleted file mode 100644 index 02d05f4..0000000 --- a/website/meta/license.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -layout: website-normal -title: Legal ---- - -## License - -Apache Brooklyn is released to the public as open source under the -terms of the [Apache License, v2.0](http://www.apache.org/licenses/LICENSE-2.0), a full copy of -which is included below for reference. - -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. - - -## Trademark - -The Brooklyn name and logo are trademarks owned by the Apache Software Foundation. - - -## Apache License, v2.0 (reference copy) - - -{% highlight text %} - - Apache License - Version 2.0, January 2004 - http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Derivative Works" shall mean any work, whether in Source or Object - form, that is based on (or derived from) the Work and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. For the purposes - of this License, Derivative Works shall not include works that remain - separable from, or merely link (or bind by name) to the interfaces of, - the Work and Derivative Works thereof. - - "Contribution" shall mean any work of authorship, including - the original version of the Work and any modifications or additions - to that Work or Derivative Works thereof, that is intentionally - submitted to Licensor for inclusion in the Work by the copyright owner - or by an individual or Legal Entity authorized to submit on behalf of - the copyright owner. For the purposes of this definition, "submitted" - means any form of electronic, verbal, or written communication sent - to the Licensor or its representatives, including but not limited to - communication on electronic mailing lists, source code control systems, - and issue tracking systems that are managed by, or on behalf of, the - Licensor for the purpose of discussing and improving the Work, but - excluding communication that is conspicuously marked or otherwise - designated in writing by the copyright owner as "Not a Contribution." - - "Contributor" shall mean Licensor and any individual or Legal Entity - on behalf of whom a Contribution has been received by Licensor and - subsequently incorporated within the Work. - - 2. Grant of Copyright License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - copyright license to reproduce, prepare Derivative Works of, - publicly display, publicly perform, sublicense, and distribute the - Work and such Derivative Works in Source or Object form. - - 3. Grant of Patent License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - (except as stated in this section) patent license to make, have made, - use, offer to sell, sell, import, and otherwise transfer the Work, - where such license applies only to those patent claims licensable - by such Contributor that are necessarily infringed by their - Contribution(s) alone or by combination of their Contribution(s) - with the Work to which such Contribution(s) was submitted. If You - institute patent litigation against any entity (including a - cross-claim or counterclaim in a lawsuit) alleging that the Work - or a Contribution incorporated within the Work constitutes direct - or contributory patent infringement, then any patent licenses - granted to You under this License for that Work shall terminate - as of the date such litigation is filed. - - 4. Redistribution. You may reproduce and distribute copies of the - Work or Derivative Works thereof in any medium, with or without - modifications, and in Source or Object form, provided that You - meet the following conditions: - - (a) You must give any other recipients of the Work or - Derivative Works a copy of this License; and - - (b) You must cause any modified files to carry prominent notices - stating that You changed the files; and - - (c) You must retain, in the Source form of any Derivative Works - that You distribute, all copyright, patent, trademark, and - attribution notices from the Source form of the Work, - excluding those notices that do not pertain to any part of - the Derivative Works; and - - (d) If the Work includes a "NOTICE" text file as part of its - distribution, then any Derivative Works that You distribute must - include a readable copy of the attribution notices contained - within such NOTICE file, excluding those notices that do not - pertain to any part of the Derivative Works, in at least one - of the following places: within a NOTICE text file distributed - as part of the Derivative Works; within the Source form or - documentation, if provided along with the Derivative Works; or, - within a display generated by the Derivative Works, if and - wherever such third-party notices normally appear. The contents - of the NOTICE file are for informational purposes only and - do not modify the License. You may add Your own attribution - notices within Derivative Works that You distribute, alongside - or as an addendum to the NOTICE text from the Work, provided - that such additional attribution notices cannot be construed - as modifying the License. - - You may add Your own copyright statement to Your modifications and - may provide additional or different license terms and conditions - for use, reproduction, or distribution of Your modifications, or - for any such Derivative Works as a whole, provided Your use, - reproduction, and distribution of the Work otherwise complies with - the conditions stated in this License. - - 5. Submission of Contributions. Unless You explicitly state otherwise, - any Contribution intentionally submitted for inclusion in the Work - by You to the Licensor shall be under the terms and conditions of - this License, without any additional terms or conditions. - Notwithstanding the above, nothing herein shall supersede or modify - the terms of any separate license agreement you may have executed - with Licensor regarding such Contributions. - - 6. Trademarks. This License does not grant permission to use the trade - names, trademarks, service marks, or product names of the Licensor, - except as required for reasonable and customary use in describing the - origin of the Work and reproducing the content of the NOTICE file. - - 7. Disclaimer of Warranty. Unless required by applicable law or - agreed to in writing, Licensor provides the Work (and each - Contributor provides its Contributions) on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - implied, including, without limitation, any warranties or conditions - of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A - PARTICULAR PURPOSE. You are solely responsible for determining the - appropriateness of using or redistributing the Work and assume any - risks associated with Your exercise of permissions under this License. - - 8. Limitation of Liability. In no event and under no legal theory, - whether in tort (including negligence), contract, or otherwise, - unless required by applicable law (such as deliberate and grossly - negligent acts) or agreed to in writing, shall any Contributor be - liable to You for damages, including any direct, indirect, special, - incidental, or consequential damages of any character arising as a - result of this License or out of the use or inability to use the - Work (including but not limited to damages for loss of goodwill, - work stoppage, computer failure or malfunction, or any and all - other commercial damages or losses), even if such Contributor - has been advised of the possibility of such damages. - - 9. Accepting Warranty or Additional Liability. While redistributing - the Work or Derivative Works thereof, You may choose to offer, - and charge a fee for, acceptance of support, warranty, indemnity, - or other liability obligations and/or rights consistent with this - License. However, in accepting such obligations, You may act only - on Your own behalf and on Your sole responsibility, not on behalf - of any other Contributor, and only if You agree to indemnify, - defend, and hold each Contributor harmless for any liability - incurred by, or claims asserted against, such Contributor by reason - of your accepting any such warranty or additional liability. -{% endhighlight %} http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/meta/sitemap.md ---------------------------------------------------------------------- diff --git a/website/meta/sitemap.md b/website/meta/sitemap.md deleted file mode 100644 index 7411976..0000000 --- a/website/meta/sitemap.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: website-normal -title: Site Map ---- - -<div class="sitemap"> - -<div class="search_right"> -<form method="get" id="simple_google" class="searchform" action="http://www.google.com/search";> - <input type="text" class="searchinput" name="brooklyn-search" placeholder="Google site search: type & hit enter"> - <input type="hidden" name="q" value=""> - </form> -</div> - -{% assign visited = "" | split: "|" %} -{% assign site_items = "" | split: "|" %} -<ul> -{% for item in site.data.menu %} - {% push site_items item %} - {% include sitemap-item.html %} -{% endfor %} -</ul> - -</div> - http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/meta/versions.md ---------------------------------------------------------------------- diff --git a/website/meta/versions.md b/website/meta/versions.md deleted file mode 100644 index d9678cc..0000000 --- a/website/meta/versions.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -layout: website-normal -title: Versions ---- - -## Current Version: {{ site.brooklyn-stable-version }} - -The current stable version of Brooklyn is {{ site.brooklyn-stable-version }}: - -* [Download]({{ site.path.website }}/download/) -* [User Guide]({{ site.path.guide }}/) -* [Release Notes]({{ site.path.guide }}/misc/release-notes.html) - -This documentation was generated {{ site.time | date_to_string }}. - - -## Version History - -Apache Brooklyn has made the following releases: - -* **[0.12.0](/v/0.12.0/)**: OSGI container runtime, improved catalog and bundle integration (September 2017) - -* **[0.11.0](/v/0.11.0/)**: Improved cloud support, additional blueprinting features (May 2017) - -* **[0.10.0](/v/0.10.0/)**: Improved blueprints and CLI, new DSL features, - Karaf distribution. (December 2016) - -* **[0.9.0](/v/0.9.0/)**: Adds Brooklyn CLI client, RPM package, getting started - using Vagrant. First release as an Apache top-level project! (April 2016) - -* **[0.8.0-incubating](/v/0.8.0-incubating/)**: Package rename to org.apache.brooklyn, and many other improvements. (September 2015) - -* **[0.7.0-incubating](/v/0.7.0-incubating/)**: New policies, more clouds, improved Windows support and many other improvements. First Apache-endorsed binary release! (July 2015) - -* **[0.7.0-M2-incubating](/v/0.7.0-M2-incubating/)**: YAML, persistence, Chef, Windows, Docker. The first Apache release! (December 2014) - -Note: These "Version History" links are to permanent versions in the archive, -different to the "Current Version" links. -To prevent accidentally referring to out-of-date information, -a banner is displayed when accessing content from these. -If you wish you can -<a href="javascript:void(0);" onclick="set_user_versions_all();">disable all warnings</a> or -<a href="javascript:void(0);" onclick="clear_user_versions();">re-enable all warnings</a>. - - -## Ancient Versions - -The versions below were made prior to joining The Apache Software Foundation, therefore **they are not endorsed by -Apache** and are not hosted by Apache or their mirrors. You can obtain the source code by -[inspecting the branches of the pre-Apache GitHub repository](https://github.com/brooklyncentral/brooklyn/branches/stale) -and binary releases by -[querying Maven Central for io.brooklyn:brooklyn.dist](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22io.brooklyn%22%20AND%20a%3A%22brooklyn-dist%22). - -* **[0.7.0-M1](/v/0.7.0-M1/)**: YAML, Chef, catalog, persistence (Apr 2014) - -* **[0.6.0](/v/0.6.0/)**: use of spec objects, chef and windows support, more clouds (Nov 2013) - -* **[0.5.0](/v/0.5.0/)**: includes new JS GUI and REST API, rebind/persistence support, cleaner model and naming conventions, more entities (May 2013) - -* **[0.4.0](/v/0.4.0/)**: initial public GA release of Brooklyn to Maven Central, supporting wide range of entities and examples (Jan 2013) - - -### Versioning - -Brooklyn follows [semantic versioning](http://semver.org/) with a leading `0.` qualifier: - - 0.<major>.<minor>[.<patch>]-<qualifier> - -Breaking backward compatibility increments the `<major>` version. -New additions without breaking backward compatibility ups the `<minor>` version. -Bug fixes and misc changes bumps the `<patch>` version. -New major and minor releases zero the less significant counters. - -From time to time, the Brooklyn project will make snapshots, milestone releases, and other qualified versions available, -using the following conventions: - -* Milestone versions (`-M<n>`) have been voted on and have been through some QA, - but have not had the extensive testing as is done on a release. - -* Snapshot (`-SNAPSHOT`) is the bleeding edge. - With good test coverage these builds are usually healthy, - but they have not been through QA or voted on. - -* Nightly builds (`-N<date>`) represent a snapshot which has - been given a permanent version number, typically for use by other projects. - The same caveats as for snapshot releases apply (no QA or Apache vote). - -* Release Candidate builds (`-RC<n>`) are made in the run-up to a release; - these should not normally be used except for deciding whether to cut a release. -
