Extending Cloud Foundry with Custom Integration


Published on

Speakers: Cornelia Davis and Scott Frederick
As you find it in the open-source codebase, Cloud Foundry includes a set of prepackaged services (Postgres, MySQL, Redis, MongoDB and RabbitMQ) and a number of application runtimes (Java, Ruby and Node.js). In addition, CloudFoundry.com integrates with a number of external service providers through a services gateway. When you are deploying your own Cloud Foundry you can extend the existing open-source features by adding additional services and runtime support. In fact, you can bring your own runtime to any Cloud Foundry (including CloudFoundry.com) via buildpacks. In this session we will show you how to build and deploy, or broker custom services. We will also introduce you to buildpacks, show you how to create your own, and how to get your apps to use them.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Extending Cloud Foundry with Custom Integration

  1. 1. Extending Cloud Foundry With Custom Integration Cornelia Davis Scott Frederick © 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission.
  2. 2. Who and What... Extending the set of services Customizing application containers 2
  3. 3. Services © 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission.
  4. 4. Demo 4 Push app with trace
  5. 5. When you cf push VM for Service Instances credentials provision (HTTP) provision (HTTP) CLI Cloud Controller bind (HTTP) bind (HTTP) Browse 5 Router ... go ahead and deploy (HTTP) Service Broker (i.e. mysql) up to you MySQL (process) up to you DEA Droplet credentials Note: • Don’t call ‘em “Gateways” anymore • Broker only used during •(un)provision •(un)bind
  6. 6. Demo 6 • Go to app code to look at how credentials are accessed
  7. 7. Agenda §Extending services offerings within run.pivotal.io –Partnering §Building services –Into your own Cloud Foundry §User-provided service instances –For access to pre&externally-provisioned services
  8. 8. run.pivotal.io Marketplace Services run.pivotal.io Contact Nima Badiey (nbadiey@gopivotal.com) to play 8
  9. 9. run.pivotal.io Marketplace Services Cloud Controller credentials AppDirect Service Broker Browser DEA Droplet credentials 9
  10. 10. Demo 10 • Create service instance from console • push an app and bind to that service
  11. 11. Cloud Foundry Services • There is only one built in - mysql – or many more depending on how you count • How to build them - the evolution: – CF v1, subclass Ruby base classes – CF v2, a RESTful protocol (which is itself evolving) Polyglot! • There are three parts to the protocol... 11
  12. 12. 1Broker Registers Offerings On Broker Startup... CLI Authenticate token Browser 12 UAA Router Services Catalog tc Ge Cloud Controller Up ata e dat lo ) TP HT g( alo ca t Service Broker (i.e. mysql) VM for Service Instances ) TP HT g( DEA My Service (process)
  13. 13. 2Broker Services (un)provision and (un)bind Prerequisite... 13 Service Broker (i.e. mysql) es ha red sec ret (H UAA vid Router CLI shared secret pro VM for Service Instances TT P) Cloud Controller My Service (process)
  14. 14. CLI 2Broker Services (un)provision and (un)bind Browser 14 UAA Router credentials (un Cloud Controller ovi )pr bin un) sio H n( P) TT ) TP HT d( ( DEA Droplet credentials Service Broker (i.e. mysql) up to you VM for Service Instances My Service (process)
  15. 15. 3Orphan Management Broker is responsible for eventual consistency... CLI Authenticate token 15 UAA Router Services Catalog tc Ge Cloud Controller ata lo ) TP HT g( Service Broker (i.e. mysql) up to you VM for Service Instances My Service (process)
  16. 16. New (V2) Services API • Simplifies things a bunch! • Unidirectional - everything initiated from Cloud Controller • Asynchronous provisioning • From V1 RESTful Services API: – Replace offerings registration with endpoint that allows the CC to GET the offerings – Remove orphan management 16
  17. 17. It’s Up To YOU Patterns One option (CF v1 services)... VM for Service Instances My Service (process) VM for Service Broker provision VM for Service Instances My Service (process) Node Service Broker Node VM for Service Instances NATS 17 My Service (process) Node
  18. 18. It’s Up To YOU Patterns Another... VM for Service Instances Warden VM for Service Broker provision VM for Service Instances Warden Warden Svc Process Svc Process Svc Process Node Service Broker Node VM for Service Instances Warden NATS 18 Svc Process Node
  19. 19. It’s Up To YOU Patterns And another... VM for Service Instances Warden VM for Service Broker provision VM for Service Instances Warden Svc Process Svc Process Node Service Broker Node VM for Service Instances Warden NATS 19 Svc Process Node
  20. 20. BOSH deployment packages - service broker - your impl - service node - services binaries - services warden - your node impl Provisions jobs broker VMs - service broker - ref service broker pkg - start web service - service node - ref service node pkg - start node Configure shared secret (for example) 20 Provisions service VMs
  21. 21. But what about... core AppDirect Service Broker Service Service Broker Broker ? ERP 21 Oracle MySQL MySvc
  22. 22. User-provided Service Instances pro vid es erv ice )bi Browser Router (un 22 nd cre (H de nti TT P) UAA CLI Prerequisite... als credentials (H ERP TT P) Cloud Controller DEA Droplet credentials Oracle
  23. 23. Demo 23 register user provided service instance
  24. 24. Tell ‘em what you told ‘em... §Extending services offerings within run.pivotal.io –Partnering §Building services –Into your own Cloud Foundry §User-provided service instances –For access to pre&externally-provisioned services
  25. 25. Buildpacks © 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission.
  26. 26. Deploying to Cloud Foundry 26
  27. 27. Staging and Buildpacks Buildpacks are responsible for preparing the machine image for an application Application Buildpack DEA Container Libraries Runtime Operating System 27 Libraries = runtime package managers like Ruby gems, Node modules, Python PIP packages App bits are downloaded into image by DEA, buildpack may move them as necessary } Droplet
  28. 28. Compatibility Cloud Foundry buildpacks follow the Heroku buildpack design Cloud Foundry and Heroku buildpacks are compatible (if you take care to make them compatible) Other PaaS providers are adopting the buildpack design 28 You can choose to implement platform-specific features in buildpacks and make them incompatible For compiled languages (Java) CF expects source to be compiled to machine code before being pushed. Heroku buildpacks will compile. Buildpack is an emerging convention for PaaS
  29. 29. Built-in or BYO cf push cf push --buildpack <url> The application is tested against a set of curated buildpacks The buildpack is referenced by a Git URL 29 Git != GitHub - use any public Git provider or local Git repositories Git repository must be visible on the network that CF is running on - public CF requires public Git repo, private CF can use private or public Git repo
  30. 30. Built-in Buildpacks → → → 30 Built into the CF open-source codebase and into Pivotal Hosted CF. Builtin means they are symlinked into the DEA in the buildpacks directory. Symlinking other buildpacks makes them builtin also. NodeJS and Ruby buildpacks are forks of Heroku buildpacks. Java buildpack is written from scratch for CF.
  31. 31. Tested Buildpacks https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Buildpacks Containers Languages Haskell 31 Not tested or endorsed by Pivotal, all community-contributed and maintained. Existing buildpacks are a great place to start when creating a new buildpack from scratch.
  32. 32. Buildpack API /bin/detect app_directory Inspect app bits to determine buildpack applicability /bin/compile app_directory cache_directory Download and install runtime, container, packages, libraries; install app bits as necessary /bin/release app_directory Build app start command 32 Written in bash shell scripts or Ruby
  33. 33. /bin/detect Inspect the app bits to determine if the buildpack knows how to handle the application Gemfile exists package.json exists setup.py exists On match, return exit code 0 and write to STDOUT a string identifying the buildpack (often just the name of the language supported) 33 Java intentionally left off this list because the CF Java buildpack has more complex detection criteria
  34. 34. /bin/detect $ cf push DEA iterates over built-in buildpacks calling /bin/detect scripts until one of them returns exit code 0 34 $ cf push --buildpack <url> /bin/detect is not called
  35. 35. /bin/compile Download and install any necessary runtime (Java VM, Ruby interpreter, JavaScript interpreter) container (web server) support libraries, packages, modules (Ruby gems, NPM packages) ...and then installing the app bits into the runtime or container 35 This is where most of the buildpack work is done. More package manager examples - Python PIP, Perl CPAN Installing the app may mean copying or moving the app files from the location DEA put them in, or symlinking them to a different location
  36. 36. /bin/compile Caching Runtime, container, and support packages are downloaded from sources external to Cloud Foundry DEA provides a location for storing downloaded artifacts to speed subsequent staging operations 36 External source can include custom packages in S3 buckets or public mirrors for public CF, or internal download locations for private CF.
  37. 37. /bin/release Build a YAML-formatted hash with three possible keys addons: [] config_vars: {} default_process_types: web: <start command> On Cloud Foundry, currently only the web: value is used to get the start command for the app 37 If creating a buildpack for compatibility, consult documentation for other platforms to see how addons and config_vars might be used.
  38. 38. Java Buildpack Supports a variety of JVM languages, containers, and frameworks with a modular, configurable, and extensible design 38
  39. 39. Java Buildpack Concepts Containers Frameworks How an application is run Additional application transformations JREs Java Runtimes 39 Frameworks - loose definition, basically anything that is orthogonal to the container
  40. 40. Java Buildpack Concepts Containers Frameworks Java main() Tomcat Groovy Spring Boot CLI Play Spring config Play config Play JPA config New Relic JREs OpenJDK 40 Zero Effort Spring - Tue 12:45-2:15 - Dave Syer and Phil Webb
  41. 41. Container Detection Criteria Java main() META-INF/MANIFEST.MF exists with Main-class attribute set Tomcat WEB-INF directory exists Groovy .groovy file with a main() method, or .groovy file with no classes, or .groovy file with a shebang (#!) declaration Spring Boot CLI one or more POGO .groovy files with no main() method, and no WEB-INF directory Play start and lib/play.play_*.jar exist Choose zero or one 41 Detection is typically based on file existence and content of files. Zero Effort Spring - Tue 12:45-2:15 - Dave Syer and Phil Webb This list is likely to grow to support other containers like Spring XD.
  42. 42. Framework Detection Criteria Spring spring-core*.jar exists Play config Play application detected Play JPA config play-java-jpa plugin exists in app New Relic New Relic service bound to app Choose all that apply 42 Detection is typically based on file existence and content of files. Can also be done based on services bound to an app.
  43. 43. /bin/compile Output Example -----> Downloaded app package (18M) -----> Downloading OpenJDK 1.7.0_21 JRE (17.5s) Expanding JRE to .java (1.4s) -----> Downloading Auto Reconfiguration 0.7.1 (1.4s) Modifying /WEB-INF/web.xml for Auto Reconfig -----> Downloading Tomcat 7.0.42 (3.5s) Expanding Tomcat to .tomcat (0.2s) Downloading Buildpack Tomcat Support 1.1.1 (0.0s) -----> Uploading droplet (55M) 43 DEA Buildpack DEA
  44. 44. See What’s Going On $ cf files <app-name> app .buildpack-diagnostics/ .java/ .lib/ Buildpack-installed runtime Buildpack-installed support libraries .tomcat/ Buildpack-installed container META-INF/ WEB-INF/ DEA-downloaded application files assets/ 44 The buildpack-installed locations are decisions made by the Java buildpack - other buildpacks will put things in other places.
  45. 45. See What’s Going On $ cf files <app-name> staging_info.yml detected_buildpack: openjdk-1.7.0_21, tomcat-7.0.42, spring-auto-reconfiguration-0.7.1 start_command: JAVA_HOME=.java JAVA_OPTS="-Dhttp.port=$PORT -Djava.io.tmpdir=$TMPDIR -XX:MaxPermSize=52428K -XX:OnOutOfMemoryError=./.buildpack-diagnostics/killjava -Xmx384M -Xss1M" .tomcat/bin/catalina.sh run 45
  46. 46. Customization Two ways to customize the Java buildpack Configure artifacts used by standard JREs, Containers, and Frameworks Extend the buildpack with your own JREs, Containers, and Frameworks Customization is done by forking the buildpack 46 Awesome documentation is in the github repo
  47. 47. Customization by Configuration Configuration files in java-buildpack/config determine the behavior of a JRE, Container, or Framework # http://download.pivotal.io.s3.amazonaws.com/openjdk/lucid/x86_64/index.yml --1.6.0_27: http://download.pivotal.io.s3.amazonaws.com/openjdk/lucid/x86_64/openjdk-1.6.0_27.tar.gz 1.7.0_21: http://download.pivotal.io.s3.amazonaws.com/openjdk/lucid/x86_64/openjdk-1.7.0_21.tar.gz 1.7.0_25: http://download.pivotal.io.s3.amazonaws.com/openjdk/lucid/x86_64/openjdk-1.7.0_25.tar.gz 1.8.0_M6: http://download.pivotal.io.s3.amazonaws.com/openjdk/lucid/x86_64/openjdk-1.8.0_M6.tar.gz 1.8.0_M7: http://download.pivotal.io.s3.amazonaws.com/openjdk/lucid/x86_64/openjdk-1.8.0_M7.tar.gz # cloudfoundry/java-buildpack/config/openjdk.yml --version: 1.7.0_+ repository_root: "http://download.pivotal.io.s3.amazonaws.com/openjdk/{platform}/{architecture}" memory_sizes: memory_heuristics:   heap: 0.75   permgen: 0.1   stack: 0.05   native: 0.1 47 version and repository_root are common to all components that download artifacts other options are specific to the component 1. consult <component-name>.yml 2. read repository_root/index.yml 3. look up the specified version in the index 4. download the matching artifact
  48. 48. Customization by Configuration Example: customizing the Tomcat artifact for download # http://files.example.com/tomcat-custom/index.yml --7.0.40: http://files.example.com/tomcat-custom/tomcat-7.0.40.tar.gz 7.0.41: http://files.example.com/tomcat-custom/tomcat-7.0.41.tar.gz 7.0.42: http://files.example.com/tomcat-custom/tomcat-7.0.42.tar.gz # cloudfoundry/java-buildpack/config/tomcat.yml --version: 7.0.42 repository_root: "http://files.example.com/tomcat-custom" support:   version: 1.1.+   repository_root: "http://files.example.com/tomcat-buildpack-support" 48
  49. 49. Customization by Configuration Tomcat container supports simple customization of context.xml and server.xml. cloudfoundry/java-buildpack/resources/tomcat/conf context.xml server.xml 49 fork, modify, push
  50. 50. Customization by Extension Implement a JRE, Container, or Framework support class as one Ruby file in the appropriate directory cloudfoundry/java-buildpack/lib/java_buildpack jre container framework (with additional support classes as necessary) 50 One class is sufficient for most extensions Existing support classes serve as good examples
  51. 51. Customization by Extension Support class types have similar interfaces, following the buildpack scripts naming conventions # initialize the support class with platform information provided in context # context includes app_dir, lib_dir, environment, java_home, java_opts, vcap_application, vcap_services def initialize(context) # return a String or an Array<String> that uniquely identifies the container/framework/jre, or nil def detect # download and unpack the container/framework/jre, and transform the application as necessary def compile # create and return the command to run the application with (containers) or add options to context[:java_opts] (frameworks) def release 51 if detect returns nil, compile and release will not be called only one container support class can return non-nil from detect
  52. 52. Customization by Extension Add new support class to config/components.yml --containers:   - "JavaBuildpack::Container::Groovy"   - "JavaBuildpack::Container::Main"   - "JavaBuildpack::Container::SpringBootCli"   - "JavaBuildpack::Container::Tomcat"   - "JavaBuildpack::Container::Play" jres:   - "JavaBuildpack::Jre::OpenJdk" frameworks:   - "JavaBuildpack::Framework::JavaOpts"   - "JavaBuildpack::Framework::NewRelic"   - "JavaBuildpack::Framework::PlayAutoReconfiguration"   - "JavaBuildpack::Framework::PlayJpaPlugin"   - "JavaBuildpack::Framework::SpringAutoReconfiguration" 52 The buildpack will iterate over all components, applying them as necessary
  53. 53. Customization Much more information and documentation included in the GitHub repository https://github.com/cloudfoundry/java-buildpack 53 The buildpack will iterate over all components, applying them as necessary
  54. 54. Cornelia Davis cdavis@gopivotal.com @cdavisafc Scott Frederick sfrederick@gopivotal.com @scottyfred Community Engineer, Cloud Foundry at Pivotal © 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission.