NginXモジュールを作成する方法と理由-理論、実践、利益

ヴァシリー・ソシュニコフ（ Mail.Ru ）

今日は、nginxモジュールの作成方法について説明し、最も重要なこととして、なぜこれを行う必要があるのか​​を答えてみます。 これは必ずしも必要ではありませんが、nginx側で解決できる特定の範囲のタスクがあります。







以下に概要を示します。 最初に、nginxアーキテクチャについて説明します。 第二に、Mail.ruで働いている人が頻繁に私のところに来て同じ質問をするので、いくつかのよくある質問にすぐに答えようとします。それらを簡単なFAQに入れることにしました。 すぐに、次に何が起こるかをよりよく理解できるようにします。



最も興味深い部分は解剖学です。 nginxモジュールの作成方法、どのタイプがあるか、落とし穴について少し説明しますが、nginxは非常に複雑なテクノロジーであるため、1000のニュアンス、1000の微妙さがあります。 そして、「なぜ作成するのか？」、「Mail.ruで作成するのはなぜですか？」、「Mail.ruではなく作業するのはなぜですか？」という質問に答えようとします。



また、昨夜、文字通りnginxモジュールのテンプレートの例を作成することにしました。これは、そのまま使用できます。 最後に参照をします。 私の仲間がこれなしではプレゼンテーションが不完全だと言ったからです。



はじめにセクションとよくある質問から始めましょう。







1つはnginxアーキテクチャです。 私はいつも入れ子人形に関連付けます。 実際、そのとおりです。 コアAPI全体が配置されている特定のコアがあり、そこから必要なものすべてを魅了できます。 この場合、httpがブラインドされ、アップストリームとスクリプトエンジンもhttpからブラインドされました。 また、メールを処理するメールエンジンもコアに基づいて作成されています。 http用にすでに作成されているモジュールは、httpコアで作成されます。 つまり あなたは理解している、これはそのような入れ子人形であり、ベースがあります-これはコアであり、下にレイヤーがあります。 また、レイヤーが低いほど、通常はどのモジュールよりも多くなります。 httpには多くのモジュールがあり、それらはすべてhttpコアとnginxの機能に基づいていることをご理解いただいています。







最もよくある質問の1つは、nginxメモリモデルに関する質問です。 Nginxはプールを使用します。 これは常に覚えておく必要があります。 そして、あなたは適切なプールを取る必要があります。 多くの人が頻繁にミスを犯し、バッファを接続に釘付けにしようとします。キープアライブモードでの接続は非常に長く続く可能性があります。 接続が生きている限り、そのようなバッファは蓄積し、nginxは単純にリークする可能性があることを理解しています。 したがって、常に適切なプールを選択する必要があります。 リクエストの存続期間だけバッファを保存したい場合は、接続ではなくリクエストに釘付けにする方が論理的です。





また、これらのプールは定期的にクリーニングされ、独自の寿命があることを覚えておく必要があります。 原則として、それらはすべて非常に論理的であり、接続は接続のフレームワーク内で存続し、要求-要求のフレームワーク内では、構成は常に存続し、定期的に支配されます。 他にも多くのコンテキストがありますが、それらについてはもう少し詳しく説明します。



また、nginx内で常にnginxロケーターを使用するようにしてください。 APIリファレンスが上部にあります。 なぜそれらを使用するのですか？ a）より高速です。 b）Valginをnginxに使用すると、デバッグが容易になります。 確かに、nginxバッファーの寿命は低下していません。 プールは、すべてが正しく行われ、すべてが計算されれば正常に機能するため、必要ありませんでした。



しかし、そのような状況があります。たとえば、最近、標準のmallock、alloc、reallockを使用しなければならなかったとき、そうなりました。 なんで？ nginxにはreallockがないためです。 これは大きな問題です。 reallockを使用する何らかの種類のライブラリがある場合、ライブラリ内のこれらの割り当て関数を単に置き換えることはできません。 ここで、良い例-yajil。 原則として、私はこれを行う方法を考え出しました。誰かがパスカル文字列に精通しているなら、あなたは単に4バイト以上を割り当て、このメモリに別のサイズを釘付けにすることができます。 また、展開には通常のnginx'ovskiy alloを使用します。







これは一例であり、nginx_conf_sです。 これがその内部構造です。 ここでは、プールへのこのリンクだけを見ることができます。 この場合、設定の一部として何かを選択すると、設定が有効である限り有効になります。 また、nginxでは、ペンでクリーニングするまで設定は常に有効です。 しかし、さまざまな設定があり、それについてはもう少し詳しく説明します。 だから、私たちは常に、あなたが釘付けしたい構造を見て、それがどこに住んでいるかを大体理解しなければなりません。 しばらくすると、これらすべてがマシン上にありますが、最初にこれを非常に明確に守る必要があります。







そして、nginxの内容と、リポジトリ内でのその構造の配置について簡単に説明します。 APIの最上部、およびそれ以下-何がありますか。 まず、nginxには多くのデータ構造があり、それらを使用しようとします。a）彼らはすでにnginxプールについて知っています。 b）これは、nginxではほとんどすべてのデータ型がtypedefシステム型または独自の構造のいずれかであるため、nginxデータ型で使用する最もネイティブな方法です。



また、nginxコアには、自然にファサードにラップされたAPIを備えたOSがあります。 これは、nginxで独自のhttpモジュールを作成しない場合に便利ですが、たとえば、独自のTCPモジュールのようなものであれば、これも可能です。 httpはコアに基づいて作成されており、必要に応じて、必要に応じて拡張できるためです。 また、ファイル記述子の洗練を担当するステートマシンや、ログ、スクリプトや構成の操作など、その他の多くの便利な機能を見つけることができます。







そして今、最も興味深く、最も痛みを伴う、またはむしろ、最も未知のものです。 これがnginxモジュールの配置方法、タイプです。 私は時間に限りがあるので、私は主に3つだけについて話すことにしました。 そして、おそらく最も興味深いのは、アップストリームに関することです。 要するに、それは本当に別のレポートのトピックだからです。







したがって、今日は3つの主要なモジュールのみを検討します-これらはハンドラー、フィルター、プロキシーです。 一言で言えばプロキシ。 実際、httpはコアベースのモジュールでもあるため、他にも多くのタイプのモジュールがあります。 しかし、非常に長い時間であり、これもまた別のレポートのトピックであるため、このようなニュアンスには触れません。







nginxのすべては、1つのパターンに従います。 これが責任の連鎖パターンです。 言い換えると、ユーザーからのリクエストはhttpモジュールを通過し、httpモジュールはいくつかのシーケンス-モジュールのチェーンを開始します。 そして、それらがすべてうまく機能していれば、ユーザーは良い答えを得るでしょう。そうでなければ、エラーが発生します。 最も近い例えは、次のコード行です。







私はそれが完璧なアナロジーだと思った、私は正しいことを願っています。 誰もがこの行を理解していますか？ これは本質的にbashです。 何かをつかんで、最初の行をデリミターで取得します。 成績をつけて単語を数えます。 nginxモジュールの動作原理はこれに非常に似ています。 つまり パイプが破損すると、チェーン全体が飛び出し、bashでエラーが発生します。 信号などもあります。 Nginxにも同じことがあるため、すべてのnginxモジュールはそのように扱う必要があります。







また、もう少し深く掘り下げると、チェーンであることに加えて、このチェーンもフェーズに分割されていることがわかります。 nginxには多くのフェーズがあり、各フェーズは特定の条件下で特定の時点で呼び出され、フェーズ内のすべてのハンドラーが渡されます。その後、そのフェーズの結果が別のフェーズに切り替えられます。 基本的に、この図はこれを示しています。 フェーズには特定のモジュールセットがあり、通過して結果を取得し、次のフェーズに進みます。



そして、nginx_httpで利用できるようになったフェーズは次のとおりです。







彼らは自発的です、私はここに質問がないと思います。 つまり server_rewrite、config search、rewrite normal、content_phase。







それでは、モジュールの開発方法に取り掛かりましょう。 モジュールごとに行う必要があるのは、これらのことです。







まず、nginxのモジュールはすべてconfigで始まります。 Nginxには、モジュールや他のモジュール、さらには内部nginxに対しても、このような構造に名前を付ける特定の方法があります。 そのような命名規則、つまり ngx_httpは、現在httpに対して何かを行っていることを示しています。 次はモジュールの名前です-それは何でも構いません。 そして、それに応じて、構成タイプの1つ-main、server、loc-および_conf。

ところで、高負荷システムHighLoad ++の開発者の会議の過去5年間の公開ビデオを公開しました。 YouTubeチャンネルを視聴、学習、共有、購読します 。

誰もがnginx_configを覚えていますか？ これはそこから来ています。 メインがあります-これは最もグローバルなスコープであり、サーバー、ベータサーバー、場所があります。 ロケーションの場合-ロケーションも考慮し、特定の場合のみ。 実際、これらの構成と構造は、さまざまな段階でマージできます。 この構造を作成するのを妨げるものは何もないので、メイン、サーバー、および場所と場所に存在するようになります。 必要なのは、1つの関数を記述し、特定のビットマスクを設定することだけです。 これについては後で詳しく説明します。







ディレクティブ。 nginx configにはディレクティブがあります。 そして、それに応じて、モジュールを開発する際には、管理者とユーザーに何らかのペンを提供する必要があることを理解する必要があります。 nginxには、このための特別な構造があります-ngx_command_sです。 APIへのすべてのリンクをここに投稿するので、後で見ることができます。複雑なことは何もありません。 実際、ここにあるのは名前だけです。 名前は、nginx configでディレクティブがどのように表示されるかです。 これはタイプであり、このディレクティブが何であるかをマスクします。 つまり それは場所、メインconf、サーバーconfに存在します。 この変数の値を解析するコールバックが存在します。 多数の既製のコールバックがあります。 たとえば、ngx_stringを使用し、行を保存する必要がある場合、このコールバックを実装するのではなく、nginxから既製のコールバックを使用する必要があります。 そして、いくつかのシステムフィールドについては、次のスライドで説明します。







MODULE_NAMEというモジュールを作成するとします。 したがって、特定の変数、通常の整数があり、この整数をconfigに転送します。 この配列でこのような構造体を宣言するだけです。 多くの異なる変数がある場合、この配列の要素が多くなります。 そして今、私が言ったように、このマスク、この場合、このビットマップは、1つの引数が受け入れられることを示しています。 これは、このディレクティブが構成、サーバー構成、およびメイン構成の場所に存在する可能性があるという事実です。 まだ場所がある場合は、このマスクの別の部分を追加する必要があります。



したがって、これはnginx関数であり、通常のintを解析するために存在します。 これは特に時間を節約するためです。そのため、毎回この機能はありません。 offsetofは、このフィールドが私たちの構造のどこにあるのかを説明するだけで、これは古き良きC-shnyハックです。 実際のところ、この文脈では与えられたとおりに取らなければならないので、私はそれに焦点を合わせません。 つまり 追加のセマンティックロードは実行しません。



そして、そのような配列は通常のngx_null_command-配列がなくなったことを示すマーカーで終わります。 nginxでは、モジュール内で宣言するほとんどすべてが静的であり、どこかで外部化されます。nginxでは、モジュールを開発する2つの方法があります-nginxでモジュールをコンパイルするか、モジュールをロードするか、後で詳しく説明します。 この場合、当面はすべてが静的であり、このマーカーはこの配列を最後まで通過するため、最終マーカーが必要であることを覚えておく必要があります。







ここでは、いくつかのディレクティブを作成しましたが、すべて正常に機能しますが、nginx内にインストールし、構成とそのマージを作成する必要があります。 これを行うには、ngx_http_module_tのような構造があります。 また、非常に簡単です。インストールのいくつかの段階があります。これは事前構成です。これは、事後構成が発生する前であり、他のいくつかの機能についても次のスライドで詳しく説明します。







たとえば、以前に発表したこと、ディレクティブがその場所に正しくマージされるようにします。 行う必要があるのは、モジュール内で宣言した2つのコールバックの構造をハンマーで叩き、ngx_pallocを使用して構成を展開することです。 そしてマージします。 nginxでは、nginxが理解できるプリミティブ型の場合、変数をマージするための多数の関数セットが既にあります。 これが独自のタイプである場合、たとえばxmlなどの解析する必要がある非常にトリッキーな行があり、別の構造で記述する場合は、関数とマージが必要であり、変数の設定を自分で記述する必要がありますそれをコールバックに渡します。 そして、この機能のマージ設定の段階で、いくつかの追加チェックを行い、そのようなエラーが発生したと言うことができます。 ここでは、何かを誓約し、他のことをすることもできます。







すべて、設定がちらつき、ディレクティブを取得しました。 ここで最も興味深い部分は、nginxにモジュールが表示されたことをどのように伝えるかです。 これにはngx_module_tがあります-これは特別なタイプです。 そして、再び、オブジェクト内で静的と宣言されています。 通常の変数。 記述し、コンテキストを伝え、これらのコマンドを作成し、より柔軟な管理のために追加のコールバックも可能です。 つまり intマスター、マスターからの出口などで特定のアクションが必要な場合を考えてみましょう。 ここでは、原則として、すべてが明確であると思います。質問はありません。 ただ余分なコントロールノブ。 たとえば、なぜこれが必要なのですか？ モジュールが共有メモリを使用している場合、ストリームを終了して強制終了するときにロックを解除したいと思うでしょう。 このため、これらのペンが存在します-追加のアクション用。



この点に基づいて、誰もがnginxモジュールを作成する方法を理解しているか、すでに推測していると思います。 実際に行う必要があるのは、いくつかの静的変数を記述し、いくつかのコールバックを宣言することだけです。 そして、モジュールが取り上げられます。 しかし、これだけではありません。現在最も重要なニュアンスは、ハンドラーをフェーズに追加する方法とフィルターを作成する方法です。 nginx内のいくつかのイベントに対して関数を呼び出すだけです。







そして、これについて今すぐ話します。 ハンドラーとフィルターについて。 これらは2つの異なるエンティティです。







念のためフェーズに戻ります。 フェーズは、すべてのフェーズが完了するか、フェーズが中断されなくなるまで、特定の時点を発生させ、特定のチェーンを発生させ、チェーンを終了して次のフェーズに進みます。 そして、ハンドラーだけがフェーズで動作します。 つまり ハンドラーとは何ですか？ これらのフェーズのいずれかに任意の関数をバインドできます。 そして今、私はそれを行う方法を紹介します。







覚えているように、モジュールを宣言するとき、追加のペンを渡すことができます。 ここで、設定後、つまり ディレクティブがすでに解決されている場合、変数を取得し、それらを入力し、いくつかのフェーズをバインドし、初期化中に関数を追加し、それに応じてこの関数で次のことを説明する必要があります-フェーズの内容を取得しますすべてnginxコア設定から。これはすべてhttpコアライフに含まれているためです。 そして、通常のarray_pushを使用してそこに関数を追加するだけです。 それだけです。コンテンツに対してこの関数が呼び出されます。



言い換えると、フェーズコンテンツとは何ですか？ 誰かが私たちから応答を返すと、フェーズの内容がひっくり返り、そこで何でもできます。たとえば、サーバーからの応答に含まれる単語の数をカウントしたり、独自のアルゴリズムでさらに圧縮したりできます。 そして、それがファイルであろうとなかろうと、誰かが私たちから答えを返すたびに、この関数が呼び出されます。 その中で、すでにhttp-requestを操作したり、必要なデータを引き出したり、そこに何かを追加したり、逆に削除したりできます。 そして、各フェーズで行うことができます。 覚えておくべき主なことは、すべてのフェーズが異なる時間に呼び出されることです。 つまり、コンテンツを操作する必要がある場合、ハンドラをログフェーズに追加する必要はありません。 ログフェーズは、大まかに書き留める必要があるときに発生するためです。 このフェーズに興味がある場合は、逆に、追加の統計を収集できます。 このフェーズでは、コンテンツを処理する必要があります。



ところで、私は良い例を思い出しました。 前回コンテンツフェーズを行ったとき、top.mail.ruのカウンター用にその場で画像を生成する必要がありました。 これが良い例です。 つまり 私は何もしませんでした。クエリパラメータやカウンタIDなどに応じて、この新しい画像を生成しました。







フィルター これはわずかに異なるエンティティです。 フィルターとは何ですか？ チェーンを覚えていますか？ 実際、フィルターは、フィルターの単純な単一リンクリストです。







そして、ハンドラーを特定のフィルターに追加するために必要なことは、top_header_filterというnginx静的変数を取得し、そこにハンドラーを追加するだけです。 この場合、これはheader_filterであり、ハンドラーはヘッダーを処理する段階のある時点で毎回呼び出されます。



良い実用的な例。 カウンターにクッキーを設定して確認する必要があります。 必要なのは、新しいヘッダーフィルターを追加して、到着したヘッダーをチェックし、何らかの方法で通常のCookieに変換することだけです。 これは、これが使用される理由の良い例です。



これが使用される別の良い例です。 標準のnginxディレクティブであるadd_headerのようなディレクティブは誰もが知っています。 彼女はこれらのヘッダーを使用します。



つまり 彼女はhttpヘッダーで何でもできます。 そして、インストール全体は常にこのようになります。 実際、まだ身体があります、私は彼のことを忘れました。 彼は同じイデオロギー、同じリストを持っていますが、コンテンツ処理の段階で機能します。







そして、最も興味深い。 私たちの構造は必要です。 nginx向けに開発したことがあるなら、このフレームワークがあなたの親友になります。 多くの場合、このコードにアクセスします。おそらく、それらに何かをバインドして、すぐにジャンプします。 彼女は巨大です、彼女は知る必要があります。 微妙な違いがたくさんあります。 したがって、何かを開発したい場合、この構造に慣れるには、そこに複雑なものは何もありません。ただそれを読んで理解する必要があります。 接続自体、ユーザーから送信されたヘッダーを保存します。ヘッダーはユーザーから離れ、すべてのハンドラーハンドラー、独自のプールを保存し、このリクエストで動作します。 彼女は体も保存します。 さらに、nginxはすべてを支払うため、保証されたボディ全体を減算するか、保証された...を送信する必要がある場合、実際には常にパイプとして機能するため、最後まで蓄積されない場合があります。 正確に保証されたものを送信する必要がある場合は、特別な関数を呼び出して特定のリクエストを使用する必要があります。 より正確には、ハンドラーに送られた特定のリクエスト構造。







そして、ここでnginxの最も興味深く、最も難しい瞬間に来ます-これはチェーンバッファです。 nginxでは、任意のバッファーでの作業はチェーンバッファーです。 これは基本的に、単一リンクのバッファのリストです。 これは非常に注意が必要です。ファイル内にある可能性があり、共有メモリである可能性があり、読み取り専用メモリである可能性があり、一時メモリである可能性があります。 ニュアンスが非常に多いので、チェーンバッファーには入らないと思いました。 あなたが彼について知る必要がある主なことは、あなたのメッセージが来ることができるということです、しかし、一般に、1つの断片ではなく、身体は、小さな小さな断片で、バッファに入ってくることができます。 これは、アップストリームを開発している場合に特に重要です。 アップストリームは一般に4Kまたはバイトで取得できるため、すべてを解析する必要がある場合は、チェーンで機能するトリッキーなストリームパーサーを実行する必要があります。 後のread meの例でリンクを提供します。これらのアップストリームのうち約2つを削除しました。これらのユーザーは、nginx内でストリームパーサーを実装する方法に興味があります。 そのような重要なルールがまだあるので、nginxはブロックできません。 ワーカーは1人です。 そこにThreadPoolがあったとしても、誰も使用することはめったにありません。このワーカーを長時間ブロックすると、多くのrpが失われます。 これも常に覚えておく必要があります。



そして、この余談の後、再びチェーンバッファに戻ります。 基本的に、構造全体は次のようになります。







つまり 最後に、これがファイルである場合、file_pos、タグ、および一連のフラグがあります。 そして、原則として、これらのコメントはすべてnginxから取られています。 覚えておく必要があります。 フィルターまたはハンドラーで、変更できないとマークされているものにメモリの一部が到着し、そのようなコンテンツを変更する権利がないと想像してください。 それを自分自身にコピーし、必要に応じて変更し、さらに提供する必要があります。 したがって、これらのフラグは常にチェックする必要があります。



または別の良い例。 私が書いたモジュールの多くは、チェックin_fileが存在する場合、チェーンバッファーで動作しません。 私が望んでいたので、これがすぐに機能するような要件がありました。 神が禁じている場合、nginxがファイル、キャッシュ、または他の場所からプルを開始すると、すべてが死にます。 , chain buffer , in_file, , : «, , ». , .



, upstream-.







6 nginx. opensource, . , . つまり , , upstream chain buffer, , . - . , . , tp_transcode – , .







Proxies. , , upstream, load-, , .. . , . , .







, upstream? proxy pass. proxy pass? , , , chain- , . . , - , , nginx . つまり – http, https - json . application server' . upstream.



, , upstream – API nginx, : ) , , - ; ) , .. , upstream', url. upstream'. , .. .



, upstream', , . , , upstream .



, , , . , , , OpenResty, balancer_by_lua, .. lua , , , , , . -. . , CPU , , - lua-, , url , .







, , , . .







. . nginx . , . , conf, nginx, . , , . . ++ runtime , . . , -, nginx ++ runtime. . , nginx , nginx . . , .







, , nginx-, . nginx-, . , , nginx.







. , .



, , nginx . – nginx' . , - nginx , apt-get install nginx . .



, nginx-. , mail.ru. , , , . , , . , .



, , , , – nginx SO'. ? nginx SO' . , nginx .



, . , , Debian, , nginx . , . , , . , . , , wiki.



, , , mail.ru, , . Docker. nginx, docker image, . , , .







, , – ?







– , , . nginx, , - nginx nginx. , http 3.0, .







, , « nginx-?». , – nginx ReverseProxy – - , , , nginx , . つまり , , , ReverseProxy, nginx-, . , application -, , , , . -.







, 3 mail.ru. http-, , , , , , .. – nginx. . , , , JS-, , image- . 4 .



彼は何をしていますか？ , , . . nginx, CPU, . - SSL , . - SSL . . .



, , -. . , , , , . - , , .







. . OpenResty, nginx- , . , . , - nginx , . , . OpenResty, .







. , , http, .. , , - http, ? upstream , http X. . 2 . , . , .



, , 3 , upstream'. , 100 , , , . , , .. つまり . make , . .

→ github

→ twitter

— Highload++ , — «».



— " HTTP- web- ", HighLoad++ Junior .

• キャッシュなしのHTTPプロキシの仕組み。
  
  永続的な接続とは何ですか？HTTPキープアライブとの違いは何ですか？
  
  アップストリームとのHTTPアクセラレータが確立できる方法、タイミング、および接続数。
  
  キューが送信されてアップストリームに接続されるのを待っているリクエストはどうなりますが、アップストリームはそのままで、100リクエストごとに接続をドロップします。
  
  HTTPパイプライン化とは何ですか？また、最新のHTTPアクセラレーターでどのように使用されていますか。
  
  べき等でない要求とは何か、そしてそれらを心配する必要がある理由。