Cloud Foundry：从开发到运维

转载自:http://cnblog.cloudfoundry.com/2013/04/02/534/

[译注]本文作者刘晓光   VMware 上海研发中心资深系统工程师。负责Cloud Foundry发布管理和cloudfoundry.com运维支持。关注Linux、虚拟化、Infrastructure as a Service等技术领域。

代码进入cf-release的过程

Cloud Foundry 是一个复杂的分布式系统。这样的系统部署和升级维护也比较繁琐。所以Cloud Foundry 开发出了BOSH用来管理这类复杂系统的部署和升级。BOSH将被管理的软件系统称为release。 Cloud Foundry 就是以BOSH release的形式发布的，它的地址是https://github.com/cloudfoundry/cf-release ，这就是我们所说的cf-release。在撰写本文时，最新Cloud Foundry release 版本为v127。

Cloud Foundry 由数十个组件构成，比如Router， Cloud Controller，DEA等。基本上每个组件都在自己独立的git repository中进行开发和版本管理。而cf-release作为一个独立的repository，和其它组件的repository是什么关系 呢？实际上cf-release通过git中的submodule引用了其它的repository。进入cf-release的src目录 （https://github.com/cloudfoundry/cf-release/tree/master/src），你就会看到哪些组件的 repository进入了cf-release，以及其对应的commit位置。Cloud Foundry 的每次发布，其实就是各个组件在自己的repository中向cf-release输出（bump）新的commit点，以使自己的新版本代码进入 cf-release中，再由BOSH工具对新的代码树进行打包，生产新的release manifest 文件的过程。

cf- release这个repository上的任何变更也是要经过Gerrit来审阅的。负责这个repository的审阅的工作是由SRE（Site Reliability Engineer）团队来承担的。SRE就是Cloud Foundry中的DevOps，负责线上环境cloudfroundry.com的部署、监控、故障解决，性能管理等工作。SRE 审阅时不会重复看那些已经在组件级repository上审阅和测试过的细节问题，而是从运维的角度，重点看这些组件的行为变更是否对线上环境造成负面影响，是否遵从了运维最佳实践等问题。

cf-release部署到cloudfoundry.com的全过程

细心的cloudfoundry.com的用户可能已经知道，cloudfoundry.com网站通常每周维护两次，时间分别是周三和周五的上午。 每次维护我们都会把最新版的cf-release推送到cloudfoundry.com网站。下面就给大家详细介绍一下整个部署过程。

每个新版本在正式部署前，都要经历Dev环境测试，Staging环境测试，然后才能部署到生产环境。

1. Dev环境

在正式部署的两个工作日前，cf-release repository的更新会暂时截止。SRE开始在Dev环境中对当前最新的cf-release进行测试。Dev环境是一个小型化的Cloud Foundry开发环境，运行在vSphere上，大概有40到50个虚拟机构成。 保证每个组件都独立运行在一个虚拟机上。整个环境也是由BOSH进行管理。限于篇幅，这里不对BOSH的用法做详细解释。大家如果有兴趣可以参考 Cloud Foundry网站上的文章。

首先要创建一个新的cf-release。 用git pull同步一下cf-release repository最新的内容到本地。然后仔细检查一下git log，确保从上一个版本到现在的新的变更都在项目的发布计划中，并且明确这些变更带来的影响，以及是否要修改BOSH deployment manifest 文件。

cd cf-release

git checkout master

./update

git log

这些都清楚了的话，就将master的内容合并的built分支中，执行bosh create release命令创建一个新的release。

git checkout built

./update

git merge master

git push origin built

bosh create release

假设当前在cloudfoundry.com上运行的版本是v127（下同）。那么刚刚创建出的release版本号会是v127.1- dev。

首先把 Dev环境初始化成v127。对于目前的Cloud Foundry版本来说，要用到50个虚拟机。其中一些关键组件的部署数量和功能见下表：

表1 Dev环境主要组件

用bosh upload命令上传这个新的release到DEV环境，修改deployment manifest 文件以采用新的release版本，当有组件的属性发生变化时还要在manifest文件中的properties部分做好相应的修改。然后用bosh deploy命令部署新的版本。BOSH会自动对比当前使用的release （v127）和即将部署的release（v127.1-dev）的差异，更新那些有变化的组件：

bosh upload release

bosh edit deployment

bosh deploy

部署完成后，执行前面提到的End-to-End测试工具Yeti，对当前的DEV环境做全面的测试。如果测试到任何问题，SRE会同相关组件的开发团队一起排查，找到原因并修复问题。如果发现是软件的bug，还要等修复bug后从头进行前面的整个过程。

2. Staging环境

Staging环境作为生产环境的版本验证和问题复现平台，在硬件型号、规模以及网络环境等各个方面都非常接近生产环境。在正式部署的一天前，SRE会在该环境中对cf-release进行测试。

如果前一天测试的release （v127.1-dev）在Dev环境中没有发现问题，这时候就要创建正式版（v128）了。执行bosh create release –final，就会生产正式版的release，版本号v128。releases目录下会创建出appcloud-128.yml文件，各个新的组件也会被打包并上传到http://blob.cfblob.com 上。 执行git push将新的yml文件上传,并在当前位置加一个代表版本号的tag：

git checkout built

bosh create release –final

git add releases/appcloud-128.yml

git commit -a

git push origin built

git tag v128

git push –tags

这时所有人都可以从GitHub的repository中的built分支看见这个新的release了。经过其他人（通常是另外一个SRE）确认该release可用后，就可以把它合并到master了。

git checkout master

git pull –rebase

git submodule update –recursive

git merge built –no-ff

git push origin master

这个时候，新的cf-release就可以被公众下载并在自己的环境中部署了。后面的Staging环境和生产环境的部署，用的都是这个 GitHub中的版本。

Staging和生产环境的部署都要由至少两名SRE一起完成。这样做一方面是可以分担工作量，但更主要的是避免人为错误的发生。在开始Staging环境的部署前，SRE会用一个脚本程序通过NATS向所有DEA发一个消息，获得并保存当前所有在DEA上运行的app列表。这样做的目的是为了与部署后的情况进行对比。如果app的运行状态发生明显变化，很可能是新版本部署中发生了问题。部署的过程与DEV环境类似，相同的部分这里就不再累述。

整个部署过程需要的时间依更新的组件多少以及这些组件的实例数量而不同。比如某个版本只更新了stager的话，整个部署十多分钟就可以结束。但如果新版本中有DEA的更新，则至少要几个小时了。说到这里，大家可能比较关心这么长的升级过程是否会带来长时间的系统停机。其实是不会的，BOSH采用的是滚动的升级方式，即每次只升级一个组件。每个组件有多个实例时每次只升级一部分。再加上组件设计时都考虑到了冗余性和平滑升级的问题。所以在整个部署过程中，系统基本上都是可用的。对于极少数单实例组件，其负责的功能也只会出现几分钟的不可用状态。

部署完成后，SRE会再导出当前在运行的app列表并与之前的列表对比。 如果没发现大的不一致，接下来会用压力测试工具对Staging环境进行15分钟的压力测试，并记录一些性能数据。这些性能数据有助于让我们了解各个版本对在性能上的差异。

同样的，如果整个过程遇到任何问题，SRE和相关开发人员又要一起努力了。由于第二天就要进行生产环境的部署，这时如果发现了问题，时间就会非常紧张。好在这种情况并不多，而且我们的开发团队也是非常给力，有问题通常能很快找到原因并修复。

3. 生产环境

由于前面做了这么多准备工作，生产环境的部署也会水到渠成。一般来说绝大多数问题都会在前面两个环境里被测出过了，所以到了生产环境部署的时候就会顺利很多了。部署过程大同小异，就不重复讲了。但其实Staging环境和生产环境还是不大一样，主要差异就在用户的app上。生产环境上跑的是用户真实的app，而 Staging环境上也有大量的app，却只是内部写的一些测试程序。为了尊重用户的权益，我们内部严格禁止将用户的app程序代码、数据甚至是log从生产环境导出到非生产环境。这就使得有些问题在Staging环境还是测不出来，非要到实际上线的时候才暴露出来。另外有些问题是要在程序运行了相对长的时间后才会暴露出来，所以部署完成也不能松懈。而下一轮新版本的部署工作也很快就开始了。

希望这些内容能对你了解Cloud Foundry社区和cloudfoundry.com有所帮助。希望能有更多的开发者关注Cloud Foundry，并参与到Cloud Foundry开发中来。