NGINX 官方給的十個常見的設定錯誤

也是在 Hacker News 上看到的,NGINX 官方給的 10 個設定上的常見錯誤:「Avoiding the Top 10 NGINX Configuration Mistakes」,對應的討論串在「Avoiding the top Nginx configuration mistakes (nginx.com)」這邊,看了一下裡面還蠻多蠻實用的?(雖然有些算是官方自己的偏見,或是官方自己在搞事...)

第一個是 worker_connections 設定與 fd 的上限沒有對應,因為每個連線會吃掉兩個 fd,所以要給夠才有辦法讓 connection 衝上去:

The common configuration mistake is not increasing the limit on FDs to at least twice the value of worker_connections. The fix is to set that value with the worker_rlimit_nofile directive in the main configuration context.

另外就是要檢查系統的 limit 設定,像是 /etc/security/limit.conf 這類的設定。

第二個是 error_log off 這個設法,在 NGINX 裡面是有 access_log off,但沒有 error_log off 這個設法,如果你這樣設的話會寫到 error 這個檔名內。所以如果真的要丟掉的話要丟到 /dev/null,像是官方給的範例這樣:

error_log /dev/null emerg;

第三個是 NGINX 對 upstream (backend) 沒有設定 keepalive,這會導致在量很大的時候會產生不少 overhead。

第四個是違反直覺的繼承設定,官方用這樣的範例來表達:

http {
    add_header X-HTTP-LEVEL-HEADER 1;
    add_header X-ANOTHER-HTTP-LEVEL-HEADER 1;

    server {
        listen 8080;
        location / {
            return 200 "OK";
        } 
    }

    server {
        listen 8081;
        add_header X-SERVER-LEVEL-HEADER 1;

        location / {
            return 200 "OK";
        }

        location /test {
            add_header X-LOCATION-LEVEL-HEADER 1;
            return 200 "OK";
        }

        location /correct {
            add_header X-HTTP-LEVEL-HEADER 1;
            add_header X-ANOTHER-HTTP-LEVEL-HEADER 1;

            add_header X-SERVER-LEVEL-HEADER 1;
            add_header X-LOCATION-LEVEL-HEADER 1;
            return 200 "OK";
        } 
    }
}

而你會發現 add_header 會蓋掉先前繼承的項目,但同一個 block 之間會疊加而不是蓋掉...

所以打 localhost:8081/test 的時候只會有 X-LOCATION-LEVEL-HEADER: 1;打 localhost:8081/correct 會有四個 HTTP headers...

第五個算是官方自己的偏見,我們一般都會希望壓低 TTFB (Time To First Byte),把 proxy_buffering 關閉算是常態了。

第六個是官方雖然實做了 if 但很不希望你拿來用。

第七個是 health check 的正確設法,避免多個 block 都有 health check,造成無用的功夫。

第八個是保護內部的資訊,這邊給的範例是 stub_status

第九個是個地雷,ip_hash 這個演算法可以依據 client 的 IP address 來打散流量到後端的伺服器上,對於 IPv6 他會拿整個 IPv6 當作 key (128 bits),但對 IPv4 他只會拿前面三碼 (24 bits) 當作 key:

The ip_hash algorithm load balances traffic across the servers in an upstream{} block, based on a hash of the client IP address. The hashing key is the first three octets of an IPv4 address or the entire IPv6 address. The method establishes session persistence, which means that requests from a client are always passed to the same server except when the server is unavailable.

這完全就是官方自己在搞... 而 workaround 是自己指定 key:

The fix is to use the hash algorithm instead with the $binary_remote_addr variable as the hash key.

第十個是沒有使用 upstream,大多數的情況就是測試發現會動,就直接上 production 的關係 XDDD

GitHub Actions

GitHub 藉著 open source 函式庫,說明了目前還在 beta 的 GitHub Actions 是什麼:「An open source parser for GitHub Actions」。

GitHub Actions 是 GitHub 規劃將自動化設定包裝成設定檔的服務,以往是透過 GitHub 網站上設定,現在則是把這些設定放到 git repository 內。

重點在於 Actions 其實是透過 HCL (HashiCorp Configuration Language) 語法定義:

All Actions workflow files are valid HCL, but not all HCL files are valid workflows.

在 nginx 環境中把 Trac 裝到子目錄下的設法

以前的「Nginx + FastCGI + Trac」提到給的範例是把 Trac 裝在 / 下的方法。如果是裝在 /trac 或是其他路徑時就需要修改了。

一開始試著改會出現這樣的錯誤:

No handler matched request to /trac/report/7

然後研究調整後,發現 Trac 純粹是吃 FastCGI 給的參數去判斷要怎麼處理 url routing,在 trac.ini 內 url 相關參數主要還是用在其他地方... (像是信件通知時用的 url)

首先是把檔案簡化,這是 2016 年寫的:

    location / {
        auth_basic "trac realm";
        auth_basic_user_file /srv/domain.example.com/.htpasswd;

        include fastcgi.conf;
        fastcgi_param AUTH_USER $remote_user;
        fastcgi_param HTTPS on;
        fastcgi_param PATH_INFO $fastcgi_script_name;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param SCRIPT_NAME "";
        fastcgi_pass unix:/var/run/trac/trac.sock;
    }

發現現在 fastcgi.conf 內都會處理 HTTPS 了,所以拿掉 HTTPS 的處理,然後把 location 的判斷改用 regex 去抓 /trac 後的東西,所以先變成這樣:

    location ~ /trac(/.*) {
        auth_basic "trac realm";
        auth_basic_user_file /srv/domain.example.com/.htpasswd;

        include fastcgi.conf;
        fastcgi_param AUTH_USER $remote_user;
        fastcgi_param PATH_INFO $fastcgi_script_name;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param SCRIPT_NAME "";
        fastcgi_pass unix:/var/run/trac/trac.sock;
    }

最後是把 PATH_INFO 改傳 $1 (在 / 的情境下 $fastcgi_script_name 剛好就會是 routing 用的 PATH_INFO 資訊,所以當時直接拿來用),把 SCRIPT_NAME 改成 /trac

也就是跟 Trac 說基底在 /trac,後面的路徑才是你的 routing engine 要處理的東西,所以變成:

    location ~ /trac(/.*) {
        auth_basic "trac realm";
        auth_basic_user_file /srv/domain.example.com/.htpasswd;

        include fastcgi.conf;
        fastcgi_param AUTH_USER $remote_user;
        fastcgi_param PATH_INFO $1;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param SCRIPT_NAME "/trac";
        fastcgi_pass unix:/var/run/trac/trac.sock;
    }

沒寫下來就會花不少時間重新摸...

AWS OpsWorks 支援 Puppet Enterprise

算是等很久的功能了... AWS 支援的是商業版本的 Puppet Enterprise,掛在 OpsWorks 產品下:「New – AWS OpsWorks for Puppet Enterprise」。

Master server 目前只支援 c4.large、c4.xlarge、c4.2xlarge 三種 instance (如上圖所顯示的),然後這一波支援的 region 只有 us-east-1、us-west-2 以及 eu-west-1,還沒看到亞洲的 region XD

At launch AWS OpsWorks for Puppet Enterprise is available in US East (N. Virginia) Region, US West (Oregon) Region, and EU (Ireland) Region.

計價方式是按照 node 來算,前面的 112,500 node hours 是 $0.017/hour,如果以一個月三十天來算,一個 node 的成本是 $12.24,不算便宜... 不過目前感覺在 AWS 上應該要吃 Packer 來玩,而不是 Puppet... 反正是多給使用者一個選擇就是了,總是有些情境下選擇這個服務是對的方向 (像是考量人的前提...)。

Percona 比較 MySQL 與 MariaDB 預設值的差異

Percona 的人花了些時間整理 MySQL 5.7 與 MariaDB 10.2 在預設值上的差異:「MySQL and MariaDB Default Configuration Differences」。

整體可以感覺到 MariaDB 10.2 相較於 MySQL 5.7 還是頗偏 MyISAM 的設計,可能跟 Monty (Michael Widenius) 的偏好有關吧... 不過技術面上來說,MariaDB 10.2 是基於 5.5 分支出來一路改出來的,當時的 InnoDB 跟現在的版本比起來的確沒那麼強...

不過這畢竟只是預設值,看過留個印象就好...

Mozilla 提供了 SSL/TLS 設定懶人包

MozillaMozilla SSL Configuration Generator 提供了各種 server side 的設定:

以及不同等級的設定 (Modern、Intermediate、Old),另外還有 HSTS 的選項可以選擇。

對於 security 的東西我不是很喜歡用 generator (因為我覺得既然是資安相關的東西,要盡可能知道每個細節),但算是一種推廣吧,看了一下設定也都還算合理...

nginx 打算使用 JavaScript 的方法...

nginx 的創辦人在接受 InfoWorld 訪問時提到了打算使用 JavaScript 做為設定檔的計畫:「The company plans to let you use JavaScript as an application language in its eponymous Web server」。

We're planning JavaScript configurations, using JavaScript in [an] Nginx configuration. We plan to be more efficient on these [configurations], and we plan to develop a flexible application platform. You can use JavaScript snippets inside configurations to allow more flexible handling of requests, to filter responses, to modify responses. Also, eventually, JavaScript can be used as [an] application language for Nginx. Currently we have only Perl and Lua [supported in Nginx]. Perl is our own model, and Lua is a third-party model.

目前的設定檔算是 DSL?還蠻有趣的想法...

Hjson:the Human JSON

前幾天看到「Hjson, the Human JSON」這東西,想要在 JSON 上面提出拓展,讓人更好維護。

有幾個設計是大家已經想很久了。

首先是允許註解:

{
  # specify rate in requests/second
  "rate": 1000
}

再來是允許 ending trailing comma,這點在新的 JavaScript Engine 裡面是允許的,但在 JSON 規格裡是不允許的,對於 copy-paste 時就得很小心有沒有中獎:

{
  one: 1,
  two: 2,
}

另外幾個特點就還好。

object 的 key 沒有特殊情況時可以省略 double quote:

{
  key: "value"
}

甚至 value 是 single line 時也可以省略:

{
  text: look ma, no quotes!
}

而且當沒有 double quote 時不需要處理 escape 問題:

{
  path: c:\windows
  inject: <div class="important"></div>

  # escapes work inside quotes
  escape: "c:\\windows"
}

然後逗點可以省略,給的範例也突顯出對腦袋不直覺的問題 (ambiguous),這邊的 1 是 integer 還是 string?

{
  one: 1
  two: 2
}

多行,用 ''' 應該是借用了 Python 的想法?

{
  haiku:
    '''
    JSON I love you.
    But strangled is my data.
    This, so much better.
    '''
}

規格後面有提到 syntax,可以看到定義。

Hjson 算是一個開始吧,YAML 的設計需要極長的 training 時間才能正確使用,不知道 SaltStack 會不會有人馬上寫 adapter 出來接?(因為 SaltStack 已經可以接 JSON 與 YAML,只要有人把該接的接上去就可以了)