PHP: Продление срока службы легаси приложений

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

Хотя обновление существующих PHP-приложений идеальный и рекомендуемый подход, неизбежно существуют приложения/веб-сайты, которые не могут оправдать затраты на обновление. Это особенно касается легаси PHP приложений работающих на PHP 5 или PHP 7. Wordpress.org сообщает, что только 16% зарегистрированных WordPress сайтов работают на версии PHP, поддерживаемой разработчиками ядра PHP.

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

Такие инструменты, как Rector, могут автоматизировать некоторые, если не большинство необходимых изменений, но очень старые версии PHP, как правило, требуют большого количества ручного обновления кода.

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

Поскольку версии PHP получают официальные обновления только в течение трёх лет, это может сделать приложение уязвимым для уязвимостей безопасности, которые часто затрагивают и эти неподдерживаемые версии PHP. PHP приложения Platform-as-a-Product (PAAS) и провайдеры виртуального хостинга также требуют обновлений до последней версии PHP, что может привести к поломке приложений в новой версии PHP.

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

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

Виртуальный хостинг и платформы на приватных серверах

Большинство платформ виртуального и управляемого хостинга, и предложений PHP PaaS обычно предлагают только текущие версии PHP, но не поддерживают старые версии PHP в долго срочной перспективе. Это имеет смысл, потому что старые версии PHP остаются не поддерживаемыми, и это может поставить под угрозу безопасность их серверов в случае обнаружения уязвимости, затрагивающей эти неподдерживаемые версии PHP.

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

CloudLinux — одна из коммерческих операционных систем используемая провайдерами виртуального/управляемого хостинга, и это провайдеры, вероятно, включают функцию HardenedPHP в CloudLinux. HardenedPHP — функция CloudLinux поддерживающая исправления безопасности даже после того как официальная команда php.net пометила версию PHP как EOL.

Другой подход — поддерживать приватный сервер/облачный сервер и настраивать его самостоятельно. Обслуживание VPS/облачного сервера сопряжено с трудностями обслуживания, но в настоящее время большинство операционных систем имею разумные настройки по умолчанию, автоматические обновления и многое другое, чтобы снять часть этой нагрузки. Однако это обслуживание может быть не для всех.

Debian LTS, Ubuntu LTS, Rocky Linux, и RHEL — несколько операционных систем на базе Linux предоставляющие PHP в своих репозиториях по умолчанию. Они не получают исправление багов из основной ветки разработки, но исправления безопасности передаются по мере необходимости.

Например, Ubuntu 20.04 LTS включает PHP 7.4.3 в свои репозитории по умолчанию. Ubuntu 20.04 LTS получает аппаратные и эксплуатационные обновления до 2025 года. PHP 7.4 в настоящее время помечен официальной командой php.net как End-of-Life, но разработчики Ubuntu 20.04 переносят все исправления безопасности в версию PHP доступную в репозитории. Любые исправления ошибок, не связанные с безопасностью, не переносятся. По сути, это означает, что PHP-версия Ubuntu 20.04 останется как PHP 7.4.3, но со всеми применёнными исправлениями безопасности. Платное (бесплатное для пяти персональных компьютеров) приложение Ubuntu Pro продлевает его на пять дополнительных лет, что, по сути, означает возможность безопасного запуска приложений PHP 7.4 до 2030 года.

Интеграция с веб-сервером

PHP интегрируется с веб-серверами, такими как Apache, Nginx, Litespeed, Caddy и другие. При запуске устаревшего PHP-приложения рекомендуется переключиться на php-fpm в качестве серверного API. Apache, например, поддерживает запуск PHP в качестве модуля Apache, что препятствует обновлению версии Apache, если приложение должно работать на более старой версии PHP.

Nginx и Caddy интегрируются только с php-fpm, поэтому никаких изменений для них не требуется.

В PHP также есть встроенный сервер. Маловероятно, что его используют как продакшен сервер, но обязательно используйте полноценный веб-сервер, чтобы добавить разделение между PHP и веб-сервером.

Контейнеризация PHP

Когда запуск полноценной операционной LTS системы (например, Ubuntu LTS) нецелесообразен, альтернативным подходом может быть использование контейнеров для запуска необходимой версии PHP.

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

Замена расширений PECL

Даже если операционная система или сторонний репозиторий представляют обновления PHP, маловероятно, что они предлагают обновления безопасности для EOL PHP расширений.

• Расширения PECL, которые подключаются к внешним службам, таким как SSH, FTP, электронная почта, LDAP и т.д., лучше использовать их с PHP реализациями на уровне пользователя.
• Расширения, предлагающие криптографические операции (например, mcrypt и openssl) лучше заменить более новыми расширениями, такими как Sodium, или его полифиллы в PHP на уровне пользователя.
• Библиотеки PDF (например, DomoPDF) можно заменить headless-браузерами или инструментами командной строки, такими как хwkhtmltopdf.
• Расширения для создания изображений (такие, как Imagick и GD) можно заменить CDN, которые предлагают манипулирование изображениями.

Composer LTS

Composer, диспетчер зависимостей PHP, недавно увеличил требования к минимальной версии PHP. Однако Composer 2.2 — это LTS-версия Composer 2, которая должна поддерживаться как минимум до конца 2023 года.

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

LTS Фреймворки, Библиотеки и локальные форки

Фреймворки и PHP библиотеки, такие как Laravel и Nette, как правило, быстро развиваются, в то время как Symfony и Slime более консервативны.

• Хотя раньше Laravel предлагал LTS релизы получавшие пять лет обновлений безопасности. Последние версии Laravel предлагают только один год активной поддержки, за которой следует год исправлений безопасности, поэтому может потребоваться ручной перенос обновлений безопасности.
• Для последних версий Drupal (таких, как Drupal 10) требуются последние версии PHP. В настоящее время Drupal 7 продолжает получать поддержку, но существуют бесплатные и коммерческие проекты Drupal LTS, которые предоставляют скоординированные выпуски безопасности даже посте того, как они официально достигнут EOL.
• Для Drupal 7 также существует BackDrop CMS обеспечивающая простой способ обновлений.
• WordPress старается поддерживать совместимость со старыми версиями PHP, поэтому обновление WordPress должно быть возможным даже на старых версиях PHP.
• Symfony (и его компоненты) предоставляют LTS версии с обновлениями безопасности не менее трёх лет.

Когда PHP-библиотека/фреймворк отказываются от версии PHP, от которой зависит PHP-приложение, тогда мейнтейнер PHP-приложения должен сделать форк репозитория и переносить обновления безопасности по мере их появления. Совместное использование этих усилий в качестве публичного проекта может окупить усилия прилагаемые для поддержки других LTS пакетов. Для приватных пактов локально клонированный репозиторий или частный репозиторий Composer помогут обеспечить интеграцию с Composer.