注:这篇文章是不是指导你建立一个直接在生产环境下使用CloudFoundry集群。但如果你尝试在自己的IaaS(哪种都行,相信我)搭建出一个CF集群来研究下,这里就有一个快速有效的指导方法了。
下文会假设你已经有了CloudFoundry和PaaS的基本知识,体验过MicroCloudFoundry,甚至已经建立了自己的单节点CF实例。
如果没有,你需要自己先研究CF几天,看看官网guide,然后再决定是否需要建立一个PaaS群集。
我们知道,几乎所有种类的IaaS都支持快速备份和还原的功能,比如快照(snapshot),或建立模板(template)。用户能够方便的从一个虚拟机创建另一个新的虚拟机。这样的话:我们应该可以只基于一个单节点CloudFoundry的“克隆”来建立一个群集的。这,也就是本文的基本思路。
相比这种在每个虚拟机安装部分CF组件然后挨个启动的方法http://support.cloudfoundry.com/entries/20407923-single-multi-node-vcap-deployment-using-chef, 我们的工作要麻利很多。但是问题出来了:
任何装过一个完整的单节点CloudFoundry(尤其是在防火墙内)的人都知道,这项工作其实是非常不容易的。我们的实际工作远比ReadMe里的那条shell指令要复杂得多。我和Alan一起经历过了五月份Chef工具的大崩盘,以及后来CloudFoundry各种依赖的很多变故,导致我们不得不多次修改chef的文件,fix了好多bug。
顺便提一下,github上8月的安装脚本也有点问题:rabbitmq-server-with-plugins-generic-unix-2.4.1.tar.gz这个包下载不下来。我们曾手动修改成旧脚本的两个包来安装依然不行。没来得及提Issue,不过应该很快会被人修正的。
关于大量外部依赖的问题,CloudFoundry现在的安装方法是把依赖全都转移到了CF blob 上面,就不用写死下载依赖包的URL了,但是依赖包的名字还是hard code。如果大家对Chef的原理感兴趣,我们在论坛里放了一个专讲Chef以及CF安装入门的帖子:
http://topic.csdn.net/u/20120903/23/d0d7017e-8de3-4931-839f-6c9820f8960c.html?76371
好了,言归正传。我们现在最希望的是,首先使用dev_setup安装一个单独的CloudFoundry虚拟机,然后把它做成一个模板(template)。接下来,只要使用这个模板,我们就可以克隆出N个CloudFoundry节点,然后简单配置一下把他们连起来,一个CF集群就可以用啦。更重要的是,这个模板可以作为一个稳定的版本保存起来,以后的安装直接克隆来,而不必再去经历那些惊心动魄的单节点安装过程。(我们Lab里面目前就有一个不同版本的CloudFoundry模板池,需要做研究的时候,直接拿来就可以用,非常方便)
任何装过一个完整的单节点CloudFoundry(尤其是在防火墙内)的人都知道,这项工作其实是非常不容易的。我们的实际工作远比ReadMe里的那条shell指令要复杂得多。我和Alan一起经历过了五月份Chef工具的大崩盘,以及后来CloudFoundry各种依赖的很多变故,导致我们不得不多次修改chef的文件,fix了好多bug。
顺便提一下,github上8月的安装脚本也有点问题:rabbitmq-server-with-plugins-generic-unix-2.4.1.tar.gz这个包下载不下来。我们曾手动修改成旧脚本的两个包来安装依然不行。没来得及提Issue,不过应该很快会被人修正的。
关于大量外部依赖的问题,CloudFoundry现在的安装方法是把依赖全都转移到了CF blob 上面,就不用写死下载依赖包的URL了,但是依赖包的名字还是hard code。如果大家对Chef的原理感兴趣,我们在论坛里放了一个专讲Chef以及CF安装入门的帖子:
http://topic.csdn.net/u/20120903/23/d0d7017e-8de3-4931-839f-6c9820f8960c.html?76371
好了,言归正传。我们现在最希望的是,首先使用dev_setup安装一个单独的CloudFoundry虚拟机,然后把它做成一个模板(template)。接下来,只要使用这个模板,我们就可以克隆出N个CloudFoundry节点,然后简单配置一下把他们连起来,一个CF集群就可以用啦。更重要的是,这个模板可以作为一个稳定的版本保存起来,以后的安装直接克隆来,而不必再去经历那些惊心动魄的单节点安装过程。(我们Lab里面目前就有一个不同版本的CloudFoundry模板池,需要做研究的时候,直接拿来就可以用,非常方便)
好了,现在开始吧!
Step 1. 我们首先需要安装好一个单节点CloudFoundry!
如果我们幸运的话,使用dev_setup的方法安装一个用来当模板用的单节点CloudFoundry是个很easy的过程。下面这篇文档的Option2就足够了:
http://support.cloudfoundry.com/entries/20407923-single-multi-node-vcap-deployment-using-chef
但是,正如前面所说的,在各种意料之外的情况出现前,我们不妨在下面几点上做一些准备工作。(尤其是你在公司防火墙后面做实验)
0、确保你使用的是基于某种IaaS的一台 Ubuntu10.04 64bit 虚拟机,越干净越好。然后在指定位置克隆好需要的源码包,检查里面有没有空文件夹。安装路径、网络代理等是可以用参数自定义的,千万要多读下面的readme:
https://github.com/cloudfoundry/vcap/tree/master/dev_setup#readme
1、很多公司禁止使用git:协议进行clone。而这样的协议偏偏需要在CF很多gem包安装(GemFIle)的时候中用到。
你可以试下git clone git://github.com/cloudfoundry/vcap-common.git 如果timeout了,就是被禁掉了。修改方法非常简单:
找到所有类似于 ../vcap/cloud_controller/Gemfile 这样的文件,把里面的git://替换成https://
(我是直接用sed指令替换的)。其他的位置还包括../vcap/health_manager/Gemfile 和 ../vcap/services/../Gemfile
2、我们默认是安装所有组件的,所以直接运行../vcap/dev_setup/bin/vcap_dev_setup就可以了。接下来,盯着屏幕,你很可能会注意到下面的提示:
意思是key不能够请求到,这是gpg请求key的端口被禁掉的缘故。解决方法也很简单,添加参数通过80端口请求即可,直接执行:
3、不防多去看看github上各个包的commit history,就会发现几乎每天都有bug被修正。所以,我们其实可以选择更稳定的commit来做我们的安装实验。如果你pull或者reset了vcap库的版本,别忘了更新它的子包(比如uaa什么的)。cd到每个repo下面看看commit log,就能确保该源码的时间了。我们做实验时候的commit log如下:
好了,然后放心的去安装吧。
下面列举下常见的Troble Shooting:
1、重启虚拟机之后,CloudController无法启动,log里显示:can not connect to the sever... 这多半是由于postgresql没起来导致的。执行 /etc/init.d/postgresql-8.4 restart 一般就会解决问题。
2、uaa 的log有ERROR,一般情况下是安装的时候就有问题了。最简单的方法是把uaa升级到最新的代码版本,然后重新执行下安装过程就好了。
3、如果在安装过程中出现timeout问题,通过读track,我们不难定位到是哪个组件的那个依赖(比如tomcat的jar包)下载不下来。然后,你可以参考前面讲chef的那篇文章,试着改掉
不过较新的CF已经用blob来缓存这些依赖了,就不能这么改了。这时,我们可以先手动下好对应版本的依赖,下面的步骤供你参考:
http://support.cloudfoundry.com/entries/20407923-single-multi-node-vcap-deployment-using-chef
但是,正如前面所说的,在各种意料之外的情况出现前,我们不妨在下面几点上做一些准备工作。(尤其是你在公司防火墙后面做实验)
0、确保你使用的是基于某种IaaS的一台 Ubuntu10.04 64bit 虚拟机,越干净越好。然后在指定位置克隆好需要的源码包,检查里面有没有空文件夹。安装路径、网络代理等是可以用参数自定义的,千万要多读下面的readme:
https://github.com/cloudfoundry/vcap/tree/master/dev_setup#readme
1、很多公司禁止使用git:协议进行clone。而这样的协议偏偏需要在CF很多gem包安装(GemFIle)的时候中用到。
你可以试下git clone git://github.com/cloudfoundry/vcap-common.git 如果timeout了,就是被禁掉了。修改方法非常简单:
找到所有类似于 ../vcap/cloud_controller/Gemfile 这样的文件,把里面的git://替换成https://
(我是直接用sed指令替换的)。其他的位置还包括../vcap/health_manager/Gemfile 和 ../vcap/services/../Gemfile
2、我们默认是安装所有组件的,所以直接运行../vcap/dev_setup/bin/vcap_dev_setup就可以了。接下来,盯着屏幕,你很可能会注意到下面的提示:
- gpg: requesting key 83EF826A from hkp server apt.opscode.com
- gpg: no valid OpenPGP data found.
- gpg: Total number processed: 0
意思是key不能够请求到,这是gpg请求key的端口被禁掉的缘故。解决方法也很简单,添加参数通过80端口请求即可,直接执行:
apt-key adv --recv-keys --keyserver hkp://apt.opscode.com/
packages@opscode.com.gpg.key:80 83EF826A
你就会看到正确的提示:(
你就会看到正确的提示:(
参数83EF826A就是你的public key,要跟最前面保持一致
)- gpg: requesting key 83EF826A from hkp server apt.opscode.com
- gpg: key 83EF826A: public key imported
- gpg: Total number processed: 1
- gpg: imported: 1 (RSA: 1)
然后再执行安装脚本即可。
3、不防多去看看github上各个包的commit history,就会发现几乎每天都有bug被修正。所以,我们其实可以选择更稳定的commit来做我们的安装实验。如果你pull或者reset了vcap库的版本,别忘了更新它的子包(比如uaa什么的)。cd到每个repo下面看看commit log,就能确保该源码的时间了。我们做实验时候的commit log如下:
vcap
commit decf636f565e0fb063548cfad616e94d5757c25b
Author: Harshawardhan Gadgil <hgadgil@rbcon.com>
Date: Fri Jun 22 11:56:35 2012 -0700
uaa
Author: Harshawardhan Gadgil <hgadgil@rbcon.com>
Date: Fri Jun 22 11:56:35 2012 -0700
uaa
commit 56063b744884ea98dfa89587844e56f554356541
Author: Dave Syer <dsyer@vmware.com>
Date: Fri May 18 19:14:24 2012 +0100
services
Author: Dave Syer <dsyer@vmware.com>
Date: Fri May 18 19:14:24 2012 +0100
services
commit e18b0bb360c3d86d9c210ce2e97c7230d639eec2
Author: Harshawardhan Gadgil <hgadgil@rbcon.com>
Date: Fri Jun 8 15:38:08 2012 -0700
Author: Harshawardhan Gadgil <hgadgil@rbcon.com>
Date: Fri Jun 8 15:38:08 2012 -0700
好了,然后放心的去安装吧。
下面列举下常见的Troble Shooting:
1、重启虚拟机之后,CloudController无法启动,log里显示:can not connect to the sever... 这多半是由于postgresql没起来导致的。执行 /etc/init.d/postgresql-8.4 restart 一般就会解决问题。
2、uaa 的log有ERROR,一般情况下是安装的时候就有问题了。最简单的方法是把uaa升级到最新的代码版本,然后重新执行下安装过程就好了。
3、如果在安装过程中出现timeout问题,通过读track,我们不难定位到是哪个组件的那个依赖(比如tomcat的jar包)下载不下来。然后,你可以参考前面讲chef的那篇文章,试着改掉
下载
这些依赖的URL。不过较新的CF已经用blob来缓存这些依赖了,就不能这么改了。这时,我们可以先手动下好对应版本的依赖,下面的步骤供你参考:
cd到../dev_setup/cookbooks.下;
其中../attributes/default.rb定义了各种依赖的版本,路径等;
如果出错的是service安装过程,你需要查看../recipes/default.rb.定义的安装代码,把cf_remote_filetarball_path这一段直接注释掉;
把下好的依赖放到 /var/cache/dev_setup下,重新run安装脚本就好了。
如果你碰到的问题实在解决不了,那就只好把源码reset到旧一点的时候吧。。。。
好了,经过上面的努力,安装一台完整的单节点CF应该不是问题了。别忘了一定要多读上面的ReadMe,里面有很多你需要事先了解的信息。比如,你需要设置某个变量为true之后再执行安装脚本,才能保证你的CF有service lifecycle management功能哦。
我们会在Part2继续讲如何制作虚拟机模板,并以此为基础来快速构建CF集群。