A Journey to the Center of the Cloud Foundry
summary
Shows exactly what happens after a cf push: the Cloud Controller writes a desired-state record into its DB, asks the blobstore for uploaded files, and invokes staging which runs Buildpack detect/compile/release to produce an immutable droplet. Diego schedules staging tasks and long‑running LRPs via an auction managed by the BBS (backed by etcd), distributing containers across cells and restarting crashed instances. Routing uses gorouter and route emitters, logs stream through Metron to Dopplers and the Traffic Controller firehose. cf push creates record in CC DB garden runC replacing garden-linux
AI-written summary · about
chapters (16)
- 0:00Introduction to journey
- 1:17Meet the speakers
- 1:38Map of Cloud Foundry
- 4:47Using CF CLI
- 5:08Cloud Controller overview
- 6:11HTTP routing explained
- 7:59Uploading application files
- 9:50Buildpacks and staging
- 11:15Staging and runtime
- 14:50Crossing to Diego Island
- 17:00How Diego stages apps
- 21:15Diego components
- 21:35Introducing Garden
- 24:50Accessing running apps
- 25:55Logging in Cloud Foundry
- 28:03Journey recap
related talks
22mPushing the Limits: Cloud Foundry Runtime and Routing at SAP...
45mKeynote:
19mHow Did Our Garden Grow? Advances in the Cloud Foundry App...
26mThe State of Supply Chain Security in the Cloud Foundry Ecosystem
12mCF Application Runtime Demo: Weighted Routing (Istio/Envoy), Multiple Custom App Ports...
29mConsiderations of a Practical Migration to Cloud Foundry
22mEmbracing OCI and CNI Open Container Standards Between Garden & Friends
01h 00mBuilding Cloud-Native Applications