Select PHP version for a specific CMS and do not cry

“I told you - they flew, but they didn’t run!”
“Come on, ostrich, go! We work, we work! ”



PHP is now one of the most popular programming languages ​​used to create websites. On shared linux web hosting in Russia with the choice of the PHP version is not entirely smooth, although there are exceptions to this rule.
Why is version selection necessary? Interesting? Welcome under the cut!

Consider the system requirements of the most common CMS on the Russian market - WordPress , Bitrix , Drupal and Joomla for PHP versions (we will not talk about the modules, this is a topic for a separate article):

But what comes out of the box in the most common distributions, which are installed at the hosts:

We use CloudLinux , which corresponds to CentOS 6.7 in terms of package base. The “out of the box” situation is not bright - the PHP versions are very old.
And those clients whose site has been created for a long time and CMS has not been updated (and there are many of them coming to us from other hosting sites) usually want exactly the opposite - older versions of PHP due to the fact that their CMS has compatibility problems.
So there are two ways out: either collect from the source itself, or install from third-party repositories, which is not always possible.

What to do, how to be:

• Constantly rebuild packages from source?
• Depend on third-party repositories (people)?
• Watch for bug tracks for prompt patching?
• Keep a few VPS or dedicated servers with different versions of PHP for various WEB projects (and also for development)?

')
There is an alternative and we use it in our work: CloudLinux + CageFS + PHP Selector ! My colleague told about the first two components in a recent article .
These three components allow us to do the following:

• Reduced labor costs, both for deployment and for project support.
• Ability to choose PHP version without contacting technical support. Switch versions in less than a minute!
• Backup and access to the console or directories using secure SSH protocol. Also a proven way - the FTP protocol.
• Disaster - the ability to quickly deploy infrastructure in another data center `s.

To obtain this functionality, we had to test and then implement the following:

• Create your own repository and update system for it. What cost us the appearance of red-eye employees. We built PHP assemblies (5.2 - 5.6) with our own parameters in order to install and use them in parallel in one system.
• Create management pages on the self-service portal.
• Implement a trained agent in CloudLinux for billing and service management from LK. At the time of development of the agent in CloudLinux, there was still no such functionality as PHP Selector, therefore, the agent itself performs this function.

How does all this happen in a real environment? This can be done from LC:

• With a registered account we go into the client’s personal account . You can register for free.
• Add the service “Hosting on Linux”, one of the four tariffs.
• Enter service settings:
  
  look

  
  
  
  
• Select the PHP version and click save. Somewhere in a minute, LK will poll the agent installed on the WEB-box and give him the changes. The agent, in turn, for the desired user will change the wrapper to run PHP, to the selected version.

Additionally, you can enable modules on the WEB service:


I will dwell a bit on the agent that interacts between the LC and the system where the hosting is deployed. The agent (written in python) is a service with a documented api that allows you to interact with CloudLinux. as an orchestrator. With regards to PHP - the agent allows you to change the version and settings for a specific client. When creating a new service (user), the agent uses the predefined settings, which can later be changed to custom ones.

If it is interesting to find out how it all works in more detail, I am waiting for comments on the most interesting points.

If you see any errors in the article - please write about it in PM.