Hi Dan,
that's a great idea: I started months ago (Jul 2016 but left on Aug!) a similar project but still pending a first public release.
Based on docker compose (still v2) and 1 service<=> 1 container approach, the goal was to have multiple environments quite easy, based on a "production ready" OS (first, "my" lovely CentOS, 7 and different compositions, and then different OSes) to give a nice way to describe how to deploy the things even in a VM and not only through containers.
The file system hierarchy was something similar to:
├───config
│ └───centos7
│ ├───appcode // <= trying to play with permissions issues with VOLUME (no way as also described
│ │ // in https://github.com/CentOS/CentOS-Dockerfiles/pull/130/files#diff-2f7a31c9e648aff543a099083dff59e4R21)
│ ├───appdata // <= ^^^ Same as above. ^^^
│ ├───httpd
│ │ └───image
│ ├───mailcatcher
│ │ └───image
│ ├───php70
│ ├───php70-mod
│ │ └───image
│ └───unoconv
│ └───image
├───data
│ ├───maria55db
│ ├───moodle
│ └───solr60
└───logs
├───maria55db
└───solr60
but I never finished it (and never give up to finish it ).
Different PHP versions, different PHP way of loading (e.g. module vs fpm), different web servers were part of the target too (still one OS for the initial release, including a syslog server to collect the logs from each container in plain files). At that time part of my future plans was also to provide a Dockerfile for each service including the ones that could be already available in the docker registry like e.g. solr 6.0 via image: solr:6.0.
Moodle code files should be external to the container - another potential difference w/ a production ready approach (still not sure about the right one for Moodle and its weeklies) - as well as all data files for persistence: I was not aware of issues on Mac.
One thing I noticed at that time is that naming the things like docker* should be avoided : https://github.com/moby/moby/issues/26556.
HTH,
Matteo