Cloud foundry architecture and deep dive

3,378 views
3,138 views

Published on

Published in: Technology

Cloud foundry architecture and deep dive

  1. 1. Cloud Series Cloud Foundry NG Deep Dive Animesh Singh (singhan@us.ibm.com)
  2. 2. Cloud Foundry PaaS Cloud Foundry provides a services registry and runtime management layer. Components are dynamically discoverable and loosely coupled, exposing health through HTTP endpoints so agents can collect state Cloud Foundry Components User Authentication and Authorization Router DEA Pool Service Gateway Apps Service Connector Health Manager Messaging Cloud Controller Build Packs Cloud Foundry BOSH Micro Clouds Private Clouds Public Clouds Service Nodes
  3. 3. User Authentication and Authorization Router DEA Pool Service Gateway Apps Service Connector Health Manager Messaging Cloud Controller Build Packs Cloud Foundry BOSH Micro Clouds Private Clouds Public Clouds Service Nodes Dynamic Router The Router shapes and routes all external system traffic (HTTP/API) and application traffic from the internet/intranet. It maintains a dynamic routing table for each load-balanced app instance with IP addresses and ports for access via the internet. Cloud Foundry Components Responsible for: •Load balancing •Maintain routing table •Access logs
  4. 4. User Authentication and Authorization Router DEA Pool Service Gateway Apps Service Connector Health Manager Messaging Cloud Controller Build Packs Cloud Foundry BOSH Micro Clouds Private Clouds Public Clouds Service Nodes UAA The User Authorization and Authentication system provides user identity, security and authorization services. It manages third party Oauth 2.0 access credentials.. Cloud Foundry Components Responsible for: •Token Server •ID Server (User management) •OAuth Scopes (Groups) •Access auditing
  5. 5. User Authentication and Authorization Router DEA Pool Service Gateway Apps Service Connector Health Manager Messaging Cloud Controller Build Packs Cloud Foundry BOSH Micro Clouds Private Clouds Public Clouds Service Nodes Cloud Controller The Cloud Controller interfaces with clients (cf, STS, Eclipse) for account and provisioning control. It provides a RESTful interface to domain objects (apps, services, organizations, spaces, service instances, user roles, and more). CLI Cloud Foundry Components Responsible for: •App expected state •Permissions/Authz •Orgs/Spaces/Users •Services management •App placement •App desired state convergence •Auditing/Journaling •Billing events •Blob storage
  6. 6. User Authentication and Authorization Router DEA Pool Service Gateway Apps Service Connector Health Manager Messaging Cloud Controller Build Packs Cloud Foundry BOSH Micro Clouds Private Clouds Public Clouds Service Nodes Health Manager The Health Manager monitors application uptime/health by looking for mismatched application states (expected/actual). The Cloud Controller provides the expected state and the DEAs provide the current state. If the Health Manager sees an incorrect current state, it notifies the Cloud Controller. Cloud Foundry Components Responsible for: •Maintains the actual state of apps •Compares to expected state
  7. 7. User Authentication and Authorization Router DEA Pool Service Gateway Apps Service Connector Health Manager Messaging Cloud Controller Build Packs Cloud Foundry BOSH Micro Clouds Private Clouds Public Clouds Service Nodes DEA and Buildpacks A DEA (Droplet Execution Agent) is a secure and fully isolated container – a VM that can run one or multiple apps. DEAs are responsible for an app’s lifecycle: Buildpacks create app droplets which execute on a DEA. Cloud Foundry Components DEA Responsible for: •Manage Linux containers (Warden) • Process, File system • Network, Memory •Manage app lifecycle •App log and file streaming •DEA heartbeats Buildpacks Responsible for: •Staging • Detect, Compile, Release •Configure droplet • Runtime (Ruby/Java/Node/Python) • Container (Tomcat/Websphere) • Application (.WAR, .rb, .py)
  8. 8. Service Gateway A Service Gateway provides an interface for both native and external 3rd party services. Service processes run on Service Nodes or with external 3rd party SaaS services (e.g., email, messaging, database, storage, etc.). User Authentication and Authorization Router DEA Pool Service Gateway Apps Service Connector Health Manager Messaging Cloud Controller Build Packs Cloud Foundry BOSH Micro Clouds Private Clouds Public Clouds Service Nodes Cloud Foundry Components Responsible for: •Makes create/delete/bind/unbind calls to service nodes •Requests inventory of existing instances and bindings from cloud controller for caching, orphan management etc.
  9. 9. User Authentication and Authorization Router DEA Pool Service Gateway Apps Service Connector Health Manager Messaging Cloud Controller Build Packs Cloud Foundry BOSH Micro Clouds Private Clouds Public Clouds Service Nodes Messaging A fast internal messaging bus (NATS) manages all system communication. Cloud Foundry Components Responsible for: •Non-Persistent messaging •Pub/Sub •Queues (app events) •Directed messages (INBOX)
  10. 10. Staging and Runnning an Application
  11. 11. Creating Custom Frameworks / Buildpacks •Buildpacks are a convenient way of packaging framework and/or runtime support for your application. Standard buildpacks available Ruby (Rails, Rack and Sinatra),Java (Java_web, Spring, Grails and Play),Node • Custom Buildpacks: The buildpack structure is pretty straight forward. A buildpack repository contains three main scripts, situated in a folder named 'bin' bin/detect This script is used to determine whether to apply this buildpack to an application or not. The script is called with one argument, the build directory for the application. bin/compile The compile script is responsible for actually building the droplet that will be run by the DEA. The script is run with two arguments, the build directory for the application and the cache directory, which is a location the buildpack can use to store assets during the build process.bin/release The release script provides feedback metadata back to Cloud Foundry, it's run with one argument, the build location of the application. The expected format for the return data is YAML
  12. 12. DEAs and Warden Containers •DEAs: The Droplet Execution Agent (DEA) is written in Ruby and managing an application instance's life cycle. It can be instructed by the Cloud Controller to start and stop application instances. It keeps track of all started instances, and periodically broadcasts messages about their state over NATS (meant to be picked up by the Health Manager). The DEA depends on Warden to run application instances. •Warden: Warden is a framework that allows you to spawn containers in seconds and programmatically control resource isolation (memory, bandwidth, disk), mounts, processes and other things using APIs. Isolation is achieved by namespacing kernel resources that would otherwise be shared. The intended level of isolation is set such that multiple containers present on the same host should not be aware of each others presence Resource control is done by using Linux Control Groups. Every container is placed in its own control group At its core warden is a Ruby daemon. Currently tested and verified for Ubuntu and CentOS, though experimental version exists for Windows. DEA Pool Apps Build Packs
  13. 13. Organization and spaces are two new concept in NG Organizations: An organization is the top-most meta object within the Cloud Foundry infrastructure. Spaces: An organization can contain multiple spaces. The defaults for a standard Cloud Foundry install are development, test, and production. Domains: A domain is a domain-name like acme.com or foo.net. Routes: A route, based on a domain with an optional host as a prefix, may be associated with one or more applications. Organization/Spaces/Users
  14. 14. © 2013 IBM Corporation

×