Your SlideShare is downloading. ×
Cloud Foundry Technical Overview
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cloud Foundry Technical Overview


Published on

Cloud Foundry Technical Overview

Cloud Foundry Technical Overview

Published in: Technology

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. 1© 2013 Pivotal Software, Inc. All rights reserved Cloud Foundry Technical Overview By Pivotal
  • 2. 2 * An actual application provisioning/update flow in a large enterprise. Image is blurred for privacy reasons Simplify Application Deployment, from: this…
  • 3. 3 To: Pushing apps to the cloud with a few easy verbs target  <my  cloud>   push  <my  app>   create  <my  services>   bind  <my  services>   scale  <my  app>  +100   Cloud  Deployment:    2-­‐4  hours App  Deployment:    30-­‐90  seconds DeveloperOperator cf-­‐iaas.yml   provision  <my  cloud>   add_capacity  <my  cloud>  
  • 4. 4 Overview: Deploying App to Cloud Foundry Runtime Developer ①  Upload app bits and metadata push app Router   ②  Create and bind services ③  Stage application ④  Deploy application ⑤  Manage application health …which we will depict in a moment Cloud  Foundry  (PaaS)   Blobstore DB Cloud Controller Service Broker Node(s) DEA DEA DEA DEA + app MD + = Service credentials app MD
  • 5. 5 Creating and Binding a Service Developer Router   Cloud  Foundry  (PaaS)   DB Service credentials reserve resourcescreate service (HTTP) create service (HTTP) bind service (HTTP)bind service (HTTP) obtain connection data CLI Cloud Controller Service Broker Data Service
  • 6. 6 Stage an Application Developer Router   Cloud  Foundry  (PaaS)   Blobstore DB DEA Detect Compile Upload No Yes System Buildpacks + = Cloud Controller
  • 7. 7 Deploying an Application Developer Router   Blobstore Cloud Controller Messaging (NATS) DEA DEA DEA Cloud  Foundry  (PaaS)   Access App ①  Deploy message ②  Droplet deployed ③  Routes registered ④  Port forwarding ①  ①  ①  ②  ③  ③  ③  ④ 
  • 8. 8 Router   Monitoring and Replacing an Application Developer Blobstore Cloud Controller Health Manager Actual StateDesired State Messaging (NATS) DEA DEA DEA Cloud  Foundry  (PaaS)   ①  App status messaging ②  App instance fails ③  Health manager detects and advises ④  New app instance deployed ⑤  Routing table updated ①  ②  ③  ④  ①  ①  ⑤ 
  • 9. 9 Dynamic  Router   Cloud  Controller   UAA/Login  Servers   Health  Manager   DEA  Pool  Service  Broker  Node(s)   User  Provided   Service  Instances   Messaging  (NATS)   Apps   Cloud  Foundry  BOSH   Build  Packs   Logging   Cloud Foundry Architecture The Cloud Foundry platform is abstracted as a set of large-scale distributed services. It uses Cloud Foundry Bosh to operate the underlying infrastructure from IaaS providers (e.g., VMware, Amazon AWS, OpenStack). Internet Underlying Infrastructure PaaS Components are dynamically discoverable and loosely coupled, exposing health through HTTP endpoints so agents can collect state information (app state & system state) and act on it.
  • 10. 10 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. How  It  Works: •  Load balancing •  Maintaining an active routing table •  Access logs •  Supports web-sockets Responsible  For: Roadmap: App-specific Metrics Throughput Latency HTTP Response Codes Bandwidth SSL Termination Router
  • 11. 11 The Cloud Controller maintains command and control systems, including interface with clients (CLI, Web UI, Spring STS), account and provisioning control. It also provides RESTful interface to domain objects (apps, services, organizations, spaces, service instances, user roles, and more). How  It  Works: •  Expected App state, state transitions, and desired convergence •  Permissions/Auth •  Orgs/Spaces/Users •  Services management •  App placement •  Auditing/Journaling and billing events •  Blob storage Responsible  For: Roadmap: Availability Zone Aware Placement Richer Auditing with Queries and Filters OpenStack Swift Blob Configuration Oauth Scope and Role Mapping Cloud Controller
  • 12. 12 “User Authorization and Authentication” provides identity, security and authorization services. It manages third party Oauth 2.0 access credentials and can provide application access and identity-as-a-service for apps running on Cloud Foundry. Composed of: UAA Server, Command Line Interface, Library. How  It  Works: •  Token Server •  ID Server (User management) •  OAuth Scopes (Groups) and SCIM •  Login Server •  UAA Database •  SAML support (for SSO integration) and Active Directory support with the VMWare SSO Appliance •  Access auditing Responsible  For: Roadmap: LDAP Login Server App User Management Services Horizontally Scalable Login Server UAA and Login Servers
  • 13. 13 Health Manager monitors application uptime by listening to the NATS message bus for mismatched application states (expected vs. actual). The Cloud Controller publishes expected state and the DEAs publish actual state. State mismatches are reported to the Cloud Controller. How  It  Works: •  Maintains the actual state of apps •  Compares to expected state •  Sends suggestions to make actual match expected (cannot make state changes itself – only CC can do that!) Responsible  For: Roadmap: Short-lived Apps Configurable Restart Policies Horizontally Scalable Health Manager Health Manager
  • 14. 14 “Droplet Execution Agents” are secure and fully isolated containers. DEAs are responsible for an Apps lifecycle: building, starting and stopping Apps as instructed. They periodically broadcast messages about their state via the NATS message bus. How  It  Works: •  Managing Linux containers (Warden) •  Monitoring resource pools •  Process •  File system •  Network •  Memory •  Managing app lifecycle •  App log and file streaming •  DEA heartbeats (NATS to CC, HM) Responsible  For: Roadmap: Placement Pools for Advanced Resource Allocation and Isolation Aggregated Logs Including All App Instances and App-related System Logs Evaluation of Windows .NET DEAs from Iron Foundry App Log Draining with Syslog DEA
  • 15. 15 Buildpacks are Ruby scripts that detect application runtimes/frameworks/plugins, compile the source code into executable binaries, and release the app to an assigned DEA. Runtime components can be cached for faster execution of subsequent app pushes. How  It  Works: •  Staging* •  /bin/detect •  /bin/compile •  /bin/release •  Configure droplet •  Runtime (Ruby/Java/Node/Python) •  Container (Tomcat/Websphere/Jetty) •  Application (.WAR, .rb, .js, .py) Responsible  For: Roadmap: Buildpack Management Including Updates and Versioning vFabric Import Tool Enhanced Caching (*) Cloud Foundry Buildpacks are compatible with Heroku Buildpacks
  • 16. 16 NATS is a fast internal messaging bus to manage system wide communication via a publish-and-subscribe mechanism. How  It  Works: •  Non-Persistent messaging •  Pub/Sub •  Queues (app events) •  Directed messages (INBOX) Responsible  For: Roadmap: RabbitMQ Investigation Robust Message Bus Interface Horizontal Scaling Messaging (NATS)
  • 17. 17 Service Brokers provide an interface for native and external 3rd party services. Service processes run on Service Nodes or with external as-a-service providers (e.g., email, database, messaging, etc.). How  It  Works: •  Advertising service catalog •  Makes create/delete/bind/unbind calls to service nodes •  Requests inventory of existing instances and bindings from cloud controller for caching, orphan management •  SaaS marketplace gateway •  Implemented as HTTP enpoint, written in any language. Responsible  For: Roadmap: Multi-Node Support Service Broker Asynchronous protocol
  • 18. 18 Service Broker Example: + AppDirect (
  • 19. 19 UPSI (formerly “Service Connectors”) store meta-data in the Service Broker to enable Cloud Foundry to connect to local services that are NOT managed by Cloud Foundry (e.g., OracleDB, DB2, SQLServer, etc.) How  It  Works: •  Metadata management Responsible  For: Roadmap: Investigate Sharing Service Instances Across Spaces Service Type Templates (OracleDB, DB2, SQLServer, MQSeries) User Provided Service Instances
  • 20. 20 User Provided Service Instances (on-prem example) Service Broker Gateway Alt Broker Service Broker Service Broker IBM DB2 ORACLE DB CF MySQL MYSQL DB LB Mongo Lab Send Grid AppDirect ClearDB INTERNET Synchronous Synchronous Synchronous Service Connector Service Connector
  • 21. 21 To: Pushing apps to the cloud with a few easy verbs target  <my  cloud>   push  <my  app>   create  <my  services>   bind  <my  services>   scale  <my  app>  +100   DeveloperOperator cf-­‐iaas.yml   provision  <my  cloud>   add_capacity  <my  cloud>  
  • 22. 22 Message Bus Deploying the CF Runtime with Cloud Foundry BOSH IaaS   Cloud  Foundry  BOSH   (  the  PaaS)   DB BOSH Director Blobs Health Monitor Deployment •  Packages •  Jobs •  Blobs •  Source •  Manifest Deploy my CF Worker VMs Messaging Target VMHealth Manager Target VMCloud Controller Target VM Operator
  • 23. 23 BOSH (Outer Shell) Logical View Deploys and manages large scale distributed systems. BOSH provides the means to go from deployment (i.e., Chef/Puppet) to VM creation and management (i.e., cloud CPI). It includes interfaces for vSphere, vCloud, AWS and OpenStack. Additional CPI can be written for alternative IaaS providers. Key Elements: •  CLI •  Director •  Blobstore •  Workers •  Message Bus •  Health Monitor •  IaaS CPI •  Agents DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 24. 24 BOSH: Command Line Interface The Command Line Interface is how users interact with BOSH using a terminal session to do a deployment, create and upload releases, and upload ‘stemcells’ (i.e. a VM template with an embedded Agent). DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 25. 25 The core orchestrating component in BOSH which controls creation of VMs, deployment, and other life cycle events of software and services. Command and control is handed over to the the Director- Agent interaction after the CPI has created resources. BOSH: Director DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 26. 26 The core BOSH engine is abstracted from any particular IaaS. IaaS interfaces are implemented as plugins to BOSH. Currently, BOSH supports both VMware vSphere and Amazon Web Services. These CPIs allow for automated VM and storage disk provisioning, and network management. BOSH: Cloud Provider Interface (CPI) DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 27. 27 BOSH: Cloud Provider Interface Stemcell create_stemcell(image, cloud_properties) delete_stemcell(stemcell_id) VM create_vm(agent_id, stemcell_id, resource_pool, networks, disk_locality, env) delete_vm(vm_id) reboot_vm(vm_id) configure_networks(vm_id, networks) Disk create_disk(size, vm_locality) delete_disk(disk_id) attach_disk(vm_id, disk_id) detach_disk(vm_id, disk_id) IaaS Neutral ...ETC
  • 28. 28 Used to store the content of Releases, Jobs and Packages in their source form as well as the compiled image. When you deploy a Release, BOSH will orchestrate the compilation of packages and store the result in Blobstore. When BOSH deploys a Job to a VM, the Agent will pull the specified Job and associated Packages from the Blobstore. BOSH: Blobstore DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 29. 29 Every VM contains an Agent. Through the Director-Agent interaction, VMs are given Jobs, or roles, within Cloud Foundry. If the VM's job is to run MySQL, for example, the Director will send instructions to the Agent about which packages must be installed and what the configurations for those packages are. BOSH: Agents DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 30. 30 A Stemcell is a VM template with an embedded Agent. Stemcells are uploaded using the CLI and used by the Director when creating VMs through the CPI. When the Director creates a VM through the CPI, it will pass along configurations for networking and storage, as well as the location and credentials for the Message Bus (NATS) and the Blobstore. BOSH: Stemcells DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 31. 31 Receives health status and life cycle events from Agents and can send alerts through notification plugins (such as email) to operations staff. BOSH: Health Monitor DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 32. 32 BOSH components use NATS, a lightweight pub sub messaging system, for command and control. BOSH: NATS DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents
  • 33. 33 BOSH: Putting it all together DB Blob Store Worker NATS Health Monitor CPI DirectorCLI Inner shell Outer shell Agents When you deploy Cloud Foundry the following sequence of steps occur: 1.  Target a BOSH director using CLI 2.  Upload a Stemcell 3.  Get a Release from a repo 4.  Create a deployment manifest 5.  BOSH Deploy Cloud Foundry: •  Prepare deployment •  Compile packages •  Create and bind VMs •  Pull in job configurations •  Create needed job instances – this is where things get pushed live