Apache — Apache как Frontend, Nginx как backend


Содержание

Apache — Apache как Frontend, Nginx как backend

># Main Module — directives that cover basic functionality

заменить на error_log /var/log/nginx/error.log;
>pid logs/nginx.pid;

заменить на pid /var/run/nginx.pid;
.

3.9 , Powar ( ? ), 17:28, 22/12/2009 [^] [^^] [^^^] [ответить] + / –
># Путь до директории с сайтами «/www»
># Имя корневой директории сайта должно совпадать с доменом сайта
>root /www/$host;

Что за глупость? У тебя сайты работают без алиасов?

4.11 , gochankot ( ? ), 10:23, 11/10/2010 [^] [^^] [^^^] [ответить] + / –
> Что за глупость? У тебя сайты работают без алиасов?

почему с ними, я это привел как пример, не кто не говорит, что нельзя по другому

1.4 , Base ( ? ), 22:05, 10/09/2009 [ответить] [﹢﹢﹢] [ · · · ] + / –
А почему бы картинки nginx’ом не раздавать?
2.7 , gochankot ( ? ), 19:05, 05/11/2009 [^] [^^] [^^^] [ответить] + / –
>А почему бы картинки nginx’ом не раздавать?

описал тут как http://www.opennet.ru/openforum/vsluhforumID3/44581.html#6

1.10 , iceman ( ?? ), 13:59, 20/09/2010 [ответить] [﹢﹢﹢] [ · · · ] + / –
htaccess host deny allow не работает в этой связке
1.12 , faf ( ? ), 01:38, 15/12/2011 [ответить] [﹢﹢﹢] [ · · · ] + / –
сть небольшой но вредный трабл:

На Ubuntu server стоит nginx+apache2+php+mysql;

apache2 прикручен на прослушку 127.0.0.1:81

Доступ к нгинксу осуществляется через домен trololo.com (к примеру :)

Теперь непосредственно сам эпик фейл — при заходе (ипользовании) phpmyadmin или phpbb3 в некоторых случаях (например при автоматической переадресации страницы средствами пхп) заменяется адрес на 127.0.0.1

Тоесть,к примеру, после ввода пароля в пхпмайадмине,вместо того, чтоб отправить меня по адресу trololo.com/phpmyadmin/index.php меня пытается переадресовать по 127.0.0.1:81/phpmyadmin/index.php , что соответственно не очень хорошо.

RPAF как я понял, отвечает сохранение и передачу ip клиента — индейцу. ОТсюда философский вопрос- что делать и как с этим бороться?

Установка nginx как front-end к apache в Debian / Ubuntu

apache

debian

nginx

ubuntu

web-сервер

Рано или поздно перед администратором встает задача разгрузить back-end, которым как правило, является apache. Одной из альтернатив для front-end является легкий web сервер Nginx. Данная конфигурация дает особенно большой выигрыш при наличии подключений по медленным каналам связи (модем), так как ресурсы системы начинают использоваться для дела, а не ждать, пока будет получен запрос или отдан ответ клиенту.

Преимущества архитектуры front-end/back-end


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

В случае же front-end/back-end конфигурации ситуация немного иная: front-end ( в нашем случае, nginx) полностью обрабатывает входящий запрос, используя при этом минимум системных ресурсов. Передает запрос back-end‘у (apache), быстро получает ответ и начинает передачу ответа клиенту. Таким образом, ресурсы, занятые под apache, были использованы только для того, чтобы сгенерировать запрошенный контент, и были сразу возвращены системе после завершения работы. А с клиентом общается лишь легкий и не требовательный к ресурсам front-end nginx.

Общий вид схемы front-end/back-end

В общем виде, http-соединение будет проделывать следующий путь:

В данном случае, fron-end и back-end располагаются на одной машине. В общем же случае, при необходимости они могут работать на разных машинах.

Установка и настройка Nginx

Установка Nginx

Установка Nginx тривиальна, начиная с Lenny (5.0). До этого, чтобы поставить nginx версии 0.6 и выше, необходимо было собирать пакет вручную.

Vladimir Drach. Official Web-Site. — Личный сайт Владимира Драча

Веб-сервер на связке nginx+apache

Понедельник, 30 Июнь 2014 00:00

Разворачиваем веб-сервер под операционной системой Linux, который будет использовать одновременно nginx и apache.

Пусть имеется аппаратная платформа, на которой уже установлен CentOS.

Настроим связку apache+nginx. На передовую (front-end) выставляем лёгкий и высокопроизводительный nginx, который будет обрабатывать запросы к статическому контенту (картинки, стили, js и т.п.). В тылу (back-end) нас будет страховать apache, задачей которого является предоставление динамического контента (в основном, PHP).

Безусловно, возникает законный вопрос, нельзя ли обойтись без apache вообще? Действительно, ничего не мешает настроить совместную работу nginx+php+mysql (вызываем PHP в режиме FastCGI с помощью php-fpm). Производительность такой системы будет ещё выше. Но есть и серьезный недостаток: большинство стандартных движков сайтов ориентировано непосредственно на работу под apache (правила доступа к различным директориям сайта настраиваются в файле .htaccess); а ввиду того, что nginx не обрабатывает .htaccess, без доработок такие сайты под nginx работать не будут. Причем, если переработка одного сайта является вполне выполнимой технической задачей, то обслуживание нескольких сайтов (особенно чужих), становится настоящей проблемой.

Итак, жертвуем экстремальной производительностью, но сохраняем поддержку .htaccess.

Устанавливаем apache, mysql, php. Для этого нам пригодится yum и стандартные репозитории.

Установка nginx чуть сложнее, придётся сходить на сайт разработчика и прочитать методику установки. К счастью, под распространенные дистрибутивы (CentOS и подобные), разработчик предоставляет готовые пакеты.

Настраиваем всю связку:

  • Конфигурация mysql
  • Конфигурация php
  • Конфигурация apache
  • Конфигурация nginx.

Теперь рассмотрим каждый шаг подробно.

Конфигурация mysql

Конфигурация php

Практически не требуется, в деталях описана в отдельной статье. Главное не забыть про shorttag: short_open_tag = On.

Конфигурация apache

Так как на передовую мы выдвигаем nginx, значит именно он будет работать на стандартном порту 80, а обращение к apache будет проксироваться через любой другой порт. Я выбрал 8080.

Модифицируем файл глобальных настроек. Я привожу только самые важные параметры, которые надо проверить:

Интересно, что KeepAlive следует отключать (спасибо за наводку внимательному читателю Mike). Производительность системы будет повышаться, если процесс httpd, отдав динамическое содержимое, будет тут же освобождаться.

Важно завести пользователя и группу, от которых будут работать в связке две службы: и nginx, и httpd. Естественно, это должен быть один и тот же пользователь как для httpd, так и для nginx во избежание конфликтов! Я для этих целей использую пользователя и группу apache; в результате httpd работает из-под «своего» имени, а nginx вынужден работать под чужим именем.

Следующим шагом будет настройка виртуальных серверов. Каждый виртуальный сервер будем настраивать, создавая для него отдельный конфигурационный файл в /etc/httpd/conf.d/ , причем необходимо следить, чтобы расширением являлось именно .conf . Предположим, создаётся виртуальный сервер для сайта drach.pro, тогда потребуется файл /etc/httpd/conf.d/drach.pro.conf со следующим содержимым:

Таким образом необходимо описать все виртуальные сервера. Кроме того, надо не забыть про файлик vhost.conf, в который надо поместить конфигурацию сайта по умолчанию.


Теперь десерт! Не достаточно настроить apache на обычную работу, необходимо корректно обрабатывать REMOTE_ADDR заголовка. Для этих целей устанавливаем и настраиваем RPAF (mod_rpaf соответствует первой версии apache, а mod_rpaf2 — второй).

Без RPAF будем иметь REMOTE_ADDR не пользовательский, а IP-адрес сервера с передовой (это nginx). RPAF будет обрабатывать заголовок X-Forwarded-For, который получен от nginx и генерировать корректный REMOTE_ADDR.

Таким образом заголовок REMOTE_ADDR снова имеет пользовательский IP! Например, для моих целей это крайне важно, так как приходится наблюдать за пользователями и вести подробные логи для отчётов.

Устанавливаем модуль RPAF, для чего его придётся найти в интернете отдельным пакетом под наш дистрибутив. Есть альтернативный путь: подключить хранилище Atomic repo и использовать yum. Затем настраиваем RPAF, создавая и редактируя /etc/httpd/conf.d/mod_rpaf.conf:

После конфигурации необходимо перезапустить Apache.

Конфигурация nginx

Описываем глобальный файл конфигурации /etc/nginx/ nginx.conf :

Теперь конфигурируем виртуальные хосты! Причем, поступаем профессионально: конфигурационные файлы складываем в /etc/nginx/ conf.d : например, для сайта drach.pro заводим отдельный файл /etc/nginx/ conf.d/drach.pro.conf :

Конец. Достаточно перезапустить все службы и убедиться, что веб-сервер работает!

Отслеживаем доступ к серверу в реальном времени:

Ежели в консоли браузера появляется ERR_INCOMPLETE_CHUNKED_ENCODING (обычно это бывает, если файлы css и js генерируются «на лету»), необходимо проверить права и владельца директории /var/cache/nginx/proxy_temp. Также есть смысл убрать эти два расширения из разрешённых статических типов файлов для nginx.

Ежели в журнале ошибок появляется upstream response is buffered to a temporary file, следует в файл глобальной конфигурации nginx добавить proxy_max_temp_file_size 0; в секцию http.

Nginx и Apache2. Установка и быстрая настройка!

Зачем нужен Nginx?

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

Так же Nginx можно использовать в режиме FastCGI, при этом Apache вам не понадобится. Однако при этом режиме у PHP наблюдается ряд проблем, поэтому на помощь приходит php-fpm!

Однако мы сегодня поговорим о совместной установке с Apache, а не в режиме FastCGI. Более того, по задаче у нас эти веб-сервера будут находится на одном сервере, поэтому выделим для Nginx — 80, а для Apache — 88 порт!

Apache (см. схему)

Установка Apache и Nginx

FreeBSD:

Debian:

При этом буду установлены так же пакеты:

Если этого не произошло, то необходимо установить их самостоятельно:

Создание сертификатов для SSL

Создание ключа

Первым делом необходимо создать приватный ключ (private key):

При создании ключа необходимо указать ключевую фразу (и запомнить ее).

Создание подписанного сертификата

После того, как сгенерирован ключ, можно создавать самоподписанный сертификат (CSR — Certificate Signing Reques):

Удаление пароля из ключа

Неприятной особенностью ключа с паролем является то, что Apache или nginx будет регулярно спрашивать пароль при старте. Очевидно, что это не очень удобно (если только кто-то не находится постоянно рядом на случай перезагрузки или аварийной остановки). Для удаления ключа из пароля необходимо выполнить следующее:


Генерация SSL сертификата

Далее, создаем сам SSL сертификат:

Теперь есть все, что необходимо для создания SSL-соединений.

Правильное расположение SSL сертификатов

Заключительным шагом в создании SSL сертификата будет распределение полученных файлов в соответствующие директории. Во-первых, копируем сам сертификат:

Во-вторых, копируем ключ:

И в-третьих, удаляем, все то, что было создано в текущей директории:

FreeBSD:

Debian:

Настройка Nginx

Отредактируем файл /usr/local/etc/nginx/nginx.conf

Должен иметь следующий вид:

Настройка виртуального хоста в Nginx

Создаем файл виртуального хоста:

Файл следующего вида:

Создание виртуальных хостов в Nginx

Создаем описание двух виртуальных хостов:

Создаем необходимые директории двух виртуальных хостов:

Настройка стандартного виртуального хоста в Nginx

Файл настройки должен иметь следующий вид:

Настройка виртуального хоста в Nginx с поддержкой SSL

Файл настройки должен иметь следующий вид:

В отличие от конфигурации для adminunix.ru тут уже появляется описание для 443 порта. Идея проста — ssl-соединение создает nginx, а вот данные по этому соединению передает уже apache.

Включение хостов и перезапуск Nginx

После того, как настройки сделаны, необходимо сделать виртуальные хосты достпными и перезапустить nginx:

Создание виртуальных хостов в Apache

Так как ssl-соединениями занимается nginx, то apache остается всего лишь работать на не стандартном порту (например, 8080) и обрабатывает входящие содинения. Создаем файлы виртуальных хостов Apache:

Далее, необходимо включить хосты и перегрузить apache:

Проверка SSL соединения

Чтобы проверить корректность настройки SSL достаточно открыть в браузере https://lists.adminunix.ru/. Так как используется самоподписанный сертификат, то браузер, вероятнее всего, выдаст предупреждение, что подлинность сервера не может быть проверена, и предоставит возможность просмотреть сертификат. В случае, если текущий домен не совпадает с тем, что указан «Common Name», может быть выдано еще одно предупреждение.

Самоподписанных сертификтов как правило хватает для административных зон на сайтах. При использовании коммерческих сертификатов никаких предупреждений выдаваться не будет.

Для более тонкой настройки SSL или для решения проблем в TLS/SSL-соединениях следует пользоваться набором утилит openssl. Например:


После конфигурации необходимо перезагрузить Nginx

Nginx: Отдаем статику

С помощью этих правил разруливаем запросы на отдачу статику и динамического контента

Настройка Apache

Редактируем файл /usr/local/etc/apache2/httpd.conf

Тоже самое делаем и в httpd-vhosts.conf для ваших хостов.

Если у вас появляется следующая ошибка:
> [warn] (2) No such file or directory:
> Failed to enable the ‘httpready’ Accept Filter

то вам следует подгрузить модуль
# kldload accf_http

Установка и настройка RPAF или даешь верный REMOTE_ADDR!

Так как у нас появился в цепи дополнительный элемент в виде фронтенд-сервера, то теперь в REMOTE_ADDR у нас не пользовательский IP, а IP-адрес фронтенд-сервера (на котором расположен Nginx). Поэтому на помощь приходит RPAF, он берет тело заголовка X-Forwarded-For, присланного от фронтенда и формирует на бекенде из него REMOTE_ADDR.

Таким образом заголовок REMOTE_ADDR снова имеет пользовательский IP!

Устанавливаем модуль RPAF
FreeBSD

Debian

Настраиваем RPAF, редактируем httpd.conf, добавляем в конец файла:

После конфигурации необходимо перезагрузить Apache

Debian

Ну вот вроде и все, смотрите ниже дополнительную литературу и задавайте вопросы в камменты!

Полезные материалы по Nginx

[urlspan]Полезные ссылки[/urlspan]
[urlspan]Пример конфигурации nginx[/urlspan]
Настройка виртуальных серверов
Отличная статья с Хабра: [urlspan]Тюнинг nginx[/urlspan]

Читайте другие интересные статьи

Понравилась статья, расскажи о ней друзьям, нажми кнопку!

flops.ru

  • Настройка nginx как front-end к apache на ubuntu 16.04
  • Настройка nginx как front-end к apache на ubuntu 16.04

    1. Установка nginx

    Затем файл /etc/nginx/sites-available/example_nginx.conf необходимо привести к следующему виду:

    2. Установка apache и php

    Затем в файле /etc/apache2/ports.conf необходимо изменить порт, который будет слушать apache:


    Файл /etc/apache2/sites-available/example-apache.conf необходимо привести к следующему виду:

    При открытии URL http://example.com/ мы должны увидеть вывод функции phpinfo().

    Apache имеет следующую структуру конфигурационных файлов:

    service apache2 start | stop | restart | reload — Запуск, остановка, перезапуск, перечитывание конфигурации

    apachectl -t — проверка синтаксиса конфигурационного файла

    apachectl -M — список включенных модулей

    a2enmod, a2dismod module_name — включение или отключение модуля

    a2enconf, a2disconf conf_name — включение или отключение конфигурационного файла

    a2ensite, a2dissite vhost_name — включение или отключение виртуального хоста

    Настройка Nginx в качестве обратного прокси к Apache

    Введение

    Apache и Nginx — два самых распространённых веб-сервера в мире. Оба они способны обслуживать веб-сайты под большими нагрузками. Каждый веб-сервер имеет свои преимущества и недостатки. Причины популярности каждого из серверов хорошо известны: мощность Apache и скорость Nginx. Тем не менее, оба сервера имеют недостатки: Apache имеет ограничения памяти сервера, в то время как Nginx, эффективный для статических файлов, нуждается в помощи php-fhm или аналогичных модулей для динамического контента.

    Тем не менее можно объединить два веб-сервера для большей эффективности, используя Nginx, как статический фронтенд и Apache — как бэкенд.

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

    Технические требования

    • Пользователь с sudo-правами
    • Ubuntu 16.04

    Шаг 1. Установка и настройка Apache

    Первым делом обновите индекс пакетов:

    Apache устанавливается одной командой:

    Далее, нужно перебросить Apache на порт 8080, поскольку на основном 80 порту соединения будет слушать Nginx. Для этого откройте конфигурационный файл портов Apache:

    В файле найдите строку:

    Сохраните изменения(Ctrl+O), подтвердите действие(Enter) и закройте конфигурационный файл(Ctrl+X).

    Откройте конфигурационный файл вашего веб-сайта:

    И замените его содержимое на:

    Перезагрузите Apache, чтобы изменения вступили в силу:

    Обязательно убедитесь, что Apache переключился на порт 8080:

    На этом установка и настройка Apache завершена. Следующим шагом будет установка и настройка Nginx.

    Шаг 2. Установка и настройка Nginx

    Откройте конфигурационный файл:


    И замените его содержимое на:

    Проверьте конфигурационный файл на валидность:

    Если всё в порядке, то вы получите следующий вывод:

    После подтверждения валидности конфигурационного файла перезагрузите Nginx, чтобы изменения вступили в силу:

    На этом установка и настройка Nginx завершена.

    Зачем всё это нужно?

    В первую очередь для экономии серверных ресурсов. Возьмём обычный html-шаблон со статичными данными и загрузим его на два разных сервера. На первом сервере будет установлен только Apache, а на втором связка Nginx и Apache. Сравним потребление оперативной памяти

    Apache:

    Nginx + Apache:

    Да, разница в 38 мегабайт не столь существенна, однако, хотелось бы напомнить, что на сервер загружен лишь одностраничный html-шаблон. При разработке больших проектов с динамическими данными разница будет существеннее. Экономия памяти происходит как раз за счёт использования Nginx. Он быстрее обрабатывает и отдаёт статические данные клиенту и потребляет меньше ресурсов для поддержания keep-alive соединений.

    Заключение

    Вы успешно настроили взаимосвязь между Apache и Nginx. Оба веб-сервера являются мощными, гибкими и функциональными инструментами. Перед выбором того или иного веб-сервера стоит определиться с требованиями к вашему проекту, ведь у каждого веб-сервера есть свои недостатки. Подробный разбор преимуществ и недостатков описан в статье Apache vs Nginx: практический взгляд.

    Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи

    Рассмотрим довольно популярную связку Apache+Nginx для снижения нагрузки на сервер. Так же, хочу заметить, что данная статья учитывает virtual hosts, а не отдельно хостящийся сайт (для такого сайта статья тоже подойдёт)

    1) Настройки Apache

    Апач у нас будет слушать порт 88. Файлы описания virtual хостов будут лежать у нас в vhosts относительно папки с конфигом apache и заканчиваться обязательно должны на ‘.conf’. В файл httpd.conf вписываем такое (или приводим к такому виду, если строки уже есть)

    Listen 127.0.0.1:88
    Include etc/apache22/vhosts/*.conf
    NameVirtualHost *:88

    Далее создаём файл sait.com в папке vhosts такого содержания:

    ServerName sait.com
    ServerAlias *.sait.com
    DocumentRoot /www/sait.com
    ErrorLog «/var/log/apache/sait.com-error»
    CustomLog «/var/log/apache/sait.com-access» common

    Для добавления нового virtual хоста достаточно создать файл и добавить содержимое, аналогичное sait.com

    2) Настройка nginx

    nginx должен быть собран с поддержкой модуля HTTP_REALIP, иначе в apache будет неправильно передаваться адрес клиента (вместо реального будет светиться 127.0.0.1)

    В nginx.conf, в директиве http пишем строку

    Файлы описания virtual хостов будут лежать у нас в vhosts относительно папки с конфигом nginx и заканчиваться обязательно должны на ‘.conf‘. Вот пример конфигурации для сайта sait.com:

    location / <
    try_files $uri @drupal;
    >
    location

    linux-notes.org

    Установка Nginx и Apache в связи в CentOS

    Данная связка распараллеливает ресурсы между двумя серверами, один работает в качестве фронтенда за это отвечает Nginx, а второй выполняет функцию бэкенда за это отвечает apache2 и сделано это все для снижения общей нагрузки на сервер. Выполняется все это за счет того, что более легкий и не обремененный дополнительным функционалом nginx который обрабатывает все запросы от пользователей. Он сам отдает по запросам весь статический контент, такой как — изображения, html, javascript (его скрипты) и все остальное и не нагружая этим apache, который занимается свою очередь, обрабаткой динамического контента. Собственно, apache не работает с клиентами напрямую, все ихние запросы проксируются на nginx и ему только возвращаются ответы на те запросы. Так соблюдается разделение труда: nginx делает свободным apache от необходимости “обращаться” с большим количеством юзеров и выполнять запросы по статике- это очень большая его часть исходящего трафика. Сам apache не создает никаких дочерних процессов, потребляющие RAM (оперативную память).

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

    Установка nginx

    Первое что нужно сделать — это подключение репозиториев EPEL и CentALT. Они нужны для того, чтобы мы установили Nginx с поддержкой модуля RPAF, модуль для Apache.


    Я писал статью по этой теме, по этому Вы можете легко найти:
    1. Установка и подключения репозитория EPEL

    После подключения всех репозиториях, выполняем:

    Я сейчас сделаю так, чтобы веб-сервер nginx автоматически стартовал при запуске ОС. Для этого:

    Конфигурация Nginx

    Следующим этапом будет — коректировка файла конфигурации на сервере nginx:

    Для более нормальной читабельности я его положил в файл и его можно прочитать тут, чтобы скачать выполните (не забудьте переименовать данный файл тогда):

    Установка Apache2

    Веб-серер энжинкс уже установлен и настроен, сейчас установим и настроим apache2 который в списке пакетов имеет имя httpd и для его установки нужно выполнить:

    Конфигурация Apache

    Нужно немного подредактировать конфигурационный файл в apache и привести к такому виду:

    Мой рабочий конфиг Вы можете посмотреть тут, можно так же и скачать (но не забудьте переименовать его):

    Установка модуля RPAF

    Сейчас все запросы к апачу поступают не от удаленных посетителей, а уже от nginx, то в итоге IP-адрес посетителя apache будет оприделятся как локальный (127.0.0.1). Собственно, чтобы решить эту проблему нужно установить и настроить модуль RPAF. Расскажу как работает данный модуль:

    Собственно, нечего непонятного тут нет, RPAF берет тело заголовка X-Forwarded-For, который прислал наш фронтенд (веб-сервер nginx) и делает замену в заголовке REMOTE_ADDR на бекенде (веб-серера apache).

    У меня этот метод установки почему то не работал, по этому я решил свою проблему немного по другому.

    Сначала я поставил пакеты нужных для работы утилит (http-devel и gcc -это компилятор):

    После чего я перейду в папку src:

    После этого я скачаю архив с исходным кодом mod_rpaf:

    Распакую данный, скачанный архив следующей командой и перейду в нужную папку для дальнейшей работы:

    После чего, выполняем команду и устанавливаем данный модуль в апач:

    Настройка модуля RPAF

    Следующим шагом будет настройка модуля, для этого откроем нужный файл и впишем в него некоторые изменения:

    Все, установка и настройка nginx и apache в связи в CentOS, но остались последние штрихи — нужно перегрузить все сервисы:

    На этом, тема «Установка Nginx и Apache в связи в CentOS» завершена, спасибо что читаете мой блог http://linux-notes.org

    Не забываем поставить еще PHP5, базы данных (Mysql, MariaDB, MongoBD, oracle или любую другую), на сайте можно найти многое по различным темам.

    Записки bаckend-разработчика

    10 отличий Apache от Nginx

    Доброго времени суток, backend/frontend/full-stack/devops/qa/.. да какая разница, добро пожаловать, мой друг!

    Свой цикл статей хотелось бы начать с до неприличия банальной фразы — «Все познается в сравнении». Ведь невозможно говорить о том, что какой-либо инструмент лучший, не опробовав другой. Попробуем сравнить два самых популярных в мире веб-сервера — Apache, который обслуживает около 60 млн сайтов, и Nginx — около 40 млн (больше интересной статистики тут). Возможно, после прочтения данной статьи вы сможете определиться, что лучше подходит для вашего dev-окружения. Итак, поехали! ;)

    Начнем с архитектурных и функциональных отличий.

    1. Метод обработки соединений с клиентами

    Издавна, Apache на каждый запрос от клиента создает отдельный процесс (или поток, зависит от выбранного mpm модуля). Выглядит это следующим образом — клиент отправляет запрос, веб-сервер создает отдельный процесс на этот запрос, отвечает клиенту и блокирует процесс до тех пор, пока клиент не закроет соединение. Это легко и просто в реализации, дебаге и мониторниге, но … Как вы могли бы догадаться, если у вас highload проект, то.. дела плохи. Процесс в любой ОС требует памяти и ресурсов, а когда процессов становиться неприлично много, обработка соединений неприлично замедляется, память кончается, CPU растет. Для мелких проектов такая реализация архитектуры обработки соединений не добавит головной боли, но для высоконагруженных проектов придется ставить очень мощное железо или искать альтернативные варианты.


    Nginx состоит из master-процесса и нескольких дочерних процессов. Мастер процесс обычно один — он создает дочерние процессы (воркеры, загрузчик кеша и кеш менеджер), считывает конфигурацию и открывает порты. Воркеров обычно несколько, разработчики nginx советуют количество воркеров определять равным числу ядер машины. Эти дочерние процессы буду обслуживать все соединения с клиентами в неблокирующей манере. В nginx используется бесконечный цикл, который бежит по всем соединениями и отвечает на запросы клиентов. Когда соединение закрывается, оно удаляется из event loop. Это решение идеально подходит для проектов, которые обслуживающих 10к+ соединений одновременно. При этом, загрузка CPU и использование памяти обычно равномерны, без видимых пиков.

    2. Отдаваемый контент

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

    Nginx — отдает только статику и из коробки генерировать динамический контент не умеет. Если вы используете nginx и хотите генерировать динамический контент на своем сайте, то вам придется проксировать запросы тому, кто это делать умеет (apache, php-fpm и др.). Поэтому, разработчикам придется настраивать дополнительную связку, которая усложняет архитектуру, например nginx+apache (кстати в этой связке, Apache называют бекенд сервером, а Nginx — фронтендом), nginx + phpfpm, nginx + python и др.

    3. Конфигурирование

    Apache полюбился разработчикам и сисадминам не в последнюю очередь из-за возможности конфигурировать обработку соединений на уровне директорий. Делается это с помощью скрытого файла .htaccess, позволяющего настраивать права доступа, авторизацию, аутентификацию, политику кеширования и др правила. Это довольно-таки удобное решение для пользователей, потому что позволяет менять конфигурацию на лету, без перезагрузки сервера и без наличия доступа к основному конфигу сервера. Но также имеется маленький минус — Apache каждый раз при обработке соединений ищет файл .htacces и считывает с него информацию, что естественно замедляет выдачу ответа клиенту (кстати, поддержку настройки конфигурирования на уровне директорий можно и отключить).

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

    4. Работа с модулями

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

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

    5. Интерпретация запросов

    Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки.

    Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.

    6. Работа со скриптовыми языками

    В Apache есть один модуль mod_php и все хосты вынуждены работать с одной и той же версией php и одним конфигурационным файлом.

    В случае с nginx, каждый виртуалхост будет выполняться в отдельном процессе и, соответственно, может использовать разные версии php (python/ruby/perl и др.). Каждый процесс может иметь свою собственную независимую конфигурацию.

    Вообще, в высоконагруженных проектах удобнее держать раздельно nginx и php. По отдельности их проще мониторить, ловить баги или узкие места. «Все-в-одном» Apache+mod_php в этом плане менее удобен.

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

    7. Скорость работы

    Скорость работы веб-сервера обычно измеряют для 2-х случаев отдачи контента: для статики и динамики. На основе тестов производительности, Nginx примерно в 2.5 раза быстрее отдает статику, чем Apache. Это довольно-таки большое превосходство. Если вам необходимо обслуживать большое количество статического контента, Nginx — лучший выбор. Во время тестирования отдачи динамического контента, Apache и Nginx показывают примерно одинаковые результаты. С точки зрения памяти, оба сервера используют один и тот же объем ресурсов. (Подробнее о тестах скорости отдачи контента можно почитать здесь)

    8. Поддержка ОС

    Apache прекрасно работает на Unix-подобных операционных системах, также разработчики этого веб-сервера полностью поддерживают линейку Microsoft Windows, включая последние версии этой ОС.

    Nginx также поддерживает работу на множестве Unix-подобных ОС и имеет некоторую поддержку Windows, которая не является полной. Но разве кто-то в наше время размещает веб-сервер на Windows?

    9. Сообщество и поддержка

    Apache на рынке с 1995 года, что очень немалый срок, обеспечивший инструменту огромное сообщество и поддержку с его стороны. Практически на все вопросы на Stack Overflow уже есть исчерпывающие ответы. Коммерческой поддержки нет.

    Nginx веб-сервер более молодой, на рынке он с 2004 года, что также не помешало большому сообществу сформироваться и поддерживать друг друга. Nginx, в отличие от Apache, имеет коммерческую версию Nginx Plus, которая дополнена инструментами балансировки нагрузки, мониторинга, потоковой передачи медиа и др.

    10. Документация и обучение

    И у Apache и у Nginx присутствует доступная официальная документация.

    Nginx предлагает платное обучение, включающее в себя онлайн курсы, практические занятия и экзамен. По окончании курса все участники получают сертификаты. Например, сдать экзамен по основам nginx и получить официальный сертификат обойдется в 49$ (подробнее здесь).

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

    Vladimir Drach. Official Web-Site. — Личный сайт Владимира Драча


    Веб-сервер на связке nginx+apache

    Понедельник, 30 Июнь 2014 00:00

    Разворачиваем веб-сервер под операционной системой Linux, который будет использовать одновременно nginx и apache.

    Пусть имеется аппаратная платформа, на которой уже установлен CentOS.

    Настроим связку apache+nginx. На передовую (front-end) выставляем лёгкий и высокопроизводительный nginx, который будет обрабатывать запросы к статическому контенту (картинки, стили, js и т.п.). В тылу (back-end) нас будет страховать apache, задачей которого является предоставление динамического контента (в основном, PHP).

    Безусловно, возникает законный вопрос, нельзя ли обойтись без apache вообще? Действительно, ничего не мешает настроить совместную работу nginx+php+mysql (вызываем PHP в режиме FastCGI с помощью php-fpm). Производительность такой системы будет ещё выше. Но есть и серьезный недостаток: большинство стандартных движков сайтов ориентировано непосредственно на работу под apache (правила доступа к различным директориям сайта настраиваются в файле .htaccess); а ввиду того, что nginx не обрабатывает .htaccess, без доработок такие сайты под nginx работать не будут. Причем, если переработка одного сайта является вполне выполнимой технической задачей, то обслуживание нескольких сайтов (особенно чужих), становится настоящей проблемой.

    Итак, жертвуем экстремальной производительностью, но сохраняем поддержку .htaccess.

    Устанавливаем apache, mysql, php. Для этого нам пригодится yum и стандартные репозитории.

    Установка nginx чуть сложнее, придётся сходить на сайт разработчика и прочитать методику установки. К счастью, под распространенные дистрибутивы (CentOS и подобные), разработчик предоставляет готовые пакеты.

    Настраиваем всю связку:

    • Конфигурация mysql
    • Конфигурация php
    • Конфигурация apache
    • Конфигурация nginx.

    Теперь рассмотрим каждый шаг подробно.

    Конфигурация mysql

    Конфигурация php

    Практически не требуется, в деталях описана в отдельной статье. Главное не забыть про shorttag: short_open_tag = On.

    Конфигурация apache

    Так как на передовую мы выдвигаем nginx, значит именно он будет работать на стандартном порту 80, а обращение к apache будет проксироваться через любой другой порт. Я выбрал 8080.

    Модифицируем файл глобальных настроек. Я привожу только самые важные параметры, которые надо проверить:

    Интересно, что KeepAlive следует отключать (спасибо за наводку внимательному читателю Mike). Производительность системы будет повышаться, если процесс httpd, отдав динамическое содержимое, будет тут же освобождаться.

    Важно завести пользователя и группу, от которых будут работать в связке две службы: и nginx, и httpd. Естественно, это должен быть один и тот же пользователь как для httpd, так и для nginx во избежание конфликтов! Я для этих целей использую пользователя и группу apache; в результате httpd работает из-под «своего» имени, а nginx вынужден работать под чужим именем.

    Следующим шагом будет настройка виртуальных серверов. Каждый виртуальный сервер будем настраивать, создавая для него отдельный конфигурационный файл в /etc/httpd/conf.d/ , причем необходимо следить, чтобы расширением являлось именно .conf . Предположим, создаётся виртуальный сервер для сайта drach.pro, тогда потребуется файл /etc/httpd/conf.d/drach.pro.conf со следующим содержимым:

    Таким образом необходимо описать все виртуальные сервера. Кроме того, надо не забыть про файлик vhost.conf, в который надо поместить конфигурацию сайта по умолчанию.

    Теперь десерт! Не достаточно настроить apache на обычную работу, необходимо корректно обрабатывать REMOTE_ADDR заголовка. Для этих целей устанавливаем и настраиваем RPAF (mod_rpaf соответствует первой версии apache, а mod_rpaf2 — второй).

    Без RPAF будем иметь REMOTE_ADDR не пользовательский, а IP-адрес сервера с передовой (это nginx). RPAF будет обрабатывать заголовок X-Forwarded-For, который получен от nginx и генерировать корректный REMOTE_ADDR.

    Таким образом заголовок REMOTE_ADDR снова имеет пользовательский IP! Например, для моих целей это крайне важно, так как приходится наблюдать за пользователями и вести подробные логи для отчётов.

    Устанавливаем модуль RPAF, для чего его придётся найти в интернете отдельным пакетом под наш дистрибутив. Есть альтернативный путь: подключить хранилище Atomic repo и использовать yum. Затем настраиваем RPAF, создавая и редактируя /etc/httpd/conf.d/mod_rpaf.conf:

    После конфигурации необходимо перезапустить Apache.

    Конфигурация nginx

    Описываем глобальный файл конфигурации /etc/nginx/ nginx.conf :

    Теперь конфигурируем виртуальные хосты! Причем, поступаем профессионально: конфигурационные файлы складываем в /etc/nginx/ conf.d : например, для сайта drach.pro заводим отдельный файл /etc/nginx/ conf.d/drach.pro.conf :

    Конец. Достаточно перезапустить все службы и убедиться, что веб-сервер работает!

    Отслеживаем доступ к серверу в реальном времени:

    Ежели в консоли браузера появляется ERR_INCOMPLETE_CHUNKED_ENCODING (обычно это бывает, если файлы css и js генерируются «на лету»), необходимо проверить права и владельца директории /var/cache/nginx/proxy_temp. Также есть смысл убрать эти два расширения из разрешённых статических типов файлов для nginx.

    Ежели в журнале ошибок появляется upstream response is buffered to a temporary file, следует в файл глобальной конфигурации nginx добавить proxy_max_temp_file_size 0; в секцию http.

    Цукерберг рекомендует:  Тест по Факультет дизайна. Дизайн-мышление
    Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих