(接着Part 1的工作) Step.3 Configure the new VM created by Template 当安装单节点CloudFoundry完成之后,我们就可以用vmc来测试下组件启动是否正常。测试之后,我们就可以使用IaaS的Template功能,把这个安装了完整CloudFoundry的虚拟机做成一个模板,
(接着Part 1的工作)
Step.3 Configure the new VM created by Template
当安装单节点CloudFoundry完成之后,我们就可以用vmc来测试下组件启动是否正常。测试之后,我们就可以使用IaaS的Template功能,把这个安装了完整CloudFoundry的虚拟机做成一个模板,留到做集群的时候使用。这一步,你完全可以使用自己喜爱的IaaS来做这件事情,比如CloudStack, Openstack, Amazon EC2之类的。这里我以CloudStack为例子。
1、给这个模板虚拟机的ROOT Volume做一个快照snapshot。(或者关机,再直接给这个VM做个Template)
2、然后基于snapshot创建模板
3、接下来就可以使用这个快照创建新VM了。这里的配置我使用的是2G内存 20G硬盘。
但是,这个新创建的虚拟机里的CF是直接启动不起来的。因为IP已经变了。我们需要配置一下。
这里我写了一个脚本,负责把虚拟机里关于CF配置中的IP部分改成新的虚拟机IP,并且重启关键的postgresql服务。(也跟IP相关)
echo -e "\033[32m================== Reconfiguring the CloudFoundry now ===================\n \033[0m" localip=`/sbin/ifconfig -a|grep inet|grep -v 127.0.0.1|grep -v inet6|awk '{print $2}'|tr -d "addr:"` grep 172.17.4.221 -rl /root/cloudfoundry/.deployments/devbox/config if [ $? -ne 0 ]; then echo -e "Nothing need to be done here \n" else sed -i "s/172.17.4.221/${localip}/g" `grep 172.17.4.221 -rl /root/cloudfoundry/.deployments/devbox/config` echo -e "\033[33m\nThe IP address of this CloudFoundry node has been set to ${localip} \033[0m\n" fi grep 172.17.4.221 -rl /etc/postgresql if [ $? -ne 0 ]; then echo -e "Nothing need to be done here \n" else sed -i "s/172.17.4.221/${localip}/g" `grep 172.17.4.221 -rl /etc/postgresql` echo -e "\033[33m\nThe IP address of postgresql node has been set to ${localip} \033[0m\n" fi echo -e "\033[34mRestarting PostgreSQL ...\n\033[0m" /etc/init.d/postgresql-8.4 stop /etc/init.d/postgresql-8.4 start /etc/init.d/postgresql stop /etc/init.d/postgresql start echo -e "\033[32m\nReconfiguration successed!\n\033[0m" echo -e "\033[32m\nYou can use export CLOUD_FOUNDRY_EXCLUDED_COMPONENT=\"comp1|comp2|...\" to choose services\n\033[0m"
172.17.4.221就是模板VM的IP。这个脚本非常简单,所以功能有限:
1、grep抓取本机IP信息的那句对于多个网卡(或者安装过VMPlayer之类的)的VM会有问题
2、CloudFoundry路径是写死的
所以,诸位大牛自己可以写一份更好的。
Step4. Configure and connect the VMs together
修改过IP之后,一个新的完整功能的CF节点就可以工作了。CloudFoundry设计非常简洁,模块间耦合度很低,天生就是用来搭建集群的。所以我们接下来的工作很简单:只要分别启动这些VM上所需的组件,并且用NATS把它们连起来即可!
这是我们最简单的一个的多节点部署方案:
node0: LoadBalancer(Nginx)
node1: CC, uaa, router0
node2: dea 0, mysql_node0
node3: dea 1, mysql_node1
node4: NATS, HM
node5: router1,mysql_gateway
这其实就是一个multi-router, multi-dea and multi-mysql的部署而已。
好了,把这些节点一个个克隆出来,然后做下面的简单工作:
1、login到每个VM中,比如node1
2、找到./devbox/config/cloud_controller.yml中nats://nats:nats@172.17.4.219:
3、修改该IP为node4的IP,
4、对其它的node做这项工作,然后启动该节点上需要的那几个组件即可(../vcap_dev start xxx xxx ...)
需要特殊处理的情况:
1、HM和CC需要共享数据库,所以如果你的HM是在独立的节点上,把这个IP改成你CC的IP
# This database is shared with the cloud controller. database_environment: production: database: cloud_controller host: 172.17.13.86
另外,把CC的external_url改为api.yourdomain.com。需要注意的是,CF所有组件配置文件中诸如*.vcap.me这样的url都要改,所以需要每个组件都查看一下config。
(这里的*.yourdomain.com域名最终会被绑定到LB上,后面很快有说明)
2、多个Service节点的情况,别忘了给他们编号(index)
index: 1 pid: /var/vcap/sys/run/mysql_node.pid node_id: mysql_node_1 #CloudFoundry need this index to distinguish those mysql nodes.
/etc/init.d/nats-server start
4、Multi-routers:这里我们的策略是用一个Nginx在多个Router前负责分配流量,Nginx节点是独立的,他的配置文件需要这么写:
upstream cf_routers {
server ip_of_router_0;
server ip_of_router_1;
}
server {
listen 80;
# if you do not have a domain, try to use your hosts file.
server_name *.yourdomain.com;
server_name_in_redirect off;
location / {
access_log /root/cloudfoundry/.deployments/devbox/log/nginx_access.log main;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect off;
proxy_connect_timeout 10;
proxy_send_timeout 30;
proxy_read_timeout 30;
proxy_pass http://cf_routers;
}
}
别忘了配置完之后重启一下:/etc/init.d/nginx restart
最后,在你的IaaS层的网络功能里把*.yourdomain.com绑定到这个LB上就可以了,以后target这个domain就可以使用你的集群环境。
Step 5. Other things TODO
截止到这里,你的集群搭建工作其实已经完成了。不过,还有些后续的东西可以做。
首先,这里的CC和HM是单节点的。如果要做成多节点怎么办?其实,这几个节点需要共享如下两个目录:
droplets: /var/vcap/shared/droplets
resources: /var/vcap/shared/resources
所以,我们需要做一个NFS的server,然后几个CC节点都从这个server上mount如上两个目录的文件到它们本地的存储中。这里NFS是原生的,其实你可以替换成支持FUSE的其他文件系统,CF是支持这部分的修改的。
当然,别忘了多个CC对应的是同一个external_url,即api.yourdomain.com,所以别忘了修改CC各自的配置文件。
这时,你对CF的target请求按照如下流程走:
vmc target api.yourdomain.com -> LB -> LB选择某一个Router -> Router选择某一个CloudController
其次,多个CC&HM节点之间还需要共享一个跨node的数据库(从CC&HM的配置文件可以看到这个数据库的配置),然后在上述配置文件中连接CC&HM到这个数据库的master节点上。
顺便说一句,我们的工作其实是在无意中模仿了BOSH。我们实验室在模板VM中建立并启动了一个Http Sever,负责接收Client端的任务请求。这其实也是类似于agent的工作。不过跟BOSH相比,我们的这种部署方法也只是半自动的。只不过,我们实验室用的IaaS不止CloudStack,所以做很多套BOSH CPI目前来看还不太需要。大家可以参考CLoudFoundry官方提供的资料来学习BOSH。