Installing more PHP versions in VestaCP using Docker

Started by lovtzova, Aug 07, 2022, 06:27 AM

Previous topic - Next topic

lovtzovaTopic starter

Probably, many of you have come across a situation where among the projects running on modern software, there are a couple of half-forgotten ones, and you don't want to keep a separate machine for them. There are many solutions, but in the support service of the hosting company, this problem does not lose its relevance.

My colleagues have developed a script that helps to add the required version of PHP to VestaCP in just a couple of minutes. This method has already proven itself on the good side, and it continues to please the support staff. It's time to publish it and help everyone who is faced with a similar problem.

In order to use the solution, it is enough to copy one line into the terminal, but we will take a closer look at how it all works.


Executed by the command:

    git clone && cd vestaphpinstaller && chmod +x && bash -s --5.6

Will install (if not already installed) docker via a unified installer (tested on CentOS7 and Ubuntu).

The last argument in the command is the desired PHP version. PHP versions currently available are 5.2, 5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2 and 7.3. The script will create a template for Vesta and two service files: docker.httpd and docker.php.56.

All services install/update images, and therefore the first launch (for example, connecting a template in Vesta) or restarting if updates are available may take some time.

PHP runs as www-data. The appropriate user will be created on the host (if not already). The owner of the website directory will be changed to www-data, the group will remain the same. The /opt/docker/ directory will also be created to store configuration files.

As a result, we will spend ~ 800 Mb on installing the docker itself and about ~ 400 Mb on images, but we will get a performance boost. The results of measuring performance using Bitrix are 1.5-2 times higher for the VestaCP + Docker bundle than when using a similar version of PHP as an Apache module.

Installation on a single-core processor

Installing a docker container on a server with a single-core processor (cpu=1) will not automatically start the PHP container.
In such cases, you need to edit the file /etc/systemd/system/docker.php.56.service (where 5.6 is the installed version of PHP):

--cpus=2 change to --cpus=1

Next, restart docker:

    systemctl stop docker
    systemctl start docker

Then switch to the desired PHP version in the VestaCP panel. If the desired version is already selected, then you should to switch to the default, save and switch again to the desired PHP version.
Scheme of work

The scheme of work is as follows:

Nginx -> apache in a container -> php-fpm in a container.

Apache needed to be packaged in a container (~80mb) due to version differences between CentOS and Apache. The version in Centos does not correctly proxy requests to fpm.

Apache is running on port 9080, so the script edits the nginx configuration. Switching to the default Vesta template (default) will return the old port (8080).

PHP runs on 9000+version i.e. 9056, 9070, 9072 etc.


httpd is started like this:

    docker run --rm --network host
    -v /home:/home
    -v /var/log/httpd/domains:/var/log/apache2/domains
    -v /opt/docker/conf/web:/usr/local/apache2/conf/vhosts
    --name docker-httpd kotpoliglot/php:httpd

/opt/docker/conf/web contains hosts, httpd in a container with a minimum set of modules due to resource savings, hosts for containers are stored in /opt/docker/conf/web, in the Vesta directory (/home/admin/conf/ web/) an empty file is created.

PHP is run like that:

    docker run --rm --network host --cpus=2
      -v /etc/passwd:/etc/passwd
      -v /etc/group:/etc/group
      -v /etc/hosts:/etc/hosts
      -v /var/lib/mysql/mysql.sock:/var/run/mysqld/mysqld.sock
      -v /opt/docker/conf/php/56/php.ini:/usr/local/etc/php/conf.d/docker.ini
      -v /home:/home --name php-56 kotpoliglot/php:56

passwd and group are passed to the container due to different requirements for uname and uid in CentOS and Ubuntu.

/etc/hosts - external addresses of Vesta domains, they are needed in the container for the correct operation of sockets in Bitrix, for example. The file is updated every time you switch templates in Vesta.
/opt/docker/conf/php/56/php.ini - a file with which you can influence the PHP settings in the container.

Adding modules and packages

If necessary, you can add one or another module or package to the container. The images are based on alpine to save resources. Packages are installed via apk, for example, we create a Dockerfile with the following content:

    FROM kotpoliglot/php:56
    RUN apk add --no-cache libpng-dev

Then we save the file and execute:

    docker build -t kotpoliglot/php:56 .


In case a PHP module is required, the containers have a set of scripts docker-php-ext-configure , docker-php-ext-install and docker-php-ext-enable (description).

The installation will look like this: create a Dockerfile in an arbitrary directory with the following content:

    FROM kotpoliglot/php:56
    RUN docker-php-ext-install zip

Then we recreate the image:

    docker build -t kotpoliglot/php:56 .

A new image will be created with the same name and the installed module.

service file, delete ExecStartPre=/usr/bin/docker pull kotpoliglot/php:56 so that the local image is launched, and not the newly downloaded from DockerHub.

Service files are available at /etc/systemd/system/.

If you found this tool useful, please let me know.


Vesta was last updated over two years ago.
There are unpatched vulnerabilities, more than three hundred open issues on the github, lack of support for Ubuntu 20, Debian 10. It is unlikely that Vesta is a good choice for the panel now.


if we use Nginx in PHP-FPM, we lose the opportunity to use it.htaccess files and we have a need for custom Nginx configurations for each site.
If you want to use Nginx+PHP-FPM, I recommend looking at ISPConfig - an excellent free hosting control panel with more functionality than VestaCP.
this solution is just for supporting old projects, in which, moreover, in the same .htaccess there may be a whole history of renaming sections of the online store, different subdomains in different folders, etc..
    The following users thanked this post: Sevad