NGINX for Windows轉移NGINX for Linux注意事項

NGINX for Windows轉移NGINX for Linux注意事項

最近終於把早期的 NGINX for Windows 轉移至 NGINX for Linux，在轉移過程有不少平台差異造成設定上需微調。以下整理 NGINX from Windows to Linux 一些組態的差異性，以及轉移後進行的一些調整。

資料夾結構

NGINX for Windows 的資料夾放那裡都行，最後需要透過 nssm 工具包起來，才有辦法在 Windows 背景執行。

NGINX for Linux 我安裝的是 nginx.org 的版本，需要注意以下幾個目錄：

  • /etc/nginx/nginx.conf 核心組態檔，針對 NGINX 本身進行設定。
  • /etc/nginx/conf.d/default.conf Reverse Proxy 主要設定檔。
  • /usr/share/nginx/html 靜態網頁。預設的首頁 index.html 與 50x.html 就是放這裡。
  • /var/log/nginx/error.log 預設 error 日誌檔。
  • /var/log/nginx/access.log 預設 access 日誌檔。

在 NGINX for Windows 之前習慣通通包成一包 nginx.conf 來管理。NGINX for Linux 則依功能不同拆分再 include 進來。所以這裡可以花點時間整理一下。

調高 worker_connections

worker_connections 預設 1024。想要在 Linux 調高最簡單的方法是設定 worker_rlimit_nofile 到你的期望值，然後 worker_connections 才能跟著調高。

worker_rlimit_nofile 10240;

events {
    # from default 1024 up to 10240
    worker_connections 10240;
}

worker_rlimit_nofile 也不是能無限調高，這部分與 Host VM 本身給的硬體資源有關，請自行參考文件。

gzip_types 與 gzip_min_length

網頁壓縮可是提高效能不二法門之一，但 gzip_types 預設會壓縮的 MIME 不多，一般都會多指定一些常用可壓縮的 MIME type，例如純文字型的 CSS / Javascript。有找到一份蠻多人引用的 h5bb 的參考清單。但與我們實際運作環境比較後發現，還少了一些我們常用字型類的 MIME type，因此以 h5bb 為基礎，我還加上幾個我們常用的字型 MIME。

gzip_types
       application/atom+xml
       application/geo+json
       application/javascript
       application/x-javascript
       application/json
       application/ld+json
       application/manifest+json
       application/rdf+xml
       application/rss+xml
       application/vnd.ms-fontobject
       application/wasm
       application/x-web-app-manifest+json
       application/xhtml+xml
       application/xml
       application/x-font-ttf
       application/font-woff
       application/font-woff2
       font/eot
       font/otf
       font/ttf
       font/opentype
       font/x-woff
       font/woff2
       image/bmp
       image/svg+xml
       image/vnd.microsoft.icon
       image/x-icon
       text/cache-manifest
       text/calendar
       text/css
       text/javascript
       text/markdown
       text/plain
       text/xml
       text/vcard
       text/vnd.rim.location.xloc
       text/vtt
       text/x-component
       text/x-cross-domain-policy;
   gzip_min_length 10k;

gzip_min_length 會去確認 Content-Length 的長度來決定要不要進行壓縮。預設是 20，但太小壓縮沒什麼意義，這裡我設定大於 10k 的 gzip_types 才進行壓縮。數值大小可以自行分析一下 NGINX 提供出去 MIME type 大小來決定，不要網路上查到什麼裝填什麼。網路上有人說 1000，有人說 1k，我自己分析的結果，1000 / 1k 跟預設的 20 沒什麼差異，因為現在的純文字 MIME type（例如 CSS / Javascript）要小於 1k 的機率實在不大，因此幾乎全中。

stub_status（nginx status）

location /nginx_status {
    stub_status on;
    access_log off;

    # allow 172.21.150.135/24;
    # deny  all;

    auth_basic "closed site";
    auth_basic_user_file /etc/nginx/htpasswd;
}

啟用 stub_status 的端點可以取一份簡易的 NGINX 統計資訊。不建議讓任何人都可以存取，可以加上 IP 限制或 auth_basic 的設定。

Active connections: 291
server accepts handled requests
 16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106
  • Active connections：當前連線數，這個數值包含 Waiting 的數量。
  • server accepts handled requests：三個數值代表accepts、handled、requests三件事。
    • 第一個 accepts 是伺服器接受的連線總數
    • 第二個 handled 是伺服器已經處理的連線總數（通常等於第一個 accepts 的數值）
    • 第三個 requests 是客戶端請求總數。若將第三個數值除以第二個數值，就會得到平均每個連線的請求數（31070465 / 16630948 = 1.8）。
  • Reading：目前正在讀取請求表頭的請求總數。
  • Writing：目前正在讀取請求主體、處理與回應的請求總數。
  • Waiting：keep-alive 的連線總數，這個值會跟 keepalive_timeout 的設定值有關，這個數值通常不太會影響伺服器效能，可以不用太在意。

路由大小寫(1)

由 NGINX for Windows 轉移到 NGINX for Linux 第一件事會立即碰到平台差異是由大小寫不敏感變成大小寫敏感。

NGINX for Windows：

location /Docfiles {
    proxy_pass https://docfilessite;
}
  • /Docfiles
  • /DocFiles
  • /docfiles
  • /DOCFILES

以上路由請求在 NGINX for Windows 都可以正常運作，但在 NGINX for Linux 只有第一條一模一樣的路由請求能正常運作。在 NGINX for Windows 自由習慣了，並且有許多系統在運作，無法一一查證請求的路由的大小寫一致性，因此決定讓 NGINX for Linux 也採用 大小寫不敏感 的模式運作。

location ~* /docfiles {
    proxy_pass https://docfilessite;
}

location ~* 代表一個不區分大小寫的 Regular expression。

路由大小寫(2) - 尾綴

在我們的 NGINX for Windows 的 proxy_pass 許多路由規則都會多帶一個尾綴：

location ~* /docfiles {
    proxy_pass https://docfilessite/docfiles;
}

這在啟用 location 的不區分大小寫的 Regular expression 之後，不能再帶尾綴直接刪除即可。你用 nginx -t 檢查還蠻容易找出未修改的組態。

location ~* /docfiles {
    proxy_pass https://docfilessite;
}

路由大小寫(3) - 多條路由規則

NGINX for Linux：

# 首頁
location / {
    proxy_pass http://homesite;
}

location ~* /kkweb {
    proxy_pass https://kkwebsite;
}

location ~* /kkapi {
    proxy_pass https://kkapisite;
}
  • /images/logo.png
  • /images/kkweb.png
  • /images/kkapi.png

我現在在 / 首頁裡，裡面有一些服務的介紹，包含 web 與 api，因此在 / 底上放個些介紹用的圖檔。當你開啟 / 存取以上三張圖片時，你認為都會正常嗎？

其實不會，因為 location ~* 這組 Regular expression 會全部掃過一遍之後才決定請求要給誰。

  • /images/logo.png （沒任何人符合，因此給 location /）
  • /images /kkweb .png （路由裡的 /kkweb 符合 location ~* /kkweb 規則）
  • /images /kkapi .png （路由裡的 /kkapi 符合 location ~* /kkapi 規則）

因此我們需要改寫一下 Regular expression：

location / {
    proxy_pass http://homesite;
}

location ~* ^/kkweb(/|$) {
    proxy_pass https://kkwebsite;
}

location ~* ^/kkapi(/|$) {
    proxy_pass https://kkapisite;
}

^/RouteName(/|$) 這組 Regular expression 的意思是，只有 /RouteName 或 /RouteName/ 兩種開頭會能符合此規則（知道結果就好，這裡不是 RegEx 的教學，我就不多做 RegEx 說明）。

小結

從大小寫開始，一路到尾綴，再到多路由的條件衝突，是上線後慢慢浮現，並不是一次就調整完成，這是比較麻煩的地方，像多路由的問題也不好找，但好在早期有 API Routing 的經驗。以上就是總結一些在 NGINX for Windows 轉移到 NGINX for Linux 碰到的的差異點。

標籤： , , , 張貼者： 於

沒有留言:

張貼留言

感謝您的留言，如果我的文章你喜歡或對你有幫助，按個「讚」或「分享」它，我會很高興的。

訂閱： 張貼留言 (Atom)