Diego介绍

2017-03-16
4 min read

Diego是Cloud Foundry(以下简称cf)的运行时架构。它用来代替来版本的DEA(Droplet Execution Agent)和HM9000(Health Manager)组件。Digo是“the DEA rewritten in Go”的缩写。Diego是可以独立部署的。

Why is Diego

Diego对Cloud Controller(关于cc可以看这里)是不可知论的。原来的DEA拿到Buildpacks生成对应容器,Diego依然使用Buildpacks生成容器。但是Diego不需要随packs预安装的Cells(Diego内部管理和维护Tasks and LRPs的组件),直接提供一种更加通用的运行时环境。Cells也不需要被限制在一个特定执行的应用程序包。总之,这种不可知的设计可以运行客户端的交互和运行时的实现多种多样和任意组合。

What is Diego

下图是Diego在cf架构中的位置。可以看到,Diego在cf的整体架构中承担着执行任务的重任。在这种分层的分布式架构中,其他cf的组件(左边)是以Diego Client的方式与Diego打交道。

diego-overview

Diego将前端的请求的任务转化成两种任务类型:

  • Task: 一个task是一次性执行并在有限时间内执行完的任务。这类任务也许是一个请求部署安装环境的脚本。
  • LRP: 一个LRP(Long Running Process)是连续执行的任务,并且可能会有多个实例执行。cf中的DesiredLRP和ActualLRP都与它有关。DesiredLRP记录每个LRP预设的实例数量, ActualLRP记录的是每个LRP在实际运行的实例数量。

因为每个组件微服务都作用于指定的Diego组件,每个服务都可以以自己的一套抽象描述自己的服务。

在Diego最高层次的抽象中,Task或者LRP的工作以组合行为(composable actions)形式被描述,这种行为定义被应用在API上。比如“RunAction”、“ParallelsAction”等。这些抽象描述的是普遍通用的行为而不是描述具体的操作过程。而我们在前面知道,cf中的流程都被描述成Tasks或者LRPs。为了能使得这两个抽象组件(cf、diego)交互顺利,必须在两者之间搭桥。而这个桥就是the Cloud Controller Bridge (CC-Bridge)。cc-bridge作为diego的客户端,能够将cf的请求转化成tasks或者LRPs。

Cloud Controller Bridge Components

cc-bridge有如下组件:

  • Stager:将请求转化成Tasks和LRPs,tasks执行完成响应给CC
  • CC-Uploader:维护Executor至CC的上传,从Executor转换HTTP POST请求成复杂的multipart-form 上传
  • Nsync:监听关系DesiredLRPs的请求并通过BBS更新DesiredLRPs
  • TPS:提供当前运行的LRPs信息,监控当前ActualLRP的华东

Diego core components

而Diego的组件有:Brain、Cell、Garden、Database VMs、Access VMs、SSH Proxy、Consul。

Brain是Diego的核心,分发Tasks和LRPs给Diego Cells,修正ActualLRP与DesiredLRP,拥有Auctioneer组件进行任务的分配和监控。

Cell管理和维护Tasks和LRPs。其内部Rep组件是Cell在Diego Auctions代表,作用是协调cell和bbs通信,确保tasks,LRPs之间的同步,维护BBS中的cell的代表,运行tasks,LRPs;通过向Executor请求创建container和RunAction recipes。

Executor是运行Cell逻辑上的进程,实现API的具体操作,向Metron agent以流式发送STDOUT、STDERR数据。

Garden是提供平台独立的server和clients,管理容器;定义Garden-runC(Docker的实现)接口,也可以是Linux、Windows的容器实现接口。

Metron Agent是监控日志和指标的一部分组件,发送日志数据给Loggregator。Loggregator汇聚并给用户(这是cf的内容)。

Database VMs,被称为Diego Bulletin Board System(简称BBS)。它记录Diego集群状态并维护,提供RPC-style API,确保task、LRP一致与容错。其内部还有MySQL,提供key-value数据存储。Consul组件动态服务注册,维护分布式锁和组件的presence状态。

其他一些组件还包括Access VMs、File Server、SSH Proxy,其功能都如其名称一致。这里就不解释了。

总之,Diego是升级版的DEA+HM9000,将功能模块进一步划分和隔离以保障系统的可用性。在应用中,Diego既可以与cf一起部署,也可以独立部署。

comments powered by Disqus