Starting Docker containers from PHP

When I attempt to startup a Docker container via PHP I get the following error

level="fatal" msg="Get http:///var/run/docker.sock/v1.16/containers/json?limit=1: dial unix 
/var/run/docker.sock: permission denied. Are you trying to connect to a TLS-enabled daemon 
without TLS?" 

I try to execute the docker run command via shell_exec so the executing user, on Ubuntu 14.04, is www-data. For good measure I tried to run the docker command as sudo but it made no difference. Googling around for “Are you trying….” turns up a few links that may well have some information that is relevant – e.g. here – but I have not been able to make much sense of it yet.

Also for good measure I output the Docker command I am trying to execute to stderr, copied it and executed it via SSH directly. Here is that command

docker run -h user118 -d -p 8406:443 -v /var/docks/user118/logs:/var/log/apache2 -v 
/var/docks/user118/mysql:/var/lib/mysql -v /var/docks/user118/redis:/var/lib/redis -v 
/var/docks/user118/secure:/var/secure -v /var/docks/user118/site:/var/www/html lamp

followed by

docker ps -a

and then browsing to that container – no issues, everything works perfectly.

I am aware that command is going to provoke comments along the lines of “you should only have one app per container”. That is not the issue here.

Am I trying the impossible here or is there a relatively simple way to manipulate Docker via a PHP script and shell_exec?

Answer

I am posting this as an answer rather than as a comment since it does in fact resolve the issue. However, I do have reservations about the solution so I am hoping that there are going to be other answers here. I modified sudoers by adding

www-data hostname=(ALL)NOPASSWD:ALL Defaults !requiretty

which offers a complete resolution to the problem – I can now start up the Docker container from a PHP script. Allv very good but I do have some concerns about loosening up sudoers in this way. The environment in which all of this is happening is controlled but even so it does sound like a far from perfect solution.

I tried replacing NOPASSWD:ALL with NOPASSWD:/path/to/script but that does not work since what is expected is NOPASSWD:application.

If anyone could suggest a way that offers a more secure solution I would be most obliged.