Centos 7 удалить php 7

Обновлено: 03.07.2024

Некоторое время назад вышла новая, практически революционная версия php 7. Революционная, потому что обещает существенный прирост производительности, в отличие от предыдущих обновлений. По предварительным данным из описаний и обещаний, якобы в некоторых случаях может быть прирост скорости обработки php в разы. А если не повезет, то на 30-70%. Решил я это проверить на свою голову.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти . Данная статья устарела. Более подробную и актуальную информацию по обновлению php 7 читайте в новом материале на тему настройки web сервера nginx и php-fpm.

Введение

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

Сразу предупреждаю, что не нужно слепо повторять то, что делал я. Просто примите к сведению информацию, которой я делюсь. Я не являюсь специалистом по тонкой настройке web серверов.

Я решил поэкспериментировать и проверить, насколько быстрее будет работать мой блог, если я перейду на php 7. Этот сайт работает на wordpress, до обновления он работал на php54 с включенной системой кэширования apc. Достаточно старая версия, но именно она ставится из стандартных репозиториев centos, которые я использую. Уже не помню точно, откуда он ставится, то ли из базового, то ли из epel. Как оказалось, не зря ставится эта версия. Серия моих экспериментов и проверок подтвердила, что именно на этой версии достигается максимальная производительность в моем конкретном случае.

Я попробовал обе утилиты и остановился на siege. Она позволяет проводить измерения наиболее приближенные к реальному поведению пользователей на сайте. Не буду в этой статье подробно останавливаться на описании работы утилиты, в интернете информация есть, легко ищется. Если вам нужно, то сами все найдете и протестируете.

Я настроил siege и прогнал серию тестов, создающую разную нагрузку и зафиксировал результаты. После этого стал готовиться к обновлениям. Сразу скажу, что итоговый результат меня не удовлетворил и я вернулся на начальную свою конфигурацию. Обо всем по порядку расскажу.

Обновление php 5.4 до php 7

Сразу расскажу о проблемах, с которыми вы столкнетесь после обновления php70.

У вас не будет работать phpmyadmin без танцев с бубном. После обновления панель управления сразу перестала работать. Я немного погуглил тему, заставить работать можно, но нужно поковыряться. Мне не захотелось этого делать, подробно не разбирался в теме.
У меня перестал работать некоторый функционал плагинов в админке wordpress. При этом сам вордпресс работает нормально, его похоже оптимизировали для работы с php70. Получилось, что сайт в целом работает, но некоторые плагины не работают, либо ими нельзя управлять. WP Super Cache вообще не заработал, пока его не отключил, не мог загрузить главную страницу сайта, вместо нее белое полотно. Панель управления моей темой не открывала некоторые страницы с настройками.

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

Теперь информация об обновлении. Существуют как минимум 2 репозитория, которые можно подключить к CentOS 7 и установить обновление php70. Это либо ius с пакетом php70u, либо webtactic с php70w. Чем они отличаются я не знаю, не стал вникать. Я решил воспользоваться репозиторием ius. Подключаем его:

Скрипт подключит нужное репо в соответствии с вашей системой. Теперь можно удалять старую версию php и устанавливать php70.

Дальнейшие действия будут зависеть от того, что вы используете на вашем веб сервере. У меня установлен nginx + php-fpm примерно по приведенной статье. Мне необходимо удалить пакеты:

Удаление этих пакетов тянет за собой удаление всех зависимостей. Запишите их куда-нибудь, чтобы потом установить новые версии этих пакетов. В качестве пакета к удалению будет в том числе и phpmyadmin. Впоследствии его можно будет установить только вручную из исходников. Если вы используете apache, то необходимо удалить mod_php, а затем заново установить mod_php70u.

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

Я точно не помню, но скорее всего этот список соответствует требованиям wordpress и phpmyadmin. Больше у меня на сервере ничего не было, поэтому лишних пакетов быть не должно. После установки нужно чуть-чуть отредактировать конфигурацию php-fpm.

Если в качестве подключения к php-fpm использовали не unix socket, то придется перейти на него. Для этого закомментируйте строку:

и добавьте новую:

Сохраняем конфиг и перезапускаем php-fpm:

Если вы использовали unix socket, то в конфиге nginx ничего менять не надо, если же TCP socket, то нужно заменить строку:

После этого перезапустите nginx:

Обновление php до версии 7.0 окончено. Можно проверять вывод phpinfo();

Подключение модулей кэширования и тестирование производительности web сервера

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

Первым делом я запустил тесты голого php70, без кэширования. Результаты при средней нагрузке, когда сервер успевает обработать все запросы, но работает на пределе своих возможностей, примерно оказались равны php54+apc. Но когда нагрузка сильно возрастает, образуется очередь запросов, php70 начинает в 2-3 раза медленнее обслуживать запросы, время отклика вырастает в 2-3 раза.

Я так прикинул, думаю, вроде неплохой результат. Сейчас включу apc и замерю как с ним будет. Оказалось, что модуль apc давно не поддерживается и поставить его на версию выше php54 нельзя. Вместо него теперь apcu. Думаю ладно, не проблема. Подключаю apcu и тестирую с ним. Результат меня расстроил. На средней нагрузке результат практически не изменился, на высокой нагрузке стал чуть хуже, а на очень высокой вообще в 2 раза просел по сравнению с работой без модуля.

Я понял, что никакого чуда с обновлением php70 не произошло. Прироста производительности я не получил, а получил кучу проблем в виде неработающих плагинов и phpmyadmin. Я принял решение откатываться назад, но не на версию php54, как было, а решил попробовать php56, чтобы проверить, что у него со скоростью.

К сожалению, уже после удаления 7-й версии php, я узнал, что модуль apc и apcu имеют принципиальное отличие и сравнивать только их нельзя. В результате мои тесты оказались недостоверны и с практической точки зрения бесполезны. Дело в том, что apc является opcode cache and data store, а apcu только data store. Таким образом, чтобы корректно протестировать производительность, мне нужно было в php70 включить еще opcache, который является opcode cache. Такая связка показала бы сопоставимый результат.

Мне все же любопытно проверить реальную производительность php70 в рабочей обстановке. Но постоянно пользоваться им пока не представляется возможным из-за проблем совместимости.

Откат обновления php 7.0 до php 5.6

Я решил откатиться на версию php 5.6. Ничего сложного в этом нет. Я уже рассказывал ранее, как в centos обновить php54 до php56. Воспользуемся информацией из этого материала. Сначала удаляем php70:

И устанавливаем все те же пакеты, что мы до этого удалили из версии php54, потом поставили и удалили php70 :)

Перезапускаем php-fpm. Он может ругнуться на строку:

Если так, то удалите ее. Я не помню, в какой версии она появляется, в 5.6 или в 7.0, в 5.4 ее точно не должно быть.

После отката на php5.6 я подключил модуль apcu и начал гонять тесты. Думаю и так понятно, что они все были хуже, чем php54+apc, так как принципы работы apc и apcu разные. Так что не буду останавливаться на этом. Жаль, что узнал об этом отличии я слишком поздно, когда уже вернулся обратно на php54 и стал спокойно разбираться в ситуации.

Я принял решение откатиться с версии php56 обратно на php54.

Отмена обновления php 5.6 и возврат на php 5.4

Тут все просто. Удаляем php56:

Подключаем и настраиваем apc как описано в моей статье и проводим тесты. Убеждаемся, что производительность вернулась на прежний уровень.

Заключение

Устроил марафон на своем сервере с сайтом. Результат практически нулевой, за исключением полученных знаний. Так как раньше я вообще был не в теме всех нюансов настройки php и веб сервера, получил некоторое представление о том, как все это работает и в какую сторону нужно двигаться для увеличения производительности. Запланировал на тестовом сервере спокойно разобрать этот вопрос и протестировать производительность wordpress.

Подозреваю, что на слабеньких VDS с небольшой памятью и одним процом большого смысла городить дополнительные модули, которые тратят и так маленькие ресурсы сервера, не нужно. Существенного прироста производительности не будет. У меня все всегда упиралось в процессор при высоких нагрузках. Если нужно быстро ускорить wordpress в разы, то достаточно просто включить какой-нибудь кэширующий плагин, который генерирует статические страницы и выдает их пользователям. Прирост сразу же в десятки и сотни раз. Статический контент nginx отдает моментально и даже слабый VDS самого начального уровня способен будет обрабатывать одновременно сотни запросов.

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

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

Рассмотрим обновление на PHP 7-ой версии в системе CentOS 7 работающей с Nginx. Произведем настройку после обновления необходимых конфигурационных файлов для работы ресурсов использующих php. Процесс обновления сложный требующий внимания и ответственности.

Введение

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

Обязательно перед обновление сделайте резервную копию системы и после обновления максимально проверьте все ресурсы использующие PHP!

В моем случае я обновляю версию которую устанавливал в статье Установка и настройка PHP.

В другой статье вы узнаете как работать с PHP используя репозиторий Remi для CentOS 7.

Удаление старой версии PHP

Перед тем как установить новую версию нам надо определить какая стоит версия, какие пакеты и с какого репазитория.

Подготовка перед удалением

Проверим установленную версию:

Выведем весь список установленных пакетов:

Исходя из вывода удалим все эти пакеты. Новую версию php мы будем устанавливать с другого репазитория. Репозиторий remi нам больше не нужен и мы его удалим.

Удаление PHP 5.6

Удалим одной командой:

Внимательно смотрим лог обновления на предмет ошибок и предупреждений! Сохраните все ошибки и предупреждения. Уверяю в последствии это сильно сократит время в настройке после обновления!

Удаление репозитория Remi-safe

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

Выведем список всех используемых репозиториев:

В выводе видим точное имя которое мы используем при удалении:

После всех действий обновим систему чтобы окончательно всё подготовить к установке новой версии:

Установка новой версии PHP

Выбор репозитория и версии PHP 7

Вероятно есть разные варианты установки PHP 7 версии, но мне нравится репозиторий WebtaticEL про него и расскажу.

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

Перейдя по ссылке вы увидите все варианты версий возможных для установки а так же способы их установки в необходимую вам систему. Мой выбор пал на версию PHP 7.1 так как на данный момент это самая стабильная новая версия.

Добавление репозитория Webtatic

Добавим репозиторий в систему:

После добавления любого репазитория необходимо обновить список пакетов. В CentOS это можно сделать командой вывода всех репозиториев которая заодно и обновит весь список пакетов:

Установка PHP 7.1

Установим все нужные мне пакеты исходя из тех что удалял:

Сознательно не стал ставить параметр с которым всё установится без вопросов. Лучше всегда быть на контроле таких сложных и ответственных обновлений.

Можем уставим все что есть, но решать вам самим что для вас лучше:

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

Проверка после обновления PHP

После обновления первым делом проверим какая версия php в системе:

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

Ошибки в логах установки/удаления

В моем случае было несколько предупреждений:

Как видите система сказала что в двух случаях она создала новые файлы а старые сохранила с пометкой rpmsave. В случае когда система не смогла создать новый файл она создала его с пометкой rpmnew.

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

Настройка PHP-FPM после обновления

Так как у нас работает Nginx и для связки с php используется php-fpm мы проверим необходимую службу:

Из вывода мы видим что служба остановлена и отсутствует в автозагрузке. Добавим в автозагрузку, запустим и посмотрим статус:

Видим что служба находится в автозагрузке и работает.

Вывод всех параметров PHP 7

Последнее что нам осталось сделать для полного понимания проделанной работы это посмотреть вывод всей информации о версии php. Создадим на работающем ресурсе в корневой директории сайта файл info.php и поместим туда код:

Вывод

Судя по статье может показаться что обновление версии PHP не такое уж и сложное дело но уверяю что эта простота придет только с опытом. Многое зависит от того как долго не обновляли систему, какие ресурсы там работают и какие у каждого в отдельности требования к версии php. В случае если вам досталась система с которой работали разные люди и мало чего комментировали в коде сложностей может возникнуть очень много и единственное что вас спасет от головной боли в случае неправильной работы важных ресурсов это резервное копирование перед выполнением обновления. Лучшим вариантом при обновлении таких систем это сделать клон системы и производить все действия на нем. Конечно при работе с клоном может возникнуть дополнительные сложности но это уже другая тема.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

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

Yum (Yellowdog Updater Modified) – консольный менеджер пакетов для дистрибутивов Linux, основанных на пакетах формата RPM (RedHat Package Manager). Сюда входят такие популярные ОС как RedHat, CentOS, Fedora, Oracle Linux, Scientific Linux.

Yum: установка, обновление и удаление пакетов

Полная справка по менеджеру пакетов yum :

Очистить кеш всех пакетов (обчычно используется при возникновении проблем при работе yum):

Пересоздать кеш пакетов заново:

Отобразить список подключенных репозиториев:

Вывести список всех доступных пакетов для установки:

Список всех пакетов, которые установлены в системе:

Вывести список пакетов, которые относятся к ядру Linux:

Проверить установлен ли в системе определенный пакет, например, apache:

Можно получить более подробную информацию о пакете:

Чтобы установить пакет используется команда yum install . Для установки веб-сервера apache выполните:

Перед установкой пакета можно проверить его на зависимости и необходимые пакеты с помощью команды:

Если вы хотите установить какой-либо пакет, но забыли его полное название, можно воспользоваться подстановочным символом * . Например:

Можно установить сразу несколько пакетов:

Удалить установленный пакет:

!Но перед удалением любого пакета, рекомендуется сначала проверить его на зависимости (бывают пакеты, удаление которых влечет за собой удаление множества других пакетов, что в следствии приводит к неработоспособности системы):

Найти пакет по имени или описанию:

С помощью опции provides вы можете найти пакеты, содержавшие определенный файл, например:

Выполнить обновление всех установленных пакетов:

Вы можете обновить только определенный пакет, указав его имя:

Проверить если доступные обновления для системы можно командой:

Получить информацию о доступных обновлениях безопасности:

Бывают случаи, когда после обновления какого-либо пакета или сервиса, возникают проблемы. Например, после обновления php, перестало работать ваше приложение или сайт. Вы можете вернуть предыдущую версию пакета, откатив установленный пакет:

Имеется возможность группой установки пакетов командой grouplist . В репозитории существуют предопределенные группы пакетов с различными наборами программ. Вы можете вывести список имеющихся групп:

Рассмотрим на примере группового листа «Basic Web Server». Получить информацию о группе и пакетах в ней:

При проверке мы видим, что будут установлены набор пакетов и сервисов для веб-сервера.

Ещё один полезный групповой лист «System Administration Tools»:

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

Установить групповой лист можно командой:

Yum: история и логи установки/удаления пакетов

Вы можете вывести информацию об истории установки пакетов yum (списка транзакций) с помощью команды:

Вывод состоит из 5 столбцов, в первом выводится ID транзакции по которому можно посмотреть всю информацию (установленные пакеты, зависимости):

Более того, можно отменить данную транзакцию командой:

В моем случае удалилось бы 4 пакета:

Так же всю информацию об истории установки/удаления пакетов менеджером yum можно посмотреть в логе /var/log/yum.log :

Дополнительные полезные параметры yum

Утилита yum имеет несколько полезных опций, которые часто приходитя использовать при управлении пакетами. Чтобы при установке или удалении пакетов, после ввода команды не подтверждать своих действий, можно воспользоваться опцией -y , например,:

Чтобы ответить no при запросе, нужно указать опцию:

Использовать yum без плагинов или отключить конкретный плагин:

Включить отключенный плагин:

Задействовать отключенный репозиторий:

Отключить определенный репозиторий:

Конфигурационный файл /etc/yum.conf

Конфигурационный файл yum — /etc/yum.conf .

Основные параметры конфигурационного файла:

cachedir – локальный кэш пакетов (по умоланию /var/cache/yum )

logfile — путь до файла с логами yum

obsoletes — обновлять или нет, устаревшие пакеты(1-да, 0-нет)

gpgcheck — проверка подписи пакета перед установкой (1-да, 0-нет)

keepcache — хранение кеша (1-да, 0-нет)

cachedir — директория для хранения кеша(по умолчанию /var/cache/yum )

debuglevel – уровень отладки от 1 до 10

plugins — включение yum плагинов (1-да, 0-нет)

installonly_limit – максимальное количество версий, которые могут быть установлены для одного пакета.

Полезные плагины yum

Некоторые популярные плагины и их описание:

yum-plugin-fastestmirror – плагин служащий для измерения скорости зеркал и предоставления самого быстрого для установки пакетов.

yum-plugin-security — плагин которые предоставляет список обновлений относящихся только к безопасности системы.

yum-plugin-keys — позволяет работать с ключами keys, keys-info, keys-data, keys-remove

Директория где хранятся все плагины /etc/yum/

yum-plugin-versionlock – позволяет блокировать обновление указанных пакетов

Вывести список доступных плагинов yum:

Вы можете установить выбранный плагин командой yum install , как и любой другой пакет:

Чтобы заблокировать обновление пакета через плагин, выполните:

Вывести список заблокировнных пакетов:

Убрать пакет из заблокированных:

Если вам в какой-то момент времени не нужно использовать определенный плагин, вы его можете отключить, добавив префикс при вызове yum:

Или же отключить вообще все плагины, установленные в системе:

Использование yum через прокси

Если прокси-сервер требует авторизацию, добавьте строки:

Для проверки работы yum через прокси сервер воспользуйтесь командой:

Для проверки я указал публичный прокси сервер с Германии и при установке, сработал плагин fastestmirror , нашел зеркала с которых скорость будет выше: