基于您的 IaaS 运行您自己的 CloudFoundry。第2部分

（接着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:4222

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.

3、在NATS节点上需要单独启动NATS服务

/etc/init.d/nats-server   start

4、Multi-routers：这里我们的策略是用一个Nginx在多个Router前负责分配流量，Nginx节点是独立的，他的配置文件需要这么写：

 上游 cf_routers {
    服务器ip_of_router_0；
    服务器 ip_of_router_1;
  }

  服务器{
    听       80；
    # 如果您没有域名，请尝试使用您的主机文件。
    服务器名称 *.yourdomain.com; 
    server_name_in_redirect 关闭；
    地点 / {
      access_log   /root/cloudfoundry/.deployments/devbox/log/nginx_access.log main;
      proxy_buffering             关闭；
      proxy_set_header            主机 $host;
      proxy_set_header            X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_redirect              关闭；
      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上就可以了，以后目标这个域就可以使用你的集群环境了。

第 5 步. 其他待办事项

初始化到这里，你的集群架构工作其实已经了。不过，还有一些后续的东西可以做。

首先，这里的CC和HM是单节点的。如果要做多节点怎么办？其实，这几个节点需要共享如下两个目录：

水滴：/var/vcap/shared/droplets

资源：/var/vcap/shared/resources

所以，我们需要做一个NFS的服务器，然后几个CC节点都从这个服务器上挂载如上两个目录的文件到它们本地的存储中。这里NFS是本质上的，其实你可以替换成支持FUSE的其他文件系统，CF是支持这部分的修改的。

当然，别忘记多个CC是对应同一个external_url，即api.yourdomain.com，所以别忘记CC各自的配置文件。

现在，你对CF的目标请求按照如下流程走：

vmc 目标 api.yourdomain.com -> LB-> LB选择某个路由器-> Router选择某个CloudController

其次，多个CC&HM节点之间还需要共享一个跨节点的数据库（从CC&HM的配置文件可以看到这个数据库的配置），在上述配置文件中连接CC&HM到这个数据库的主节点上。

顺便说一句，我们的工作其实是在无意中修改了BOSH。实验室我们在模板VM中建立并启动了一个Http Sever，负责接收Client端的任务请求。这其实也是类似于agent的工作。不过这种跟BOSH相比，我们的部署方法也只是半自动的。只不过，我们实验室用的IaaS不止CloudStack，所以做很多套BOSH CPI目前看来还不太需要大家。可以参考CLoudFoundry官方提供的资料来学习BOSH。