Шаг 10 — Блокировка прямого доступа к Apache (опционально)
Поскольку Apache прослушивает порт на публичном IP-адресе, он доступен кому угодно. Его можно заблокировать с помощью следующей команды IPtables в наборе правил брандмауэра.
Обязательно используйте IP-адрес своего сервера вместо выделенного красным адреса в примере. Когда ваш брандмауэр заблокирует порт , убедитесь в недоступности Apache через этот порт. Для этого откройте браузер и попробуйте получить доступ к любому из доменных имен Apache через порт . Например: http://example.com:8080
Браузер должен вывести сообщение об ошибке Unable to connect (Не удается подключиться) или Webpage is not available (Страница недоступна). Если используется опция IPtables , сторонний наблюдатель не увидит разницы между портом и портом, где отсутствует какое-либо обслуживание.
Примечание. По умолчанию правила IPtables теряют силу после перезагрузки системы. Существует несколько способов сохранения правил IPtables, но проще всего использовать параметр в хранилище Ubuntu. Прочитайте эту статью, чтобы узнать больше о настройке IPTables.
Теперь настроим Nginx для обслуживания статических файлов для сайтов Apache.
Создание первого файла server block (виртуального хоста) конфигурации
В отличие от apache в nginx виртуальные хосты называются server block.
Из коробки на веб-сервере активирован только один виртуальный хост (server block) — «default» . Находится он «/etc/nginx/sites-available/defaul».
Будем использовать его в качестве шаблона для двух сайтов.
Для начала скопируем дефолтный файл в новый веб-сайт.
Отредактируем default.
Немного о параметрах конфига.
listen — указывает на IP-адрес и порт на который программа или сайт будет слушать. Здесь можно указать default_server — тогда этот server block будет использоваться по умолчанию.
Для примера, установим параметр default_server для первого веб-сайта, однако его можно перенести на любой другой веб-сайт или оставить в default.
server_name — доменные имена, на которые будет отзываться сайт. Добавим название веб-сайта с www и без.
root — полный путь к файлам виртуального хоста.
Укажем корневой каталог первого веб-сайта.
Заменим:
На:
Итоговый файл с конфигурацией выглядит так:
Сохраните файл.
На этом первичная настройка первого веб-сайта закончена. Далее переходим ко второму сайту.
В чем выигрыш?
Возьмем тот же Apache (prefork или itk). Мы выставили у него максимальное количество рабочих процессов, равное 35
Что это значит? Это значит, что мы сможем одновременно обработать только 35 запросов пользователей и это не важно — запрос это за статикой или за динамикой. 35 всего
У вас на странице 100 картинок+js+css-ок? Значит, большая их часть будет висеть в очереди внутри сервера Apache и ждать, когда пользователь получит предыдущие 35 ответов.
В случае с Nginx + PHP-FPM важнее всего количество процессов PHP-FPM. Мы можем поставить его таким же равным тридцати пяти. Что это значит? Это значит, что мы можем одновременно обрабатывать 35 запросов к динамике, запросы же к статике nginx разгребет своими силами в количестве 3000+ одновременных почти на любой слабой VPS.
Расход оперативной памяти при использовании Nginx+PHP-FPM меньше, чем на «голом» Apache, при равном количестве процессов (FPM и Apache). Скорость обработки запросов выше.
На расход CPU внутри PHP замена Apache на FPM никак не скажется. CPU в первую очередь кушает Ваш PHP-код, а пока его никто не оптимизирует, работать быстрее и экономичнее он не начнет.
FPM
SAPI, он же Server API. В php есть несколько таких API для разных вариантов его работы:
-
CLI SAPI — в качестве консольной команды `php` для запуска наших кронов и других cli-программ (Command Line Interface)
-
apxs2 SAPI — в качестве модуля к apache2
-
CGI SAPI — в качестве запускаемого на каждом запросе CGI (сейчас так почти никто не делает)
-
FPM SAPI — Fast Process Manager, написанный для PHP разработчиками из комании Badoo и теперь поддерживаемый сообществом
Работа с FPM отличается от работы с Apache в первую очередь тем, что FPM — это только PHP. Это не веб-сервер, не что-то умное. Это наоборот — максимально простой, легкий и быстрый менеджер процессов для PHP. В отличие от апача, он даже не использует http-протокол, а работает со специальным fastcgi-протоколом. В первую очередь FPM быстрее обрабатывает запросы благодаря его легковесности и простоте.
Во вторую очередь, FPM действительно умный менеджер процессов. Он контролирует количество работающих PHP-процессов, частоту их перезапуска для борьбы с утечками памяти (да, модули php как и всегда текут) и прочие простые вещи, необходимые для контроля сервера.
Нужно помнить, что независимо от того, какое SAPI вы используете, будь то модуль Apache, CGI или PHP-FPM — это не отнимает ни каких особенностей php. А первая его особенность:
-
Один процесс одновременно обрабатывает один запрос. Это абсолютно так же свойственно для PHP-FPM, как и для Apache.
-
Количество процессов определяет, сколько одновременно может «висеть» запросов в обработке.
-
Точно также, как и Apache, FPM подвержен DoS-атакам путем «длительных запросов». Допустим, у Вас на сервере работает не более 50-ти процессов PHP-FPM, а это значит, что если 50 пользователей одновременно начнут делать upload файла (пусть даже небольшого, но главное, чтобы они делали это медленно) — пятьдесят первый пользователь получит ошибку 504, т.к. FPM не возьмет его запрос на обработку, пока не разберется с теми, что у него уже есть.
5: Настройка локальных хостов (опционально)
Если вместо настоящих доменных имён вы использовали фиктивные имена, вы можете испытать новые виртуальные хосты, не подключаясь при этом к доменному имени. Для этого нужно настроить на компьютере локальные хосты.
Это не позволит другим посетителям просматривать сайт, но даст вам возможность проверить работу и настройки каждого сайта. Этот метод работает путем перехвата запросов, которые, как правило, поступают в DNS для разрешения доменных имен. Вместо этого можно указать IP-адреса, которые будут использоваться локальным компьютером, при поступлении запросов к доменным именам.
Примечание: прежде чем приступить к выполнению данного раздела, убедитесь, что вы находитесь на компьютере, а не на сервере. Для выполнения данного раздела нужно иметь root-права и состоять в административной группе, чтобы иметь возможность редактировать системные файлы.
В системах Mac или Linux войдите как root-пользователь (su) и откройте файл hosts:
При использовании Windows обратитесь к сайту Microsoft.
На данном этапе понадобится внешний IP-адрес и домены, которые нужно направить на сервер. Допустим, внешний IP-адрес сервера 111.111.111.111; в таком случае строки будут выглядеть так:
Сохраните и закройте файл.
Дополнительные материалы по Freebsd
Онлайн курс по Linux
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Что даст вам этот курс:
- Знание архитектуры Linux.
- Освоение современных методов и инструментов анализа и обработки данных.
- Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
- Владение основными рабочими инструментами системного администратора.
- Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
- Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .
| Рекомендую полезные материалы по Freebsd: |
Описание установки Freebsd 11 на одиночный диск, либо на софтовый raid1, сделанный средствами zfs, которые поддерживает стандартный установщик. Базовая настройка Freebsd, которую можно выполнить после установки сервера общего назначения. Представлены некоторые рекомендации по повышению удобства пользования и безопасности. Описание и нюансы обновления системы Freebsd с помощью утилиты freebsd-update. Показано пошагово на конкретном примере обновления. Настройка Freebsd шлюза для обеспечения выхода в интернет. Используется ipfw и ядерный нат, dnsmasq в качестве dhcp и dns сервера. Мониторинг сетевой активности с помощью iftop. Подробная настройка на Freebsd прокси сервера squid + sams2 — панели управления для удобного администрирования. Настройка максимально быстрого web сервера на базе Freebsd и nginx + php-fpm. Существенный прирост производительности по сравнению с классическим apache. Настройка web сервера на Freebsd в связке с apache, nginx, php и mysql. Пошаговая установка и настройка каждого компонента. |
Мониторинг 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. Если с этими метриками проблемы, нужно идти в мониторинг, смотреть графики и решать, что нужно изменить в конфигурации. Это мое личное мнение, с ним можно поспорить. Для этого есть комментарии, буду рад замечаниям и обсуждениям по существу.
