Hi Dan,

this is a great idea. My entire Moodle development environment is based on docker containers for ~5 months now, which I started mostly because I frequently encountered conflicts between database state and codebases given that I had multiple instances (vanilla Moodle, our custom Moodle, and both in different versions at the same time). Separating all of them into containers resolved all these conflicts, because no two codebases ever shared the same db (they could, but why? ;) ). Also, my laptop now doesn't have to run postgres & nginx servers anymore if I am not using them. In order to facilitate all this, I created helper commands that manage multiple instances and their respective containers: https://github.com/Dagefoerde/Moodledocker . It also allows running selenium tests and phpunit tests inside the containers (undocumented, but `moodledocker startbehat INSTANCENAME` will aid ). These containers are still flawed in some respect, but maybe this can be of some inspiration.

Also I noticed https://moodle.org/mod/forum/discuss.php?d=349797 recently, which is another approach to this. I haven't looked into that yet.

Re your points:

- Mounting works perfectly for me (Linux), but I can't state anything about macs.
- config.php is mounted as well; of course this doesn't work if an instance is used both in docker and in regular environment. However, since you might have database mismatches here, I assumed that you wouldn't want that anyway. Therefore, in my own environment, a codebase is either for docker or for the outside world. ;)
- Why not use separate containers for 1) php-fpm and 2) nginx? Usually, in the docker world, it seems preferable to have one service per container only. 
- `docker exec`: Absolutely! In order to simplify this, we created a helper script: https://github.com/Dagefoerde/Moodledocker/blob/master/Scripts/moodledocker-exec so instead of executing `php admin/cli/...` locally, you would execute `moodledocker exec php admin/cli/...`. The script takes care of locating the correct PHP docker container and executing you command there.

Cheers
Jan

Hi Dan,

We have a set of images for Moodle development available at https://github.com/lucisgit/docker-moodle-dev (posted on dockerhub as well) and it comes with the compose files and instruction how to override them for your requirements. At the moment the are separate images for web and cron (both php+apache based), for database I suggest using official images and link them through compose file in appropriate way (see example how I use it with postgres). The set is also clamav-friendly (running clamd in the container, but this can be disabled through env variable) and you can easily make it exposing ssl, as it comes preconfigured with snakeoil certificates, for details see https://github.com/lucisgit/docker-moodle-dev/tree/master/apache. 

Regarding points you made:

1. I found docker-sync is doing the right job to eliminate performance issues on mac, there are compose examples for that in our repo too, have a look at https://github.com/lucisgit/docker-moodle-dev#note-for-mac-users

2. For development purposes I just mount it as a part of moodle code.

3. I would suggest to design images for different platforms and leave user a choice which one to use.

4.  I found it perfectly fine to run `docker exec -it ...` on either of containers and run whatever you need from www-data user.

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

Hey Dan, just wanted to give you a thumbs up on this initiative, would be very helpful for contributing to Moodle and hopefully re-usable for partner development environments (your comments on mixing and matching sound like a good fit for this).

Do you plan to include MDK in this to make it easier to contribute changes to Moodle?

Cheers, looking forward to updates.

Hi Dan,

In The last few month all ouer Dev env moved to containers, We are work with docker and docker-compose to run different env for moodle. The solution we implimented to solve the problem of container user and OS user is to change the UID of the PHP docker to the UID of the developer user. then the www-data user have the same UID as the developer so the developer and php-fpm have the full access to the files. 

You can find the php container by pull sysbind/php deocker

here is example of yaml of docker compose:

version: '2'

services:

  db:

    image: mariadb:10.0.26

    volumes: 

      - /your/workspaces/mysql/10.0.26:/var/lib/mysql

      - ./mariadb.cnf:/etc/mysql/conf.d/mariadb.cnf

    restart: always

    environment:

      MYSQL_ROOT_PASSWORD: moodleroot

      MYSQL_USER: moodleuser

      MYSQL_PASSWORD: realpassword

      MYSQL_DATABASE: moodle

    security_opt:

      - label:disable

    # DB ports need only if you want to debug DB from your host
    ports:

      - "3306:3306"

  webserver:

    image: nginx:1.10.1

    volumes:

      - ../nginx.conf:/etc/nginx/nginx.conf

      - ../virtualhost.conf:/etc/nginx/conf.d/virtualhost.conf

      - /your/workspaces/PHP:/var/www/html

      - /your/workspaces/moodledata:/var/www/moodledata

      - ../../ssl:/etc/nginx/ssl

    links:

      - db

      - php

    ports:

      - "80:80"

      - "443:443"

    security_opt:

      - label:disable

  php:

    image: sysbind/php:7.0-fpm

    volumes:

      - /your/workspaces/PHP:/var/www/html

      - /your/workspaces/moodledata:/var/www/moodledata

      - ../../php.ini:/usr/local/etc/php/php.ini

    security_opt:

      - label:disable

    links:

      - db

      - memcached

      - redis

    environment:

      # You can find it by echo $UID

      - UID=XXXX

  memcached:

    image: memcached

  redis:

    image: redis

Hi Everyone,

Since I originally posted I have been through quite a few iterations, refactoring and rethinking of how to structure the project, but I think i've ended up with some decent now. I am keen to encourage some of you to grab this project and try it out as I think its ready for wider testing.

What i've ended up with:

1. docker-moodle being the repo containing the docker-compose configuration and some utility scripts to help people get going quickly
2. moodle-php-apache being the Moodle-customised php-apache images with all php extensions enabled/configured (published to dockerhub)
3. moodle-db-mssql being the Microsoft SQL Server image configured read for Moodle install (published to dockerhub)
4. moodle-db-oracle being the Oracle XE image configured read for Moodle install (published to dockerhub)

As originally planned, i've tried to keep things clean and reusable and have put extensive effort into backing it all with automated tests.

Quick example - running your branch tests on Oracle

A primary target I had in mind for working on this was a developer who wants to run their tests against oracle. Here is an example of how you would do that (assuming your branch was checked out in ~/git/moodle

git clone https://github.com/danpoltawski/docker-moodle.git ~/git/docker-moodle
cp ~/git/docker-moodle/config.docker-template.php ~/git/moodle/config.php

export MOODLE_DOCKER_WWWROOT=~/git/moodle
export MOODLE_DOCKER_DB=oracle

# Start up containers
~/git/docker-moodle/bin/moodle-docker-compose up -d

# Run behat tests..
~/git/docker-moodle/bin/moodle-docker-compose exec webserver php admin/tool/behat/cli/init.php
~/git/docker-moodle/bin/moodle-docker-compose exec webserver php admin/tool/behat/cli/run.php --tags=@auth_manual

# Shut down containers
~/git/docker-moodle/bin/moodle-docker-compose down

Please kick the tyres and give me your feedback!

There is more info in README and you might find the travis config and test scripts illustrative, but i'd love to hear your comments, particularly:

• Reports of success or otherwise
• What you think of the approach
• If you think we need more helper scripts
• Bug reports in the projects

• You need to prepare the terminal you are going to use by running 'docker-machine env' and then running the commands it prints to screen.
• The Moodle directory must be in c:\Users\Public or it will not mount properly

Here is my approach to Moodle containerization: https://github.com/docker-scripts/moodle

It is not meant to be used for testing, but maybe it can be fixed and adopted.

(I know this suggestion is too late, but better late than never.)