Поиск по сайту:

Как перейти с веб-сервера Apache на Nginx на Ubuntu VPS

Введение

Есть несколько вариантов, которые вы должны сделать при запуске веб-сайта или приложения. Иногда ваши требования меняются, новые технологии становятся жизнеспособными или ваша пользовательская база неожиданно увеличивается. Независимо от ваших причин, одним из компонентов вашего стека приложений, который вы можете изменить, является веб-сервер.

Хотя веб-сервер Apache в настоящее время является самым популярным веб-сервером в мире, Nginx быстро завоевывает позиции. Это неудивительно, учитывая, что Nginx отлично работает, используя мало ресурсов. Для многих веб-сайтов переход на Nginx улучшит производительность.

В этом руководстве мы обсудим, как перенести веб-сайт с Apache на Nginx на Ubuntu 12.04 VPS. Мы постараемся оставаться общими в наших предложениях, но дадим вам подсказки о некоторых областях, которые вам, возможно, придется настроить для ваших собственных целей.

В этом руководстве предполагается, что вы установили стек LAMP (Linux, Apache, MySQL и PHP) с помощью этого руководства. Если вы просто выбрали образ LAMP одним щелчком мыши при создании дроплета, ваш сервер также будет иметь эту конфигурацию.

Установите Nginx

Первое, что мы сделаем, чтобы начать миграцию наших веб-сайтов, — это установим наше новое серверное программное обеспечение. Это позволит нам настроить наш новый сервер, взглянув на наши текущие файлы конфигурации Apache.

К счастью, Nginx присутствует в репозиториях Ubuntu по умолчанию. Давайте установим его сейчас:

sudo apt-get update
sudo apt-get install nginx

Одна деталь реализации, которая становится очень важной в нашем случае использования, заключается в том, что Nginx переносит любую динамическую обработку в отдельный процесс. Это позволяет Nginx оставаться компактным и быстрым. Он может сосредоточиться на своих основных функциях, не пытаясь добавить поддержку PHP через модули. Вместо этого он просто разгружает это в приложение, созданное для этой цели.

Все это упоминается здесь, чтобы сказать, что нам также необходимо установить обработчик PHP для обработки PHP-скриптов. Стандартный выбор — php5-fpm, который хорошо работает с Nginx:

sudo apt-get install php5-fpm

У вас должно быть все программное обеспечение, необходимое для перевода вашего сайта на Nginx. Нам все еще нужно настроить наше программное обеспечение для эмуляции конфигурации, в которой работал Apache.

Настройка тестовой конфигурации Nginx

Поскольку в настоящее время у нас работает Apache, если мы можем этого избежать, мы хотели бы настроить наш сервер Nginx независимо от Apache, чтобы наш сайт продолжал работать во время перехода.

Это так же просто, как протестировать Nginx на альтернативном порту, пока мы не будем готовы закрепить наши изменения. Таким образом, мы можем запускать два сервера одновременно.

Начните с открытия файла конфигурации для сайта Nginx по умолчанию:

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

В разделе server{ добавьте директиву listen, чтобы указать Nginx прослушивать порт, отличный от порта 80 (который Apache все еще использует для обслуживания запросов). Для нашего урока мы будем использовать порт 8000.

server {

    listen 8000;
    . . .
    . . .

Сохраните и закройте файл. Сейчас самое время провести выборочную проверку, чтобы убедиться, что мы можем получить доступ к нашему серверу Nginx. Запустите Nginx, чтобы проверить это:

sudo service nginx start

Используйте номер порта, который мы настроили, для доступа к конфигурации Nginx по умолчанию. Введите это в свой браузер:

http://your_ip_or_domain:8000

Ваш экземпляр Apache должен по-прежнему работать на порту 80 по умолчанию. Вы также можете проверить это, посетив свой сайт без :8000 в конце (в нашем примере просто обслуживается страница Apache по умолчанию. Если вы настроил ваш веб-сайт, вместо этого он будет здесь):

http://your_ip_or_domain

Переведите свою конфигурацию Apache

Теперь, когда у вас есть оба сервера, вы можете начать миграцию и перевод конфигурации Apache для использования с Nginx. Это нужно делать вручную, поэтому важно, чтобы вы понимали, как настроен Nginx.

Эта задача в основном сводится к написанию серверных блоков Nginx, которые аналогичны виртуальным серверам Apache. Apache хранит эти файлы в /etc/apache2/sites-available/, а Nginx следует его примеру и хранит свои объявления блоков сервера в /etc/nginx/sites-available/ в Ubuntu. .

Для каждого объявления виртуального сервера вы будете создавать блок сервера. Если вы просматриваете свои файлы 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. Это дает нам значение по умолчанию, которое мы будем использовать.

Мы также удалили директиву ServerAdmin, потому что Nginx не встраивает эту информацию в свои страницы ошибок.

Обработка PHP также немного изменилась. Из-за того, что PHP обрабатывается в Nginx отдельно, мы передаем эти файлы программе php-fpm, которую мы установили ранее. Это реализуется через сокет (который нам нужно будет настроить на мгновение).

Раздел документации изменен, чтобы отразить документацию Nginx. В остальном он работает примерно так же.

Наконец, мы настраиваем Nginx, чтобы запретить доступ к любому файлу .htaccess или другим файлам, начинающимся с .ht в нашем каталоге. Это специфичные для 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.

Если мы получим доступ к файлу info.php, который мы создали в учебнике Ubuntu LAMP, он должен отображаться следующим образом:

http://your_ip_or_domain:8000/info.php

В разделе «Переменные PHP» вы должны увидеть Nginx в качестве переменной «SERVER_SOFTWARE»:

Переведите свой сайт Nginx в рабочее состояние

После того, как вы провели всестороннее тестирование, вы можете попытаться плавно перенести свой сайт с Apache на Nginx.

Это возможно из-за того, что ни один из этих серверов не реализует изменения, пока не будет перезапущен. Это позволяет нам настроить все, а затем щелкнуть выключателем в одно мгновение.

На самом деле, единственное, что нам нужно сделать, это изменить порт в блоке сервера Nginx. Откройте файл сейчас:

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

Измените порт обратно на порт 80 по умолчанию. Это позволит ему начать принимать обычный HTTP-трафик сразу после перезапуска.

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

Сохраните и закройте файл.

Если вы только переводите некоторые из своих сайтов на Nginx и продолжаете обслуживать некоторый контент из Apache, вам необходимо отключить виртуальные серверы Apache, которые обслуживают запросы через порт 80. Это необходимо для предотвращения конфликтов. Если это сделать неправильно, 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 для обслуживания какой-либо части своих сайтов, вместо этого вы можете полностью остановить его веб-процесс:

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

Осложнения миграции

Есть несколько общих вещей в мире Apache, которые могут вызвать некоторую путаницу при попытке переключиться на Nginx.

Переписать переводы и файлы .htaccess

Одно из самых фундаментальных отличий заключается в том, что Nginx не учитывает переопределения каталогов.

Apache использует файлы .htaccess вместе с директивой AllowOverride All в блоке местоположения. Это позволяет вам помещать конфигурации для конкретного каталога в каталог, в котором находятся файлы.

Nginx не пропускает эти файлы. Размещение конфигурации с обслуживаемыми файлами потенциально является проблемой безопасности, если она неправильно настроена, и легко просмотреть централизованные файлы конфигурации и не понять, что параметр перезаписывается через файл .htaccess.

В результате вся конфигурация, которую вы указали в активном файле .htaccess, должна быть помещена в блок местоположения в конфигурации блока сервера для этого хоста. Как правило, это не сложнее, но вы должны перевести эти правила точно так же, как вы делали это с определениями виртуального хоста.

Обычно в файлах .htaccess хранятся правила для модуля Apache mod_rewrite, который изменяет URL-адреса доступа к контенту, чтобы сделать их более удобными для пользователя. Nginx имеет аналогичный модуль перезаписи, но использует другой синтаксис. К сожалению, переписывание URL-адресов в Nginx выходит за рамки этого руководства.

Осложнения модуля и внешней конфигурации

Еще одна вещь, которую следует иметь в виду, это то, что вам нужно осознавать, какую функциональность предоставляют модули 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;
    . . .

Важно помнить об этом.

Одна вещь, которая может быть полезна при переносе сложной конфигурации сайта, — это скопировать и вставить все файлы конфигурации из отдельных источников в один монолитный файл и систематически просматривать и переводить каждую строку.

Это может быть головной болью, но для производственного сервера это может сэкономить вам много времени на отслеживание того, что вызывает странное поведение, которое вы не можете точно определить.

Заключение

Сложность перехода с Apache на Nginx почти полностью зависит от сложности ваших конкретных конфигураций. Nginx может обрабатывать почти все, что может Apache, но с меньшими ресурсами. Это означает, что ваш сайт может беспрепятственно обслуживать большее количество пользователей.

Хотя миграция не имеет смысла для всех сайтов, и хотя Apache — прекрасный сервер, который адекватно удовлетворяет потребности многих проектов, вы можете увидеть прирост производительности или увеличение масштабируемости с помощью Nginx. Если вам по-прежнему требуется Apache, другой альтернативой является использование Nginx в качестве обратного прокси-сервера для вашего сервера Apache. Такой подход может эффективно использовать сильные стороны обоих серверов.