TOC

Ubuntu 16.04でNginxサーバーブロック（仮想ホスト）をセットアップする方法

前書き

Nginx Webサーバーを使用する場合、server blocks（Apacheの仮想ホストと同様）を使用して、構成の詳細をカプセル化し、単一のサーバーから複数のドメインをホストできます。

このガイドでは、Ubuntu 16.04サーバー上のNginxでサーバーブロックを構成する方法について説明します。

前提条件

このチュートリアルでは、sudo権限を持つroot以外のユーザーを使用します。 このようなユーザーが構成されていない場合は、Ubuntu 16.04 initial server setupガイドに従って作成できます。

また、サーバーにNginxをインストールする必要があります。 次のガイドでこの手順を説明しています。

これらの要件を満たしたら、このガイドを続行できます。

設定例

デモンストレーションのために、Nginxサーバーで2つのドメインをセットアップします。 このガイドで使用するドメイン名は、example.comとtest.comです。

DigitalOceanhereを使用してドメイン名を設定する方法に関するガイドを見つけることができます。 予備のドメイン名が2つない場合は、今のところダミー名を使用してください。構成をテストするためにローカルコンピューターを構成する方法については後で説明します。

ステップ1：新しいドキュメントルートディレクトリを設定する

デフォルトでは、Ubuntu 16.04のNginxにはデフォルトで1つのサーバーブロックが有効になっています。 /var/www/htmlのディレクトリからドキュメントを提供するように構成されています。

これは単一のサイトではうまく機能しますが、複数のサイトを提供する場合は追加のディレクトリが必要です。 /var/www/htmlディレクトリは、クライアントのリクエストが他のどのサイトとも一致しない場合に提供されるデフォルトのディレクトリと見なすことができます。

各サイトの/var/www内にディレクトリ構造を作成します。 実際のWebコンテンツは、これらのサイト固有のディレクトリ内のhtmlディレクトリに配置されます。 これにより、必要に応じて、htmlディレクトリの兄弟としてサイトに関連付けられた他のディレクトリを作成するための追加の柔軟性が得られます。

サイトごとにこれらのディレクトリを作成する必要があります。 -pフラグは、途中で必要な親ディレクトリを作成するようにmkdirに指示します。 

sudo mkdir -p /var/www/example.com/html
sudo mkdir -p /var/www/test.com/html

ディレクトリができたので、通常のユーザーアカウントにWebディレクトリの所有権を再割り当てします。 これにより、sudoなしでそれらに書き込むことができます。

Note

[.note]＃必要に応じて、www-dataユーザーに特定のアクセスを許可するために、フォルダーのアクセス許可または所有権を再度調整する必要がある場合があります。 たとえば、動的なサイトでは多くの場合これが必要になります。 特定の許可と所有権の要件は、構成によって異なります。 使用している特定のテクノロジーの推奨事項に従ってください。
＃

$USER環境変数を使用して、現在サインインしているアカウントに所有権を割り当てることができます（rootとしてログインしていないことを確認してください）。 これにより、このディレクトリのコンテンツを簡単に作成または編集できます。 

sudo chown -R $USER:$USER /var/www/example.com/html
sudo chown -R $USER:$USER /var/www/test.com/html

umask値を変更していない場合、Webルートのアクセス許可はすでに正しいはずですが、次のように入力することで確認できます。 

sudo chmod -R 755 /var/www

これでディレクトリ構造が構成され、先に進むことができます。

ステップ2：各サイトのサンプルページを作成する

ディレクトリ構造が設定されたので、表示するものがあるように、各サイトのデフォルトページを作成しましょう。

最初のドメインにindex.htmlファイルを作成します。 

nano /var/www/example.com/html/index.html

ファイル内に、現在アクセスしているサイトを示す非常に基本的なファイルを作成します。 これは次のようになります。

/var/www/example.com/html/index.html


    
        Welcome to Example.com!
    
    
        
Success!  The example.com server block is working!

完了したら、ファイルを保存して閉じます。

2番目のサイトのファイルは基本的に同じになるため、次のように2番目のドキュメントルートにコピーできます。 

cp /var/www/example.com/html/index.html /var/www/test.com/html/

これで、エディターで新しいファイルを開くことができます。 

nano /var/www/test.com/html/index.html

2番目のドメインを参照するように変更します。

/var/www/test.com/html/index.html


    
        Welcome to Test.com!
    
    
        
Success!  The test.com server block is working!

終了したら、このファイルを保存して閉じます。 これで、2つのドメインの訪問者に表示するページがいくつかできました。

ステップ3：ドメインごとにサーバーブロックファイルを作成する

提供したいコンテンツができたので、Nginxにこれを行う方法を伝えるサーバーブロックを実際に作成する必要があります。

デフォルトでは、Nginxにはdefaultと呼ばれる1つのサーバーブロックが含まれており、これを独自の構成のテンプレートとして使用できます。 最初のドメインのサーバーブロックを設計することから始め、それを2番目のドメインにコピーして必要な変更を加えます。

最初のサーバーブロックファイルを作成する

上記のように、デフォルトファイルをコピーして、最初のサーバーブロック構成ファイルを作成します。 

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com

次に、作成した新しいファイルをsudo権限でテキストエディタで開きます。 

sudo nano /etc/nginx/sites-available/example.com

コメント行を無視すると、ファイルは次のようになります。

/etc/nginx/sites-available/example.com

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                try_files $uri $uri/ =404;
        }
}

まず、listenディレクティブを調べる必要があります。 Only one of our server blocks on the server can have the default_server option enabled.これは、要求されたserver_nameが使用可能なサーバーブロックのいずれとも一致しない場合に、どのブロックが要求を処理するかを指定します。 訪問者はドメイン名を介してサイトにアクセスするため、これは現実のシナリオではあまり頻繁には発生しません。

listenディレクティブにdefault_serverオプションを含めることにより、サイトの1つを「デフォルト」として指定するか、デフォルトのサーバーブロックを有効のままにして、％のコンテンツを提供するかを選択できます。 （t2）sディレクトリ（要求されたホストが見つからない場合）。

このガイドでは、一致しないリクエストを処理するためにデフォルトのサーバーブロックをそのままにして、このサーバーブロックと次のサーバーブロックからdefault_serverを削除します。 サーバーブロックのいずれかが意味をなすものにオプションを追加することを選択できます。

/etc/nginx/sites-available/example.com

server {
        listen 80;
        listen [::]:80;

        . . .
}

Note

[。注意]＃＃

次のように入力すると、default_serverオプションが単一のアクティブファイルでのみ有効になっていることを確認できます。 

grep -R default_server /etc/nginx/sites-enabled/

ファイル（左端の列に表示）以外でコメントされていない一致が見つかった場合、Nginxは無効な構成について文句を言います。

次に調整する必要があるのは、rootディレクティブで指定されたドキュメントルートです。 作成したサイトのドキュメントルートを指定します。

/etc/nginx/sites-available/example.com

server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;

}

次に、最初のドメインのリクエストに一致するようにserver_nameを変更する必要があります。 さらに、一致させたいエイリアスを追加できます。 示すために、www.example.comエイリアスを追加します。

終了すると、ファイルは次のようになります。

/etc/nginx/sites-available/example.com

server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

基本的な構成に必要なのはそれだけです。 ファイルを保存して閉じ、終了します。

2番目のサーバーブロックファイルを作成する

サーバーブロックの初期構成ができたので、これを2番目のファイルのベースとして使用できます。 それをコピーして新しいファイルを作成します。 

sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com

エディターでsudo特権で新しいファイルを開きます。 

sudo nano /etc/nginx/sites-available/test.com

繰り返しになりますが、すでに他の場所で使用している場合は、このファイルのlistenディレクティブにdefault_serverオプションを使用しないでください。 2番目のドメインのドキュメントルートを指すようにrootディレクティブを調整し、2番目のサイトのドメイン名と一致するようにserver_nameを調整します（エイリアスを含めるようにしてください）。

終了すると、ファイルは次のようになります。

/etc/nginx/sites-available/test.com

server {
        listen 80;
        listen [::]:80;

        root /var/www/test.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name test.com www.test.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

終了したら、ファイルを保存して閉じます。

ステップ4：サーバーブロックを有効にしてNginxを再起動する

サーバーブロックファイルができたので、それらを有効にする必要があります。 これを行うには、これらのファイルからsites-enabledディレクトリへのシンボリックリンクを作成します。これは、起動時にNginxが読み取ります。

次のように入力して、これらのリンクを作成できます。 

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/test.com /etc/nginx/sites-enabled/

これらのファイルは現在、有効なディレクトリにあります。 これで、3つのサーバーブロックが有効になり、listenディレクティブとserver_nameに基づいて応答するように構成されました（Nginxがこれらのディレクティブhereを処理する方法の詳細を読むことができます）。

  • example.com：example.comおよびwww.example.comの要求に応答します

  • test.com：test.comおよびwww.test.comの要求に応答します

  • default：他の2つのブロックと一致しないポート80の要求に応答します。

サーバー名を追加することで発生する可能性のあるハッシュバケットメモリの問題を回避するために、先に進み、/etc/nginx/nginx.confファイル内の単一の値を調整します。 今すぐファイルを開きます。 

sudo nano /etc/nginx/nginx.conf

ファイル内で、server_names_hash_bucket_sizeディレクティブを見つけます。 #記号を削除して、行のコメントを解除します。

/etc/nginx/nginx.conf

http {
    . . .

    server_names_hash_bucket_size 64;

    . . .
}

完了したら、ファイルを保存して閉じます。

次に、Nginxファイルに構文エラーがないことをテストして確認します。 

sudo nginx -t

問題が見つからなかった場合、Nginxを再起動して変更を有効にします。 

sudo systemctl restart nginx

これで、Nginxは両方のドメイン名を提供するはずです。

ステップ5：テスト用にローカルホストファイルを変更する（オプション）

所有するドメイン名を使用しておらず、代わりにダミー値を使用している場合、ローカルコンピューターの構成を変更して、Nginxサーバーブロック構成を一時的にテストできるようにすることができます。

これにより、他の訪問者がサイトを正しく表示できなくなりますが、各サイトに個別にアクセスして設定をテストすることができます。 これは基本的に、ドメイン名を解決するために通常DNSに送られる要求を傍受することで機能します。 代わりに、ドメイン名を要求するときにローカルコンピューターが移動するIPアドレスを設定できます。

Note

[.note]＃これらの手順では、VPSサーバーではなく、ローカルコンピューターで操作していることを確認してください。 これを行うには、rootアクセス権を持っているか、管理グループのメンバーであるか、システムファイルを編集できる必要があります。
＃

自宅のMacまたはLinuxコンピューターを使用している場合は、次のように入力して必要なファイルを編集できます。 

sudo nano /etc/hosts

Windowsを使用している場合は、ここでfind instructions for altering your hosts fileを実行できます。

サーバーのパブリックIPアドレスと、サーバーにルーティングするドメインを知る必要があります。 サーバーのパブリックIPアドレスが203.0.113.5であるとすると、ファイルに追加する行は次のようになります。

/etc/hosts

127.0.0.1   localhost
. . .

203.0.113.5 example.com www.example.com
203.0.113.5 test.com www.test.com

これにより、example.comとtest.comのリクエストがすべて傍受され、サーバーに送信されます。これは、使用しているドメインを実際に所有していない場合に必要なことです。

完了したら、ファイルを保存して閉じます。

ステップ6：結果をテストする

すべての設定が完了したので、サーバーブロックが正しく機能していることをテストする必要があります。 ウェブブラウザでドメインにアクセスすることでそれを行うことができます： 

http://example.com

次のようなページが表示されます。

Nginx first server block

2番目のドメイン名にアクセスすると、わずかに異なるサイトが表示されるはずです。 

http://test.com

Nginx second server block

これらのサイトが両方とも機能する場合、2つの独立したサーバーブロックをNginxで正常に構成しました。

この時点で、テストのためにローカルコンピューターのhostsファイルを調整した場合は、追加した行を削除することをお勧めします。

公開サイトのサーバーにドメイン名でアクセスする必要がある場合は、サイトごとにドメイン名を購入することをお勧めします。 ここでset them up to point to your serverの方法を学ぶことができます。

結論

これで、同じサーバーからホストするドメインごとにサーバーブロックを作成できるようになります。 ハードウェアがトラフィックを処理できる限り、作成できるサーバーブロックの数に実際の制限はありません。

Related