Cloud Foundry Overview
This topic describes Cloud Foundry and how it works.
Cloud platforms let anyone deploy network apps or services and make them available to the world in a few minutes. When an app becomes popular, the cloud easily scales it to handle more traffic, replacing with a few keystrokes the build-out and migration efforts that once took months. Cloud platforms represent the next step in the evolution of IT, enabling you to focus exclusively on your apps and data without worrying about underlying infrastructure.
Not all cloud platforms are created equal. Some have limited language and framework support, lack key app services, or restrict deployment to a single cloud. Cloud Foundry has become the industry standard. It is an open source platform that you can deploy to run your apps on your own computing infrastructure, or deploy on an IaaS like vSphere, AWS, Azure, GCP, or OpenStack. You can also use a PaaS deployed by a commercial Cloud Foundry cloud provider. A broad community contributes to and supports Cloud Foundry. The platform’s openness and extensibility prevent its users from being locked into a single framework, set of app services, or cloud.
Cloud Foundry is ideal for anyone interested in removing the cost and complexity of configuring infrastructure for their apps. Developers can deploy their apps to Cloud Foundry using their existing tools and with zero modification to their code.
See the following links for more information:
- Cloud Foundry project on GitHub
- Cloud Foundry Certified Platforms
- Welcome to the Cloud Foundry Community
To flexibly serve and scale apps online, Cloud Foundry has subsystems that perform specialized functions. The sections below describe how some of these main subsystems work.
This section describes how Cloud Foundry handles load balancing.
Clouds balance their processing loads over multiple machines, optimizing for efficiency and resilience against point failure. A Cloud Foundry installation accomplishes this using the following components:
BOSH: creates and deploys VMs on top of a physical computing infrastructure, and deploys and runs Cloud Foundry on top of this cloud. To configure the deployment, BOSH follows a manifest document. For more information, see the BOSH documentation.
Cloud Controller: runs the apps and other processes on the cloud’s VMs, balancing demand and managing app lifecycles. For more information, see Cloud Controller.
Gorouter: routes incoming traffic from the world to the VMs that are running the apps that the traffic demands, usually working with a customer-provided load balancer. For more information, see Gorouter.
This section describes the VMs that run your apps in Cloud Foundry and how the platform packages your apps to run on these VMs.
Cloud Foundry designates the following types of VMs:
- Component VMs: make up the platform’s infrastructure.
- Host VMs: host your apps for the outside world.
Within Cloud Foundry, the Diego system distributes the hosted app load over all of the host VMs, and keeps it running and balanced through demand surges, outages, or other changes. Diego accomplishes this through an auction algorithm.
For more information, see Diego Components and Architecture.
To meet demand, multiple host VMs run duplicate instances of the same app. This means that apps must be portable. Cloud Foundry distributes app source code to VMs with everything the VMs need to compile and run the apps locally.
Cloud Foundry includes the following with your app’s source code:
- Stack: the operating system the app runs on.
- Buildpack: contains all languages, libraries, and services that the app uses.
Before sending an app to a VM, the Cloud Controller stages it for delivery by combining the stack, buildpack, and source code into a droplet that the VM can unpack, compile, and run. For simple, standalone apps with no dynamic pointers, the droplet can contain a pre-compiled executable instead of source code, language, and libraries.
For more information, see the following topics:
This section describes authentication in Cloud Foundry.
Cloud Foundry manages user accounts through two User Authentication and Authorization (UAA) servers, which support access control as OAuth2 services and can store user information internally, or connect to external user stores through LDAP or SAML.
For more information, see User Account and Authentication (UAA) Server.
The following table describes what the two UAA servers do:
|First UAA server||
|Second UAA server||
For more information, see Orgs, Spaces, Roles, and Permissions.
This section describes how Cloud Foundry stores its resources.
Cloud Foundry uses the git system on GitHub to version control source code, buildpacks, documentation, and other resources. Developers on the platform also use GitHub for their own apps, custom configurations, and other resources. To store large binary files, such as droplets, Cloud Foundry maintains an internal or external blobstore. Cloud Foundry uses MySQL to store and share temporary information, such as internal component states.
This section describes how Cloud Foundry components communicate with one another.
Cloud Foundry components communicate in two of the following ways:
- By sending messages internally using HTTP and HTTPS protocols
- By sending NATS messages to each other directly
For more information, see Messaging (NATS).
BOSH Director co-locates a BOSH DNS server on every deployed VM. All VMs keep up-to-date DNS records for all the other VMs in the same foundation. This enables service discovery between VMs.
BOSH DNS allows deployments to continue communicating with VMs even when the VMs’ IP addresses change. It also provides client-side load balancing by randomly selecting a healthy VM when multiple VMs are available.
For more information about BOSH DNS, see Native DNS Support in the BOSH documentation.
This section describes logging in Cloud Foundry.
Cloud Foundry generates system logs from Cloud Foundry components and app logs from hosted apps.
As Cloud Foundry runs, its component and host VMs generate logs and metrics. Cloud Foundry apps also typically generate logs. The Loggregator system aggregates the component metrics and app logs into a structured, usable form, the Firehose. You can use all of the output of the Firehose, or direct the output to specific uses, such as monitoring system internals, triggering alerts, or analyzing user behavior, by applying nozzles.
For more information, see .
The component logs follow a different path. They stream from rsyslog agents, and the cloud operator can configure them to stream out to a syslog drain.
This section describes how you can use services with your apps on Cloud Foundry.
Typical apps depend on free or metered services such as databases or third-party APIs. To incorporate these into an app, a developer writes a Service Broker, an API that publishes to the Cloud Controller the ability to list service offerings, provision the service, and enable apps to make calls out to it.
For more information, see Services.View the source for this page in GitHub