Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Cloud Foundry Technical Overview

This presentation covers both the Cloud Foundry Elastic Runtime (known by many as just "Cloud Foundry") as well as the Operations Manager (known by many as BOSH). For each, the main components are covered with interactions between them.

  • Identifiez-vous pour voir les commentaires

Cloud Foundry Technical Overview

  1. 1. Cloud Foundry Technical Overview By Pivotal © 2013 Pivotal Software, Inc. All rights reserved 1
  2. 2. Simplify Application Deployment, from: this… * An actual application provisioning/update flow in a large enterprise. Image is blurred for privacy reasons 2
  3. 3. To: Pushing apps to the cloud with a few easy verbs Operator cf-­‐iaas.yml   provision  <my  cloud>   add_capacity  <my  cloud>   Cloud  Deployment:    2-­‐4  hours Developer target  <my  cloud>   push  <my  app>   create  <my  services>   bind  <my  services>   scale  <my  app>  +100   App  Deployment:    30-­‐90  seconds 3
  4. 4. Overview: Deploying App to Cloud Foundry Runtime Blobstore push app DB app MD Service credentials + app MD ②  Create and bind services ③  Stage application ④  Deploy application ⑤  Manage application health Router   ①  Upload app bits and metadata Developer Cloud Controller DEA DEA DEA + = DEA Service Broker Node(s) Cloud  Foundry   Run.me  (PaaS)   …which we will depict in a moment 4
  5. 5. Creating and Binding a Service DB create service (HTTP) bind service (HTTP) Router   CLI Cloud Controller Developer Service credentials create service (HTTP) bind service (HTTP) Service Broker reserve resources Data Service obtain connection data Cloud  Foundry   Run.me  (PaaS)   5
  6. 6. Stage an Application Blobstore Developer DB Router   Cloud Controller DEA Detect System Buildpacks Compile Upload No Yes + = Cloud  Foundry   Run.me  (PaaS)   6
  7. 7. Deploying an Application Blobstore ②  Droplet deployed ①  ②  ③  Routes registered Messaging (NATS) ①  ④  Router   ①  Deploy message Cloud Controller ③  Access App Developer DEA ③  ④  Port forwarding ③  ①  DEA DEA Cloud  Foundry   Run.me  (PaaS)   7
  8. 8. Monitoring and Replacing an Application Developer ③  ①  Desired State Actual State App status Blobstore messaging ②  App instance fails ③  Health manager Cloud Controller Health Manager ④  ⑤  Messaging (NATS) detects and advises ④  ①  New app instance ①  ①  ⑤  Routing table updated Router   deployed DEA DEA ②  DEA Cloud  Foundry   Run.me  (PaaS)   8
  9. 9. Cloud Foundry Architecture Internet Dynamic  Router   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). Cloud  Controller   UAA/Login  Servers   DEA  Pool   Service  Broker  Node(s)   Apps   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. Health  Manager   User  Provided   Service  Instances   Build  Packs   Logging   Messaging  (NATS)   Cloud  Foundry  BOSH   Underlying Infrastructure 9
  10. 10. Router Responsible  For: How  It  Works: 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. •  •  •  •  Load balancing Maintaining an active routing table Access logs Supports web-sockets Roadmap: App-specific Metrics Throughput Latency HTTP Response Codes Bandwidth SSL Termination 10
  11. 11. Cloud Controller How  It  Works: 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). Responsible  For: •  Expected App state, state transitions, and desired convergence •  Permissions/Auth •  Orgs/Spaces/Users •  Services management •  App placement •  Auditing/Journaling and billing events •  Blob storage Roadmap: Availability Zone Aware Placement Richer Auditing with Queries and Filters Oauth Scope and Role Mapping OpenStack Swift Blob Configuration 11
  12. 12. UAA and Login Servers Responsible  For: How  It  Works: “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. •  •  •  •  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 Roadmap: LDAP Login Server Horizontally Scalable Login Server App User Management Services 12
  13. 13. Health Manager Responsible  For: How  It  Works: 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. •  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!) Roadmap: Short-lived Apps Horizontally Scalable Health Manager Configurable Restart Policies 13
  14. 14. DEA How  It  Works: “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. Roadmap: •  •  Responsible  For: 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) Placement Pools for Advanced Resource Allocation and Isolation Evaluation of Windows .NET DEAs from Iron Foundry Aggregated Logs Including All App Instances and App-related System Logs App Log Draining with Syslog 14
  15. 15. Buildpacks How  It  Works: 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. Responsible  For: •  Staging* •  •  •  /bin/detect /bin/compile /bin/release •  Configure droplet •  •  •  Runtime (Ruby/Java/Node/Python) Container (Tomcat/Websphere/Jetty) Application (.WAR, .rb, .js, .py) (*) Cloud Foundry Buildpacks are compatible with Heroku Roadmap: vFabric Import Tool Enhanced Caching Buildpack Management Including Updates and Versioning 15
  16. 16. Messaging (NATS) How  It  Works: NATS is a fast internal messaging bus to manage system wide communication via a publish-and-subscribe mechanism. Responsible  For: •  •  •  •  Non-Persistent messaging Pub/Sub Queues (app events) Directed messages (INBOX) Roadmap: Robust Message Bus Interface Horizontal Scaling RabbitMQ Investigation 16
  17. 17. Service Broker Responsible  For: How  It  Works: 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.). •  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. Roadmap: Multi-Node Support Asynchronous protocol 17
  18. 18. Service Broker Example: run.pivotal.io + AppDirect (run.pivotal.io) 18
  19. 19. User Provided Service Instances How  It  Works: 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.) Responsible  For: •  Metadata management Roadmap: Service Type Templates (OracleDB, DB2, SQLServer, MQSeries) Investigate Sharing Service Instances Across Spaces 19
  20. 20. User Provided Service Instances (on-prem example) Synchronous AppDirect INTERNET Synchronous Service Connector IBM DB2 Service Broker Service Connector Synchronous ORACLE DB Service Broker Gateway Service Broker Alt Broker CF MySQL MYSQL DB Mongo Lab Send Grid LB ClearDB 20
  21. 21. To: Pushing apps to the cloud with a few easy verbs Operator cf-­‐iaas.yml   provision  <my  cloud>   add_capacity  <my  cloud>   Developer target  <my  cloud>   push  <my  app>   create  <my  services>   bind  <my  services>   scale  <my  app>  +100   21
  22. 22. Deploying the CF Runtime with Cloud Foundry BOSH Operator DB Deploy my CF BOSH Director Worker VMs Blobs Message Bus Deployment •  Packages •  Jobs •  Blobs •  Source •  Manifest Messaging Health Manager Target VM Health Monitor Cloud Controller VM Target Cloud  Foundry  BOSH   (Opera.ng  the  PaaS)   Target VM IaaS   22
  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 Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 23
  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). Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 24
  25. 25. BOSH: Director 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 DirectorAgent interaction after the CPI has created resources. Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 25
  26. 26. BOSH: Cloud Provider Interface (CPI) 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. Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 26
  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) IaaS Neutral ...ETC Disk create_disk(size, vm_locality) delete_disk(disk_id) attach_disk(vm_id, disk_id) detach_disk(vm_id, disk_id) 27
  28. 28. BOSH: Blobstore 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. Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 28
  29. 29. BOSH: Agents 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. Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 29
  30. 30. BOSH: Stemcells 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. Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 30
  31. 31. BOSH: Health Monitor Receives health status and life cycle events from Agents and can send alerts through notification plugins (such as email) to operations staff. Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 31
  32. 32. BOSH: NATS BOSH components use NATS, a lightweight pub sub messaging system, for command and control. Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 32
  33. 33. BOSH: Putting it all together When you deploy Cloud Foundry the following sequence of steps occur: 1.  2.  3.  4.  5.  Target a BOSH director using CLI Upload a Stemcell Get a Release from a repo Create a deployment manifest 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 Blob Store DB CLI Director Worker NATS Health Monitor CPI Inner shell Outer shell Agents 33