Обновление PHP на Linux – это не формальность, а прямая необходимость, если сервер обрабатывает современные сайты, фреймворки или CMS. Новые версии PHP содержат исправления уязвимостей, улучшения производительности и поддержку актуальных функций, без которых Laravel, Symfony, WordPress, Drupal и другие системы либо работают нестабильно, либо не запускаются вовсе. Например, PHP 8.x даёт ощутимый прирост скорости за счёт JIT-компиляции и оптимизированного движка Zend.
Процесс обновления PHP отличается в зависимости от дистрибутива Linux, используемого веб-сервера и способа установки PHP. В системах на базе Ubuntu и Debian чаще всего применяются сторонние репозитории, такие как Ondřej Surý, тогда как CentOS, AlmaLinux и Rocky Linux используют Remi или AppStream. Неправильный выбор репозитория или пропуск зависимостей может привести к конфликтам пакетов и отказу веб-сервера.
Перед обновлением важно определить текущую версию PHP, режим работы (mod_php, PHP-FPM, CLI) и список подключённых расширений. Это позволяет избежать ситуаций, когда после обновления перестают работать модули pdo_mysql, intl, gd, opcache или возникает несовместимость с конфигурацией Apache или Nginx. Отдельное внимание следует уделить резервному копированию файлов php.ini и конфигураций пулов PHP-FPM.
В этой инструкции разобран практический и безопасный порядок обновления PHP на Linux: от подготовки системы и установки новой версии до переключения версии по умолчанию и проверки работы сайтов. Все шаги ориентированы на рабочие серверы, где важна стабильность, предсказуемость и минимальный простой.
Вот детальный план информационной статьи из 8 прикладных и узких заголовков без подзаголовков:
1. Проверка текущей версии PHP в Linux с помощью команд php -v и phpinfo() для CLI и веб-окружения, так как версии могут отличаться.
2. Определение дистрибутива и его версии через lsb_release -a или /etc/os-release для выбора корректного репозитория и метода обновления PHP.
3. Создание резервных копий файлов php.ini, конфигураций PHP-FPM и виртуальных хостов Apache или Nginx перед установкой новой версии.
4. Подключение актуального репозитория PHP: ondrej/php для Ubuntu и Debian либо Remi для CentOS, AlmaLinux и Rocky Linux.
5. Обновление PHP через пакетный менеджер apt, dnf или yum с установкой обязательных расширений под используемые приложения.
6. Переключение версии PHP по умолчанию для CLI и веб-сервера с помощью update-alternatives или модулей AppStream.
7. Перезапуск служб Apache, Nginx и PHP-FPM для применения новой версии и загрузки обновлённых модулей.
8. Проверка работоспособности сайтов и расширений PHP после обновления с анализом логов error.log и php-fpm.log.
Проверка текущей версии PHP в Linux
Перед обновлением необходимо точно определить, какая версия PHP используется в системе и в каком режиме она работает. В Linux часто одновременно установлены несколько версий PHP, при этом CLI и веб-сервер могут использовать разные бинарные файлы.
Для проверки версии PHP в командной строке выполните:
- php -v – показывает версию PHP, используемую в CLI, включая сборку, дату релиза и активный движок Zend.
Чтобы узнать путь к используемому бинарному файлу PHP, выполните:
- which php – помогает определить, какая версия PHP выбрана по умолчанию и откуда она запускается.
Если сервер обрабатывает сайты через Apache или Nginx, необходимо проверить версию PHP именно в веб-окружении. Для этого создайте файл с минимальным содержимым:
- <?php phpinfo(); ?> – позволяет увидеть версию PHP, режим работы (mod_php или PHP-FPM) и список загруженных расширений.
При использовании PHP-FPM важно определить, какая версия запущена в виде сервиса:
- systemctl status php*-fpm – показывает активные пулы и версии PHP-FPM.
Дополнительно рекомендуется проверить установленные пакеты PHP, чтобы выявить параллельно установленные версии:
- dpkg -l | grep php – для Ubuntu и Debian.
- rpm -qa | grep php – для CentOS, AlmaLinux и Rocky Linux.
Фиксация текущей версии PHP и активных расширений позволяет избежать конфликтов при обновлении и точно восстановить рабочее окружение в случае отката.
Определение дистрибутива и версии Linux перед обновлением PHP
Выбор способа обновления PHP напрямую зависит от дистрибутива Linux и его версии. Использование неподходящего репозитория или пакетов от другой ветки приводит к конфликтам зависимостей и невозможности запуска PHP или веб-сервера.
Базовую информацию о системе следует получать из системных файлов, а не по внешним признакам. Основная команда для большинства дистрибутивов:
cat /etc/os-release
В системах на базе Debian дополнительно можно уточнить кодовое имя релиза:
lsb_release -a
Параметр Codename (например, focal, bullseye, bookworm) критичен при добавлении репозиториев ondrej/php, так как несовпадение кодового имени приведёт к установке некорректных пакетов.
Для RHEL-совместимых систем важно определить мажорную версию платформы:
cat /etc/redhat-release
Эта информация используется при выборе потока AppStream или репозитория Remi, так как версии PHP жёстко привязаны к версии системы и уровню поддержки ядра.
Если сервер работает в контейнере или виртуальной среде, рекомендуется дополнительно проверить архитектуру:
uname -m
Несовпадение архитектуры (x86_64, aarch64) может ограничить доступные версии PHP и набор расширений.
Точное определение дистрибутива, версии и архитектуры Linux позволяет выбрать корректный источник пакетов и выполнить обновление PHP без сбоев и ручного устранения зависимостей.
Создание резервной копии конфигурации PHP и веб-сервера
Перед обновлением PHP необходимо сохранить текущие конфигурации, так как установка новой версии может перезаписать файлы или изменить структуру каталогов. В первую очередь резервируются активные файлы php.ini, настройки пулов PHP-FPM и конфигурации веб-сервера.
Для PHP важно определить используемый конфигурационный файл, так как он различается для CLI и веб-окружения. Проверка выполняется командой php —ini, после чего копируется основной файл php.ini и все дополнительные файлы из каталогов conf.d.
При использовании PHP-FPM необходимо сохранить директории с пулами, обычно расположенные в /etc/php/*/fpm/pool.d или /etc/php-fpm.d. Эти файлы содержат параметры сокетов, пользователей, лимитов памяти и таймаутов, которые не всегда переносятся автоматически при обновлении.
Конфигурации веб-сервера копируются полностью, без выборочной фильтрации. Для Apache это каталоги /etc/apache2 или /etc/httpd, для Nginx – /etc/nginx. Особое внимание следует уделить виртуальным хостам, файлам подключения PHP и пользовательским директивам.
Резервные копии рекомендуется сохранять в отдельный каталог с указанием даты, например /root/backup-php-2025-01-15, используя рекурсивное копирование с сохранением прав доступа. Это позволяет быстро восстановить рабочее состояние сервера при возникновении ошибок после обновления.
Наличие актуальной копии конфигурации PHP и веб-сервера исключает необходимость ручного восстановления параметров и снижает риск простоя при переходе на новую версию PHP.
Добавление официального репозитория PHP для актуальных версий
Стандартные репозитории большинства дистрибутивов Linux содержат устаревшие версии PHP, которые не получают своевременных обновлений и исправлений безопасности. Для установки и обновления актуальных версий PHP необходимо подключить проверенный внешний репозиторий, совместимый с конкретным дистрибутивом и его версией.
Для систем на базе Ubuntu и Debian используется репозиторий ondrej/php, который поддерживает параллельную установку нескольких версий PHP, регулярные обновления и полный набор расширений. Подключение выполняется только после обновления списка пакетов и установки инструментов работы с HTTPS-репозиториями.
В дистрибутивах семейства RHEL (CentOS, AlmaLinux, Rocky Linux) применяется репозиторий Remi, интегрированный с AppStream. Он позволяет выбирать конкретную версию PHP через модульные потоки и получать обновления без ручной компиляции.
Выбор репозитория должен строго соответствовать дистрибутиву и его версии. Использование неправильного источника пакетов приводит к несовместимости библиотек и невозможности обновления PHP.
| Дистрибутив Linux | Рекомендуемый репозиторий PHP | Поддерживаемые версии PHP |
| Ubuntu / Debian | ondrej/php | 7.4, 8.0, 8.1, 8.2, 8.3 |
| CentOS 7 | Remi | 7.4, 8.0, 8.1 |
| AlmaLinux / Rocky Linux 8–9 | Remi + AppStream | 8.0, 8.1, 8.2, 8.3 |
После добавления репозитория необходимо обновить кэш пакетов и убедиться, что система видит доступные версии PHP. Только после этого следует переходить к установке или обновлению PHP, чтобы избежать частичной установки пакетов и ошибок зависимостей.
Обновление PHP через пакетный менеджер apt или yum
После подключения корректного репозитория обновление PHP выполняется штатными средствами пакетного менеджера. На этом этапе важно установить не только основной пакет PHP, но и все расширения, которые используются приложениями и веб-сервером.
В системах на базе Ubuntu и Debian обновление начинается с актуализации индекса пакетов:
- apt update – загружает актуальные списки пакетов из подключённых репозиториев.
Установка новой версии PHP выполняется явным указанием версии, что позволяет избежать автоматической замены без контроля:
- apt install php8.2 php8.2-fpm php8.2-cli
Дополнительно необходимо установить используемые расширения, иначе приложения могут перестать работать:
- php8.2-mysql – поддержка MySQL и MariaDB.
- php8.2-gd – обработка изображений.
- php8.2-intl – локализация и работа с Unicode.
- php8.2-opcache – кэширование байткода.
В дистрибутивах CentOS, AlmaLinux и Rocky Linux используется пакетный менеджер yum или dnf. Перед установкой требуется выбрать поток нужной версии PHP:
- dnf module reset php – сбрасывает активный поток PHP.
- dnf module enable php:remi-8.2 – включает поток нужной версии.
После выбора версии выполняется установка PHP и расширений:
- dnf install php php-fpm php-cli
- dnf install php-mysqlnd php-gd php-intl php-opcache
После завершения установки рекомендуется проверить отсутствие ошибок зависимостей и убедиться, что новые пакеты PHP корректно зарегистрированы в системе, прежде чем переходить к переключению версии по умолчанию и перезапуску сервисов.
Переключение версии PHP по умолчанию в системе
После установки новой версии PHP система продолжает использовать ранее активную версию, пока явно не выполнено переключение. Это касается как командной строки, так и веб-сервера, поэтому необходимо проверить и настроить оба окружения.
В дистрибутивах Ubuntu и Debian переключение версии PHP для CLI выполняется через механизм update-alternatives. Команда позволяет выбрать, какой бинарный файл PHP будет использоваться по умолчанию при выполнении php в терминале.
Для изменения версии PHP в веб-окружении требуется отдельно включить нужный модуль или сокет PHP-FPM. При использовании Apache необходимо отключить старую версию PHP и активировать новую, иначе сервер продолжит обрабатывать запросы через предыдущий модуль.
При работе с Nginx и PHP-FPM ключевым моментом является корректный путь к сокету или TCP-порту. Конфигурация виртуальных хостов должна указывать на каталог вида /run/php/php8.2-fpm.sock или соответствующий порт новой версии, иначе PHP-код будет выполняться старым пулом.
Перезапуск Apache или Nginx после обновления PHP
После обновления PHP веб-сервер продолжает использовать загруженные ранее модули и сокеты, поэтому без перезапуска новая версия PHP не применяется. Перезапуск требуется даже в тех случаях, когда пакеты установлены корректно и версия PHP уже доступна в системе.
При использовании Apache перезапуск необходим для загрузки обновлённого модуля PHP или корректного подключения к PHP-FPM. Если этого не сделать, сервер продолжит обрабатывать запросы через старую версию интерпретатора.
Для связки Nginx + PHP-FPM требуется перезапуск не только веб-сервера, но и службы PHP-FPM. Особенно важно убедиться, что запущен именно пул новой версии PHP, а сокет или порт соответствует обновлённой конфигурации.
После перезапуска сервисов следует проверить их статус, чтобы убедиться в отсутствии ошибок запуска. Неуспешный старт Apache, Nginx или PHP-FPM чаще всего указывает на некорректные пути к сокетам, несовместимые директивы или отсутствующие расширения PHP.
Дополнительно рекомендуется проверить журналы error.log и логи PHP-FPM сразу после перезапуска. Ошибки уровня fatal или warning на этом этапе позволяют быстро выявить проблемы, связанные с обновлением PHP, до того как они повлияют на работу сайтов.
Только после успешного перезапуска веб-сервера и PHP-FPM можно считать обновление PHP завершённым и переходить к финальной проверке работы приложений.
Проверка корректной работы PHP после обновления
После обновления необходимо убедиться, что PHP действительно работает в новой версии и корректно обрабатывает запросы. Первым шагом выполняется проверка версии в командной строке командой php -v, которая должна соответствовать установленной версии без упоминаний старых сборок.
Отдельное внимание следует уделить расширениям, используемым приложениями. Необходимо убедиться, что модули pdo_mysql, curl, mbstring, intl и opcache загружены и не помечены как отключённые.
После визуальной проверки выполняется анализ журналов ошибок. Для Apache и Nginx это файлы error.log, для PHP-FPM – журналы пулов. Ошибки уровня deprecated и fatal error часто указывают на несовместимость кода с новой версией PHP.
Завершающим этапом является тестирование сайтов и скриптов, включая формы, авторизацию и фоновые задачи. Если страницы загружаются без ошибок, логи остаются чистыми, а нагрузка не выросла, обновление PHP можно считать успешно завершённым.
Вопрос-ответ:
Можно ли обновить PHP на сервере, где работает несколько сайтов с разными требованиями к версии?
Да, на большинстве Linux-серверов можно установить несколько версий PHP одновременно. Для Ubuntu и Debian это реализуется через репозиторий ondrej/php, а для AlmaLinux и Rocky Linux — через Remi и модульные потоки. Каждый сайт на Apache или Nginx можно привязать к своей версии PHP через отдельный сокет PHP-FPM. Это позволяет обновить PHP для одного проекта, не затрагивая остальные.
Почему после обновления PHP сайт начинает выдавать ошибки, хотя установка прошла без сбоев?
Чаще всего причина связана с несовместимостью кода или расширений с новой версией PHP. После обновления могут отсутствовать модули, которые раньше были установлены автоматически, либо в логах появляются ошибки deprecated или fatal error. Решение — проверить список загруженных расширений, журналы ошибок и при необходимости скорректировать код или установить недостающие модули.
Нужно ли удалять старую версию PHP после обновления?
Удаление старой версии не является обязательным. На сервере часто оставляют предыдущую версию PHP для быстрого отката при проблемах. Если сервер стабильно работает на новой версии и старые сайты больше не используются, устаревшие пакеты PHP можно удалить вручную, предварительно убедившись, что они не задействованы веб-сервером или планировщиком задач.
Чем отличается обновление PHP для CLI и для веб-сервера?
CLI использует бинарный файл PHP, выбранный по умолчанию в системе, тогда как веб-сервер работает через модуль Apache или PHP-FPM. После обновления версия PHP в терминале может измениться, а сайты продолжат работать на старой версии. Поэтому всегда требуется проверять обе среды отдельно и настраивать переключение для PHP-FPM или модулей Apache.
Как понять, что обновление PHP прошло успешно и сервер работает стабильно?
Успешное обновление подтверждается совпадением версии PHP в CLI и через phpinfo(), отсутствием ошибок запуска Apache, Nginx и PHP-FPM, а также чистыми журналами ошибок. Дополнительно проверяются основные функции сайтов: загрузка страниц, работа форм, подключение к базе данных и выполнение фоновых скриптов. Если нагрузка и отклики остались на прежнем уровне, обновление можно считать завершённым.
Можно ли обновить PHP без остановки сайтов и как снизить риск простоя?
Обновление можно выполнить с минимальным простоем, если новая версия PHP устанавливается параллельно со старой. В этом случае сайты продолжают работать на текущей версии, пока не будет выполнено переключение сокета PHP-FPM или модуля Apache. Перед сменой версии рекомендуется проверить конфигурацию и запустить новый пул PHP-FPM отдельно, а само переключение выполнить в период низкой нагрузки.
Что делать, если после обновления PHP перестал работать планировщик cron?
Чаще всего проблема связана с тем, что cron использует старый путь к бинарному файлу PHP. После обновления следует проверить, какая версия PHP указана в заданиях cron, и при необходимости заменить вызов php на полный путь к нужной версии, например /usr/bin/php8.2. Также стоит проверить, какие расширения доступны в CLI, так как окружение cron отличается от веб-сервера.
Загрузка...
