（接著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.

/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。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com