“Я же сказал — полетели, а не побежали!”
“Давай, страус, пошел! Работаем, работаем!”



PHP сейчас один из самых популярных языков программирования, используемых для создания сайтов. На shared linux веб хостинге в России с выбором версии PHP не совсем гладко, хотя встречаются исключения из этого правила.
Почему выбор версии необходим? Интересно? Добро пожаловать под кат!

Рассмотрим системные требования самых распостраненных CMS на рынке России — WordPress, Bitrix, Drupal и Joomla к версиям PHP (про модули говорить не будем, это тема для отдельной статьи):

А вот что идет из коробки в наиболее распостраненных дистрибутивах, которые и установлены у хостеров:

У себя мы используем CloudLinux, который по пакетной базе соответствует CentOS 6.7. Ситуация “из коробки” не радужная – версии PHP весьма старые.
А те клиенты, у которых сайт создан давно и CMS не обновлялась (а таких немало приходит к нам с других хостингов) как правило хотят ровно обратного — более старых версий PHP из-за того, что на их CMS имеются проблемы с совместимостью.
Так что выходов два: либо собирать самому из исходников, либо ставить из сторонних репозиториев, что не всегда возможно.

Что же делать, как же быть:

• Постоянно пересобирать пакеты из исходников?
• Зависеть от сторонних репозиториев (людей)?
• Следить за баг трэками для оперативного внесения заплаток?
• Держать несколько VPS или dedicated серверов с разной версией PHP для различных WEB проектов (а ещё и для разработки)?

Есть альтернатива и мы ее используем в работе: CloudLinux + CageFS + PHP Selector! Про первые два компонента мой коллега рассказывал в недавней статье.
Эти три составляющие позволяют нам делать следующее:

• Уменьшение трудозатрат, как на развертывание, так и на сопровождение проектов.
• Возможность выбрать версию PHP не обращаясь к техподдержке. Переключение версий происходит меньше чем за минуту!
• Бэкап и доступ к консоли или каталогам по безопасному протоколу SSH. Также и проверенным способом – протоколом FTP.
• Катастрофоустойчивость – возможность быстрого развертывания инфраструктуры в другом ЦОД`е.

Для получения данного функционала нам пришлось протестировать и потом внедрить следующее:

• Создать собственный репозиторий и систему обновлений для него. Что стоило для нас появлением у сотрудников красных глаз. Сборки PHP (5.2 — 5.6) мы собирали со своими параметрами, для того чтобы установить и использовать их параллельно в одной системе.
• Создать на портале самообслуживания страницы управления.
• Внедрить обученного агента в CloudLinux для биллинга и управления услугами из ЛК. На момент разработки агента в CloudLinux еще небыло такого функционала как PHP Selector, поэтому данную функцию выполняет сам агент.

Как это все происходит в реальной среде? Это можно проделать из ЛК:

• Зарегестрированным аккаунтом заходим в личный кабинет клиента. Зарегистрироваться можно совершенно бесплатно.
• Добавить услугу “Хостинг на Linux”, один из четырёх тарифов.
• Зайти в настройки услуги:
  
  посмотреть

  
  
  
  
• Выбрать версию PHP и нажать сохранить. Где-то через минуту ЛК опросит агента установленного на WEB-боксе и передаст ему изменения. Агент, в свою очередь, для нужного пользователя изменит обертку для запуска PHP, на выбранную версию.

Дополнительно можно включить модули на WEB сервисе:


Немного остановлюсь на агенте, который взаимодействует между ЛК и системой где развернут хостинг. Агент (написан на питоне) представляет из себя службу с документированным api, позволяющую взаимодействовать с CloudLinux`ом. в качестве оркестратора. Касаемо PHP — агент позволяет изменить версию и настройки для определенного клиента. При создании новой услуги (пользователя) агент использует предустановленные настройки, которые позже можно сменить на кастомные.

Если интересно узнать как все это устроено более детально, жду комментарии по наиболее интересным моментам.

Если вы увидите какие-либо ошибки в статье — пишите пожалуйста об этом в личку.