Diego 架构

Diego是Cloud Foundry中全新的容器管理系统。本文简要概述Diego的架构和组件。

本文包含以下几个部分：

架构图

Diego 核心组件
Diego Brain
Auctioneer

Diego Cells
Rep

Executor

Garden

Metron Agent

Database VMs
Diego Bulletin Board System

MySQL

Access VMs
File Server

SSH Proxy

Consul
Go MySQL 驱动

Cloud Controller Bridge 组件
Stager

CC-Uploader

Nsync

TPS

平台特定组件
Garden 后台

应用生命周期二进制文件
目前实现

其他组件
Route-Emitter

架构图

Cloud Foundry 采用Diego架构来管理应用的容器。Diego各组件承担来自Cloud Controller的应用调度和管理职责。

下图及其描述给出了Diego处理应用请求的流程和方式。



1、Cloud Controller 将stage和run应用的请求发送给Cloud Controller Bridge(CC-Bridge)；

2、CC-Bridge 将staging和running请求转换为Tasks和Long Running Processes(LRPs)，然后通过HTTP上的API将其提交到Bulletin Board System(BBS)；

3、BBS将Tasks和LRPs提交给Auctioneer(Diego Brain的一部分)；

4、Auctioneer通过Auction将这些Tasks和LRPs分配给Cells。Diego Brain使用SSL/TLS协议和Diego Cells 进行通信；

5、只要Auctioneer将某个Task或LRP分配给Cell，in-process Executor 就会在Cell中创建一个Garden 容器。Task或LRP运行在容器中；

6、BBS跟踪desired LRPs、运行时LRP实例和in-flight Tasks。它还定期对这些信息进行分析，并纠正错误，以确保

ActualLRP

和

DesiredLRP

数量之间的一致性；

7、作为Cell的一部分，Metron Agent 将应用日志、错误和指标转发给Cloud Foundry Loggregator。

Diego 核心组件

Diego核心组件运行并监控Tasks和LRPs。核心组件主要包含以下几个：

Diego Brain

Diego Cells

Database VMs

Access VMs

Consul

Diego Brain

Diego Brain 组件将Tasks和LRPs分配给Diego Cells，并纠正

ActualLRP

与

DesiredLRP

之间的差异，以确保容错和长期的一致性。Diego Brain由Auctioneer组成。

Auctioneer

利用auction包来运行Tasks和LRPs的Diego Auctions；

通过SSL/TLS与Cell Reps进行通信；

在BBS上维护一个锁，以限制每次只能对一个Auctioneer进行auctions。

Diego Cells

Diego Cell组件负责管理和维护Tasks和LRPs。

Rep

代表Tasks和LRPs的Diego Auctions中的Cell

中介Cell和BBS之间的所有通信

确保BBS中Tasks和LRPs与Cell容器保持同步

保持BBS中Cell的存在

通过请求in-process Executor 创建容器和RunAction来运行Tasks和LRPs

Executor

在Rep中作为逻辑进程运行

实现详细的通用Executor操作

将STDOUT和STDERR传输到运行在Cell上的Metron agent

Garden

提供独立于平台的服务器和客户端来管理Garden容器

定义容器实现的Garden-runC接口

Metron Agent

将应用日志、错误和应用程序以及Diego指标转发给Loggregator Doppler组件。

Database VMs

Diego Bulletin Board System

维护Diego集群状态的实时表示，包括所有desired LRPs、运行时LRP实例和in-flight Tasks。

通过HTTP为Diego 核心组件和外部客户端提供RPC风格的API ，包括SSH Proxy，CC-Bridge和Route Emitter。

通过将所需状态（存储在数据库中）与实际状态（来自于运行实例）进行比较来确保Tasks和LRPs的一致性和容错性。

通过以下方式保持

DesiredLRP

计数和

ActualLRP

计数同步：

如果

DesiredLRP

计数超过

ActualLRP

计数，则要求Auctioneer开始auction；

如果

ActualLRP

计数超过

DesiredLRP

计数，则向托管实例的Cell的Rep发送停止消息。

监控潜在错过的消息，如有必要重新发送。

MySQL

为Diego提供一致的键值数据存储

Access VMs

File Server

blobstore 提供静态资产，可以包含通用应用生命周期二进制文件和应用特定的droplets 和build 工件。

SSH Proxy

在实例容器中运行的SSH客户端和SSH服务器之间的连接。

Consul

通过DNS解析提供动态服务注册和负载均衡

为维护分布式锁和组件存在提供一致的键值存储

Go MySQL 驱动

Diego BBS将数据存储在MySQL中。Diego使用Go MySQL驱动程序与MySQL通信。

Cloud Controller Bridge 组件

Cloud Controller Bridge（CC-Bridge）组件将应用特定的请求从Cloud Controller 转换到BBS。这些组件包括：

Stager

将Cloud Controller 的staging 请求转换为通用Tasks和LRPs

当Tasks完成时，向Cloud Controller发送响应

CC-Uploader

中介来自于Executor的上传到Cloud Controller

将来自Executor的简单HTTP POST请求转换为Cloud Controller的复杂多部分表单上传

Nsync

监听应用请求来更新

DesiredLRPs

计数和通过BBS更新

DesiredLRPs

定期对每个应用进行Cloud Controller轮询，以确保Diego保持准确的

DesiredLRPs

计数

TPS

为Cloud Controller提供有关当前运行的LRPs的响应

cf apps

和

cf app APP_NAME

请求的信息

监控

ActualLRP

崩溃活动并向Cloud Controller报告

平台特定组件

Garden 后台

Garden包含一组每个特定于平台的后台必须实现的接口。

应用生命周期二进制文件

以下三个平台特定的二进制文件部署应用并管理其生命周期：

Builder 构建(stage) CF应用。在每次staging请求时，CC-Bridge 运行Builder 作为一个T
4000
ask。Builder对应用代码执行静态分析，并在应用首次运行之前进行任何必要的预处理。

Launcher 运行CF应用。CC-Bridge将Launcher设置为应用的

DesiredLRP

的Action。Launcher使用正确的系统上下文来执行start命令，包括工作目录和环境变量。

Healthcheck 对容器中运行的CF 应用进行状态检查。CC-Bridge将Healthcheck设置为应用的

DesiredLRP

的Monitor action。

目前实现

Buildpack 应用生命周期 实现了Cloud Foundry基于buildpack的部署策略。

Docker 应用生命周期 实现了Docker部署策略。

其他组件

Route-Emitter

作为每个Diego Cell上的一个全局route-emitter或本地route-emitters

监控

DesiredLRP

和

ActualLRP

状态，当它检测到变化时，向Cloud Foundry 的router 发出路由注册和注销信息

定期将整个路由表发送到Cloud Foundry的router