Меню Рубрики

Установка nginx на апач

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка 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

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

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

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

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

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

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

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

источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Настраиваем веб-сервер. Nginx как front-end к Apache

Всем хорош веб-сервер Apache, кроме одного — потребления ресурсов. Многие «продвинутые» пользователи могут порекомендовать вообще отказаться от него в пользу того же Nginx, но это не всегда возможно, например, ваш движок использует сложные преобразования URL для получения красивых ссылок. Можно, конечно, переписать их под другой веб-сервер, но это требует определенной квалификации и затрат. Как быть? Поставить Nginx в качестве front-end к Apache, что позволит использовать сильные стороны каждого из продуктов.

Начнем с теории

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

В формировании современного динамического контента принимают участие три основных службы: веб-сервер, сервер приложений и сервер СУБД. Если у вас проблемы с БД или не хватает производительности PHP, то никакая замена Apachе на Nginx вам не поможет. Но для чего тогда все продолжают ставить Nginx перед Apache? Давайте разбираться.

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

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

Рассмотрим следующую схему:

В верхней ее части показан Apache, работающий в качестве самостоятельного сервера. Давайте посмотрим, что происходит, когда пользователь запрашивает веб-страницу. Прежде всего генерируется динамическое содержимое: запускается экземпляр Apache, его модуль mod_php собирает страницу и отдает пользователю. Но это только начало, каждая страница содержит ссылки на статическое содержимое: скрипты, стили, изображения и т.д. и т.п.

А теперь вспомним немного об особенностях протокола HTTP/1.1: для каждого получаемого от веб-сервера ресурса создается отдельное HTTP-соединение, т.е. запускается отдельный процесс веб-сервера. Это серьезно упрощенная модель, но вполне достаточная для понимания происходящих процессов. Проще говоря, для того, чтобы отдать пользователю картинку мы вынуждены каждый раз запускать достаточно ресурсоемкий Apache со всеми его модулями, которые в данный момент не нужны.

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

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

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

Читайте также:  Установка deb пакетов archlinux

Что можно сделать в такой ситуации? Увеличение количества доступных ресурсов в данном случае мы не рассматриваем, остается второй путь — оптимизировать работу Apache. Вот здесь на сцену и выходит Nginx.

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

Однако Nginx не поддерживает динамическую генерацию контента и несовместим с директивами htaccess, поэтому в тех случаях, когда от Apache отказываться нежелательно, Nginx устанавливают перед Apache в качестве front-end.

Нижняя часть схемы как раз отражает такую ситуацию. Apache по-прежнему генерирует динамический контент, остаются рабочими директивы htaccess, но теперь его клиентом выступает не браузер, а Nginx, причем очень быстрым клиентом, это позволяет оперативно забрать у Apache результат его работы и освободить занимаемые им ресурсы. Браузер посетителя получает созданное Apachе содержимое уже у Nginx, как и всю статику.

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

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

Перейдем к практике

Здесь и далее мы будем подразумевать, что веб-сервер настроен по нашей статье Настраиваем веб-сервер на базе Apache в Debian / Ubuntu Server, в иных случаях, возможно, вам потребуется уточнить некоторые детали.

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

Начнем с Apache, откройте /etc/apache2/ports.conf и измените порты на которых принимает соединения веб-сервер, для этого

Теперь перейдите в /etc/apache2/sites-available и в настройках каждого виртуального хоста приведите директиву VirtualHost к виду:

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

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

Если ошибок нет, то переходим к следующему этапу, на котором мы установим и настроим Nginx.

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

Подключим репозитории разработчиков, для этого создадим в папке /etc/apt/sources.list.d файл nginx.list:

и внесем в него следующие записи.

где codename — кодовое имя дистрибутива, например, jessie для Debian 8 или trusty для Ubuntu 14.04.

Затем скачаем и установим PGP-ключ для проверки подлинности пакетов:

Затем обновим список пакетов и установим Nginx:

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

Конфигурацию Nginx в файле /etc/nginx/nginx.conf приведем к следующему виду:

Мы не будем подробно комментировать все перечисленные опции, так как подробно останавливались на них в статье: Настраиваем веб-сервер на базе Nginx + PHP-FPM в Debian / Ubuntu Server. Отметим лишь новую секцию upstream apache24.

Директива upstream позволяет описывать сервер (группу серверов), которым Nginx может передавать свои запросы, такая конструкция удобна прежде всего тем, что в конфигурациях виртуальных хостов не фигурирует адрес и порт вышестоящего сервера, в нашем случае Apache, а только его символьное имя. В опции server, как вы уже догадались, указываем адрес и порт, на котором работает Apache.

Читайте также:  Установок газоразделения производства этилена

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

Следующий шаг — настройка виртуальных хостов. Создадим две папки для конфигураций сайтов и одну для хранения шаблонов:

Чтобы не писать из конфигурации в конфигурацию хостов одно и то-же создадим шаблон apache24.conf в котором укажем все основные опции подключения к вышестоящему серверу и работы со статическим содержимым. Создадим файл:

И внесем в него параметры соединения с вышестоящим сервером:

Опция proxy_pass перенаправляет все запросы вышестоящему серверу, proxy_set_header нужным образом изменяют HTTP-заголовки страниц, последние три опции задают тайм-ауты соединения.

Ниже добавим секцию для работы со статическим содержимым:

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

Следующая секция задает правила работы со скриптами и стилями:

Ее содержимое аналогично предыдущей, кроме времени кэширования, оно установлено в 180 мин (3 часа), как разумный компромисс между снижением нагрузки на сервер и возможным изменением их содержимого.

Наконец запретим доступ к ht-файлам, в которых содержатся конфигурационные директивы Apache:

Если вы используете phpMyAdmin, то создайте еще один шаблон:

Внесите в него следующее содержимое:

Теперь, когда шаблоны готовы, можно перейти к описанию виртуальных хостов, для этого в папке /etc/nginx/sites-available создадим для каждого сайта свой конфигурационный файл, для примера мы используем домен example.com:

Внутри разместите следующий текст:

Данная секция server содержит настройки нашего виртуального хоста: порт, имя, кодировку, корневую папку, файлы логов и индексный файл. Директива root — корневая папка — должна указывать на директорию с содержимым сайта, а в директиве index лучше указать реально используемый тип индексного файла, например, только index.php.

И в самом конце подключим шаблоны для работы с вышестоящим Apache и phpMyAdmin.

Обратите внимание, что приведенная настройка хоста будет обслуживать запросы как с www, так и без, если вы хотите использовать вариант только без www или наоборот, например, в целях SEO, то оставьте в директиве server_name только один хост:

А в конфигурационный файл сайта добавьте еще одну секцию server:

Данная конструкция осуществит редирект всех запросов с www, на страницы без www.

Сохраним и подключим файл конфигурации:

Проверим его правильность командой:

И, если все хорошо, перезапустим оба веб-сервера:

Как видим, мы установили Nginx в качестве front-end к Apache на работающем сервере без простоя последнего, спокойно все настроив и проверив правильность настройки. Остается последний вопрос: как проверить, что статическое содержимое отдает действительно Nginx?

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

Вполне закономерно мы получим ошибку 404, теперь смотрим, кто именно сообщил нам об этом — правильно, Nginx. А если запросить несуществующий динамический контент, то получим аналогичное сообщение, но от Apache:

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

источник

Добавить комментарий

Adblock
detector