I run a container for each service. Remember that one of the Docker principles is "separation of concern".
You may have Nginx + PHP-FPM on the same container, though.
To launch all the services (in dev or prod environment) you can use docker-compose and the magic "SYMFONY_ENV=dev" environment variable to launch everything. I suggest to launch the consumers in a separate conainer, but with different project / log /cache paths, possibly. Consider that consumers, on production, may affect online performances if they are running with shared CPU/memory/disk.
I am currently investigating alternatives to deploy/postdeploy the webapp, the suboptimal solution is now a simple entrypoint bash script (which is passed to "docker run -d myimage php_entrypoint.sh" that:
- prepares the environment
- downloads and updates vendors
- syncs resources to cdn, updates db schema, etc
- runs the applications server (php-fpm in this case, i use supervisord to do the task)
It results in something like this:
#$OPTIMIZE is an ENV-propagated or a calulated variable
su -c "php composer.phar install $OPTIMIZE" webmgr
cp -f web/HTACCESS_${SYMFONY_ENV} web/.htaccess
/usr/bin/supervisord -c /etc/supervisord/supervisord.conf
The reason why I am using supervisord is that I have to copy/mount the [program:] sections that I need to run, thus maintaining a single php image that is good both for php-fpm and CLI/consumer work. I can also restart the php appserver without killing the container. Moreover, supervisord is quite clever at managing "daemonized" processes.
UPDATED
The webapp is mounted as a volume, and docker-compose.yml is in the project root directory, which contains docker image configurations and the symfony project. This is an excerpt of docker-compose.yml
webapp_fpm:
image: ...
volumes:
- ./symfony:/var/www/html
- ./docker-conf/supervisord:/etc/supervisord
- /var/log/appname/symfony:/var/log/symfony
entrypoint: "/bin/bash php_entrypoint.sh"