The CF Brooklyn Service Broker and Plugin

Transcription

1 Simplifying Services with the Apache Brooklyn Catalog The CF Brooklyn Service Broker and Plugin 1

2 What is Apache Brooklyn? Brooklyn is a framework for modelling, monitoring, and managing applications through autonomic blueprints. Brooklyn has a rich catalog: Web: Tomcat, JBoss, Nginx Data: MySQL, MariaDB, PostgreSQL, Redis, Riak MongoDB, Cassandra, Solr, CouchBase, CouchDB, Containers: Karaf Messaging: ActiveMQ, Qpid, Rabbit MQ, Kafka Network: Bind 2

3 Blueprints Describe the components that make up a managed application Written in YAML Composable Can run scripts/recipes Inject dependencies between services Configure locations Attach management logic 3

4 name: Couchbase with Elastic Load Generator location: softlayer:wdc01 services: - type: brooklyn.entity.nosql.couchbase.couchbasecluster id: cb-cluster adminusername: Administrator adminpassword: Password initialsize: 3 createbuckets: [ { bucket: default } ] brooklyn.config: provisioning.properties: minram: 16g mincores: 4 brooklyn.policies: - type: brooklyn.policy.autoscaling.autoscalerpolicy brooklyn.config: metric: $brooklyn:sensor("brooklyn.entity.nosql.couchbase.couchbasecluster", "couchbase.stats.cluster.per.node.ops") metriclowerbound: 500 metricupperbound: 1000 minpoolsize: 3 maxpoolsize: 8 - type: brooklyn.entity.webapp.controlleddynamicwebappcluster name: Web Couchbase Load Gen Cluster war: brooklyn.config: provisioning.properties: mincores: 4 java.sysprops: brooklyn.example.couchbase.nodes: $brooklyn:formatstring("'%s'", component("cb-cluster").attributewhenready("couchbase.cluster.node.addresses")) initialsize: 2 4

5 Brooklyn Concepts (Entities) Resources under management Entity responsibilities: Provision the entity in the given location(s) Hold configuration and state (attributes) for the entity Report monitoring data (sensors) about the status of the entity Expose operations (effectors) that can be performed on the entity Host management policies and tasks related to the entity 5

6 6

7 Brooklyn Concepts (Locations) Uses Apache jclouds to support different cloud providers and to support BYON (Bring Your Own Nodes) The implementation of an entity (e.g. Tomcat) is agnostic about where it will be installed/started 7

8 Brooklyn Concepts (Sensors) Activity information and notifications Updated by the entity or associated tasks Can be subscribed to by other entities to track changes 8

9 9

10 Brooklyn Concepts (Effectors) Operations that can be invoked on the entity start/restart/stop resize cluster replace cluster member... 10

11 Brooklyn Concepts (Policies) Policies can subscribe to sensors run periodically perform calculations invoke effectors, or emit sensor values for the purpose of Auto-Scaling Failure-Detecting Load-Balancing Service Replace/Restart 11

12 The Brooklyn Service Broker 12

13 Brooklyn Service Broker Motivation: Allow Brooklyn managed services to be used by CF apps Expose the Brooklyn catalog to the CF marketplace Maps Brooklyn locations to CF plans Each Brooklyn catalog item can be deployed to a location 13

14 Brooklyn Broker Implementation Extends community Spring Boot project Uses Brooklyn s client library to make REST calls to a Brooklyn server Gets all catalog Applications Gets all Locations Creates a service definition for each application using all locations as plans unless blueprint specifies one, in which case just make one plan using that location Persists service instance/binding data in a Brooklyn entity 14

15 Brooklyn Broker Implementation Defines additional routes for managing Brooklyn e.g with Brooklyn Plugin: /create a catalog item, posting yaml /delete/{name}/{version} a catalog item /sensors/{application} /effectors/{application} /invoke/{application}/{entity}/{effector} /is-running/{application} 15

16 Brooklyn Broker Usage Deploy to CF with env specifying: BROOKLYN_URI BROOKLYN_USERNAME BROOKLYN_PASSWORD to inform the broker of Brooklyn s credentials And SECURITY_USER_NAME SECURITY_USER_PASSWORD to set the broker s credentials 16

17 Brooklyn Broker Usage Then use as with any other broker: create-service-broker service-access enable-service-access create-service delete-service bind-service unbind-service 17

18 The Brooklyn Plugin 18

19 Brooklyn CLI plugin A companion to the Brooklyn Broker Uses the extra routes provided to manage Brooklyn services: cf cf cf cf cf brooklyn brooklyn brooklyn brooklyn brooklyn add-catalog effectors invoke sensors ready Automates service creation on push cf brooklyn push (Assuming user has permission!) 19

20 cf brooklyn push When application manifests contain a brooklyn section: call the service broker to create a specified service append instance name to the existing services section applications: applications: - name: my-app - name: my-app brooklyn: services: - name: my-demo-web-cluster - my-demo-web-cluster location: localhost - old-service service: Demo Web Cluster services: - old-service 20

21 Interlude: cf brooklyn add-catalog With cf brooklyn add-catalog a user supplied blueprint is added to the Brooklyn catalog Then need to update-service-broker, and enable-service-access before blueprint can be used Quite manual, but allows new blueprints to be added by Devs 21

22 cf brooklyn push Specify a service definition in the brooklyn section Automates: add-catalog, update-broker, enable-service-access, create-service before pushing, which will also bind as usual 22

23 applications: - name: my-app memory: 512M brooklyn: - name: Sharded MongoDB location: localhost services: - type: brooklyn.entity.nosql.mongodb.sharding.mongodbshardeddeployment id: mongo name: Mongo DB Backend provisioning.properties: minram: 16gb brooklyn.config: initialrouterclustersize: 1 initialshardclustersize: 5 shardreplicasetsize: 3 23

24 Invoking effectors Use cf brooklyn effectors to find the effector you need Invoke it with cf brooklyn invoke E.g. clusters of entities have a resize effector to scale out a service MongoDBShardedDeployment has: a cluster of shards where each shard has a cluster of replica nodes a cluster of routers a cluster of config servers 24

25 Conclusions Manage services with Apache Brooklyn for use in CF Service Broker allows a simplification of services Manage services through the CF interface using CLI-Plugin Scale services using effectors Monitor services with sensors Simplify deployment to One-click push From writing service brokers to writing Brooklyn Blueprints Exposes an extensive catalog of existing Blueprints Only one broker to maintain Interaction with Brooklyn through the Service Broker With autonomic blueprints Specify service blueprints in application manifests Create and wait for service up Bind to application 25

26 Thanks! 26