PHP-FPM 8.2 в связке с Apache на Ubuntu 20.04 — легко

По горячим следам запишу, как поставил на сравнительно древнюю по нонешним меркам (хоть и всё ещё поддерживаемую) Ubuntu 20.04 Focal Fossa новенький PHP версии 8.2 в связке с дефолтным веб-сервером Apache с PHP-FPM, оно же FastCGI Process Manager (менеджер процессов FastCGI).

Казалось бы, зачем так заморачиваться, тем паче когда у тебя вовсе не нагруженный проект, а обычный, просите, блог на WordPress?

Ну, во-первых. Проблема в том, что мой текущий VPS-хостинг реально медленный. Примерно таким и выбирался, дабы не жалко было денег, но тем не менее. И вот если хоть на скрупул возможно как-то ускорить работу всей этой веб-обвязки или улучшить производительность — и то хлебушек, право слово. Тем более, в интернете этот самый PHP-FPM очень хвалят — попробуйте сами загуглить. Да и разработчики Apache рекомендуют именно эту модель работы, а не через специальный php-модуль, что предлагается дистрибутивами из коробки.

Далее. Если почитать отзывы бывалых сисадминов и программистов, PHP версии 8+ показал себя производительней и быстрей в ряде тестов, нежели версии 7.4. И ежели WordPress на последних релизах поддерживает (хоть и с оговорками, в рамках бета-тестирования) версию 8.2, почему б не воспользоваться.

В общем, окончательно решил вместо используемых по умолчанию PHP7.4 + apache + модуль libapache2-mod-php7.4 (т.е. libphp7.4.so) замахнуться на последний, так сказать, писк моды: PHP8.2 + apache (ну, принято nginx, но для Вордпресса всё же перебор 🙂) + php8.2-fpm.

Да вот беда: по умолчанию в репозитории Убунты 20.04 предлагается PHP версии лишь 7.4. Немного обескураживающе, не так ли?

Однако в интернете советуют не отчаиваться и подключить специальный репозиторий. Но зачем? Зачем тянуть те же лишние зависимости? Когда всё доступно по прямым ссылкам: https://packages.sury.org/php/pool/main/p/php8.2/

1. Из этого листинга нам на деле потребуются пакеты для Debian 11 архитектуры amd64 — этот минимальный набор проверен лично, благодаря чему я и успешно пишу сейчас в редакторе WordPress этот пост, кстати: 😺

• php8.2-cli_8.2.8-1+0~20230815.27+debian11~1.gbp5cf2f6_amd64.deb
• php8.2-common_8.2.8-1+0~20230815.27+debian11~1.gbp5cf2f6_amd64.deb
• php8.2-fpm_8.2.8-1+0~20230815.27+debian11~1.gbp5cf2f6_amd64.deb
• php8.2-opcache_8.2.8-1+0~20230815.27+debian11~1.gbp5cf2f6_amd64.deb
• php8.2-readline_8.2.8-1+0~20230815.27+debian11~1.gbp5cf2f6_amd64.deb
• php8.2-sqlite3_8.2.8-1+0~20230815.27+debian11~1.gbp5cf2f6_amd64.deb

Последний пакет — у меня база соотв. образом сконвертирована и теперь (благодаря энтузиастам из команды Вордпресс, запилившим чудесный плагин) работает на SQLite вместо громоздкого MySQL. Что правда экономит и место, и ресурсы, и для небольшого блога на Вордпрессе вполне адекватно.

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

2. Единственное, прежде чем всё это ставить, надо сперва обновить пакет libpcre2-8-0 для обеих архитектур (amd64 и i386), взяв из версии Ubuntu 22.04 (Jammy Jellyfish) — https://packages.ubuntu.com/jammy-updates/libpcre2-8-0. Дело в том, что установленные для нашей Ubuntu 20.04 — версии 10.34, тогда как требуется версия не менее 10.38. Никаких репозиториев подключать не нужно (дабы не захламлять систему) — просто тупо качаем по ссылке и ставим с помощью dpkg -i *.deb

После установки перечисленных пакетов проверяем статус нового сервиса php8.2-fpm (должен запуститься и добавиться в автозагрузку systemd):

$ systemctl status php8.2-fpm

3. Далее нам надо активировать следующие модули apache:

$ sudo ln -s /etc/apache2/mods-available/proxy.conf /etc/apache2/mods-enabled
$ sudo ln -s /etc/apache2/mods-available/proxy.load /etc/apache2/mods-enabled
$ sudo ln -s /etc/apache2/mods-available/proxy_fcgi.load /etc/apache2/mods-enabled

Также требуются модули setenvif.conf и setenvif.load — но они уже были активны, т.е. симлинки присутствовали в /etc/apache2/mods-enabled. Кстати, помимо этого (для работоспособности сайта по https — пишу, чтоб не забыть) ранее активировал модули: ssl.load, ssl.conf и socache_shmcb.load

4. Допишем в конфиге(-ах) нашего сайта, расположенных в директории /etc/apache2/sites-available и /etc/apache2/sites-enabled, следующие строки (притом как для http-версии — т.е. порт 80 — так и для https — 443):

<FilesMatch \.php$>
SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost/"
</FilesMatch>

Последние два пункта вроде можно проделать и с помощью встроенных скриптов a2enmod и a2ensite, но они, как мне думается, затуманивают суть.

5. Удалим из той же директории /etc/apache2/mods-enabled связанные с PHP 7.4 (и с другими версиями тоже — речь именно про специальный apache-модуль, вместо которого будем использовать fpm) симлинки: php7.4.conf и php7.4.load

6. Осталось вычистить с помощью dpkg -P связанное с PHP7.4 — установленные пакеты можно посмотреть таким образом:

$ apt list ‐‐installed | grep php7

7. Ну и перезапустить apache:

$ sudo systemctl restart apache2

Если вдруг не запустится, можно глянуть логи в journalctl, с помощью клавиши PageDown переместившись там к самой нижней (последней) строке.

8. Проверить работоспособность можно, создав в любом месте сайта php-файл содержания:

<?php phpinfo(); ?>

И открыв его в браузере:

Картинка из интернета

Небольшой постскриптум — совместимость плагинов

После перехода на PHP 8.2 перестал работать плагин капчи WP Advanced Math Captcha! Но с другой стороны, нам никто ничего и не обещал, тем паче что на плагин, кажется, разработчики давно забили. 🙂

Однако отчаиваться не сто̀ит — судя по логам апача, что-то случилось с синтаксисом при вызове функций fopen(), fclose() и fwrite(). Судя по всему, в этом плагине они используются для работы с локальными файлами логов, что некритично. Так что в файлах wp-math-captcha.php (строка 144 и ниже) и includes/class-core.php (строка 40 и ниже) просто закомментируем вызовы этих функций — и voilà.