配置和使用Pivotal Cloud Foundry中的HAPorxy詳解
Pivotal使用HAProxy作為其訪問入口，當然是允許使用其他負載均衡軟件或硬件進行替換的。不過，基于怕麻煩和強迫癥，個人還是用了HAProxy到最終的生產環境。為了滿足特定的應用需求和可靠性需求，對負載均衡這一層做了一定的配置，本文通過四個案例共享這些經驗。
為不同應用分配不同的HAProxy
Pivotal Cloud Foundry的配置界面中，HAProxy允許配置多個IP(同時需要在資源尺寸頁配置相同個數的HAProxy虛擬機)，這樣一個CF就擁有了多個入口。可以通過管理員的人腦，對運行在這套CF上不同應用按照負載和安全的考量，分配到不同的HAProxy上。具體實例如下：
假定為PCF配置了兩個HAProxy(10.20.30.40和10.20.30.41)，在DNS上，默認將*.pcf.mydomain.com子域分配給了這個PCF，指向了10.20.30.40。此時，如果應用app1域名為app1.pcf.mydomain.com，則該應用的訪問將通過 10.20.30.40進入PCF。
這時如果這個應用app1需要使用域名app1.mydomain.com，并且負載很大和/或可靠性要求高，則可以在DNS上將app1.mydomain.com指向10.20.30.41，然后cf create-domain org1 mydomain.com創建域名(如果這個域名整個CF都要用，那就用cf create-shared-domain)，然后用cf map-route app1 mydomain.com -n app1為這個應用增加一個新的域名。
此時，通過app1.mydomain.com和app1.pcf.mydomain.com都可以訪問這一應用，但是前者通過10.20.30.41進入PCF，后者通過10.20.30.40進入PCF。
為同一HAProxy上的不同域名配置SSL證書并自動訪問https
PCF可以生成個自簽名的域名給分配給自己的子域，但實際生產中使用證書肯定不會是自簽名的，而且多數也不會是整個子域的域名，而是單獨的域名，還是針對前文的實例，增加如下需求：另一個應用app2與app1屬于同一系統，需要使用域名 app2.mydomain.com，app1.mydomain.com和app2.mydomain.com均有各自的SSL證書，同時二者均要求禁止http訪問。
此時可以將DNS上app2.mydomain.com指向10.20.30.41，然后登陸10.20.30.41這個HAProxy的OS(用戶名為vcap，密碼可以在Pivotal Operation Manager的界面上找到)，進行HAProxy配置。
對于自動跳轉https的需求，可以通過修改/var/vcap/jobs/haproxy/config/haproxy.config里的http-in完成。
- frontend http-in
- mode http
- bind :80
- option httplog
- option forwardfor
- reqadd X-Forwarded-Proto:\ http
- acl is_app1_mydomain_com hdr(host) -i app1.mydomain.com
- redirect location https://app1.mydomain.com:443 if is_app1_mydomain_co
- acl is_app2_mydomain_com hdr(host) -i app2.mydomain.com
- redirect location https://app2.mydomain.com:443 if is_app2_mydomain_com
- default_backend http-routers
對于多個證書的需求，可以通過修改/var/vcap/jobs/haproxy/config/haproxy.config里的https-in完成。將需要的證書上傳到這臺HAProxy，并在配置文件中添加即可，證書文件支持的格式請參見/var/vcap/jobs/haproxy/config/cert.pem。
- frontend https-in
- mode http
- bind :443 ssl crt /var/vcap/jobs/haproxy/config/cert.pem crt /var/vcap/jobs/haproxy/config/app1.mydomain.com.pem crt /var/vcap/jobs/haproxy/config/app2.mydomain.com.pem
- option httplog
- option forwardfor
- option http-server-close
- reqadd X-Forwarded-Proto:\ https
- default_backend http-routers
#p#
多層負載均衡滿足安全需求和業務需求
企業的安全及防火墻策略對PCF來說是個災難，當然現在的版本已經有Availability Zone來覆蓋這一需求，但是下面這種需求還是難以實現：PCF部署在生產網絡，但是需要被互聯網訪問，安全策略僅允許DMZ網絡對外提供服務，因此需要做個脫褲子放屁的事兒是PCF可以從internet訪問。還以上例為基礎，app1和app2均需要互聯網訪問（將定DMZ網絡中存在可用的負載均衡設備50.60.70.100和50.60.70.101）：
首先獲取一個DMZ網段的IP，如50.60.70.80，開通負載均衡設備50.60.70.100和50.60.70.101訪問PCF的對外IP的10.20.30.41的80和443端口，將10.20.30.41的80和443端口在DMZ負載均衡設備上負載均衡為50.60.70.80的80和443，將50.60.70.80的80和443端口NAT成公網的80和443，并返回需要的域名（比如app1.bjsdns.mydomain.com、app2.bjsdns.mydomain.com等），在DNS中把app1.bjsdns.mydomain.com、app2.bjsdns.mydomain.com做別名成app1.mydomain.com和app2.mydomain.com，就大功告成了。
讓CF與普通Tomcat應用服務一塊工作
對于企業內部的私有PaaS來講，PCF中最讓人擔心的技術就是PCF的運行環境架構（包含負載均衡和自動彈性）。下面的方案可以屏蔽使用互聯網技術帶來的新技術不確定性風險，使私有PaaS為實時業務系統提供服務成為可能。這個方案通過將應用服務負載均衡到IaaS資源，確保在PCF的整個運行環境框架出現問題時，可做到用戶無感知的故障恢復。具體細節如下：
1、在PCF中（比如分配10個應用實例，假定應用名稱為app1）和使用IaaS虛擬機單獨部署的多個Tomcat節點（比如2個）中部署相同應用代碼。
2、在PaaS中使用如下命令創建域（比如mydomain.com），創建應用域名（app1.mydomain.com），綁定應用域名（app1.mydomain.com綁定到應用app1）：
- cf create-domain org1 mydomain.com
- cf map-route app1 mydomain.com -n app1
3、在負載均衡設備中配置virtual service（比如50.60.70.80），其對應的real service為PaaS環境的入口IP（比如10.20.30.41）和其他使用IaaS虛擬機單獨部署的多個Tomcat節點，單獨Tomcat節點的權重為1，PaaS入口IP的權重為其為此應用分配的應用實例個數（10）。
4、在DNS中將應用域名（app1.mydomain.com）配置為負載均衡設備上的virtual service IP（50.60.70.80）。
5、當用戶訪問app1.mydomain.com，DNS將解析到負載均衡設備，負載均衡設備會根據策略和權重將請求負載均衡到單獨的Tomcat或PaaS入口IP上，如果到了PaaS入口IP上，PaaS將根據客戶端訪問的域名在此進行解析，并根據策略將請求route到應用app1的10個應用實例上。
博文出處：http://blog.csdn.net/cloudguru/article/details/45054165
