|
先吐槽一下haproxy的官方文檔,，這個文檔真是個神奇的東西，所有需要的東西都在里邊,，但是如果你想象力不夠豐富,，就是不知道怎么使用。以下文檔,，是我簡單翻譯的aloha
blog中的文檔而來,，加了一點自己的理解。
原文地址見參考文檔部分,。 我有一個做售后服務(wù)的朋友,，遇到過一家客戶，他們只有一個公網(wǎng)IP,，但是要承擔(dān)幾十個不同域名的網(wǎng)站,。當(dāng)時他們使用的是F5
BIGIP,是通過irule取不同主機頭，分配到后端不同的pool中去,。
haproxy面對同樣的問題,，也采取了類似的方法，通過ACL來匹配請求中的主機頭,，然后分配給不同的backend,。例子如下:
frontend ft_allapps
這個方法對于少量主機頭當(dāng)然OK，但是要把情況極端化一點,，例如上百個主機頭的情況呢,？
那估計配置文件會讓人發(fā)瘋的。
但在haproxy
1.5版以后,，haproxy引入了converter這個功能,，其中有一種map類型的converter。
這個map converter的功能就是將input和output數(shù)據(jù)1:1做預(yù)先對應(yīng),。
實際使用中,，只要調(diào)用map
converter,輸入map中預(yù)先定義好的input值，就會得到對應(yīng)的output值,。
map實際存在于一個包含格式的文本文件中,，這個文件在haproxy啟動時被加載進來。該文件有兩列,，左邊是input串,，右邊是output串
。
那么對應(yīng)前述例子,，我們可以預(yù)先定義一個map文件,，假設(shè)文件為/etc/hapee-1.5/domain2backend.map,，其內(nèi)容如下:
#domainname
app1.domain1.com bk_app1
app1.domain2.com bk_app1
app2.domain1.com bk_app2
app2.domain2.com bk_app2
第一列是主機頭,，第二列是對應(yīng)分配的backend名稱。
然后在haproxy的配置文件中，做如下配置:
frontend ft_allapps
haproxy會按照如下步驟操作:
1.req.hdr(host) ==> 從HTTP請求中取得主機頭
2.lower ==> 轉(zhuǎn)換所有字符為小寫
3.map(/etc/hapee-1.5/domain2backend.map,bk_default)
==>在這個map文件中查找小寫的主機頭,，如果找到對應(yīng)項,，則返回對應(yīng)的backend名稱，如果沒找到返回bk_default這個backend名稱,。
4.將請求流量發(fā)送給map返回的backend服務(wù)器,。
這樣即使面對成百上千的主機頭，也只是需要在map文件中操作,，然后reload即可,。
即不需要寫正則表達式，也不需要在haproxy配置文件中寫入大量的ACL判斷,。
另外,，map數(shù)據(jù)是以"樹"的數(shù)據(jù)結(jié)構(gòu)存儲，所以其查找速度比起查ACL來說要快多了,。
簡單就是美?。?/div>
2016.01.22增補
如果是https網(wǎng)站,，則需要從sni中獲取hostname
use_backend
%[ssl_fc_sni,lower,map(/etc/hapee-1.5/domain2backend.map,bk_default)]
參考文檔:
http://blog./2015/01/26/web-application-name-to-backend-mapping-in-haproxy/
|
|
|
來自： waitingnothing > 《待分類》
