仮想プライベートサーバーでNginxWebサーバーを構成する方法

getdocs

2年前

ステータス：非推奨

この記事では、サポートされなくなったバージョンのUbuntuについて説明します。現在Ubuntu12.04を実行しているサーバーを運用している場合は、サポートされているバージョンのUbuntuにアップグレードまたは移行することを強くお勧めします。

理由： Ubuntu 12.04は2017年4月28日に保守終了（EOL）に達し、セキュリティパッチまたはアップデートを受信しなくなりました。このガイドはもう維持されていません。

代わりに参照してください：
このガイドは参考として役立つかもしれませんが、他のUbuntuリリースでは機能しない可能性があります。可能な場合は、使用しているUbuntuのバージョン用に作成されたガイドを使用することを強くお勧めします。ページ上部の検索機能を使用して、より新しいバージョンを見つけることができます。

Nginxとは何ですか？

Nginxは、Webサーバーおよびリバースプロキシサーバーです。それは広く採用されており、他の多くの一般的なオプションに取って代わっています。

Nginxは強力なツールですが、その構成は、他のサーバーからのユーザーや、一般的にWebサーバーを初めて使用するユーザーにとっては威圧的です。このガイドでは、メインのNginx構成ファイルを調べ、構文とオプションのいくつかをわかりやすく説明します。

Ubuntu 12.04インストールを使用しますが、ほとんどのディストリビューションは同様のファイルの場所で構成されます。

Nginx構成ディレクトリ階層

Nginxは、構成ファイルを「/ etc/nginx」ディレクトリに保存します。

このディレクトリ内には、いくつかのディレクトリとさまざまなモジュラー構成ファイルがあります。

cd /etc/nginx
ls -F

conf.d/         koi-win           naxsi.rules   scgi_params       uwsgi_params
fastcgi_params  mime.types        nginx.conf    sites-available/  win-utf
koi-utf         naxsi_core.rules  proxy_params  sites-enabled/

Apacheを使用している場合は、「sites-available」および「sites-enabled」ディレクトリはおなじみです。

これらのディレクトリは、Webサイトの構成を定義するために使用されます。ファイルは通常、「sites-available」ディレクトリに作成され、公開の準備ができたら「sites-enabled」ディレクトリにシンボリックにリンクされます。

「conf.d」ディレクトリは、サイトの構成にも使用できます。「.conf」で終わるこのディレクトリ内のすべてのファイルは、Nginxの起動時に構成に読み込まれるため、すべてのファイルが有効なNginx構成構文を定義していることを確認してください。

「/etc/ nginx」ディレクトリ内の他のほとんどのファイルには、特定のプロセスまたはオプションのコンポーネントの構成の詳細が含まれています。

ただし、「nginx.conf」ファイルがメインの構成ファイルです。このファイルについて詳しく説明します。

nginx.confファイルの探索

nginx.confファイルはNginxのメインコントロールポイントです。このファイルは、他のすべての適切な構成ファイルを読み込み、サーバーの起動時にそれらをモノリシック構成ファイルに結合します。

ファイルを開いて、一般的な形式について説明します。

sudo nano /etc/nginx/nginx.conf

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
        worker_connections 768;
        # multi_accept on;
}

http {
. . .

最初の数行は、Nginxがどのように動作するかについてのいくつかの一般的な事実を定義するために使用されます。

たとえば、サーバーは「userwww-data」行によって実行するユーザーを決定します。これはUbuntuの典型的なWebサーバーユーザーです。

「pid」ディレクティブは、内部参照のためにプロセスpidが格納される場所を指定します。「worker_processes」は、Nginxが使用する同時プロセスの数を定義します。

構成ファイルのこの部分には、「error_log」ディレクティブを使用したエラーログの場所などを含めることもできます。

ファイルの次のセクションはイベントセクションです。これは、Nginxが接続を処理する方法を制御する特別な場所です。この例では、このセクションでは何も調整する必要がないため、次に進みます。

次のセクションはhttpブロックです。これは、Nginx構成ファイルがどのようにフォーマットされるかについてのより複雑な議論につながります。

Nginx構成ファイルのレイアウト

Nginx構成ファイルは「ブロック」で管理されます。

最初に見たブロックはイベントブロックでした。次はhttpブロックで、構成ファイル内のメイン階層の開始です。

httpブロック内の構成の詳細は階層化されており、囲まれたブロックは、それらが配置されているブロックからプロパティを継承します。 Nginxの一般的な構成のほとんどは、サーバーブロックを格納するhttpブロックで行われ、サーバーブロックにはロケーションブロックが含まれます。

重要な部分は、構成の詳細を、それらが適用される最も高いコンテナーに常に配置する必要があるということです。つまり、パラメーターXをすべてのサーバーブロックに適用する場合は、パラメーターXをhttpブロック内に配置すると、パラメーターXがすべてのサーバー構成に伝播されます。

私たちのファイルを見ると、ソフトウェアが全体としてどのように機能するかを指示する多くのオプションがあることに気付くでしょう。これは、これらの種類のディレクティブに適した場所です。

たとえば、次の行でファイル圧縮オプションを設定します。

gzip on;
gzip_disable "msie6";

これは、クライアントに送信されるデータを圧縮するためにgzipを有効にするように、Nginxに指示しますが、クライアントがInternet Explorerバージョン6の場合、そのブラウザーはgzip圧縮を理解しないため、gzip圧縮を無効にします。

一部のサーバーブロックに対して異なる値を持つ必要があるオプションがある場合は、それらをより高いレベルで指定してから、サーバーブロック内でそれらをオーバーライドできます。 Nginxは、設定に適用される最低レベルの仕様を採用します。

可能な限り最高レベルで設定を適用するこのスタイルにより、複数の同一の宣言を管理する必要がなくなります。また、「サーバー」ブロックレベル以下で何かを宣言するのを忘れた場合に使用できるデフォルトを提供するという利点もあります。

「nginx.conf」ファイルでは、「http」ブロックの最後に次の情報が含まれていることがわかります。

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

これは、特定のサイトとURLの一致場所を定義するサーバーと場所のブロックがこのファイルの外部で行われることを示しています。

これにより、新しいサイトにサービスを提供したいときに新しいファイルを作成できるモジュラー構成の配置を維持できます。これにより、ほとんどの状況で変更されない詳細を非表示にしながら、関連するコンテンツをグループ化できます。

次のセクションで個々のサイト構成を調べることができるように、「nginx.conf」ファイルを終了します。

デフォルトのサーバーブロックの調査

Nginxはサーバーブロックを使用して、Apacheの仮想ホストにある機能を実現します。サーバーブロックは、サーバーがホストできる個々のWebサイトの仕様と考えてください。

「sites-available」ディレクトリにある、含まれているデフォルトのサーバーブロック構成を確認します。このファイルには、デフォルトのWebページを提供するために必要なすべての情報が含まれています。

cd sites-available
sudo nano default

server {
	root /usr/share/nginx/www;
	index index.html index.htm;

	server_name localhost;

	location / {
		try_files $uri $uri/ /index.html;
	}

	location /doc/ {
		alias /usr/share/doc/;
		autoindex on;
		allow 127.0.0.1;
		deny all;
	}
}

デフォルトのファイルは非常によくコメントされていますが、スペースを節約し、サイトの定義がいかに簡単であるかを示すために、ここでコメントを削除しました。

開き括弧と関連する閉じ括弧の間のすべてを含むサーバーブロックがあります。

server {
	. . .
}

このブロックは、前のセクションで説明したように、「include」ディレクティブを使用して、httpブロックの終わり近くの「nginx.conf」ファイルに配置されます。

「root」ディレクティブは、Webサイトのコンテンツが配置されているディレクトリを定義します。これは、Nginxがブラウザによって要求されたファイルの検索を開始する場所です。デフォルトのWebサイトは、「/ usr / share / nginx/www」でコンテンツを検索します。

各行がセミコロン（;）で終わっていることに注目してください。これにより、Nginxは、1つのディレクティブが終了し、次のディレクティブが開始されることを認識します。セミコロンを忘れないでください。そうしないと、Nginxは後続の行をディレクティブへの追加の引数として扱います。セミコロンに達するまでこれを行います。

次の行には、「index」ディレクティブが含まれています。

これにより、ドメインに提供されるデフォルトのページが構成されます。ページが要求されなかった場合、サーバーブロックは「index.html」というファイルを検索して返します。そのファイルが見つからない場合は、「index.htm」というファイルを提供しようとします。

server_nameディレクティブの使用

「server_name」ディレクティブには、このサーバーブロックから提供されるドメイン名のリストが含まれています。スペースで区切って、好きなだけ名前を含めることができます。

サーバー名の最初または最後にあるアスタリスク文字を、すべてに一致するワイルドカードとして使用することもできます。たとえば、「*。example.com」は「forum.example.com」と「animals.example.com」のリクエストに一致します。

要求されたURLが複数の「server_name」ディレクティブに一致する場合、最初に完全に一致するものを選択します。完全に一致するものがない場合は、アスタリスクで始まる最長のワイルドカード名が選択されます。

それでも一致するものが見つからない場合は、アスタリスクで終わる最長の一致するワイルドカード名を探します。これらのいずれも見つからない場合は、最初に一致する正規表現の一致を返します。

一致する正規表現を使用するサーバー名は、チルダ（〜）文字で始まります。正規表現は非常に強力ですが、この記事の範囲外です。

ロケーションブロックの使用

構成ファイルの次の部分は、ロケーションブロックを開きます。ロケーションブロックは、サーバー内で特定のリソース要求を処理する方法を指定するために使用されます。

「location/」の行は、括弧内のディレクティブが、他のロケーションブロックと一致しないクライアントによって要求されたすべてのリソースに適用されることを指定します。

ロケーションブロックには、ファイルのさらに下で指定された「/ doc /」パスのようなURIパスを含めることができ、ロケーションとURIの間に等号（=）を付けて完全一致を指定するか、チルダ（〜）文字を使用して正規表現を示すことができます。式が一致します。

プレーンなチルダは大文字と小文字を区別する一致を示し、チルダとそれに続くアスタリスク（〜*）は大文字と小文字を区別しない一致を意味し、カラット（^〜）が前に付いたチルダは、uriがこの場所に一致する場合、正規表現検索を実行しないようにNginxに指示します。

Nginxには、使用するブロックを決定するための明確に定義されたプロセスがあるという点で、ロケーションマッチングはserver_nameマッチングに似ています。

クエリが等号の場所と一致する場合、その場所が使用され、検索が停止します。そうでない場合は、通常のリテラルuriの場所が検索されます。カラットチルダ（^〜）が使用され、URIの場所が一致する場合、このブロックが選択されます。

そのオプションが使用されていない場合、最も具体的な一致が選択され、値が保持されます。次に、正規表現のマッチングを実行して、これらのパターンのいずれかに一致するかどうかを確認します。見つかった場合は、正規表現ブロックが使用されます。そうでない場合は、以前に一致したuriの場所が使用されます。

要約すると、Nginxは完全一致、正規表現一致、リテラルURI一致を優先しますが、リテラルURI一致は、それらの前に「^〜」を付けることで明示的に重要にすることができます。

このリストは、これらの設定を定義します。

<ol>
	<li>Equal sign matches</li>
	<li>Literal URI matches with "^~"</li>
	<li>Most specific regular expression match</li>
	<li>Most specific literal URI match</li>
</ol>

これは紛らわしいように思えるかもしれませんが、Nginxがあいまいさなしに決定を下せるようにするには、これらの定義されたルールが必要です。

try_filesの使用方法

try_filesディレクティブは、リソース要求に対して行われる必要のある一連の試行を定義するための非常に便利なツールです。

これが意味するのは、一連の代替オプションを通じて、Nginxがリクエストを処理しようとする方法を宣言できるということです。

デフォルトの構成ファイルの例は次のとおりです。

try_files $uri $uri/ /index.html;

これは、そのロケーションブロックによって提供されているリクエストが行われると、Nginxは最初に文字通りのURIをファイルとして提供しようとすることを意味します。これは、要求されているリソースを保持する「$uri」変数を使用して宣言されます。

$ uriの値に一致するファイルがない場合は、uriをディレクトリとして使用しようとします。 uriディレクトリのデフォルトファイル（思い出すと、index.html）を提供しようとします。

$ uriの値に一致するディレクトリがない場合は、デフォルトのファイルを使用します。これは、サーバーブロックのルートディレクトリにある「index.html」ファイルです。各「try_files」ディレクティブは、最後のパラメーターをフォールバックのデフォルトとして使用するため、既知の実際のファイルである必要があります。

上記のパラメータが一致しない場合にファイルを返したくない場合のもう1つのオプションは、エラーページを返すことです。これは、等号とエラーコードを使用して実現されます。

たとえば、デフォルトの「index.html」ページを提供する代わりにリソースを見つけることができなかった場合に「location /」ブロックが404エラーを返すようにしたい場合は、最後のファイルを「=404」に置き換えることができます。

try_files $uri $uri/ =404;

これにより、ユーザーが存在しないリソースを要求した場合に、適切なエラーページがユーザーにスローされます。

追加オプション

構成ファイルの残りの部分には、他のいくつかの興味深いディレクティブが含まれています。

「alias」ディレクティブは、そのロケーションブロックのページを指定されたディレクトリから提供する必要があることをNginxに通知します。これらはルートディレクトリの外にある可能性があります。

この例では、「/doc/」内でリクエストされたリソースは「/usr/ share /doc/」から提供されます。

「autoindexon」ディレクティブを使用すると、Nginxは指定された場所のディレクトリリストを生成できます。これは、ディレクトリが要求されたときに返されます。

「許可」と「拒否」の行は、ディレクトリのアクセス制御を設定します。ファイルの行により、ユーザーがローカルサーバーから場所にアクセスしようとしたときにコンテンツを読み取ることができます。

結論

Nginxは、その機能の一部に異なる用語を使用していますが、多くの構成オプションを備えた非常に有能なサーバーです。

Nginx Webサーバーを適切に構成する方法を学ぶことで、非常に強力でリソースが非常に少ないソフトウェアを最大限に活用できるようになります。これにより、あらゆるサイズのWebサイトに最適です。

ジャスティン・エリングウッド