寫給運維的Nginx秘籍
要說Web服務器、代理服務器和調度服務器層面，目前使用最大的要數Nginx。對于一個運維工程師日常不可避免要和Nginx打交道。為了更好地使用和管理Nginx，本文就給大家介紹幾個蟲蟲日常常用的秘籍。
限制訪問
當Nginx開放到公網上以后，就會有大量的非正常訪問，這不光耗費服務器資源，而且有可能是某種信息探索，然后攻擊的前奏，有對針對性的限制這些訪問很有必要。在Nginx中可以通過一些內置的變量來進行限制訪問。
限制客戶端代理
在nginx可以使用$http_user_agent變量匹配客戶類型，然后對對匹配的訪問return 4.3來限制器訪問。
在Nginx配置的server部分，直接用if語句實現：
- if ($http_user_agent ~ (Go-http-client/1.1|curl)) {
- return 403;
- }
但是如果要匹配的客戶端代理比較多時候，直接這樣拼寫就比較繁瑣也不好管理。這種情況下給大家一個技巧就是用Map函數。
Map函數在Nginx ngx_http_map_module中實現的。利用Map函數可以創建一個變量，并將其與其他變量(比如內置的$http_user_agent)關聯起來，可以同時關聯多個值到多個不同值并儲存到一個變量。其基本語法為：
- map $var1 $var2 { ... }
其作用于為http模塊，這樣可以在開頭映射后，然后在具體的server部分進行封禁。
對應本例子中：
- map $http_user_agent:$arg_key $ban {
- ~*spider* 1;
- ~Go-http-client/1.1 1;
- ~curl;
- default 0;
- }
這樣在后續if封禁語句中就可以使用新建的$ban變量進行封禁了。
- if ($ban = 1) {
- return 403;
- }
IP限制
有時候對一些惡意來源的IP封禁則更為直接簡單有效。Nginx進行IP封禁的方法也很簡單，直接用deny語句，他是Nginx內置模塊ngx_http_access_module，支持allow和deny兩個語句，基本語法為：
- deny address | CIDR | unix: | all;
可以在http或者server塊直接使用：
- deny 135.125.180.235;
如果要封閉的IP很多，可以直接在nginx配置文件中include一個封禁文件專管理封禁的IP。
- include banip.conf;
在banip.conf文件中用：
- deny 135.125.180.235;
- deny 135.125.180.1/24;
- …
這樣語句即可，當然也可以用allow和deny all搞成實時上的白名單限制模式：
- allow 127.0.0.1;
- allow 192.168.0.0/18;
- allow 110.242.68.66;
- …
- deny all;
這樣除了本機、18位的內網段和110.242.68.66外其他IP都會禁止訪問。
速率限制
除了直接限制訪問外很多時候，不能直接限制其訪問，但是需要針對特定請求限制訪問的速率(頻率)。在Nginx速率限制通過limit_req_zone和limit_req兩個指令實現。
limit_req_zone用來定義請求限制區域。區域包含有關如何分類的配置請求速率限制和實際限制。
limit_req將區域應用于特定http上下文對于全局限制，server每個虛擬服務器，以及location對于虛擬中的特定位置服務器。
為了說明這一點，假設要實現速率限制配置：
- 全局速率限制100 RPS
- 由User-Agent來限制特定來源(搜索蜘蛛)請求為1RPM。
- 通過API令牌將來自某些可以客戶端的請求限制為1RPS。
要對請求進行分類，需要提供索引到 limit_req_zone。鍵通常是一些變量，要么由nginx預定義，要么由通過map定義。
要通過IP設置全局速率限制，需要以IP作為鍵。
- limit_req_zone $binary_remote_addr zone=global:100m rate=100r/s;
現在，通過以下方式限制搜索蜘蛛的User-Agent，此處我們使用map函數：
- map $http_user_agent $crawler {
- ~*.*( Baiduspider|bot|spider|slurp).* $http_user_agent;
- default "";
- }
- limit_req_zone $crawler zone=crawlers:1M rate=1r/m;
上面配置中通過map設置$crawler變量作為limit_req_zone的鍵。limit_req_zone對于不同的客戶端必須有不同的值才能正確計算請求計數。如果請求不是來自crawler，使用一個空字符串來禁用速率限制。
對API令牌限制請求，使用map創建一個多個鍵，對應其速率限制區域：
- map $http_authorization $eclients {
- ~.*6d96270004515a0486bb7f76196a72b40c55a47f.* 6d96270004515a0486bb7f76196a72b40c55a47f;
- ~.*956f7fd1ae68fecb2b32186415a49c316f769d75.* 956f7fd1ae68fecb2b32186415a49c316f769d75;
- default "";
- }
- limit_req_zone $eclients zone=eclients:1M rate=1r/s;
下面我們來看看 AuthorizationAPI 令牌的標頭，如 Authorization: Bearer 1234567890. 如果我們匹配一些已知的標記，我們使用該值$eclients為了變量，然后其作為鍵引入到limit_req_zone。
- server {
- listen 80;
- server_name test.show;
- limit_req zone=crawlers;
- limit_req zone=global;
- # ...
- }
- server {
- listen 80;
- server_name api.test.show;
- # ...
- location /heavy/method {
- # ...
- limit_req zone=eclients;
- limit_req zone=global;
- # ...
- }
- # ...
- }
請注意，配置中必須添加globa區域作為后備，非匹配的情況。
最后總結一下速率限制的流程：
- 創建保存速率限制的變量的鍵。不同鍵值對應于不同的速率限制區域。
- 空鍵表示禁用速率限制。
- 使用帶限速鍵的變量來配置限速區域配置。
- 在需要的地方應用速率限制區域limit_req。
- 速率限制將有助于保持系統穩定。
除了速率限制，Nginx也有一個請求頻率限制方法limit_conn_zone和對應的 limit_conn用來限制請求的頻次。其使用方法，具體和limit_req_zone以及limit_req的方法也類似，下面是一個例子：
- http {
- limit_conn_zone $binary_remote_addr zone=perip:10m;
- limit_conn_zone $server_name zone=perserver:10m;
- server {
- location / {
- limit_conn perip 10;
- limit_conn perserver 1000;
- }
- }
- }
緩存
Nginx 最大的用途是作為代理緩存服務器。假設請求代理到某個后端應用服務器，后端服務器返回請求數據的成本很高。則可以通過緩存它來減少后端的負載。
- http {
- # ...
- proxy_cache_path /var/cache/nginx/test keys_zone=test:500m max_size=1000m inactive=1d;
- # ...
- server {
- # ...
- location /test {
- proxy_pass test.show_backend;
- proxy_cache test;
- proxy_cache_key "$scheme$proxy_host$request_uri $http_customer_token";
- proxy_cache_valid 200 302 1d;
- proxy_cache_valid 404 400 10m;
- }
- }
- }
在此示例中，通過添加 $http_customer_token保存值的變Customer-Token HTTP 標題。然后，與速率限制一樣，定義緩存區域應用于服務器、位置或全局使用 proxy_cache指示。另外還要配置緩存失效。 默認情況下，僅對200、301 和 302 HTTP狀態碼響應緩存，超過10分鐘更新一次緩存內容。另外對于后端服務器Nginx會遵守其指示性的Http頭，例如Cache-Control標頭。如果標頭包含類似no-store,must-revalidate，nginx則不會對其緩存響應。可以在Nginx配置
- proxy_ignore_headers "Cache-Control";
來覆蓋該行為。
因此，要配置 nginx 緩存失效，請執行以下操作：
- 設置max_size在 proxy_cache_path限制磁盤的占用。如果nginx需要緩存超過max_size，將從緩存中移除最近最少使用的值
- 設置inactive參數輸入proxy_cache_path配置TTL整個緩存區。可以用 proxy_cache_valid指示。
- 最后，添加proxy_cache_valid將指示TTL的指令在給定位置或服務器中緩存項目，這將為緩存設置TTL條目。
結構化日志
從Nginx訪問日志是個大寶藏，我們可以通過其挖掘當前Web服務的在線狀態，使用狀態和用戶信息。但是其默認訪問日志有點太簡陋，需要對其進行配置增加必須的字段，調整其位置，使其更加格式化。Nginx日志的配置需要用 log_format語句。一個典型的配置如下：
- log_format main '$remote_addr - $remote_user [$time_iso8601] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent - $ssl_client_s_dn $ssl_client_serial $ssl_client_verify" "$http_x_forwarded_for"';
上述配置中，除了常見的各種字段外，另外增加了$ssl_client_s_dn $ssl_client_serial和$ssl_client_verify，用于在https雙向認證時候客戶的端用CA簽發dn信息，用戶證書序列號用來記錄合法認證的用戶信息。
另外為了和ELK或者其他日志系統的集成使用json格式的結構化日志很有必要，可以使用graylog將文本日志轉化，也可以直接在Nginx配置生成：
- http {
- # ...
- log_format json escape=json '{'
- '"server_name": "test.show",'
- '"ts":"$time_iso8601",'
- '"remote_addr":"$remote_addr","host":"$host","origin":"$http_origin","url":"$request_uri",'
- '"request_id":"$request_id","upstream":"$upstream_addr",'
- '"response_size":"$body_bytes_sent","upstream_response_time":"$upstream_response_time","request_time":"$request_time",'
- '"status":"$status"'
- '"$https_info": "$ssl_client_s_dn $ssl_client_serial $ssl_client_verify"'
- '}';
- # ...
- }
escape=json選項將替換不可打印的字符，如換行符和轉義值，例如\n. 引號和反斜杠也將被轉義。
如果是K8S容器云節點的服務可以，直接用filter用來指定：
- filter {
- json {
- source => "log"
- remove_field => ["log"]
- }
- }
灰度發布(A/B測試)
運維部門為了保證服務升級，往往會采用灰度發布的方式，逐步將用戶切換到新的版本中。
在Nginx 可以用split_client模塊實現提供逐步升級的功能。他有點類似像map函數，但不是通過某種模式設置變量，而是創建來自源變量分布的變量。下面一個例子：
- http {
- upstream current {
- server backend1;
- serverbackend2;
- }
- upstream new {
- server dev.show max_fails=0;
- }
- split_clients $arg_key $new_api {
- 5% 1;
- * 0;
- }
- map $new_api:$cookie_app_switch $destination {
- ~.*:1 new;
- ~0:.* current;
- ~1:.* new;
- }
- server {
- # ...
- location /api {
- proxy_pass $destination/;
- }
- }
- }
在此示例中，app_switch和split_clients cookie 值結合生成調度鍵。如果 cookie設置為設置$destination調度到上游的new為1。 否則，從 split_clients調度。這是在生產一種用于測試新系統的功能標志：擁有cookie集用戶都將始終請求到new。
鍵的分布是一致的。如果已將API鍵用于split_clients那么具有相同API鍵的用戶將始終被放入同一組。
使用此配置，可以將流量分流到新系統，從小百分比開始并逐漸增加。當然修改百分比參數后，不需要reload才能生效。
結論
本文我們介紹一些日常運維中Nginx的管理秘籍，當然密不密不是絕對只是個人看法，希望以此拋磚引玉，如果你有任何建議和建議補充，可以回復說明。
