Cloud Foundry

Cloud Foundry can be run on cloud infrastructures such as Amazon Web Services (AWS), Microsoft Azure, Google Compute Platform (GCP), OpenStack, VMware vSphere, SoftLayer and many more.

At Comcast, Cloud Foundry is run on VMware vSphere and Amazon Web Services (AWS). Unlike VMware vSphere, using Cloud Foundry in AWS incurs recurring costs to customers. If you are interested in taking advantage of using Cloud Foundry on AWS, please send a message to @cfadmin on the #cloudfoundry Slack channel.

Supported Application Platforms 

Cloud Foundry supports a wide array of application platforms through their Buildpack mechanism. Buildpacks provide the runtime environment for your application. The platform will automatically combine your application code with one of these buildpacks to create a droplet that will run as a container in CF. Some of the supported buildpacks are shown below:

• JAVA
• Node.js
• Python
• Go
• .NET Core
• Static HTML
• Ruby
• PHP
• Docker Images (non-buildpack) – Docker image

Other platforms are also supported through the use of online community Buildpacks.

Integrated Services 

In addition to providing a platform for hosting applications, Cloud Foundry also includes integrated services that provide additional capabilities. These services are available on-demand through the CLI/UI, and through the CF Service Broker facility, can be easily integrated into your application. For more information about using services, please see the Cloud Foundry documentation.

Tenancy and Quotas 

Cloud Foundry is a multi-tennant solution that can host many different applications within isolated areas called Orgs. An Org is a collection of Users, Spaces, and Apps that share a single Quota. When users request creation of an Org in Cloud foundry, they will be given full access to that CF Org. Adding new users to an existing CF Org is self-service.

Restrictions 

While CF is a compelling platform with many advantages, not everything can run in CF. Before you begin requesting access for CF and getting started, you should head over to our standards section.

Cloud Foundry Architecture

Cloud Foundry makes it faster and easier to build, test, deploy and scale applications, providing a choice of clouds, developer frameworks, and application services. This document will not only cover components that make up the Cloud Foundry ecosystem but also components that are specific to Comcast’s implementation of Cloud Foundry. For more detailed reading on all Cloud Foundry components, visit the Cloud Foundry documentation

HAProxy (Comcast-specific) 

The HAProxy is the front end for all ingress traffic into Cloud Foundry. The HAProxy component is created, deployed and managed by the CNAP Team. This implementation allows the CNAP Team to provide customers the ability to bring their own custom certificates and use it with applications deployed in Cloud Foundry. The HAProxy performs SSL Termination and balances load between all of the Cloud Foundry Routers.

Routers 

The Cloud Foundry router component routes incoming traffic to the appropriate component, either a Cloud Controller component (for all API and UI calls) or to a hosted application running on a Diego Cell. Using internal Cloud Foundry mechanisms, the router updates itself periodically with information on where an applications app instances reside. The router routes application traffic to all application instances in a round-robin fashion.

UAA 

The Cloud Foundry UAA component is responsible for providing identity management. At Comcast, UAA is configured to use secure LDAP for all non-PCI sites and SAML authentication for all PCI sites.

Cloud Controller and Diego Brain 

The Cloud Foundry Cloud Controller (CC) is the component that receives all the requests for Application Management. Every time you execute a command using the CLI or API, you are targeting the Cloud Controller. When pushing an application to Cloud Foundry, the Cloud Controller directs the Diego Brain to coordinate staging and running applications on Diego Cells.

The Cloud Controller is also responsible for maintaining records of orgs, spaces, user roles, services, and more.

Blobstore 

The Cloud Foundry blobstore is a repository for storing large binary files. The Blobstore stores application code packages, buildpacks and application droplets. For Private Cloud deployments on VSphere, VSphere datastores are used. For Public Cloud deployments on AWS, S3 is used as the Blobstore.

Diego Cell 

The Cloud Foundry Diego cell is where all applications run as containers. Each Diego cell may host multiple application containers and, among a lot of functions, reports its app status to other Cloud Foundry components.

Loggregator 

The Cloud Foundry loggregator system is responsible for streams logs to the console or logging endpoints defined by developers. Since the loggregator is a shared component across all tenants in a Cloud Foundry site, it can be easily abused by applications or customers streaming numerous logs. For reliable delivery of your application logs, follow the best practices for logging in Cloud Foundry

Service Brokers 

Cloud Foundry Service Brokers are connectors that enable application teams to use consume services such as databases or third-party SaaS providers easily. You can view the list of services available in a Cloud Foundry site, by running the command cf marketplace using the CLI. When a developer provisions and binds a service to an application, the service broker for that service is responsible for providing the service instance.

Architecture Diagram 

The below diagram is a basic representation of how traffic flows within a Cloud Foundry site deployed in the Green Network zone at Comcast. Green zone applications can be exposed to the Internet and ingress traffic to them come via a separate set of HAProxies deployed in the Blue Network Zone.