Understanding Pivotal Cloud Foundry - sambos/Architectures GitHub Wiki

Pivotal Cloud Foundry Architecture

This page is dedicated to understand the PCF Architecture in a simplest way. Refer Cloud Foundry Architecture Concepts

  • Cloud Foundry - open source multi-cloud PaaS provider
  • PCF - Pivotal managed complete platform offering Cloud Foundry solution Diff-CF-vs-PCF
  • PWS - Pivotal Web Services is a PaaS operated by Pivotal - A hosted environment for PCF. Its hosted on AWS and has its own pricing model. You can deploy your own version of PCF on AWS or another IaaS as well.
  • PCF-Dev - Small footprint of PCF to be run on local machine for evaluation. Runs with basic services installed like Spring Cloud Services (SCS), MySQL, Redis databases and RabbitMQ broker. If you want to run it locally with SCS you need more than 6GB RAM free.

PCF Arch vs CF Arch

Diego Design Notes

DEA vs Diego (old vs new)

Terminology

Deployment

  • Bosh Bootloader (bbl)
    • Sets up CF IaaS (Both Director, public/private subnets, Load Balancers etc)
  • cf-deployment (cf-release deprecated)
    • use it for deploying cloudfoundry environment
  • jumpbox
    • acts as a proxy to Bosh - used to avoid exposing Bosh in public subnet. jumpbox is deployed in public subnet which then routes requests to bosh (deployed in private subnet)
  • KUBO

What does PCF do ?

PCF helps you in building cloud native applications without having to worry about managing infrastructure and portability across multiple clould provider issues. You develop an application and push to PCF, the platform does the rest deploy process:

  • does everything from understanding application dependencies
  • builds droplet - CF unit of execution
  • selects the appropriate Diego cell to run - Container building
  • Scaling and wiring up networking and routing

Diego

  • A self healing container management system. (resp for container placement & lifecycle)
  • Attempts to keep the correct number of instances running in Diego Cells to avoid network failures and crashes.
  • Relies on consistent datastore (MySQL or Postgres)
  • Component discovery and coordination is done by using Consul (now replaced by locket) - since noticed some issues with consul and Bosh.
  • pre-Diego -> DEA - (Droplet Execution Agent) was the Old version

Diego cell

  • A VM responsible to run Garden Containers - containerized workloads.
  • Diego schedules and runs Tasks and Long-Running Processes (LRP)
  • pre-Diego -> called DEA Node

Garden

  • A CF Container Engine
  • Responsible for creating containers and running/managing application processes in them
  • Garden visibility is local to itselft and Diego connects it to the rest of PCF
  • Garden has a platform neutral API for creating and running isolated environments (called containers).
  • Since Garden is built on open standards (supports multiple pluggable backends), its now possible to run Docker images

Warden

  • -- Now replaced by Garden
  • Warden is a container implementation used in CF (predates Docker)

BuildPack

  • A framework & Runtime support for an application in a given lang.
  • When Pushed CF automatically detects appropriate buildpack for your app.
  • CF has baseline buildpacks which can be extended for additional functionality support.

Droplet

  • A CF unit of execution.
  • Its an archive within PAS Runtime(Pivotal Application Service --earler-known-as: Elastic Runtime) ready to run on Diego.
  • droplet is the result of application staging process