Nginx クイックスタートガイド: コマンドと構成チュートリアル

Nginx に関する基本的な記事では、Nginx とは何か、および Nginx をシステムにインストールして設定する方法をまとめています。Nginx は、高性能の Web サーバーおよびリバースプロキシサーバーであり、大量の同時ネットワークリクエストを処理でき、ロードバランシング、キャッシュ、SSL 暗号化などの機能も提供します。Nginx はもともとロシアのプログラマー Igor Sysoev によって開発され、世界で最も人気のある Web サーバーの 1 つになりました。

Nginx は、高性能、スケーラブル、機能豊富な Web サーバーおよびリバースプロキシサーバーであり、ユーザーがシステムの可用性とパフォーマンスを向上させ、アプリケーションサーバーのセキュリティと安定性を保護し、Web サイトのアクセス速度を向上させ、ユーザーのプライバシーを保護するのに役立ちます。

Nginxのインストールとセットアップ

Nginx を使用すると、次のような利点があります。

ハイパフォーマンス: Nginx はイベント駆動型の非同期ノンブロッキングアーキテクチャを採用しており、メモリ使用量と CPU 負荷を低く抑えながら、多数の同時リクエストを処理できます。
スケーラビリティ: Nginx はモジュラーアーキテクチャをサポートしており、さまざまなモジュールを追加することで機能を拡張できます。
負荷分散: Nginx は負荷分散を通じてリクエストを複数のサーバーに分散できるため、システムの可用性とパフォーマンスが向上します。
リバースプロキシ: Nginx をリバースプロキシサーバーとして使用して、リクエストをバックエンドアプリケーションサーバーに転送することで、アプリケーションサーバーのセキュリティと安定性を保護できます。
キャッシュ: Nginx はキャッシュを通じて Web サイトのアクセス速度を向上させ、バックエンドサーバーへのリクエストの数を減らすことができます。
SSL 暗号化: Nginx は、Web サイトのセキュリティとユーザーのプライバシーを保護するために SSL 暗号化を提供できます。

次のチュートリアルでは、最新の Web サーバーソフトウェアの基本的なコマンドと構成オプションの概要を説明します。

中央制御ユニット: nginx.conf

Nginx はイベントベースであるため、Apache とは動作が異なります。単一のリクエストは、新しいワークフロー (すべてのモジュールをロードする必要がある) として分類されず、イベントとして分類されます。これらのイベントは既存のワーカープロセスに分割され、ジュニアマスタープロセスによって維持されます。nginx.conf 構成ファイルは、最終的に存在するワーカープロセスの数と、サーバーリクエスト (つまりイベント) がどのように分割されるかを定義します。これらは、ファイル /usr/local/nginx/conf、/etc/nginx、または /usr/local/etc/nginx にあります。

プロセスを管理し、新しい構成を採用する

Nginx はインストール後に自動的に起動しますが、次のコマンドで起動することもできます。

1	sudoサービスnginxの起動

Web サーバーソフトウェアが実行されたら、-s パラメーターと特定のシグナルを使用してプロセス (主にメインプロセス) をアドレス指定することで、Web サーバーソフトウェアを管理できます。対応するコマンドの構文はそれほど印象的ではありません。

1	sudo nginx -s シグナル

「Signal」には次の 4 つの可能性があります。

stop: nginx はすぐに終了します。
quit: すべてのアクティブなリクエストが応答された後、nginx は終了します。
reload: 設定ファイルをリロードします。
再開: ログファイルを再開します。

構成ファイルを再ロードするためのリロードオプションは、Web サーバーソフトウェアを終了したり、後で再起動したりせずに変更を加えるための優れた方法です。いずれの場合も、変更を受け入れるには、サーバーを完全に再起動するか、nginx をリロードするだけかを決定する必要があります。後者のオプションを選択して次のコマンドを実行した場合、マスタープロセスは nginx.conf ファイルに変更を適用するように指示されます。

1	sudo nginx -s リロード

これを行うには、まず構文の正確さを確認します。肯定的なフィードバックがある場合、新しい設定により、メインプロセスは新しいワークフローを開始し、同時に古いワークフローを停止します。構文を検証できない場合は、古い構成状態が保持されます。すべてのアクティブなリクエストが処理されると、すべてのアクティブなワークフローが終了します。

さらに、kill などのツールを使用して nginx プロセスをターゲットにすることもできます。必要なのは、/usr/local/nginx/logs ディレクトリまたは /var/run ディレクトリの nginx.pid ファイルにある、対応するプロセス ID だけです。たとえば、メインプロセスの ID が 1628 の場合、kill シグナルと quit シグナルを順番に使用して終了できます。

1	sudo kill -s quit 1628

サーバープログラム ps を使用して、実行中のすべての nginx プロセスのリストを表示することもできます。

1	sudo ps -ax \| grep nginx

静的コンテンツの配信を規制する方法

画像、ビデオ、静的 HTML コンテンツなどのファイルを配信するには、Web サーバーを使用することが多いでしょう。効率を高めるには、コンテンツタイプごとに異なるローカルディレクトリを選択するのが最善です。まず、サンプルディレクトリ /data/html を作成し、その中にサンプル HTML ドキュメントindex.html を配置します。次に、いくつかのサンプル画像を含むフォルダー /data/images を作成します。

次のステップでは、これら 2 つのディレクトリをサーバーブロックディレクティブに保存することによって構成ファイルに入力する必要があります。サーバーブロックディレクティブは、HTTP ブロックディレクティブのサブディレクティブです。さまざまなディレクティブがデフォルトで設定されています。最初に (off) でそれらをオフにすることができます。次に、別のサーバーブロックステートメントを作成するだけです。

1
2
3
4

http { サーバー { } }

このサーバーブロックでは、画像と HTML ドキュメントを含む 2 つのディレクトリを指定する必要があります。対応する結果は次のとおりです。

1
2
3
4
5
6
7
8
9

サーバー { 場所 / { ルート /data/html; } 場所 /images/ { ルート /data; } }

この構成は、ポート 80 でリッスンし、ローカルホスト経由でアクセスできるサーバーのデフォルトです。/images/ で始まる URI を持つすべてのリクエストは、/data/images ディレクトリのファイルをリクエストするようになります。適切なファイルが存在しない場合は、エラーメッセージが表示されます。URI が /images/ で始まらないすべての nginx イベントは、/data/html ディレクトリに配信されます。

変更を適用するには、nginx をリロードまたは再起動することを忘れないでください。

単純な Nginx プロキシサーバーをセットアップする

Nginx は、受信リクエストのプロキシサーバーを実行するために (実際のサーバーの代わりに) よく使用されます。さまざまな基準に従ってそれらをフィルタリングし、転送し、適切な応答をクライアントに渡します。キャッシングプロキシは特に人気があります。これらは、ローカルに保存された静的コンテンツを直接提供し、それ以降のすべてのリクエストのみをサーバーに転送します。ファイアウォールプロキシも一般的で、安全でない接続や不要な接続を除外します。以下は、要求されたイメージをローカルディレクトリから取得し、それ以降のすべての要求を Web サーバーに転送するキャッシュプロキシの例です。

最初のステップとして、nginx.conf でマスターサーバーを定義する必要があります。

1
2
3
4
5
6
7

サーバー { リッスン 8080; ルート/data/up1; 場所 / { } }

前の例とは異なり、受信リクエストにはポート 8080 (標準ポートではなく) が使用されるため、list ディレクティブが使用されます。また、ターゲットディレクトリ /data/up1 を作成し、そこにindex.html ページをファイルする必要があります。

次に、プロキシサーバーとその画像コンテンツを配信する機能が定義されます。これは、プライマリサーバープロトコル (http)、名前 (localhost)、およびポート (8080) の詳細を含む ProxyPass ディレクティブを使用して実行されます。

1
2
3
4
5
6
7
8
9

サーバー { 場所 / { proxy_pass http://localhost:8080; } location ~ \.(gif|jpg|png) $ { root /data/images; } }

2 番目の location ブロックは、URI が .gif、.jpg、.png などの一般的な画像ファイルで終わる場合、ローカルの /data/images ディレクトリから適切なコンテンツを取得することですべてのリクエストに応答するようにプロキシサーバーに指示します。他のすべてのリクエストはマスターサーバーに転送されます。前のセットアップと同様に、リロード信号をメインプロセスに渡すか、nginx を再起動して、イメージプロキシを保存します。