Cloudfoundry的部署工具BOSH介绍

长平狐 发布于 2013/11/25 18:27
阅读 6K+
收藏 1

   我们知道在使用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、S3、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模板:

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

原文链接:http://blog.csdn.net/alan90121/article/details/8184849
加载中
0
潇雪53
潇雪53
LZ  CPI的参考文档没有呢。。。可以把连接补上不。。感谢!
返回顶部
顶部