Cloud Foundry Diego Project
Diego schedules and runs Tasks and Long Running Processes:
Tasks and LRPs are submitted to Diego via a RESTful HTTP API documented extensively in Diego’s Receptor API docs. Diego’s Auctioneer optimally distributes Tasks and LRPs to the cluster of Diego Cells via an Auction involving the Cell Reps. Once a Task/LRP is assigned to a Cell, the Executor spins up a Garden container and executes the work encoded in the Task/LRP. This work is encoded as a generic, platform-independent, recipe of composable actions.
An up-to-date cache of the state of the Diego cluster (including a picture-in-time of all desired LRPs, running LRP instances, and inflight Tasks) is maintained in the BBS (Bulletin Board System/Store). The Converger operates on the BBS periodically and takes actions to ensure Diego attains eventual consistency.
Diego interfaces with doppler to provide real-time streaming logs for all Tasks/LRPs. Diego also interfaces with the gorouter to automatically route web traffic to running LRP instances.
Diego is the next-generation runtime powering Cloud Foundry (CF), however Diego is abstracted away from CF: CF simply consumes Diego via the Receptor API. For now, there is a translation layer called the CC-Bridge that converts the Cloud Controller’s domain-specific requests to stage and run applications into requests for Tasks and LRPs. Eventually Cloud Controller will be modified to communicate directly with the Receptor. The process of staging and running a CF application is complex and filled with platform and implementation-specific details. We encapsulate these concerns in a triad of binaries known collectively as the App Lifecycle. The Tasks and LRPs produced by the CC-Bridge download the App Lifecycle binaries and run them to stage, start, and health-check CF applications.
|Platforms (OS)||Non-OS specific|
Presentation on Diego: http://www.slideshare.net/mstine/cloud-foundry-diego