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.
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
- kubo (Kubernetes and Bosh) - For deploying Kubernetes on many IaaS using Bosh
- Deploying kubernetes on vSphere using Bosh
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