Nginx + apache + mysql + php-fpm (fastcgi) + ftp + phpmyadmin + memcached на ubuntu. полноценный веб-сервер

4 ответа

Решение

2019 обновление:

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

И то и другое:

Поддержка HTTPS
Поддержка веб-сокетов
Стабильные, зрелые и очень эффективные продукты
Может обрабатывать 10 тыс. Соединений с минимальной настройкой или без настройки

HAProxy:

Балансировка нагрузки TCP, TCP-SSL, HTTP и HTTPS
Больше гибкости при проверках работоспособности и условиях отработки отказа
Базовое кеширование (v1.8 — 2017)
Настраиваемый формат журнала, чтобы импортировать журналы доступа в kibana/splunk/graylog
Подробная страница состояния, чтобы увидеть активные запросы и состояние серверов
Экспортируемые метрики для интеграции с решениями для мониторинга (графит / прометей / данные)
Более ориентированный на высокую производительность. Лучше указывать на обработку 100 тыс. Соединений или 40 GbE-интерфейсов.

Nginx:

Балансировка нагрузки HTTP и HTTPS (TCP — UDP в платной версии)
Больше гибкости при кэшировании
Настраиваемый формат журнала, чтобы импортировать журналы доступа в kibana/splunk/graylog
Нет страницы статуса (только платная версия)
Нет экспортируемых метрик (только платная версия)
Может обслуживать локальные файлы
Может обслуживать приложения FastCGI (не CGI)

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

Nginx является открытым ядром, и многие функции доступны только в платной версии. Примечательно, что ему не хватает страницы состояния и показателей мониторинга, что является большим НЕТ НЕТ для работы балансировщика нагрузки.

2019-03-13 01:08

HAProxy — это просто балансировщик нагрузки / обратный прокси. Nginx — это веб-сервер, который также может работать как обратный прокси-сервер.

Вот некоторые отличия:

HAProxy:

Поддерживает ли TCP и HTTP-прокси (SSL добавлен с 1.5-dev12)
Больше вариантов ограничения скорости
Автор отвечает на вопросы здесь о сбое сервера;-)

Nginx:

Поддерживает SSL напрямую
Также есть кеширующий сервер

В Stack Overflow мы в основном используем HAProxy с nginx для разгрузки SSL, поэтому HAProxy — моя рекомендация.

2011-02-03 15:23

Я использую nginx для внешнего интерфейса HAProxy, но только для завершения SSL.

HAProxy — гораздо более настраиваемый и управляемый балансировщик нагрузки (по моему опыту).

Я также включил Varnish для кэширования статических объектов. (как специфический бэкэнд HAProxy)

Смотрите этот вопрос о сбое сервера для получения дополнительной информации. Заказ nginx/ лака /haproxy

2011-02-03 05:49

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

2012-10-16 15:40

Тестирование системы

AB (Apache Benchmark) — простой инструмент тестирования нагрузки от Apache Foundation. Еще одна программа для тестирования — Siege. Также доступен инструмент на основе Python — Locust.

После установки Locust нужно будет создать файл locust в каталоге, из которого вы запускаете приложение:

from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000

Затем запускаем инструмент из командной строки:

locust --host=https://my-website.com

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

Подготовка apache к мониторингу

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

С веб сервером apache мне давно не приходилось связываться в отрыве от bitrix сайтов, поэтому решил показать его мониторинг на его примере. Здесь принцип будет такой же, как и раньше — забираем страницу с информацией о веб сервере, который apache нам предоставляет через свой модуль mod_status.

Дальше мы передаем страницу в zabbix server и там парсим регулярками по зависимым элементам данных. Первым делом вам надо настроить указанный выше модуль. Подробности на официальном сайта — https://httpd.apache.org/docs/current/mod/mod_status.html. Если кратко, то просто добавьте в конфиг apache примерно следующие настройки.

<Location "/server-status">
    SetHandler server-status
    Require host localhost
</Location>

Bitrixenv автоматически все настроит, если вы через консольное меню включите Monitoring in pool. Запустится роль ansible, которая настроит в том числе apache, установит и запустит nagios и munin. Если они вам не нужны, то просто добавьте приведенный выше кусок конфига в /etc/httpd/bx/custom/z_bx_custom.conf.

Listen localhost:8886
<IfModule mod_status.c>
    ExtendedStatus On
</IfModule>
<VirtualHost localhost:8886>
    <Location /server-status>
        SetHandler server-status
        Require ip 127.0.0.1
	require ip ::1
    </Location>
</VirtualHost>

После этого проверьте настройки apache и перезапустите его.

# apachectl -t
# apachectl restart

Если все настроили правильно, то состояние apache можно посмотреть в консоли.

# curl http://localhost:8886/server-status?auto
Total Accesses: 1051
Total kBytes: 104324
CPULoad: 4.7515
Uptime: 1835
ReqPerSec: .572752
BytesPerSec: 58216.8
BytesPerReq: 101644
BusyWorkers: 1
IdleWorkers: 29
Scoreboard: _______________________W______

И на всякий случай проверьте, что zabbix-agent может получать эту же информацию.

# zabbix_agentd -t web.page.get

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

Определение¶

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

С точки зрения «железа», веб-сервер — это компьютер, который хранит файлы сайта (HTML-документы, CSS-стили, JavaScript-файлы, картинки и другие) и доставляет их на устройство конечного пользователя (веб-браузер и т.д.). Он подключен к сети Интернет и может быть доступен через доменное имя, подобное .
С точки зрения ПО, веб-сервер включает в себя несколько компонентов, которые контролируют доступ веб-пользователей к размещенным на сервере файлам, как минимум — это HTTP-сервер. HTTP-сервер — это часть ПО, которая понимает URL’ы (веб-адреса) и HTTP (протокол, который ваш браузер использует для просмотра веб-страниц).

На самом базовом уровне, когда браузеру нужен файл, размещенный на веб-сервере, браузер запрашивает его через HTTP-протокол. Когда запрос достигает нужного веб-сервера («железо»), сервер HTTP (ПО) принимает запрос, находит запрашиваемый документ (если нет, то сообщает об ошибке ) и отправляет обратно, также через HTTP.

Создание настроек для нескольких сайтов

После настройки основного сайта рекомендуем Вам составить список сайтов и определить, какой сайт должен открываться по IP-адресу сервера (если он один). Затем в директории /etc/nginx/sites-available создать файлы с сайтами, заполнить их настройками и сохранить их. Так как сервер учитывает только настройки из директории /etc/nginx/sites-enabled, то необходимо создать символическую ссылку на файл:

$ ln -s /etc/nginx/sites-available/имя_сайта
/etc/nginx/sites-enabled/имя_сайта

Это позволит Вам отключать сайт на время без удаления его конфигурационного файла. Проверить конфигурацию NGINXпосле работ можно командой:

$ sudo nginx -t

Если вывод содержит «syntax is ok» и «test is successful», то можно применить настройки, написав команду:

$ sudo service nginx reload

Как используется и работает nginx

NGINX является широко используемым продуктом в мире IT, по популярности уступая лишь Apache.
Как правило, его используют либо как самостоятельный HTTP-сервер, используя в бекенде PHP-FPM, либо в связке с Apache, где NGINX используется во фронтэнде как кеширующий сервер, принимая на себя основную нагрузку, отдавая статику из кеша, обрабатывая и отфильтровывая входящие запросы от клиента и отправляя их дальше к Apache. Apache работает в бекэнде, работая уже с динамической составляющей проекта, собирая страницу для передачи её в кеш NGINX и запрашивающему её клиенту. Это если в общих чертах, чтобы понимать суть работы, так-то внутри всё сложнее.

Управление службами с помощью systemctl

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

После завершения установки Nginx уже настроен для автоматического запуска. Nginx выполняется как daemon. Состояние деймона можно проверить с помощью systemctl.

Команда используется для управления «службами» для таких задач, как отображение состояния службы или ее запуск и остановка. Некоторые доступные параметры: запуск, остановка, перезапуск, включить, отключить и состояние. Чтобы проверить состояние Nginx, запустите .

Эта команда создает некоторые полезные сведения. Как показано на этом скриншоте, Nginx находится в состоянии, а iD процесса экземпляра Nginx — 8539

Кроме того, обратите внимание на и заявления. означает, что этот daemon начнется при перезапуске машины и означает, что nginx включен по умолчанию при установке

Поэтому при запуске сервера Nginx запустится автоматически.

Мониторинг php-fpm в zabbix

Теперь настраиваем мониторинг php-fpm на сервере zabbix. Действуем по аналогии с мониторингом nginx. Забираем страницу состояния php-fpm на сервер мониторинга и там его парсим в зависимых элементах данных.

С php-fpm будет один нюанс. Нам все-таки придется менять параметры zabbix agent. Настраивать мониторинг php-fpm очень легко, потому что он из коробки умеет отдавать все свои метрики в формате json. Это очень удобно, так как его не надо парсить регулярками. Достаточно только указать JSONpath для получения необходимой метрики.

Нам нужно добавить один UserParameter следующего содержания.

UserParameter=phpfpm.json,curl -s 'http://localhost/phpfpm-status?json' | tr ' ' _

Перезапускаем zabbix-agent и проверяем, что он корректно возвращает необходимые данные.

# systemctl restart zabbix-agent
# zabbix_agentd -t phpfpm.json
phpfpm.json

Дальше как и в случае с nginx, идем в веб интерфейс и импортируем шаблон zabbix-phpfpm-template.xml. Добавляем этот шаблон к серверу и ждем обновления данных. Проверяем их поступление, как обычно, в Monitoring -> Latest Data:

Если все в порядке, то проверяйте графики, создавайте необходимые дашборды. Я свой покажу в самом конце.

В шаблоне php-fpm настроен только один триггер, который следит за тем, чтобы хотя бы один процесс php-fpm был запущен. Раньше я использовал больше триггеров, но потом решил, что они не очень нужны. Состояние работы сайта лучше оценивать по финальным метрикам, таким как скорость загрузки страниц, доступность сайта и коды ответов. Об этом я подобно написал в статье про мониторинг сайта в zabbix. Если с этими метриками проблемы, нужно идти в мониторинг, смотреть графики и решать, что нужно изменить в конфигурации. Это мое личное мнение, с ним можно поспорить. Для этого есть комментарии, буду рад замечаниям и обсуждениям по существу.

Apache

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

Устанавливаем apache и модуль для php:

apt-get install apache2 libapache2-mod-php

Заходим в настройки портов:

vi /etc/apache2/ports.conf

И редактируем следующее:

Listen 8080
#<IfModule ssl_module>
# Listen 443
#</IfModule>
#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

* мы настроили прослушивание на порту 8080, так как на 80 уже работает NGINX. Также мы закомментировали прослушивание по 443, так как и он будет слушаться NGINX.

Теперь открываем настройку следующего модуля:

vi /etc/apache2/mods-available/dir.conf

И добавляем впереди индексных файлов index.php:

<IfModule dir_module>
DirectoryIndex index.php index.html …
</IfModule>

* если не указан конкретный скрипт, сначала веб-сервер пытается найти и запустить index.php, затем index.html и так далее.

Открываем основной конфигурационный файл для apache:

vi /etc/apache2/apache2.conf

Рядом с опциями Directory дописываем:

<Directory /var/www/*/www>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>

* где Directory указывает на путь, для которого мы хотим задать настройки; AllowOverride — позволит переопределить все настройки с помощью файла .htaccess; Options задает некоторые настройки: Indexes разрешает списки каталогов, ExecCGI разрешает запуск cgi скриптов, Require all granted — предоставляет всем доступ к сайтам в данном каталоге.

Ниже допишем:

<IfModule setenvif_module>
SetEnvIf X-Forwarded-Proto https HTTPS=on
</IfModule>

* этой настройкой мы при получении заголовка X-Forwarded-Proto со значением https задаем переменную $_SERVER равную on. Данная настройки критична для функционирования некоторых CMS.

Запрещаем mpm_event:

a2dismod mpm_event

* по умолчанию, apache2 может быть установлен с модулем мультипроцессовой обработки mpm_event. Данный модуль не поддерживает php 7 и выше.

Разрешаем модуль мультипроцессовой обработки mpm_prefork:

a2enmod mpm_prefork

Разрешаем модуль php:

a2enmod php7.4

* в данном примере установлен php версии 7.4.

Разрешаем модуль setenvif:

a2enmod setenvif

Разрешаем модуль rewrite:

a2enmod rewrite

В процессе включения модулей, если мы видим «Module … already enabled», значит модуль уже включен.

Разрешаем автозапуск Apache и перезапускаем службу:

systemctl enable apache2

systemctl restart apache2

Открываем браузер и вводим в адресную строку http://<IP-адрес сервера>:8080. Мы должны увидеть привычную страницу:

* в разделе Server API мы должны увидеть Apache.

NGINX + Apache

Ранее мы настроили связку nginx + php-fpm. Теперь настроим nginx + apache. Открываем конфигурационный файл nginx для сайта по умолчанию:

vi /etc/nginx/sites-enabled/default

Находим наш настроенный location для php-fpm:

…
location ~ \.php$ {
set $root_path /var/www/html;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
…

и меняем на:

…
location ~ \.php$ {
proxy_pass http://127.0.0.1:8080;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…

Проверяем и перезапускаем nginx:

nginx -t

systemctl restart nginx

Пробуем открыть в браузере http://<IP-адрес сервера> — должна открыться та же страница, что при проверке Apache (с добавлением 8080):

Apache Real IP

Запросы на apache приходят от NGINX, и они воспринимаются первым как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей. Для решения проблемы будем использовать модуль remoteip.

Создаем конфигурационный файл со следующим содержимым:

vi /etc/apache2/mods-available/remoteip.conf

<IfModule remoteip_module>
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1/8
</IfModule>

Активируем модуль:

a2enmod remoteip

Перезапускаем apache:

systemctl restart apache2

Для проверки настройки открываем браузер и вводим в адресную строку http://<IP-адрес сервера>, где откроется наша страница phpinfo. В разделе Apache Environment мы должны увидеть внешний адрес компьютера, с которого обращаемся к серверу в опции REMOTE_ADDR.

Блокировка прямого доступа к Apache (опционально)

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

Обязательно используйте IP-адрес своего сервера вместо выделенного красным адреса в примере. Когда ваш брандмауэр заблокирует порт , убедитесь в недоступности Apache через этот порт. Для этого откройте браузер и попробуйте получить доступ к любому из доменных имен Apache через порт . Например: http://example.com:8080

Браузер должен вывести сообщение об ошибке Unable to connect (Не удается подключиться) или Webpage is not available (Страница недоступна). Если используется опция IPtables , сторонний наблюдатель не увидит разницы между портом и портом, где отсутствует какое-либо обслуживание.

Примечание. По умолчанию правила IPtables теряют силу после перезагрузки системы. Существует несколько способов сохранения правил IPtables, но проще всего использовать параметр в хранилище Ubuntu.

Теперь настроим Nginx для обслуживания статических файлов для сайтов Apache.

Шаг 5. Настройка редиректа

Чтобы все запросы по http автоматически перенаправлялись на https, необходимо настроить перенаправление (redirect). Есть несколько способов это сделать.

В конфигурационном файле

Открываем файл с настройкой виртуальных доменов (как в шаге 3) и дописываем следующее:

<VirtualHost *:80>
ServerName site.ru
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

* в конкретном примере, мы перенаправили все запросы для сайта site.ru.
** обратите особое внимание, что если у Вас уже есть VirtualHost *:80 для настраиваемого сайта, необходимо его закомментировать или отредактировать

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

Чтобы перенаправление работало в Apache, необходимо установить модуль rewrite.

а) в CentOS открываем конфигурационный файл и проверяем наличие строки:

vi /etc/httpd/conf.modules.d/00-base.conf

LoadModule rewrite_module modules/mod_rewrite.so

* если ее нет, добавляем; если она закомментирована, снимаем комментарий.

systemctl restart httpd

б) в Ubuntu:

a2enmod rewrite

systemctl restart apache2

Использование Nginx в качестве обратного прокси

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

URL-адрес проксируемого сервера устанавливается с директивы и может использовать или качестве протокола, доменного имени или IP-адреса, а также необязательного порта и URI в качестве адреса.

Приведенная выше конфигурация указывает Nginx передавать все запросы в прокси-серверу по адресу .

В дистрибутивах на основе Ubuntu и Debian файлы серверных блоков хранятся в каталоге , а в CentOS — в .

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

Если посетитель обращается к , Nginx передаст этот запрос по прокси на .

Когда адрес проксируемого сервера содержит URI, ( ), URI запроса, который передается на проксируемый сервер, заменяется URI, указанным в директиве. Если адрес прокси-сервера указан без URI, полный URI запроса передается на прокси-сервер.

2: Настройка Apache и PHP-FPM

Теперь нужно настроить порт Apache (8080) и подготовить веб-сервер к работе с PHP-FPM с помощью модуля mod_fastcgi. Откройте конфигурационный файл Apache:

Найдите строку:

Измените её:

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

Примечание: Обычно 127.0.0.1:8080 прослушивают прокси-серверы, но это позволит установить в качестве значения переменной окружения РНР server_addr loopback IP-адрес вместо внешнего IP сервера. В данном случае целью является такая настройка Apache, при которой веб-сайты, поддерживаемые Apache, не увидят обратного прокси-сервера. Таким образом, Apache нужно настроить для прослушивания порта 8080 на всех IP-адресах.

После этого нужно отредактировать стандартный виртуальный хост Apache. Директива <VirtualHost> в этом файле обслуживает сайты только на порт 80, это нужно изменить. Откройте файл:

Первая строка должна выглядеть так:

Измените её:

Сохраните и закройте файл. Перезапустите Apache.

Убедитесь, что порт изменился:

Вывод должен выглядеть так:

Шаг 1. — Подготовка

На этапе подготовки мы убеждаемся что у нас есть всё необходимое для выполнения дальнейшей инструкции:

Нам нужна установленная ОС Ubuntu Server 18.04 — Вам в помощь статья — Установка Ubuntu Server 18.04 LTS
Ubuntu Server 18.04 должна иметь статический IP-адрес и доступ в интернет — Настройка сети в Ubuntu Server 18.04
Необязательно, но желательно включить фаервол UFW — Первоначальная настройка Ubuntu Server 18.04

Посмотрим свой IP-адрес, командой ifconfig.(Рис.1)

ifconfig

Рис.1 — Командой ifconfig узнаём IP-адрес нашего сервера.

Адрес моего сервера — 192.168.3.9, в этой статье я буду вводить его в браузере на другом ПК, для проверки работоспособности Nginx. Вы должны будете ввести свой IP-адрес.

Если у вас, допустим, Ubuntu Desktop 18.04 и нету возможности подключиться с другого ПК, то вводите на своей же Ubuntu в браузере -«localhost» или IP-адрес — 127.0.0.1

Всё! На этом подготовка завершена.

7: Настройка Nginx для поддержки виртуальных хостов Apache

Теперь нужно создать дополнительный хост Nginx для нескольких доменов. Запросы к этим доменам будут проксироваться на Apache.

Создайте новый файл:

Добавьте в него следующий блок кода. Он задаёт имена сайтов Apache и проксирует их запросы. В proxy_pass укажите внешний IP-адрес сервера.

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

Проверьте настройки:

Перезапустите Nginx, если ошибок не обнаружено.

Найдите раздел PHP Variables. Переменные SERVER_SOFTWARE и DOCUMENT_ROOT подтверждают, что запрос был обработан Apache. Переменные HTTP_X_REAL_IP и HTTP_X_FORWARDED_FOR добавлены сервером Nginx и отображают внешний IP-адрес текущей машины.

Теперь Apache использует Nginx в качестве обратного прокси-сервера. Теперь нужно установить переменную Apache, REMOTE_ADDR. Она позволяет скрыть прокси-сервер.

Важные элементы конфигурации

worker_processes — количество рабочих процессов, которые будет использовать сервер. Число должно соответствовать количеству ядер процессора.
worker_connections — это максимальное количество подключений каждого рабочего процесса. Чем выше показатель, тем больше человек обслуживается одновременно.
access_log & error_log — эти файлы используется для регистрации любой ошибки и попыток получения доступа. Журналы изучаются для устранения неполадок и при аварийном завершении работы.
gzip — это настройки для «сжатия» запросов Nginx. Включение параметра позволит повысить производительность. По умолчанию поднастройки закомментированы.
gzip_comp_level — уровень сжатия от 1 до 10. Этот показатель обычно не превышает 6.
gzip_types — это перечень типов ответов, к которым применяется сжатие.

Сервер может обслуживать множество сайтов. Файлы, которые определяют какие именно, находятся в директории /etc/nginx/sites-available.

Чтобы Nginx работал с сайтами, их необходимо слинковать с /etc/nginx/sites-enabled.

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

Символьная ссылка — это путь к файлу. Общий синтаксис для неё выглядит так:

ln -s <на какой существующий объект будет вести> <создаваемый симлинк>

Примеры ссылок для каталога и файла:

ln -s /usr/share/nginx/html/index.php /home/dmosk/;
ln -s /usr/share/nginx/html /home/dmosk/.

Директория sites-available содержит конфигурацию виртуальных хостов. Это позволяет веб-серверу настраиваться для множества сайтов с разной конфигурацией. Сайты в этой директории не задействуются и будут обслуживаться только, если сделать символьную ссылку на папку sites-enabled.

Как в NGINX сделать редирект на мобильную версию сайта

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

### Устанавливаем переменную в 0. В неё пишем 1, если обнаружили мобильную версию браузера
set $mobile_rewrite 0;

if ($http_user_agent ~* "(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino") {
  set $mobile_rewrite 1;
}

if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez(0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-)|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10|n20|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-(|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)") {
  set $mobile_rewrite 1;
}
### Мобильный барузер обнаружен, редиректим на мобильный поддомен, в моём случае, m.example.com
if ($mobile_rewrite = 1) {
    rewrite ^ http://m.example.com/$request_uri redirect;
    break;
}

8: Установка и настройка mod_rpaf

Теперь нужно установить модуль mod_rpaf, который будет переопределять значения REMOTE_ADDR, HTTPS и HTTP_PORTс помощью значений, предоставленных обратным прокси-сервером. Без этого модуля некоторые приложения PHP

могут потребовать изменений в коде. Модуль можно найти в репозитории Ubuntu, его пакет называется libapache2-mod-rpaf. Однако этот пакет устаревший и не поддерживает некоторых директив. Потому лучше скомпилировать модуль из исходного кода.

Чтобы собрать модуль, установите пакеты:

Загрузите последний релиз с GitHub:

Распакуйте его:

Перейдите в рабочий каталог:

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

В каталоге mods-available создайте файл для модуля rpaf.

Вставьте в файл:

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

Создайте файл для настроек модуля:

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

Этот файл содержит следующие настройки:

RPAF_Header: хедер для клиентского IP-адреса.
RPAF_ProxyIPs: IPпрокси-сервера, для которого нужно отредактировать запросы.
RPAF_SetHostName: обновление имени виртуального хоста для ServerNameиServerAlias.
RPAF_SetHTTPS: настраивает переменную среды HTTPSна основе значения X-Forwarded-Proto.
RPAF_SetPort: устанавливает переменную среды SERVER_PORT (эта настройка полезна для Apache на SSL).

Сохраните файл rpaf.conf и включите модуль:

Эта команда создаст символьную ссылку файлов rpaf.load и rpaf.conf в каталоге mods-enabled. Проверьте настройки:

Перезапустите Apache, если ошибок не обнаружено.

Откройте страницу phpinfo() одного из сайтов Apache и найдите раздел PHP Variables. Переменная REMOTE_ADDR теперь должна содержать IP локального сервера.

Установка Nginx на CentOS

Рассмотрим практически установку Nginx на Linux, взяв за основу один из самых популярных дистрибутивов данной операционной системы – CentOS.

Добавляем yum-репозиторий Nginx на ОС с помощью команды:

sudo rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

Для установки используем команду sudo yum install nginx. Подтверждаем появившееся извещение.
Для запуска сервера используем команду:
```
sudo systemctl start nginx.service
```
Проверить, успешна ли установка, можно, посетив общественный IP-адрес сервера. Узнать его можно через команду:
```
ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//'
```
Чтобы Nginx автоматически запускался при загрузке ОС, вводим:
```
sudo servicectl enable nginx.service
```

Заключение

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

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

Оцените материал: