This document provides an overview of the key components of Cloud Foundry, including: - The Cloud Controller which manages application deployments, services, user roles, and more. - Buildpacks which stage and compile applications to create droplets run by DEAs on VMs. - DEAs which manage application container lifecycles using Warden containers for isolation. - Routers which route traffic to applications and maintain dynamic routing tables. - Services which provide interfaces to both native and 3rd party services running on Service Nodes. - UAA which handles user authentication, authorization, and manages OAuth access credentials. It also describes how organizations and spaces segment the platform and how domains

1. Cloud Series
Cloud Foundry NG Deep Dive
Animesh Singh (singhan@us.ibm.com)

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. 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. 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. 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. 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. 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. 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. 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. Staging and Runnning an Application

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. 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. 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. © 2013 IBM Corporation