This container is intended to run Laravel applications and thus comes with a few items to assist:

• Composer (with hirak/prestissimo for parallel dependency installation)
• PHP Extensions
  • mbstring
  • pdo_mysql
  • gd
  • opcache - Automatically enabled when APP_ENV=production
  • xdebug - Only enabled when XDEBUG_ENABLE=true. Only installed when XDEBUG_ENABLE=true when building the container
• Adding a default virtual host serving apps from /var/www/html/public

For Laravel applications, see bkuhl/laravel-fpm-nginx.

For a container to run cron and other CLI tasks, check out bkuhl/php.

Why 2 processes in 1 container?

1. DNS issues - Both the fpm/nginx containers need to be redeployed when your application is updated. Nginx maintains an internal DNS cache, so while Docker may ensure zero downtime for fpm containers, nginx's internal workings can still create problems. The only way to solve this (that I've found) is to restart the nginx process. Having them on the same container eliminates the problem.
2. Laravel Mix - The front/backend of applications are kind of coupled when using something like Laravel Mix. The index of assets it creates need to be on both containers and running these separately is possible, but redundant.

This container uses S6 Overlay as it's process monitoring solution. Add a new directory to services.d with a run file in it where run in a shell script that kicks off the process. The rest is taken care of for you.

FROM bkuhl/fpm-nginx:latest

WORKDIR /var/www/html

# Copy the application files to the container
ADD --chown=www-data:www-data  . /var/www/html

USER www-data

    # production-ready dependencies
RUN composer install  --no-interaction --optimize-autoloader --no-dev --prefer-dist \

    # keep the container light weight
    && rm -rf /home/www-data/.composer/cache

USER root