Dockerix

Local Docker for Mac-centered web development environment to run older and newer Drupal (WordPress etc.) (multi-)sites in parallel.

• Debian 9
• Apache 2.4
• MariaDB 10
• PHP 5.6 & PHP 7.1

The underlying base image can be found on Docker Hub: https://hub.docker.com/r/leymannx/apache-multiphp/

You are supposed to put your CMS files into ./www/php56 or ./www/php71 depending on the PHP version you need to run the site with.

The base image comes with:

• drush8 command for older Drupal projects
• drush command for Drush Launcher
• composer
• npm

The databases can be accessed with mysql -uroot -proot -hmariadb from within the base container. When it comes to connecting to a database you have to define mariadb as host (where it usually would be localhost).

Possible routine

Tested with Docker for Mac (Stable channel Version 17.12.0-ce-mac49)

1. $ git clone https://github.com/leymannx/dockerix.git dockerix
2. $ cd dockerix
3. $ docker-compose up -d

Now visit http://localhost:8856 or http://localhost:8871 in your browser to see the corresponding PHP info files.

To run commands inside the base container get inside it with:

$ docker exec -it dockerix_multiphp_1 bash

From there maybe create a databases:

1. $ mysql -uroot -proot -hmariadb -e "create database drupal7"

Or run drush commands:

1. $ cd /var/www/php56
2. $ drush8 dl drupal-7
3. $ mv drupal-7.56 drupal7
4. Update RewriteBase in .htaccess

Now visit http://localhost:8856/drupal7 in your browser and start the installation routine.

Performance

Honestly without any fine-tuning page load times can be super bad with the initial version 1 setup. Time-to-First-Byte of up to 10 seconds per node. This delay is caused by Docker for Mac's built-in volume mount and file sync process. You could simply fix it by not mounting any host volumes. But that really can't be it.

Starting with version 2 I've included two of cweagans' bg-sync containers. They dramatically improve page load times. They only need a little while for the first sync ( 5-15 minutes). From then on Time-To-First-Byte will be less then a second. Pretty good. Unfortunately this limits this version to Mac OS and Docker for Mac. You may want to try other background sync approaches on a differing host.

Note: When using this image as is (with cweagans/bgsync) and if you ever have to run docker-compose down pay attention to prevent the initial and time-consuming filesync on the next run by restarting the containers with docker-compose restart -d in their already-synced state (which normally is done automatically on your Mac's wake-up or boot).

Also before you shut down the containers or your Mac you may have a look at the Activity Monitor and look if the hyperkit process is not super-active anymore (CPU usage > 100%). If it is, you may like to wait a short while until it's done (CPU usage ~ 1-5%). Which simply means to wait that bg-sync is done syncing and there will be no/less conflicts on the next restart.

restart: always?

No. Unfortunately there seems to be a bug with Unison or with the bg-sync container that resets the syncing behavior after restarting Docker for Mac (or your Mac respectively). So for now you have to restart the containers always manually. Navigate to the folder where the docker-compose.yml is located and run $ docker-compose start.

Linux / Windows

To check out a non-Mac centered version of this repo you might want to fork an older version that doesn't rely on cweagans/bgsync and start from there:

$ git clone https://github.com/leymannx/dockerix.git --branch 0.1.1 dockerix

Kudos to

• Ruben Egiguren! (for his Docker LAMP)
• Michael Moravec! (for his article on multiple PHP versions and the comments there)
• Cameron Eagans! (for bg-sync)