(接著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/configif [ $? -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"figrep 172.17.4.221 -rl /etc/postgresqlif [ $? -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"fiecho -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 startecho -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: 1pid: /var/vcap/sys/run/mysql_node.pidnode_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節點是獨立的,他的設定檔需要這麼寫:
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。