Cloudfoundry的部署工具BOSH介绍

（转自http://blog.csdn.net/alan90121/article/details/8184849）

我们知道在使用dev_setup部署cloudfoundry过程中存在很多的重复工作，分机运行脚本不仅效率低下，且cloudfoundry版本不能控制。这对于大规模的生产环境来讲，部署运维的工作量非常庞大，在这种情况下极大的限制了cloudfoundry推向产品化的发展。为了解决这个问题，Vmware自己研发了BOSH作为自动化部署cloudfoundry，它能够给cloudfoundry的部署带来极大的便利。
官方文档给BOSH的定义是：BOSH是一个针对大规模分布式系统的部署和生命周期管理的开源工具，其基础是“a tool of release
engineering"。由其定义可以看出，虽然BOSH的诞生出自cloudfoundry的部署难题，但BOSH能做的不只是部署cloudfoundry这一个产品。别的分布式系统只要提供给bosh一个release，BOSH一样可以做到系统的部署和生命周期的管理。所以，这里不要陷入一个误区。

这篇文档适合刚开始接触BOSH，并对cloudfoundry相对了解的开发人员。本文的基础是BOSH的官方文档，其中加入了我对相关概念的认识。其中的不足之处，还望指正。

主要介绍了如下的几部分内容：

BOSH架构及各组件介绍
BOSH关键名词概念
BOSH运行机制

主要参考资料：

官方BOSH文档https://github.com/cloudfoundry/oss-docs/blob/master/bosh/documentation/documentation.md（信息量很大）
Dr.Nic的BOSH神级入门教程汇总https://github.com/drnic/bosh-getting-started

看完本文如果你想着手开始部署BOSH的话：

如果你使用的IaaS是vsphere，官方提供了vsphere的BOSH部署教程。http://cloudfoundry-doc.csdn.net/deploy/vSphere.html
如果是使用的IaaS是AWS，可以参考：http://blog.cloudfoundry.org/2012/09/06/deploying-to-aws-using-cloud-foundry-bosh/
如果是在openstack上尝试搭建，可以看我写的：《在openstack上使用Bosh部署cloudfoundry集群（上）》

如果使用了除上述三种平台之外的IaaS，就需要涉及CPI的开发。有关CPI的知识，可以看我写的：

一
BOSH架构及各组件介绍

我们先来看BOSH的总架构图，有一个直观的概念：



对Cloudfoundry相对熟悉的读者可以发现，BOSH在整体架构上跟CF有着不少相似之处。图中的Message Bus组件没有明确指出这里使用的是哪一种消息中间件，实际上BOSH仍使用了NATS做消息部分的处理。主要的组件有如下几个，我们逐一分析。

CLI

CLI类似于CF的vmc，是用户客户端的一个命令终端，它提供了BOSH的命令界面。命令的格式是：

[plain] view
plaincopy

$ bosh [--verbose] [--config|-c<FILE>] [--cache-dir <DIR>]

[--force] [--no-color] [--skip-director-checks] [--quiet]

[--non-interactive]

有关CLI的完整命令介绍可以参见BOSH官方文档的BOSHCommand Line Interface部分。

Director

Director组件是BOSH的核心，其作用是负责虚拟机的创建、部署和其他软件和服务生命期的管理。如果和CF类比的话，Director扮演的角色有点类似于CF的cloud_controller。

Agent

Agent运行在已经创建出的VM上，每个BOSH创建的虚拟机都一个Agent。它是BOSH在VM上的代理，通过从Director获取配置信息，使虚拟机分配不同的角色。比如，在部署cloudfoundry集群的时候，我需要添加一个DEA节点。这时BOSH先会创建并启动一个VM，其中也运行着BOSH的Agent。然后Director就会发送一个命令到VM的Agent，明确告知这个VM需要安装有关DEA的组件和软件包，以及详细的配置信息。Agent就会根据这些信息创建一个配置好的DEA节点，这样VM就分配好了角色。

Health Monitor

HealthMonitor从Agent接收状态和生命周期信息，并且可以发送警告报警。这里的Health Monitor是一个简单的事件机制，当一个组件更新时，不会产生报警。

Blobstore

Blobstore是用来存储用户上传的Release。用户通过CLI的上传Release指令，通过Director将Release存储到Blobstore中。当你对上传的Release进行部署时，BOSH将在Blobstore中排列这些编译包和存储结果。当BOSH部署一个job到VM上时，Agent将从Blobstore中拿出指定的BOSH
Jobs和相关的资源包。
BOSH也使用Blobstore作为大型有效载荷的中间存储，比如日志文件，Agent处超过消息总线最大尺寸的输出。
现在有三种Blobstore支持BOSH：Atmos、S3、simple blobstore server。

db

BOSH用来存储有关VM的元数据的数据库。

IaaS interface

这里就是BOSH CPI（Cloud Provide Interface）的部分。CPI封装了一套IaaS的API，它使得BOSH能够通过对CPI的调用从而实际调用IaaS的API。CPI包括了下面的方法：

[plain] view
plaincopy

create_stemcell / delete_stemcell

create_vm / delete_vm / reboot_vm

configure_networks

create_disk / delete_disk / attach_disk / detach_disk

有关的详细分析，请见文章开头的参考文档4

二 BOSH关键名词概念

stemcell

一个集成了Agent的VM模板，BOSH创建的VM就是以这个模板来进行创建的。Director通过CPI创建VM之前需要上传stemcell，也就是说stemcell处于部署过程的开始阶段，它初始化了BOSH的运行环境。stemcell在创建VM时会传递网络和存储的配置，以及NATS和Blobstore的位置

Releases

BOSH是一个release engineering的工具，其面向的对象自然是Releases。BOSH 的一个Release包含了源码，配置信息和启动脚本等内容。

目录	内容
jobs	有关job（作业）的定义
packages	有关资源包的定义
config	release的配置文件
releases	最终的release
src	源代码
blobs	大的源代码包

jobs：jobs是packages的具体实现，其中包括了运行资源包的二进制文件的配置和启动脚本，官方的翻译是“作业”。job和VM的关系是一对多的关系，也就是说每一个VM上只能对应一个job。拿Cloudfoundry的release举例来说，总共有包括Cloud_controller，DEA，health_manager，router，NATS等jobs。每当一个VM启动后，Agent就根据Director分配的job，让VM担当不同的任务。BOSH使用了monit监视job的进程。
pakages：packages是一个源代码和编译安装脚本的集合。
src：包含了package里的源代码。
blobs：最终的release会放置于releases文件下面，但是可能会出现文件目录下出现过多的肿胀二进制文件。所以，这里会把这些较大的文件放在blobs里，然后在上传到blobstore时一起上传过去。
这里可能会有一个理解误区。看到Release这个单词，可能会有一种感觉是BOSH是将整个release上传到blobstore然后进行部署。实际上并不是这样。BOSH的一个release也是一个工程，对于这个工程，还需要使用命令bosh create release之后BOSH才能使用。所以，BOSH的Release也需要生成最终的一个release，然后在上传到Blobstore中。
此外，在一个BOSH的release里，通常都使用git进行源码管理。

三 BOSH运行机制

这张图很好的说明了BOSH的运行机制。右边是cloudfoundry的release，它包含了cloudfoundry的jobs。上面在介绍组件时已经讲到一些，在这里我们在详细总结一下关键的几个运行步骤。

VM的镜像Stemcell

在BOSH部署的整个周期处在最上环的是stemcell的上传。首先开发人员通过命令bosh download stemcell将官方提供的stemcell下载到本地，然后BOSH通过调用CPI的create_stemcell方法，将本地的stemcell上传至IaaS的镜像存储。这时，BOSH已经具有了一个VM的模板，其中有最关键的bosh
agent。

部署过程中的package编译

Director首先会查看是否存在编译的版本，如果不存在，Director就会启动一个VM作为编译机。从blobstore中取出后编译，然后将编译好的package放在blobstore里。在这里，package的编译依靠的是一个叫做packaging的脚本，它跑在编译机上，会从agent中得到两个变量：BOSH_INSTALL_TARGET和BOSH_COMPILE_TARGET。第一个变量说明在何处安装package生成的文件，会被设置成/var/vcap/data/packages/<package
name>/<package version>；第二个变量说明哪个文件包含了源代码。

新增节点的创建

BOSH会根据主配置文件bosh_manifest.yml得到新增节点的job信息以及相关网络和资源池信息，并根据这些信息配置部署新增节点。

我们还是拿上面说到的DEA的例子。这时BOSH先会调用CPI，根据网络资源池等信息创建并启动一个VM，其中也运行着BOSH的Agent。然后Director就会根据job的信息发送一个命令到VM的Agent，明确告知这个VM需要安装有关DEA的组件和软件包，以及详细的配置信息。Agent就会根据这些信息创建一个配置好的DEA节点，这样VM就完整的部署完成。

所以我们看出，bosh_manifest.yml是整个BOSH的关键配置信息，详细的对分布式系统（cloudfoundry）的部署进行了安排计划。目前由于庞大系统的部署信息量较大，manifest的配置是一个比较麻烦的工作，不过在将来相信这一点一定会进行改善。下面是基于vsphere部署bosh的一个manifest模板：
https://github.com/cloudfoundry/oss-docs/blob/master/bosh/tutorial/examples/bosh_manifest.yml

从整体上看，BOSH的运行主要是Director和blobstore的交互，director和agent的交互。其中设计的精妙之处在于stemcell内嵌agent的做法，从而做到VM执行不同的部署任务。所以，学习BOSH应在尝试搭建的基础上，尽量搞懂bosh agent和director交互的原理，才能理解BOSH在实现release engineering的设计思路。从而才能进一步为自己研发CPI，实现cloudfoundry的自动部署铺平道路。