Diego Architecture

Page last updated: October 30, 2015

This topic provides an overview of the high-level structure of Diego, the next-generation container management system for Cloud Foundry (CF).

  • To deploy Diego, see the GitHub Diego-Release

  • For more information about the major components of Diego and how they interact with other Cloud Foundry components, see the Diego Components topic.

Overview

In a Cloud Foundry deployment without Diego, the Cloud Controller schedules and manages applications on the Droplet Execution Agents (DEAs). Diego replaces the DEAs and the Health Manager (HM9000), and assumes application scheduling and management responsibility from the Cloud Controller.

Refer to the diagram and descriptions below for information about the way Diego handles application requests.

  1. The Cloud Controller passes requests to stage and run applications to the Cloud Controller Bridge (CC-Bridge).

  2. The CC-Bridge translates staging and running requests into Tasks and Long Running Processes (LRPs), then submits these to the Bulletin Board System (BBS) through an RPC-style API over HTTP.

  3. The BBS submits the Tasks and LRPs to the Auctioneer, part of the Diego Brain.

  4. The Auctioneer distributes these Tasks and LRPs to Cells through an Auction.

  5. Once the Auctioneer assigns a Task or LRP to a Cell, an in-process Executor creates a Garden container in the Cell. The Task or LRP runs in the container.

  6. The BBS tracks desired LRPs, running LRP instances, and in-flight Tasks for the Converger, part of the Diego Brain. The Converger periodically analyzes this information and corrects discrepancies to ensure consistency between ActualLRP and DesiredLRP counts.

  7. Metron Agents, part of the Cells, forward application logs, errors, and metrics to the Cloud Foundry Loggregator. For more information, see the Application Logging in Cloud Foundry topic.

Monitoring and Testing

The following releases monitor and test runtime deployment:

Inigo

Inigo is an integration test suite that launches the Diego components through various test cases, including component failures and other exceptional scenarios. Inigo validates a given set of component versions to ensure mutual compatibility, robustness, and graceful performance degradation in failure conditions.

Refer to the Inigo repo on GitHub for more information.

Auction

The auction package encodes behavioral details about Task and LRP allocation to cells during a Diego Auction. It includes a simulation test suite that validates the optimal performance of the auction algorithm. You can run the simulation for different algorithm variants at various scales, and in the following ways:

  • In-process, for short feedback loops

  • Across multiple processes, to reveal the impact of communication in the auction

  • Across multiple machines in a cloud-like infrastructure, to reveal the impact of latency on the auction

Refer to the Auction repo on GitHub for more information.

Diego Acceptance Tests

Diego Acceptance Tests (DAT) is a suite of acceptance-level tests that run against Cloud Foundry and Diego deployment releases. DAT executes a number of “happy-path” test cases across an entire deployment.

Refer to the Diego Acceptance Test repo on GitHub for more information.