bitrix php fpm config

Битрикс в связке Nginx+PHP-FPM, настройка ЧПУ, а так же композитный кэш с отдачей через nginx. Доработанная конфигурация

Цель: Предоставить конфигурацию виртуального сервера Nginx для работы Битрикс-cms в связке Nginx+PHP-FPM. Который в прочем подойдёт и для связки Nginx+Apache2, с небольшими доработками.

Целевая аудитория: Администраторы серверов, продвинутые администраторы сайтов, программисты.

Cтатей на эту тему достаточно, но если смотреть не официальные, то там как правило содержатся ошибки, а в официальных полно if которые в Nginx использовать не желательно. Надеюсь после того как я выложу данный конфиг к связке Nginx+PHP-FPM станут относиться серьёзнее.

Я покажу реализацию отдачи файлового композитного кэша. В целом отдача с memcached делается по аналогии. В конфигурации отдачи файлового кэша я насчитал 11 if, от которых я и избавился переделав их на map.

Начну с упрощённого варианта ЧПУ для тех кому нужна просто связка Nginx+PHP-FPM без отдачи композитного кэша через Nginx. Подразумевается что секция server уже настроена, с доменными именами и передачей в php-fpm.

Как не удивительно смотря на те полотна конфигов которые мне попадались, этого достаточно чтобы битрикс корректно заработал. Если нужен редирект с index.php и index.html на без, то нужно ещё дописать вот эту строку:

К сожалению тут достойной замене if нет. Но данная строчка работает не создавая проблем.

Хочу подчеркнуть что это именно минималистичная конфигурация без правил для статики, сжатия, и я там прикрыл только файлы композитного кэша от прямого доступа. Конфигурация которая прикрывает определённые места от прямого доступа через nginx довольно индивидуальна. У меня есть вот такой набор который может кому-то подойти. Но использовать нужно аккуратно с осознанием дела. Учитите что внесение данных локейшенов в свою конфигурацию может привести к неработоспособности сайта или части его функций.

Ну и конечно пример location для статических файлов

Теперь перейдём к конфигу для работы композита с отдачей файлов кэша через nginx. Первым делом необходимо определить можно ли отдавать данному запросу композитный кэш или его нужно отправить на обработку через php. Для этого в Nginx в секции http добавим несколько map, а так же несколько директив:

Далее уже непосредственно в секции server прописываем

Ну и для понимания как примерно будет выглядеть минимальная конфигурация секции server

Источник

Birtix + Nginx ( О нюансах перевода сайтов под управлением CMS «Битрикс» на работу через легковесную спарку «Nginx + PHP-FPM». )

28 июня 2017 (обновлено 2 декабря 2017)

OS: «Linux Debian 9», «Linux Ubuntu 16 LTS».

Расскажу здесь о некоторых особенностях настройки площадки для запуска сайтов под управлением CMS «Bitrix». Эта система управления контентом продвигается в продажах как средство легко и непринуждённо создавать сайты. В инструкции от разработчиков сайты под управлением движка «Битрикс» рекомендуется разворачивать в среде исполнения «Apache + modPHP», даже распространяют готовую сборку в этой конфигурации под названием «VMBitrix» на базе «CentOS/Ubuntu», но мне такой подход сильно не нравится и здесь будет изложена последовательность действий, которые необходимо предпринять для корректной работы CMS «Bitrix» с «Nginx + PHP-FPM».

Уже лет десять как прошло с того момента, как стало странно запускать сервисы непосредственно на аппаратуре физического сервера, так что да, мы готовим для web-сервера виртуальную площадку, соблюдая определённые условия.

В KVM-Qemu для виртуального диска и сетевой карты обязательно всегда использовать VirtIO-драйверы:

В VMware следует обязательно использовать драйверы «VMware Paravirtual (PVSCSI)» для виртуального HDD и «VMXNET 2/3» для виртуальных NIC:

Тест производительности дисковой подсистемы.

Тест записи, по возможности в обход «кеша»:

Выше приведены показатели тестирования вначале дискового массива «NetApp» из SSD, а следом SSD и обычного SATA2 дисков моей рабочей станции.

Защищаем административный вход.

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

.
# Отключаем возможность удалённого входа для суперпользователя
PermitRootLogin no

# Запрещаем использование «пустых» паролей при подключении
PermitEmptyPasswords no

# Запрещаем передачу пользовательских переменных окружения
PermitUserEnvironment no

# Запрещаем перенаправление портов пользователя и транзит подключений (это конечный сервер, а не «шлюз»)
GatewayPorts no
X11Forwarding no
.

Добавляем аккаунты web-разработчиков.

По хорошему web-разработчику нечего делать на web-сервере и проекты должны выгружаться в рамках процессов CI/CD, но реальность такова, что на мелких сайтах работа ведётся с кодом напрямую. Потому добавляем нужных пользователей:

Явно включаем пользователя в группу, от имени которой работает web-сервер:

Включаем для пользователя web-разработчика возможность через SUDO работать в окружении привелегий и переменных «www-data»:

Таким образом, например, web-разработчику можно будет изменить параметры запуска задач по расписанию:

Файловая структура сайтов.

Обозначу сразу незаметную многим начинающим специалистам особенность: в Linux файлы и директории по умолчанию создаются с групповыми разрешениями доступа «только чтение» (общесистемная установка «umask 0022»). Отсюда истекает проблема, когда файл созданный web-сервером или PHP-интерпретатором оказывается недоступным для изменения web-разработчику этого сервера. По мере развития Linux это решалось разными способами, но на данный момент проще всего переопределить политику доступа применительно к структуре директорий с помощью надстройки над подсистемой регулирования доступа «POSIX ACL».

Предпишем устанавливать всем создаваемым впредь файлам (и директориям) разрешения полного доступа как для владельца, так и группы, при этом ограничиваем чтение и запись всем остальным:

Проверить установки можно следующим способом:

Исполняемое ядро CMS «Bitrix» может быть использовано для обслуживания нескольких сайтов. В простейшем случае программное ядро и директория загрузки объектов группы сайтов выносятся отдельно от таковых и подключаются через символические ссылки.

Разделяемый между сайтами «one.example.net» и «two.example.net» движок «Bitrix» (впоследствии к этим двум сайтам можно «прилеплять» дополнительные, по отработанной схеме):

Разделяемая между сайтами «one.example.net» и «two.example.net» директория для загрузок файлов:

Разделяемая между сайтами директория временных файлов:

И файловая структура поддержки сайтов:

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

Конечно же, закрываем доступ к данным сайтов всем посторонним:

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

В настройках FPM-пула изменим ряд параметров для достижения лучшей производительности:

Возьмём за основу конфигурационный файл PHP-FPM (как наиболее активно используемый):

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

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

Удовлетворяем ресурсные аппетиты Bitrix-сайтов.

CMS «Bitrix» даже в представлениях его разработчиков настолько прожорлив и неоптимизирован, что для удовлетворения требованиям PCRE-функциональности теста «самопроверки» (site_checker.php) размер доступного PHP «стека» приходится увеличивать в десять тысяч (. ) раз.

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

В рамках классического «unix-way» задаём новые ограничения пользователю, от имени которого запускаются наши web-приложения:

Для приложений, запускаемых через игнорирующий системные лимиты «Systemd» придётся создавать индивидуальные конфигурации.

Уточняем наименование сервиса, в рамках которого запущен PHP-FPM:

Просматриваем параметры текущей конфигурации сервиса:

Теперь можно воспользоваться встроенной функциональностью «systemctl edit php7.0-fpm.service» для дополнения существующей конфигурации, но я предпочитаю вручную создать в соответствующем месте директорию для автоматически включаемых сервисом дополнительных файлов конфигурации с удобным мне именем файла:

Указываем «Systemd» перечитать и принять новый набор конфигураций, после чего перезапускаем сервис PHP-FPM:

Особо одарённые стремлением курочить системные настройки могут внести свои параметры лимитирования прямо в файлы конфигурации сервиса «/etc/init.d/php7.0-fpm» или «/lib/systemd/system/php7.0-fpm.service», но это «фу-фу»-путь.

Чтобы убедиться, что лимиты настроены верно и применяются к целевым приложениям, можно проверить параметры лимитов прямо из PHP-скрипта:

Оптимизация работы PHP с дисковой подсистемой.

Место сохранения сессий в PHP определяется параметров «session.save_path» и по умолчанию оно располагается в директории «/var/lib/php/sessions». Точнее всего это выявляется через вывод функции «php_info()». Мне представляется самым простым смонтировать поверх этой директории кусочек «tmpfs»:

Монтируем или перемонтируем (если вносились изменения в уже существующую конфигурацию) «tmpfs»-файловую систему:

Прежде всего, для включения поддержки Nginx протокола HTTPv2 генерируем DH-сертификат:

Для очень старых ОС и браузеров (Windows XP IE6, Java 6) придётся снизить размер DH до 1024:

Конечно же защищаем директорию SSL-сертификатов от посторонних:

Слегка корректируем глобальную конфигурацию web-сервиса:

# Явно запускаем Nginx в рамках привилегий пользователя «www-data» и такой же группы «www-data»
user www-data www-data;
.
worker_processes 24;
.
events <
worker_connections 1024;
.
>

http <
.
tcp_nodelay on;
tcp_nopush on;

# Запрещаем web-серверу сообщать о себе подробные данные
server_tokens off;

# Запрещаем просмотр содержимого директории, если не указан целевой файл
autoindex off;

# Отключаем проверку размера тела передаваемого PHP-FPM запроса
client_max_body_size 0;

Описываем конфигурацию типового web-сайта под управлением CMS «Bitrix»:

# Перехватываем все запросы по протоколу без шифрования и перенаправляем их на HTTPS
server <
listen 80 default_server;
server_name one.example.net www.one.example.net;
access_log off;
error_log off;
location / <
rewrite ^ https://one.example.net$request_uri permanent;
>
>

# Перехватываем запросы к имени нежелательного формата и перенаправляем к нужному
server <
listen 443 ssl http2;
server_name www.one.example.net;

access_log off;
error_log off;

ssl on;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.2048.pem;
ssl_certificate /etc/nginx/ssl/one.example.net.crt;
ssl_certificate_key /etc/nginx/ssl/one.example.net.key.decrypt;
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;
ssl_stapling on;
add_header Strict-Transport-Security max-age=15768000;

location / <
rewrite ^ https://one.example.net$request_uri permanent;
>
>

# Описывем рабочее окружение web-сайта как такового
server <
listen 443 ssl http2 default_server;
server_name one.example.net;

access_log /var/www/one.example.net/log/access.log;
error_log /var/www/one.example.net/error.log;

# SSL Configuration
ssl on;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
# Old backward compatibility (Windows XP IE6, Java 6)
ssl_ciphers HIGH:SEED:AES128-SHA:AES256-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.2048.pem;
ssl_certificate /etc/nginx/ssl/one.example.net.crt;
ssl_certificate_key /etc/nginx/ssl/one.example.net.key.decrypt;
# SSL Caching
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;
# SSL Verify Optional
ssl_stapling on;
# SSL Strict Optional
add_header Strict-Transport-Security max-age=15768000;

# Выключаем невостребованную обычно перекодировку контента
charset off;

# Явно указываем корень файловой структуры сайта, выше которой web-сервер не должен выходить
root /var/www/one.example.net/www;

# Задаём перечень файлов, которые web-сервер должен выдать в отсутствии явного указания со стороны клиента
index index.html index.htm index.php;

# Подставляем свою страницу обработки некоторых ошибок сервиса
error_page 500 502 503 504 /maintenance.html;
error_page 403 /403.html;

# Блокируем доступ к типовым «закрытым» ресурсам
location

* (/\.ht|/\.hg|/\.svn|/\.git|/\.enabled|/\.config) <
deny all;
log_not_found off;
access_log off;
>

# Блокируем доступ извне к внутренностям CMS «Bitrix»
location

# Разрешаем доступ в административную панель Bitrix только избранным
location

# Разрешаем доступ только с определённого перечня IP-адресов
satisfy all;
allow 1.2.3.4/24;
deny all;

# Обрабатываем PHP-скрипты, доступные только после успешной аутентификации
location

# Включаем «HTTP Basic Authentication» для доступа к REST-API
location

# Обрабатываем PHP-скрипты, доступные только после успешной аутентификации
location

# Обработчик прямых обращений к PHP-скриптам
location

# Обработчик ошибок при доступе к ресурсам (таким образом в «Битрикс» реализована поддержка ЧПУ)
location @bitrix <

# Специфичная для Bitrix SEO-процедура подстановки к URL завершающего «/»
rewrite ^/(.+[^/])$ /$1/ permanent;

# Не реагируем на неинтересные события загрузок
location = /(404.html|favicon.ico|robots.txt|sitemap.xml) <
log_not_found off;
access_log off;
>

# Напрямую отдаём «статические» данные, предлагая браузеру сохранить их в своём «кеше», и не фиксируем в журнале эти события
location

Очевидно, что конфигурация Nginx для другого сайта будет отличатся лишь в части параметров включающих имя сайта «one.example.net», которое следует заменить на нужное.

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

Старые клиентские системы и новые требования к SSL/TLS.

Наладка «HTTP Basic Authentication» посредством Nginx.

Если осуществляется полный переход с web-сервера «Apache» на «Nginx», то наверняка потребуется воспроизвести логику файлов «.htaccess», «.htpasswd» и «.htsecure» в части аутентификации пользователей при обращении к закрытым ресурсам.

Прежде всего ищем файлы точечной настройки и изучаем их функционал:

Особо важно не упустить блоков аутентификации средствами web-сервера при доступе к ресурсам, что-то вроде такого:

Подсистема «HTTP Basic Authentication» использует шифрование паролей на грани минимально допустимого с точки зрения устойчивости к взлому, но иногда приходится поддерживать совместимость со старыми протоколами, так что генерируем из желаемого пароля специфичного типа «хеш» (MD5-based password algorithm, Apache variant):

Полученный «хеш» подкладываем в файл с перечнем пользователей, доступ которым разрешается:

Рекомендую сразу запустить утилиту конфигурирования уровня безопасности СУБД:

Как и с PHP-интерпретатором «Битрикс» хочет от MySQL определённого. Предоставляем ему это:

.
[mysqld]
.
tmpdir = /var/lib/mysql/tmp
innodb_tmpdir = /var/lib/mysql/tmp

# Обязательно включаем приём подключений через файловый «сокет», существенно снижая операционные задержки
socket = /var/run/mysqld/mysqld.sock

# Разрешаем подключаться только с «localhost»
bind-address = 127.0.0.1

# Читаем документацию и подбираем подходящие параметры работы с доступной памятью
table_cache = 512
.
tmp_table_size = 512M
max_heap_table_size = 512M
.
query_cache_limit = 10M
query_cache_size = 256M
key_buffer_size = 512M //

20% RAM
.
innodb_buffer_pool_size = 1G //

60% RAM
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
.
innodb_read_io_threads = 16
innodb_write_io_threads = 16

# Явно указываем создавать для каждой таблицы отдельные файлы описаний (.frm) и данных (.ibd) на диске, а не сваливать всё в один (по умолчанию «ibdataX»)
innodb_file_per_table = 1
.

Параметры MySQL/MariaDB раскиданы по нескольким файлам в директории «/etc/mysql», так что есть смысл убедится, не переопределяются ли они где-то в «/etc/mysql/mariadb.conf.d/».

Для применения изменений перезапускаем СУБД или даём команду перечитать изменения, по необходимости:

Проконтролировать фактическое применение параметров можно через SQL-запросы:

Оптимизация работы MySQL с дисковой подсистемой.

Для СУБД MySQL, активно создающей и уничтожающей файлы для временных таблиц, выгодно вынести (параметром «tmpdir») эту работу в файловую систему, смонтированную в область памяти ОЗУ:

Добавляем в системный перечень монтируемых файловых систем нашу:

Монтируем или перемонтируем (если вносились изменения в уже существующую конфигурацию) нашу файловую систему:

Я бы выделил под эту файловую систему до 25% от объёма ОЗУ (она не заблокирует всё заявленное место, а будет выбирать блоки памяти по мере появления необходимости).

Разворачиваем БД для сайта.

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

Снимаем «дамп базы» MySQL исходного сервера (откуда осуществляется перенос сайта) и применяем его на новом сервере СУБД:

Для базы в целом (будет наследоваться после при создании новых таблиц):

Для таблицы (будет наследоваться при создании новых колонок):

Если таблица имеет внутри колонку в неверной кодировке, то можно это исправить за один проход, воздействуя на всю таблицу:

. или воздействовать точечно на нужную колонку таблицы:

CMS «Bitrix» весьма запутанная система, с массой подключаемых модулей, генерирующих большое количество блоков данных, используемых при генерации итоговых страниц из шаблонов. Вся эта неоптимальная деятельность сильно сказывается на отзывчивости сайта, терзая дисковую подсистему записью и считыванием информационного мусора, тормозя работу всех сервисов сервера в целом. Хорошо хоть часть этого промежуточного материала можно сохранять в кеширующем сервисе вроде «memcached» или «Redis»:

.
# Имя пользователя, для которого запускается сервис
-u www-data

# Количество одновременных подключений (по умолчанию 1024)
-c 1024

# Объем выделяемой памяти для кеша (по умолчанию 64MB)
-m 1024m

# Количество потоков Memcached (по умолчанию 4)
-t 8

# Выключаем прослушивание сетевого TCP-порта
#-l 127.0.0.01
#-p 11211

# Включаем работу через локальный файловый «сокет»
-s /tmp/memcached.sock
.

Настраиваем подсистему отправки почты.

Журнал регистрации событий утилита сама создавать не умеет, так что помогаем ей в этом:

Утилита «msmtp» способна полностью эмулировать классический «sendmail», так что для совместимости с уже настроенным по умолчанию программным обеспечением есть смысл сделать символическую ссылку, направляющую обращения в нужное место:

Для начала настроим один профиль, используемый по умолчанию:

# Set default values for all following accounts.
defaults
auth off
tls off
logfile /var/log/msmtp.log

# Default Account
account default
host mx.example.net
port 25
from www-data@one.example.net

Проверяем, работает ли это непосредственно из CLI сервера:

loaded system configuration file /etc/msmtprc
.
EHLO localhost
.
—> QUIT
Настройка подключения CMS «Bitrix» к БД.

$DBLogin = «user_one»;
$DBPassword = «user_password»;
$DBName = «one_example_net»;
$DBDebug = false;
$DBDebugToFile = false;
.

Кто заглядывал в PHP-код ядра «Битрикс», тот не удивится, зачем разработчики этой CMS требуют выключения режима строгого следования SQL-стандартам при формировании запросов к БД. В официальной инструкции предлагается сделать это глобально, для всей СУБД, но я предпочитаю всем остальным сайтам предоставить возможность работы в нормальных условиях, а «Битриксу» дать битриксово:

Замена пароля подключения к БД.

CMS «Bitrix» хочет, чтобы «всё было безопасно» и требует пароль подключения к СУБД состоящий из символов разного регистра и включающий в себя цифры со спецсимволами. Удовлетворяем его пожелания.

Генерируем кучу паролей и выбираем понравившийся:

Всё. Теперь в панели производительности Битрикс (http://site.com/bitrix/admin/perfmon_panel.php) должны увидеть подтверждение возможности использования этого типа кеша.

Особенность настройки FQDN.

CMS «Bitrix» активно использует для «самотестирования» обращения из своих скриптов к самим себе же, через обычные HTTP-запросы. Так вот, если в файле конфигурации локального «резольвинга» завязать доменные имена обслуживаемых сайтов на локальный IP (что часто случается на этапе первоначально наколенной разработки), то «самодиагностика» не состоится из-за сбоя авторизации при обращении к административной части сайта.

Адресация файловых систем.

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

Обновление «движка» CMS «Bitrix».

После запуска web-сайта на новой площадке возможно захочется протестировать, как скоро он сломается под возрастающей нагрузкой. Для этого можно воспользоваться утилиткой «Siege».

Вот так очень просто протестировать сервер в сценарии «250 пользователей 10 минут упорно ходят по сайту»:

[ уже посетило: 10385 / +5 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Источник

битрикс + nginx + php-fpm

мне увы пока так и не удалось полностью подружить эту связку.
столкнулся с проблемой заголовков(при ЧПУ), т.е. получаем либо на все 200 OK либо 404 Not Found

если интересно могу выложить конфиги.

совместными усилиями, собрали рабочий конфиг, спасибо Сергею Ляпко

UPD 23.12.2015: Добавил новый конфиг.

Старый

Evgeniy Pedan, наверно nginx кеширует страницу phpinfo() когда через админку Битрикс смотришь
/bitrix/admin/phpinfo.php?test_var1=AAA&test_var2=BBB#authorize

вот я конфиг nginx поменял, кеш видно сбросился.

Все работает, спасибо большое! Такая экономия времени.

* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)$ <
error_page 404 /404.html;
expires 30d;
>
вот этим:
location

* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)\?4*$ <
error_page 404 /404.html;
expires 30d;
>

Куда не вставляю location /bitrix/admin < return 404; >не работает, открывается админка

* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ < access_log off; expires max; >#+ Close some uri for security location

Собственно рабочий конфиг (для оптимизации необходимо еще добавить другой 404 для статики ну и вообще посмотреть на дебаг на предмет лишних итераций)

Источник

битрикс + nginx + php-fpm

если интересно могу выложить конфиги.

совместными усилиями, собрали рабочий конфиг, спасибо Сергею Ляпко

UPD 23.12.2015: Добавил новый конфиг.

Старый

вот я конфиг nginx поменял, кеш видно сбросился.

Все работает, спасибо большое! Такая экономия времени.

* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)$ <
error_page 404 /404.html;
expires 30d;
>
вот этим:
location

* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)\?8*$ <
error_page 404 /404.html;
expires 30d;
>

Куда не вставляю location /bitrix/admin < return 404; >не работает, открывается админка

* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ < access_log off; expires max; >#+ Close some uri for security location

Источник