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

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

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

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

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

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

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

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

Переход от общего хостинга и платформ к частному серверу

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

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

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

Еще один популярный подход заключается в использовании частного/облачного сервера и его самостоятельной настройке. Эксплуатация 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, Email, LDAP и т.д., лучше использовать их пользовательские PHP-реализации.

• Расширения с криптографическими операциями (например, mcrypt и openssl), лучше заменить более новыми расширениями, такими как Sodium, или его пользовательскими PHP-полифиллами.

• PDF-библиотеки (например, DomPDF) могут быть заменены headless-браузерами или инструментами командной строки, такими как wkhtmltopdf.

• Расширения для генерации изображений (такие как Imagick и GD) могут быть заменены на CDN, предлагающие работу с изображениями.

Composer LTS

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

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

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

Такие PHP-фреймворки и библиотеки, как Laravel и Nette, как правило, развиваются очень динамично, в то время как Symfony и Slim более консервативны.

• Хотя раньше Laravel предлагал LTS-релизы, гарантирующие пять лет обновлений безопасности, последние версии Laravel предлагают только один год активной поддержки, а затем год исправлений безопасности, поэтому с ним в конечном итоге может потребоваться ручной перенос этих обновлений.

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

• WordPress старается поддерживать совместимость со старыми версиями PHP, поэтому обновление WordPress должно быть возможным даже на старых версиях PHP.

• Symfony (и ее компоненты) предоставляют LTS-версии с обновлением безопасности не менее трех лет.

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

Перевод статьи подготовлен в преддверии запуска курса PHP Developer. Professional. В рамках курса скоро пройдут открытые уроки, на которых разберем шаблонизаторы в PHP и поговорим о том, как устроены современные PHP-фреймворки. Регистрируйтесь, будет интересно.