Diego 架构

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

本文包含以下几个部分：

---

架构图

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 作为一个Task。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