基於nginx實現上游伺服器動態自動上下線——不需reload
網上關於nginx的介紹有很多,這裡講述的是上游服務(如下圖的Java1服務)在沒有“閘道器”的情況下,如何通過nginx做到動態上下線。
傳統的做法是,手動修改nginx的upstream檔案,將Java1的配置註釋或者標記為down,然後reload nginx生效。當然可以做成指令碼自動化修改,然而對於一個繁忙的nginx來說,貿然reload輕則響應緩慢,重則雪崩丟失流量。
那麼怎樣做到nginx動態載入upstream配置呢?網上大體有3種方案:
- 通過Lua指令碼結合nginx,也就是Openresty方案;
- 給nginx的每個server額外新增一個埠,每次通過呼叫這個埠修改upstream;
- 給nginx新增資料庫,upstream資料放在資料庫中,通過修改資料庫資料實現修改upstream配置。
對於一個正在執行的生產環境nginx來說,第3個方案無疑是成本最低的。下面讓我們具體看一下:
技術方案:nginx1.16+nginx_upstream_check_module+nginx-upsync-module+consul
說明:
- 這裡的consul就是上面所說的資料庫,它不只是key/value型別的庫,還有一個簡潔的web管理頁面,可以很方便的管理鍵值對資料;
- nginx_upstream_check_module是阿里開源的針對上游服務的健康檢測模組;
- nginx-upsync-module是微博開源的可以與consul/etcd結合的模組。
下面分別通過consul叢集部署、nginx改造、建立upstream資料3個方面逐一討論實施細節。
一、部署consul叢集
官網:https://www.consul.io/
假設用下面3臺機器組成一個Consul叢集:
192.168.21.11 192.168.21.12 192.168.21.13
192.168.21.14 # 這個IP為代理IP,用於代理上面3臺機器
1. 準備工作
從官網下載consul壓縮包,分別上傳到上面3臺伺服器,這裡的consul版本為1.8.4:
unzip consul_1.8.4_linux_amd64.zip mv consul /usr/local/bin/ [root@nginx-11 tmp]# consul Usage: consul [--version] [--help] <command> [<args>] Available commands are: acl Interact with Consul's ACLs agent Runs a Consul agent catalog Interact with the catalog ....
mkdir -p /data/consul/{data,log} mkdir /etc/consul
2.生成consul配置檔案
下面以192.168.21.11的配置檔案為例:
[root@nginx-11 tmp]# cat /etc/consul/config.json { "datacenter":"dc1", "primary_datacenter":"dc1", "bootstrap_expect":3, "start_join":[ "192.168.21.11", "192.168.21.12", "192.168.21.13" ], "retry_join":[ "192.168.21.11", "192.168.21.12", "192.168.21.13" ], "advertise_addr": "192.168.21.11", "bind_addr": "192.168.21.11", "client_addr": "0.0.0.0", "server":true, "connect":{ "enabled":true }, "node_name":"192.168.21.11", "ui": true, "data_dir":"/data/consul/data", "enable_script_checks":false, "enable_local_script_checks":true, "log_file":"/data/consul/log/", "log_level":"info", "log_rotate_bytes":100000000, "log_rotate_duration":"24h", "encrypt":"a2zC4ItisuFdpl7IqwoYz3GqwA5W1w2CxjNmyVbuhZ4=", "acl":{ "enabled":true, "default_policy":"deny", "enable_token_persistence":true, "enable_key_list_policy":true, "tokens":{ "master":"6c95012f-d086-4ef3-b6b9-35b60f529bd0" } } }
說明:
- 另外2臺伺服器的配置檔案,分別將上面的advertise_addr、bind_addr、node_name對應值修改為對應IP,其他配置不需要改變;
- 引數 "bootstrap_expect":3 意為希望部署一個3個節點的叢集,請根據實際情況配置;
- encrypt與tokens對應的值,3臺機器應保持一致,encrypt值可以通過consul keygen命令生成,token值可以通過uuidgen命令生成,也可以都通過這2個工具生成;
- 相關引數的理解可以參考:https://juejin.im/post/6844903860717240334
3. 建立consul叢集
分別在3臺機器上啟動consul即可:consul agent -config-file=/etc/consul/config.json &通過瀏覽器訪問http://192.168.21.14:8500(或者任意一個IP:Port)即可訪問consul後臺介面,輸入上面master的tokens值可以看到裡面具體內容。
注意:
- 上面配置檔案中的acl配置,“enable_key_list_policy”配置一定要加上,且值要配成“true”,否則匿名使用者可能訪問不到consul配置內容。
4. 為非管理員建立consul訪問許可權
1)建立訪問策略 通過瀏覽器訪問consul,點選ACL -> Access Controls -> Policies -> 右上角Create 建立一個只讀“upstreams”kv策略,名稱為:readonlykv,Rules內容為:key_prefix "upstreams/" { policy = "list" }
建立一個可以寫“upstreams”kv策略,名稱為:writekv,Rules內容為:
key_prefix "upstreams/" { policy = "write" }建立好的2條策略截圖如下: 2)建立訪問token 在匿名使用者token中加入允許訪問只讀“upstreams”kv策略,用於允許nginx模組匿名讀取consul配置: 點選00000002,在Policies中選擇readonlykv即可。 建立可以寫“upstreams”kv的token,用於指令碼帶此token修改consul配置: 通過瀏覽器訪問consul,點選ACL -> Access Controls -> Tokens -> 右上角Create,在Policies中選擇writekv。 修改/建立好的2條token截圖如下: 到此Consul叢集部署完成。 二、nginx改造 1. 升級nginx 下載nginx相關模組:
- nginx-upsync-module:https://github.com/weibocom/nginx-upsync-module
- nginx_upstream_check_module:https://github.com/xiaokai-wang/nginx_upstream_check_module
注意:
- 下載nginx_upstream_check_module模組時請一定到xiaokai-wang的GitHub上下載,千萬不要到阿里的官方GitHub上下載,否則版本不相容編譯不過去;
- 在對Nginx升級前請先做好資料備份。
1)對nginx_upstream_check_module打patch
cd nginx-1.16.0 patch -p1 < /usr/local/src/nginx-1.16/nginx_upstream_check_module-master/check_1.12.1+.patch
說明:我把下載的2個nginx模組原始碼包放在了/usr/local/src/nginx-1.16/路徑下。
2)編譯nginx
./configure --prefix=/usr/local/nginx --add-module=/usr/local/src/nginx-1.16/nginx_upstream_check_module-master --add-module=/usr/local/src/nginx-1.16/nginx-upsync-module-master ...
說明:
- 我把nginx安裝在/usr/local/下面;
- 命令後面的省略號是你要安裝的模組,請根據實際情況新增,通過nginx -V可以看到當前安裝了哪些模組,然後加上去即可。
3)安裝nginx
make
# 如果是平滑升級,該步不要執行
make install
4)升級nginx
#再次備份nginx二進位制檔案 mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx16.old #用新nginx二進位制檔案替換老的 cp objs/nginx /usr/local/nginx/sbin/ #檢視已安裝的nginx模組 /usr/local/nginx/sbin/nginx -V
提醒:經過測試發現nginx1.6通過reload或者傳送kill -USR2命令,老的nginx程序並不會退出,需要重啟nginx才可以生效,不知道是不是Bug。
/usr/local/nginx/sbin/nginx -s stop #如果老的nginx程序仍未推出,使用kill -9強制殺掉
ps -ef |grep nginx #開啟nginx /usr/local/nginx/sbin/nginx # 說明:傳送kill -USR2命令 kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
到此,nginx升級完成。
2. 配置nginx
1)首先配置nginx展示頁面,用於快速瞭解nginx執行狀態
cat nginx.conf server { listen 80; server_name localhost; # 在server 80中展示upstream,相當於全域性配置,其他配置檔案不需要配置
# 瀏覽器訪問http://nginx-ip:80/upstream_show能檢視到nginx upstream的具體配置資訊 location = /upstream_show { upstream_show; } # 在server 80中展示check詳情,相當於全域性配置,其他配置檔案不需要配置
# 瀏覽器訪問http://nginx-ip:80/status能檢視到上游服務的健康狀態,報紅即為有問題,白色即為正常 location /status { check_status; } # 在server 80中展示nginx自帶的狀態,相當於全域性配置,其他配置檔案不需要配置
# nginx原生自帶功能 location /NginxStatus { stub_status on; access_log off; allow 192.168.0.0/16; deny all; } } # 引入具體server配置,每個server需要配置nginx-upsync-module模組的配置 include /usr/local/nginx/conf/vhosts/*.conf;
2)server配置
- http方式檢測
upstream rs1 { server 127.0.0.1:11111; upsync 192.168.21.14:8500/v1/kv/upstreams/rs1/ upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off; upsync_dump_path /usr/local/nginx/conf/servers/servers_rs1.conf; check interval=1000 rise=2 fall=2 timeout=3000 type=http default_down=false; check_http_send "HEAD /health.htm HTTP/1.0\r\n\r\n"; check_http_expect_alive http_2xx http_3xx; } server { listen 80; ...
- tcp方式檢測(tcp為預設檢測方式)
upstream rs2 { server 127.0.0.1:11111; upsync 192.168.21.14:8500/v1/kv/upstreams/rs2/ upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off; upsync_dump_path /usr/local/nginx/conf/servers/servers_rs2.conf; check interval=1000 rise=2 fall=2 timeout=3000 type=tcp default_down=false; } server { listen 80; ...
說明:
- 推薦使用http方式檢測,http比tcp方式更準確,該檢測方式為nginx_upstream_check_module提供,功能強大,引數簡單解釋:每隔1秒進行1次健康檢查,每次超時時間為3秒,連續2次健康檢查成功則認為這個上游服務健康,將會被上線或一直保持線上;連續2次健康檢查失敗則認為這個上游服務不健康,將會被剔除下線。“/health.htm”是上游服務的健康檢查介面,通過它判斷服務是否健康。具體引數解釋可參考:http://tengine.taobao.org/document_cn/http_upstream_check_cn.html
- 引數簡單解釋:nginx-upsync-module模組會每隔0.5秒向consul資料庫檢查一次配置,每次超時時間為6分鐘。具體引數解釋可參考:https://github.com/weibocom/nginx-upsync-module
- nginx會在/usr/local/nginx/conf目錄下面建立servers子目錄,該子目錄下會自動建立相關server配置檔案。
到此,nginx配置修改完成。
三、建立upstream資料(consul鍵值對)
可以通過web頁面或者指令碼建立upstream資料,方法如下:
1. web頁面操作
如果需要建立目錄,在要建立的欄位後面加上"/"即可,如:upstreams/ 。
"Key/Value"中必須先建立"upstreams"目錄(後面有字母s),然後再建立對應的server名稱,截圖如下:
2. 命令列操作
使用命令列時不需要先建立"upstreams/"目錄,命令會自動建立目錄以及server資料。
下面以上游服務Java1(IP為192.168.20.100,埠號為8080,upstream分組名稱為rs1)為例:
新增記錄
curl -X PUT http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
上述命令執行後,會形成一條nginx的upstream預設配置資訊,即:
server 192.168.20.100:8080 weight=1 max_fails=2 fail_timeout=10s;
可以通過下面命令自定義權重等值:
curl -X PUT -d "{\"weight\":100, \"max_fails\":2, \"fail_timeout\":10}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
# 或者
curl -X PUT -d '{"weight":100, "max_fails":2, "fail_timeout":10}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
刪除記錄
curl -X DELETE http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
更新權重
curl -X PUT -d "{\"weight\":100, \"max_fails\":2, \"fail_timeout\":10}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token # 或者 curl -X PUT -d '{"weight":100, "max_fails":2, "fail_timeout":10}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
下線服務
curl -X PUT -d "{\"weight\":2, \"max_fails\":2, \"fail_timeout\":10, \"down\":1}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token # 或者 curl -X PUT -d '{"weight":2, "max_fails":2, "fail_timeout":10, "down":1}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
檢視upstream rs1下面有哪些上游伺服器
curl http://192.168.21.14:8500/v1/kv/upstreams/rs1?recurse
推薦使用命令列操作,建議將命令列組裝成指令碼實現DevOps
四、一點感悟
在改造該動態發現方案期間,遇到了很多問題,最棘手的一個問題是測試環境種nginx一直報錯,upstream資料始終無法完整下載,經過各種排查還是沒有發現問題,中間我懷疑過是consul的問題,換成了etcd還是同樣的報錯,最後通過抓包跟蹤,發現是Linux核心引數配置不當,導致佇列溢位tcp三次握手失敗,影響nginx與consul通訊。
很多方案理論上是沒有問題的,甚至說有人已經成功運用了,但是實際上親自實施的話還是會遇到各種各樣的問題,有些甚至是致命的,這時候就需要耐心的解決。希望大家在看到這篇文章的時候也去動手試試,如果遇到了問題請靜下心來耐心排查。
還有一個是,很多人說運維是不產生價值的,我認為這麼說是不對的,運維需要體現的價值有很多,SRE就是其中的一種。