序章


Webサイトまたはアプリケーションを起動して実行するときに、いくつかの選択を行う必要があります。 場合によっては、要件が変更されたり、新しいテクノロジーが実行可能になったり、ユーザーベースが予期せず膨らんだりします。 理由に関係なく、変更を検討する可能性のあるアプリケーションスタックのコンポーネントの1つはWebサーバーです。

Apache Webサーバーは現在世界で最も人気のあるWebサーバーですが、Nginxは急速に普及しています。 Nginxが少数のリソースを使用しながら優れたパフォーマンスを発揮することを考えると、これは驚くべきことではありません。 多くのWebサイトでは、Nginxに移行するとパフォーマンスが向上します。

このガイドでは、Ubuntu12.04VPSでWebサイトをApacheからNginxに移行する方法について説明します。 私たちは提案の中で一般的なままでいるように努めますが、あなたがあなた自身の目的のために微調整する必要があるかもしれないいくつかの領域についてのヒントをあなたに与えるでしょう。

このガイドは、このチュートリアルを使用してLAMP(Linux、Apache、MySQL、およびPHP)スタックをインストールしていることを前提としています。 ドロップレットを作成するときにワンクリックのLAMPイメージを選択しただけの場合、サーバーにもこの構成が適用されます。

Nginxをインストールします


Webサイトの移行を開始するために最初に行うことは、新しいサーバーソフトウェアをインストールすることです。 これにより、ガイダンスとして現在のApache構成ファイルを確認して、新しいサーバーを構成できるようになります。

幸い、NginxはデフォルトでUbuntuリポジトリに存在します。 今すぐインストールしましょう:

sudo apt-get update
sudo apt-get install nginx

私たちのユースケースで非常に重要になる実装の詳細の1つは、Nginxが動的処理を別のプロセスにオフロードすることです。 これにより、Nginxは無駄のない高速な状態を維持できます。 モジュールを介してPHPサポートを追加しようとせずに、コア機能に集中できます。 代わりに、その目的のために構築されたアプリケーションにそれをオフロードするだけです。

これはすべてこの時点で言及されており、PHPスクリプトを処理するためにPHPハンドラーもインストールする必要があると言っています。 標準的な選択はphp5-fpmで、これはNginxでうまく機能します。

sudo apt-get install php5-fpm

サイトをNginxに切り替えるために必要なすべてのソフトウェアが必要です。 Apacheが実行されていた構成をエミュレートするようにソフトウェアを構成する必要があります。

テストNginx構成をセットアップする


現在Apacheを実行しているので、回避できる場合は、移行中もサイトが引き続き機能するように、Apacheとは別にNginxサーバーを構成します。

これは、変更を確定する準備ができるまで、代替ポートでNginxをテストするのと同じくらい簡単です。 このようにして、2つのサーバーを同時に実行できます。

デフォルトのNginxサイトの構成ファイルを開くことから始めます。

sudo nano /etc/nginx/sites-available/default

server {セクションで、listenディレクティブを追加して、ポート80(Apacheが引き続きリクエストを処理するために使用している)以外のポートでリッスンするようにNginxに指示します。 このチュートリアルでは、ポート8000を使用します。

server {

    listen 8000;
    . . .
    . . .

ファイルを保存して閉じます。 これは、Nginxサーバーにアクセスできることを確認するためにスポットチェックを行う良い機会です。 これをテストするには、Nginxを起動します。

sudo service nginx start

デフォルトのNginx構成にアクセスするために構成したポート番号を使用します。 これをブラウザに入力します。

http://your_ip_or_domain:8000

DigitalOcean Nginx default page

Apacheインスタンスは引き続きデフォルトのポート80で実行されているはずです。 これは、最後に:8000を付けずにサイトにアクセスすることでも確認できます(この例では、デフォルトのApacheページを提供しているだけです。 Webサイトを構成した場合は、代わりにここに表示されます):

http://your_ip_or_domain

DigitalOcean Apache default page

Apache構成を翻訳する


両方のサーバーが稼働しているので、Nginxで使用するためにApache構成の移行と変換を開始できます。 これは手動で行う必要があるため、Nginxがどのように構成されているかを理解することが重要です。

このタスクは主に、Apache仮想サーバーに類似したNginxサーバーブロックの作成になります。 Apacheはこれらのファイルを/etc/apache2/sites-available/に保持し、Nginxはそれに続き、Ubuntuの/etc/nginx/sites-available/にサーバーブロック宣言を保持します。

仮想サーバー宣言ごとに、サーバーブロックを作成します。 Apacheファイルを調べると、おそらく次のような仮想ホストが見つかります。

<VirtualHost *:80>
    ServerAdmin webmaster@your_site.com
    ServerName your_site.com
    ServerAlias www.your_site.com

    DocumentRoot /var/www

    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>

    <Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
    </Directory>

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    LogLevel warn
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>
</VirtualHost>

この構成を使用して、Nginxサーバーブロックの構築を開始できます。

/etc/nginx/sites-available/ディレクトリで、前に編集したファイルを開いてNginxポートを宣言します。

sudo nano /etc/nginx/sites-available/default

今のところコメントされた行を無視すると、次のようになります。

server {
    listen 8000;

    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;
    }
}

Apacheの構成に対応していると思われる項目のいくつかがすでに表示され始めているはずです。 一般的に、主なディレクティブは次のように変換されます。

Apache                                 Nginx
------                                 ------

<VirtualHost *:80>                     server {
                                            listen 80;

ServerName yoursite.com
ServerAlias www.yoursite.com           server_name yoursite.com www.yoursite.com;

DocumentRoot /path/to/root             root /path/to/root;

AllowOverride All                      (No Available Alternative)

DirectoryIndex index.php               index index.php;

ErrorLog /path/to/log                  error_log /path/to/log error;

CustomLog /path/to/log combined        access_log /path/to/log main;

Alias /url/ "/path/to/files"           location /url/ {
<Directory "/path/to/files">                 alias /path/to/files;

上から仮想ホストファイルの機能をエミュレートするサーバーブロックを作成する場合、次のようになります。

server {
    listen 8000;   # We're deliberately leaving this as-is to avoid conflict at the moment

    root /var/www;
    server_name your_site.com www.your_site.com;

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

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

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

    location ~/\.ht {
        deny all;
    }

}

いくつかの項目を削除し、説明する必要のある行をいくつか追加しました。

まず、エラーログ行が構成から削除されました。 これは、/etc/nginx/nginx.confファイルですでに定義されているためです。 これにより、使用するデフォルトが提供されます。

また、Nginxはその情報をエラーページに埋め込まないため、ServerAdminディレクティブを削除しました。

PHPの処理も少し変更されました。 PHPはNginxで個別に処理されるため、これらのファイルを以前にインストールしたphp-fpmプログラムに渡します。 これはソケットを介して実装されます(これは一時的に構成する必要があります)。

ドキュメントセクションは、Nginxドキュメントを反映するように変更されています。 それ以外はかなり同じように機能します。

最後に、ディレクトリ内の.htaccessまたは.htで始まる他のファイルへのアクセスを拒否するようにNginxを構成します。 これらはApache固有の構成ファイルであり、Nginxでは機能しません。 これらの構成ファイルを公開しない方が安全です。

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

これらの変更を認識するために、Nginxサーバーを再起動する必要があります。

sudo service nginx restart

PHP-FPMを構成する


ほとんどのNginx構成が邪魔にならないので、指定したチャネルを使用して通信するようにphp-fpm構成を変更する必要があります。

まず、php.iniファイルを変更して、ファイルが安全に提供されないようにする必要があります。

sudo nano /etc/php5/fpm/php.ini

変更する必要のある行は、不完全な一致があるかどうかを推測するのではなく、要求された正確なファイルを提供するためにPHPを必要とします。 これにより、PHPが、PHPハンドラーの弱点を調査している誰かに機密データを提供したり公開したりするのを防ぐことができます。

cgi.fix_pathinfoディレクティブを指定する行を見つけて、次のように変更します。

cgi.fix_pathinfo=0

このファイルを保存して終了します。

次に、php-fpmがサーバーに接続する方法を変更します。 このファイルをエディターで開きます。

sudo nano /etc/php5/fpm/pool.d/www.conf

listenディレクティブを見つけて変更し、サーバーブロック構成ファイルに入力した値と一致させます。

listen = /var/run/php5-fpm.sock

多くのPHPリクエストの処理で問題が発生した場合は、ここに戻って、一度に生成できる子プロセスの数を増やすことをお勧めします。 変更する行は次のとおりです。

pm.max_children = Num_of_children

このファイルを保存して閉じます。

これで、php-fpmプログラムが正しく構成されているはずです。 変更を反映させるには、再起動する必要があります。

sudo service php5-fpm restart

Nginxを再起動しても問題はありません。

sudo service nginx restart

ルートディレクトリにあるPHPファイルが正しく機能することをテストします。 PHPファイルをApacheの場合と同じように実行できるはずです。

UbuntuLAMPチュートリアルで作成したinfo.phpファイルにアクセスすると、次のようにレンダリングされます。

http://your_ip_or_domain:8000/info.php

DigitalOcean Nginx PHP files

PHP変数セクションで、Nginxが「SERVER_SOFTWARE」変数としてリストされているはずです。

DigitalOcean Nginx server software

Nginxサイトをライブに移行する


広範なテストを行った後、サイトをApacheからNginxにシームレスに移行してみることができます。

これは、これらのサーバーのどちらも、再起動するまで変更を実装しないために可能です。 これにより、すべてをセットアップしてから、スイッチを瞬時に切り替えることができます。

実際、私たちがする必要があるのは、Nginxサーバーブロックのポートを変更することだけです。 今すぐファイルを開きます。

sudo nano /etc/nginx/sites-available/default

ポートをデフォルトのポート80に戻します。 これにより、再起動するとすぐに通常のHTTPトラフィックの受け入れを開始できます。

server {
    # listen 8000;
    listen 80;
    . . .

ファイルを保存して閉じます。

一部のサイトのみをNginxに移行し、Apacheから一部のコンテンツを引き続き提供する場合は、ポート80でリクエストを提供するApache仮想サーバーを無効にする必要があります。 これは、競合を回避するために必要です。 これが正しく行われないと、ポートがすでに使用されているため、Nginxは起動に失敗します。

Apacheの実行を継続することを計画している場合は、これらのファイルと場所でポート80の使用状況を確認してください。

/etc/apache2/ports.conf
/etc/apache2/apache2.conf
/etc/apache2/httpd.conf
/etc/apache2/sites-enabled/  ## Search all sites in this directory

必要なすべてのポートを変更したことを確認したら、次のように両方のサービスを再起動できます。

sudo service apache2 reload && sudo service nginx reload

Apacheはリロードし、ポート80を解放する必要があります。 その後すぐに、Nginxはリロードして、そのポートでの接続の受け入れを開始する必要があります。 すべてが順調に進んだ場合、サイトはNginxによって提供されるはずです。

サイトの一部を提供するためにApacheを使用する予定がない場合は、代わりにWebプロセスを完全に停止できます。

sudo service apache2 stop && sudo service nginx reload

Apacheを使用しなくなった場合は、この時点でApacheファイルをアンインストールできます。 次のように入力すると、Apache関連のファイルを簡単に見つけることができます。

dpkg --get-selections | grep apache

apache2						    install
apache2-mpm-prefork				install
apache2-utils					install
apache2.2-bin					install
apache2.2-common				install
libapache2-mod-auth-mysql		install
libapache2-mod-php5				install

その後、apt-getを使用してそれらをアンインストールできます。 例えば:

sudo apt-get remove apache2 apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common libapache2-mod-auth-mysql libapache2-mod-php5

不要になったすべての依存関係パッケージを削除することもできます。

sudo apt-get autoremove

移行の合併症


Nginxに切り替えようとすると、混乱を招く可能性のあるApacheの世界で一般的なことがいくつかあります。

翻訳と.htaccessファイルを書き直します


最も基本的な違いの1つは、Nginxがディレクトリオーバーライドを尊重しないことです。

Apacheは、ロケーションブロックでAllowOverride Allディレクティブとともに.htaccessファイルを使用します。 これにより、ファイルを格納するディレクトリにディレクトリ固有の構成を配置できます。

Nginxはこれらのファイルを許可しません。 提供されているファイルで構成を収容することは、構成を誤った場合にセキュリティの問題になる可能性があり、一元化された構成ファイルを確認するのは簡単で、設定が.htaccessファイルによって上書きされていることに気づきません。

その結果、アクティブな.htaccessファイルにリストしたすべての構成は、そのホストのサーバーブロック構成のロケーションブロック内に配置する必要があります。 これは一般的にこれ以上複雑ではありませんが、仮想ホスト定義の場合と同じようにこれらのルールを変換する必要があります。

.htaccessファイルに保持する一般的なものは、Apacheのmod_rewriteモジュールのルールです。これは、コンテンツのアクセスURLをよりユーザーフレンドリーに変更します。 Nginxには、類似しているが異なる構文を使用する書き換えモジュールがあります。 残念ながら、NginxでURLを書き換えることは、このガイドの範囲外です。

モジュールと外部構成の複雑さ


覚えておくべきもう1つのことは、有効にしたApacheモジュールが提供している機能を意識する必要があるということです。

簡単な例はdirモジュールです。 有効にすると、仮想ホストファイルに次のような行を配置することで、Apacheがディレクトリインデックスとして機能しようとするファイルの順序を指定できます。

DirectoryIndex index.html index.htm

この行は、この仮想ホストで発生する処理を決定します。 ただし、この行が存在せず、dirモジュールが有効になっている場合、提供されるファイルの順序は次のファイルによって決定されます。

sudo nano /etc/apache2/mods-enabled/dir.conf

<IfModule mod_dir.c>

          DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm

</IfModule>

これを提起するポイントは、モジュール、またはあらゆる種類の外部ソース構成が、舞台裏で明示的に実行する必要がある何かを実行している可能性があることに注意する必要があるということです。 Nginx。

この例では、これをサーバーブロックに追加することで、Nginxでディレクトリインデックスの順序を指定できます。

server {
    . . .
    index index.php index.html index.htm;
    . . .

これを覚えておくことが重要です。

複雑なサイト構成を移行する場合に役立つ可能性のあることの1つは、個別にソースされたすべての構成ファイルを1つのモノリシックファイルにコピーして貼り付け、各行を体系的に調べて変換することです。

これは頭痛の種かもしれませんが、実稼働サーバーの場合、特定できない奇妙な動作の原因を突き止めるのに多くの時間を節約できます。

結論


ApacheからNginxへの移行の複雑さは、特定の構成の複雑さにほぼ完全に依存しています。 Nginxは、Apacheが処理できるほとんどすべてのものを処理でき、より少ないリソースで処理できるという利点があります。 これは、サイトがより多くのユーザーにスムーズにサービスを提供できることを意味します。

移行はすべてのサイトにとって意味があるわけではなく、Apacheは多くのプロジェクトのニーズに適切に対応する優れたサーバーですが、Nginxを使用するとパフォーマンスが向上したりスケーラビリティが向上したりする場合があります。 それでもApacheが必要な場合は、別の方法としてNginxをApacheサーバーのリバースプロキシとして使用する。 このアプローチでは、両方のサーバーの長所を強力な方法で活用できます。