NGINX ユニットは、新機能 (統計エンジン!) とエキサイティングな計画で 2022 年秋を迎えます

まず最初に、NGINX Unit チームからのニュースを共有してからかなり時間が経ちました。この混乱した時代はすべての人に影響を与えており、私たちも例外ではありません。 今年 3 月、Unit チームの創設メンバーである Valentin Bartenev 氏と Maxim Romanov 氏の 2 人は、 NGINX Unitに長年の努力と多大な創造性を注いだ後、他の機会に進むことを決めました。 当然の功績は認めるべきです。彼らがいなければ、NGINX Unit は今のような地位にはなかったでしょう。 素晴らしいですね、皆さん。

それでも、私たちの決意は固く、NGINX の共同創設者である Igor Sysoev の NGINX Unit に対する当初の願望を実現するという私たちの取り組みも固くなっています。 2 人の新しいチーム メンバー、Alejandro Colomar と Andrew Clayton の参加により開発作業が加速し、 NGINX Unit バージョン 1.25から 1.28 までの注目すべき項目が数多く公開されました。

可観測性は今や重要

Unit の重要な目標の 1 つは常に可観測性であり、バージョン 1.28.0 には、最も待ち望まれていた機能の 1 つである統計エンジンの最初のイテレーションが含まれています。 その出力は新しい/status API エンドポイントで公開されます。

$ curl --unix-socket /var/run/control.unit.sock http://localhost/status

{
「接続」: {
「承認済み」: 1067,
「アクティブ」: 13,
「アイドル」: 4,
「閉鎖」: 1050
},

"リクエスト": {
"合計": 1307
},

"アプリケーション": {
"wp": {
"プロセス": {
"実行中": 14,
「開始」: 0,
「アイドル」: 4
},

"リクエスト": {
"アクティブ": 10 } } } }

ここでのフィールドのほとんどは自己記述的です。接続(行 2) とリクエスト(行 9) はインスタンス全体のデータを提供しますが、アプリケーションオブジェクト (行 13) は/config/applicationsをミラーリングし、アプリケーションに特に関係するプロセスとリクエストをカバーします。

3 行目から 6 行目は、NGINX Unit によって追跡される接続の 4 つのカテゴリ ( accepted 、 active 、 idol 、 closed )を示しています。 プロセスのカテゴリは、実行中、開始中、アイドル状態です (16 ～ 18 行目)。 これらのカテゴリは接続とプロセスの内部表現を反映しているため、サーバーと同様にそれらについて知ることができます。

簡潔に思えますか? 今のところ、わかっていることはこれだけです。 もちろん、より有用なメトリクスを公開できるよう取り組んでいますが、すでにこの API をコマンド ラインからクエリしてサーバーで何が起こっているかを確認したり、出力をダッシュボードにプラグインしたりして、より独創的なアプローチを取ることもできます。 ダッシュボードがないのでしょうか? まあ、私たちの計画の中には組み込みのものを提供することも含まれていますので、これがどのように展開されるか見てみましょう。

詳細については、NGINX Unit ドキュメントの使用状況統計を参照してください。

変数が増えれば、使える場所も増える

バージョン 1.24 以降に導入された変数のリストは非常に広範囲で、 $body_bytes_sent 、 $header_referer 、 $header_user_agent 、 $remote_addr 、 $request_line 、 $request_uri 、 $status 、 $time_localなどが含まれます。

これらのほとんどはかなり単純ですが、特に注目すべきものをいくつか紹介します。

• $request_uri には、ブラウザのエンコーディングが保持された、要求された URI からのパスとクエリが含まれます。
• 同様の名前の$request_line は、 GET /docs/help.html HTTP/1.1などのリクエスト全体を保存し、ログ記録を目的としています…
• HTTPレスポンスステータスコードを含む$statusも同様です。

気づきましたか？ 回答について言及しました。 はい、私たちもその領域に進出しています。以前の Unit バージョンの変数は受信リクエストに重点を置いていましたが、現在は$statusや$body_bytes_sentなど、応答プロパティも取得する変数があります。

変数を使用する新しい場所に関して、最初に言及すべきは、新しいカスタマイズ可能なアクセス ログ形式です。 NGINX Unit のログエントリで JSON を使用したいですか? 単純なパス文字列を指定することに加えて、 access_logオプションは、ログ エントリの形式も設定するオブジェクトにすることもできます。

{ 
"access_log": {
"path": "/var/log/unit/access.log", 
"format": "{ \"remote_addr\":\"$remote_addr\", "time\":\"$time_local\", \"request\":\"$request_line\", \"response\":\"$status\", \"header_referer\":\"$header_referer\", \"header_user_agent\":\"$header_user_agent\" }" 
} 
}

したがって、通常のログ形式を超えて、好きなように操作できます。

変数の 2 番目の注目すべき使用例は、ルートアクションの場所の値です。

{ 
「アクション」: { 
「戻り値」: 301, 
"場所": "https://$host$request_uri" 
} 
}

ここでは、 $request_uri を使用して、クエリ部分を含むリクエストを HTTPS 経由で同じ Web サイトに中継しています。

chrootオプションは、 shareオプションと同様に変数をサポートするようになりました。これは当然のことです。

{ 
"action": { 
"share": "/www$uri",
"chroot": "/www/data/$host/" 
} 
} 

NGINX Unit は動的変数もサポートするようになりました。 リクエスト引数、Cookie、およびヘッダーは変数として公開されます。たとえば、クエリ文字列Type=car&Color=red は、 $arg_Typeと$arg_Color という2 つの引数変数になります。 実行時に、これらの変数は動的な値に展開されます。存在しない変数を参照すると、空であると見なされます。

詳細については、NGINX ユニットのドキュメントの「変数」を参照してください。

X-Forwarded-*ヘッダーの広範なサポート

ご要望にお応えしてお届けしました。 バージョン 1.25.0 以降、NGINX Unit はリスナー向けに TLS 構成機能をいくつか提供しており、これにはX-Forwarded-*の認識も含まれます。これで、リスナーの構成でクライアント IP アドレスとプロトコルの置換を構成できます。

{
"listeners": {
"*:80": {
"pass": "routes/my-app",
"forwarded": {
"client_ip": 「X-Forwarded-For」、
「プロトコル」: "X-Forwarded-Proto",
"再帰": false,
"ソース": [
"198.51.100.1-198.51.100.254",
"!198.51.100.128/26",
"203.0.113.195"
]
}
}
},
...
}

注記： この新しい構文は以前のclient_ip構文を廃止するもので、将来のリリースでは削除される予定です。

詳細については、NGINX ユニットのドキュメントの「IP、プロトコル転送」を参照してください。

改良された株式オプション

NGINX Unit バージョン 1.11.0 では、静的コンテンツを提供するための共有ルーティング オプションが導入されました。 これは、NGINX のルートディレクティブに相当します。

{
"share": "/path/to/dir/"
}

当初、共有オプションはいわゆるドキュメント ルート ディレクトリを指定していました。 提供するファイルを決定するために、Unit はリクエストの URI をこの共有パスに追加するだけです。 たとえば、 /some/file.htmlに対する単純なGETリクエストに応答して、Unit は/path/to/dir/some/file.html を返しました。 それでも、ファイル パスをより細かく制御する必要がある境界ケースに遭遇し続けたため、進化することにしました。 バージョン 1.26.0 以降では、共有オプションはドキュメント ルートだけでなく、共有ファイルへのパス全体を指定します。

特定のファイルを提供したいですか? 大丈夫：

{
"share": "/path/to/a/file.html"
}

パス内で変数を使用しますか? 大丈夫です、問題ありません:

{
「共有」:「/www/data/$host/app.html」
}

しかし、NGINX や以前の Unit バージョンですでに慣れている動作を模倣するにはどうすればよいでしょうか? 数段落前に時代遅れだと判断したドキュメント ルートのことですね。 解決策はあります。

次のように構成を書き換えることができます。

{
「共有」:「/www/data/」
}

次のように、要求された URI をパスに明示的に追加します。

{
「共有」:「/www/data/$uri」
}

最後に、 shareディレクティブはパスの配列を受け入れ、ファイルが見つかるまでパスを 1 つずつ試すことができます。

{
"share": [
"/www/$host$uri",
"/www/static$uri",
"/www/app.html"
]
}

ファイルが見つからない場合、ルーティングは 後退する アクション; ない場合 後退する、 の 404 （ない 見つかった） ステータスコードが返されます。

詳細については、NGINX Unit ドキュメントの「静的ファイル」を参照してください。

計画: njs、URI 書き換え、アクション チェーン、OpenAPI

これを読んでいる時点で、私たちはすでに次のリリースに取り組んでいます。ここで、私たちが準備しているものを少しだけご紹介します。

まず、NGINX Unit を NGINX JavaScript モジュール ( njs ) と統合します。これは、NGINX で現在活発に開発が進められているもう 1 つの主要プロジェクトです。簡単に言うと、NGINX Unit は JavaScript モジュールの呼び出しをサポートすることになります。 次のことを考慮してください。

var hellonjs = {} hellonjs.hello = function(vars) { if (vars の 'unitvar') { return vars.unitvar;

    } else { 'デフォルト' を返します。
    デフォルトの hellonjs をエクスポートします

NGINX Unit にモジュールをインポートすると、設定でいくつかの便利な操作を実行できるようになります。

{ "match": { "uri": "~(?.*)" }, "action": { "share": "`/www/html${hellonjs.hello(vars)} `" } }

また、私たちは、常に人気のある NGINX書き換えディレクティブに似たものを導入することを目指しています。

{
"match": {
"uri": "/app/old_path"
},

"action": {
"rewrite": "/app/new_path",
"pass": "routes"
}
}

しかし、私たちの計画はそれだけでは終わりません。 NGINX Unit のルーティングをアプリ自体の出力に結び付ける (アクションチェーンとも呼ばれる) のはいかがでしょうか?

{
"action": [
{
"pass": "applications/auth_check"
},
{
"pass": "applications/my_app"
}
]
}

ここでの考え方は、 auth_checkアプリが受信リクエストを認証し、結果を示すステータス コードを返すというものです。 認証が成功した場合、200 OKが返され、リクエストはmy_appに渡されます。

一方、NGINX Unit の API とその正確な機能を一括して定義するためのOpenAPI仕様にも取り組んでいます。 これは巨大な事業なので、幸運を祈ってください。

それでもまだ好奇心が満たされない場合は、ロードマップを参照して、計画を詳細に分析してください。インタラクティブなので、読者の皆様からのご意見は大歓迎です。