Від стабільної і швидкої роботи сервера залежить доля сайту. Його повільна робота і часті падіння здатні відлякати як відвідувачів, так і пошукові системи. Останні ще й знизять рейтинг гальмуючого сайту в результатах пошуку і він виявиться не в топ-10, а, скажімо, в топ-100 по всім запитам.
Використання зв'язки nginx і php-fpm для обслуговування сайтів дозволяє збільшити швидкість їх роботи, а також стабільність системи в цілому. До того ж, відмовившись від використання apache, ми кілька спрощуємо систему і навіть захищаємо її. Адже якщо немає apache, то зловмисник не зможе використовувати, наприклад, файл .htaccess для своїх цілей.
Зв'язку nginx + php-fpm налаштовувати досить легко і вона підтримується багатьма популярними CMS: WordPress, MODX, DLE, різними фреймворками. Все це здатне працювати і без громіздкого apache.
При установці веб-сервера, не обійтися без створення користувачів. В ідеалі, для кожного сайту повинен бути створений окремий юзер. Так ми зможемо захистити інші сайти, якщо один з користувачів буде зламаний. Приклади в цій статті написані з урахуванням того, що користувачів ви створили за інструкцією.
Для початку встановимо базові модулі: php-fpm, mysql, curl, GD. Все інше - за індивідуальною необхідності.
Файли розміщуються в каталозі / etc / php5 / fpm /.
Налаштовуємо php-пул для обслуговування запитів
Спочатку в php-fpm є тільки один пул по імені www. Ми будемо використовувати його в якості основи для інших пулів.
Відкриємо конфігураційний файл /etc/php5/fpm/pool.d/www.conf. розглянемо деякі змінні і підберемо для них значення.
Перша змінна - це ім'я пулу. Воно полягає в квадратні дужки і не може збігатися з ім'ям будь-якого існуючого в системі користувача.
Далі вказуємо ім'я користувача і його групу, в чиєму домашньому каталозі розташовується сайт.
Зазначаємо, що пул повинен працювати як unix-сокета. Змінна $ pool буде замінена на ім'я.
Визначаємо використання статичного режиму, при якому під час запуску fpm створюється певна кількість процесів пулу. Вони обслуговують всі запити.
Чому саме такий вибір. ) Це найекономніший варіант. Кожен процес пулу буде займати об'єм оперативної пам'яті, виділений змінної memory_limit плюс кілька мегабайт на підключені модулі, кеш і т.п. При статичному варіанті всі запити будуть оброблятися тільки створеними процесами, а нові породжуватися (і займати дорогоцінну пам'ять) не будуть. В результаті отримаємо фіксоване споживання пам'яті.
Вказуємо необхідну кількість процесів, які обслуговують запити. Підбирається в залежності від завантаженості.
Наступні параметри рекомендую додати в кінець конфігураційного файлу пулу.
Каталог для розміщення тимчасових файлів:
Каталог для зберігання файлів сесій:
З міркувань безпеки, доступ до цих каталогів повинен бути тільки у користувача, з правами якого запускається пул php-fpm. Також не слід використовувати один каталог і для зберігання файлів сесій, і для тимчасових файлів.
Обмеження пам'яті для виконання скриптів слід підбирати, виходячи з вимог сайту. Для початку:
Вкажіть обов'язковий параметр, який усуває вразливість:
Змінні sendmail_path і open_basedir не вказуються спеціально. Вони будуть передані в якості параметрів fast-cgi в конфігураційному файлі nginx. Таким чином, для кожного конкретного сайту можна визначити свою настройку. )
Після того, як всі необхідні параметри прописані, слід перезавантажити конфігурацію php-fpm командою:
Обробка php скриптів за допомогою nginx
Залишається налаштувати nginx для роботи з php-fpm. готовий конфиг
example.com замінюємо на свій домен.
try_files $ uri = 404; відобразить помилку 404 в браузері користувача, замість повідомлення no input file specified. в разі, коли дана помилка має місце.
fastcgi_pass - шлях до сокета php-fpm.
Перераховуємо каталоги для open_basedir: каталог з сайтом, каталог для збереження тимчасових файлів, каталог для файлів сесій.
Якщо потрібно передати кілька параметрів, до робити це слід так:
Як можна помітити, параметри розділяються за допомогою розриву рядків: \ n.
Зберігаємо всі виконані зміни і перезапускаємо nginx.