Cloudfoundry的部署工具BOSH介绍

咱们知道在使用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的官方文档，其中加入了我对相关概念的认识。其中的不足之处，还望指正。

    主要介绍了以下的几部份内容：

 

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

   主要参考资料：

 

 

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

 

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

 

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

    

4. 若是使用了除上述三种平台以外的IaaS，就须要涉及CPI的开发。有关CPI的知识，能够看我写的：

 

一  BOSH架构及各组件介绍

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

 

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

• CLI

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

$ 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、S三、simple blobstore server。

 

• db

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

 

 

• IaaS interface

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

 

 

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的自动部署铺平道路。