使用ansible快速部署一個主流的Web架構

拓撲：

 

 

拓撲說明：

1. 兩臺服務器配置Keepalived+Nginx作雙主模型的Load Balance，主機名爲lb1和lb2

2. 兩臺服務器配置lamp，用於處理動態資源請求，主機名爲lamp1和lamp2

3. 兩臺服務器配置varnish做爲靜態資源緩存服務器，主機名爲varnish1和varnish2

4. 兩臺服務器配置Nginx用於處理靜態資源請求

5. 額外須要一臺服務器安裝ansible，使用ansible批量管理全部服務器

 

 

關鍵技術點：

1. Keepalived配置了郵件報警腳本，當節點的狀態發生改變時，會發送報警郵件（腳本中的郵箱需修改）

 

2. Load Balance部分使用Nginx進行動靜分離

 

3. 調度動態資源流量時，爲了綁定session會話，使用的是ip_hash算法，若是使用sticky方式調度，須要調整緩存規則，不然訪問靜態資源時因爲擁有cookie信息，資源沒法被緩

 

4. 調度靜態資源流量時，爲了提升緩存命中率，使用的是ip_hash算法。能夠考慮使用consistent_hash算法（一致性哈希）。但通過測試，Nginx使用consistent_hash算法時，沒法實現對後端服務器的健康狀態監測以及故障轉移。所以，若是須要使用consistent_hash算法，建議使用Tengine

 

5. 關於靜態資源緩存部分，使用的是多層級緩存。前端LB上，Nginx配置了proxy_cache，用於存放少部分熱點數據，後端Varnish上存放常常被訪問的數據。因爲測試用，前端LB上緩存的時間很短

 

6. 全部web服務天天會分割一次access_log

 

7. 在響應報文中添加自定義Hearder，可顯示相應資源是從哪臺服務器上獲取的，便於之後排錯

 

 

還能夠進一步改進的地方：

1. 實驗配置中的緩存策略能夠進一步修改和優化

 

2. varnish的日誌服務還未配置

 

3. 可使用Tengine替代Nginx，使用consistent_hash算法提升緩存命中率的同時，分散緩存的存儲位置

 

4.    關於ansible的安全隱患:

因爲使用密鑰方式進行通訊，所以一旦ansible server被非法登陸，其餘被管理節點也存在被篡改的風險。所以，可考慮專門建立一個ansible用戶用於和其餘被管理節點使用密鑰方式進行ssh通訊，其餘用戶若是須要使用ansible來管理服務器，須要sudo至ansible用戶來執行ansible命令，這樣在日誌中會有相應的記錄

 

 

實驗環境：

 

全部服務器ssh端口號: 2222

 

ansibleserver與被管理節點的通訊方式:  使用密鑰方式進行ssh通訊，remote_user爲root

 

全部服務器使用hosts來解析主機名,所以全部服務器的hosts須要保持一致

 

 

ansible_server   Centos7.2

192.168.1.200

 

lb1  Centos 7.2

192.168.1.202

 

llb2  Centos 7.2

192.168.1.203

 

varnish1  Centos 7.2

192.168.1.208

 

varnish2  Centos 7.2

192.168.1.209

 

lamp1 Centos 6.5

192.168.1.101

 

lamp2 Centos 6.5

192.168.1.102

 

static_server1 Centos 7.2

192.168.1.205

 

static_server2 Centos 7.2

192.168.1.206

 

 

最終效果：

 

 

 

附件爲ansible所需的全部配置文件，包含了實驗中所需的全部角色，一共是兩個壓縮分卷。感興趣的能夠下載測試