Add better support for multiple concurrent container setups

[abias]

With this project, you can currently build and spin up one container setup aka. Moodle instance which will get its configuration from the MOODLEDOCKER* environment variables and will be named after the name of the directory where this repository was cloned into.

So, if you cloned this repository into ~/moodle-docker and run bin/moodle-docker-compose up -d, you will have four containers named

• moodle_webserver_1
• moodle_db_1
• moodle_selenium_1
• moodle_mailhog_1

If you run bin/moodle-docker-compose up -d a second time, docker-compose only checks if the service configuration or images were changed after the containers' creation (see https://docs.docker.com/compose/reference/up/) and does recreate a container if needed. But it does not spin up another container setup aka. Moodle instance like you might expect.

If you want now to run multiple container setups concurrently, for example if you want to test the same Moodle codebase on two different DBMS concurrently or if you want to test two plugin versions concurrently, this isn't officially supported by this project and you are on your own.

Luckily, you can define the container prefix for docker-compose. To test the same Moodle codebase on two different DBMS, you can run these commands in two different terminals:

Terminal 1:

# Set up environment for this project
export COMPOSE_PROJECT_NAME=moodle-pgsql
export MOODLE_DOCKER_WWWROOT=~/moodle
export MOODLE_DOCKER_DB=pgsql
export MOODLE_DOCKER_WEB_PORT=8000

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

Terminal 2:

# Set up environment for this project
export COMPOSE_PROJECT_NAME=moodle-mysql
export MOODLE_DOCKER_WWWROOT=~/moodle
export MOODLE_DOCKER_DB=mysql
export MOODLE_DOCKER_WEB_PORT=8001

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

This will spin up two Moodle instances on Port 8000 and 8001 concurrently. Unfortunately, this approach isn't really bullet-proof. You will have to set the correct environment variables everytime you run a bin/moodle-docker-compose command to target the correct Moodle instance. And you will have to have one terminal open per Moodle instance to prevent conflicts of the environment variables.

So: How about adding official support for multiple concurrent container setups? If you say "YES!", we should think about useful implementation approachs. There may be simple approachs and there might be more sophisticated approachs like @Dagefoerde already built in his https://github.com/Dagefoerde/Moodledocker project.

Thanks, Alex

[scara]

Hi Alex, https://docs.docker.com/compose/reference/envvars/#compose_project_name could be enough for those people trying to achieve what you've perfectly described above as use case.

Too much automation means a rigorous CLI to manage it while use this env var let the user still use the "plain" commands (given she/he has understood the simple logic behind that env var): though an automation would be nice, I'm keen to go ahead in documenting that env var plus at least one use case where it could fail. In my previous experiences this would be fine enough, including what described in #10 where the env var could be an alternative to keep running different version of the same DB type (e.g. MDL-59099 and MDL-59596).

TIA, Matteo

[dashohoxha]

Let me suggest another approach, which you can use or just get some inspiration from: https://gitlab.com/docker-scripts/ds

[scara]

TNX for sharing 👍, @dashohoxha. Your approach could be for something clearly managed - unplanned failures excluded - , mostly in the direction @abias is talking about - and something tools like Softaculous try to achieve, not using docker (and w/ some issues when updating in production e.g. a major version of Moodle).

AFAIK this repo should address a dev/test env, which IMHO requires a bit of knowledge to step into the components to look for failures and a full automation could not be the best solution, not to mention that this repo could be the base for several other automations, including CI. Note: this is my personal opinion, I'm not part of Moodle HQ.

HTH, Matteo

[dashohoxha]

Thanks for your opinion @scara. Yes, you can think of DockerScripts as a CLI Softaculous. But I also believe that it is flexible, customizable and extensible. And I also think that it is scriptable.

[danpoltawski]

I agree we need to support this use case (and there have been steps towards it like avoiding allocation of ports and so on) but I haven't thought deeply about how to achieve it.

One of my primary goals for creating this project was for simplifying the simple case when a developer wants to test their code on an 'alien' environment and can just spin it up without too much effort. It's key to me that we keep that in mind when thinking about how to achieve the more complex use case.

I think we've got to a good point of the 'spin up a quick test environment' side of things and I agree that to evolve this further we need to support this case and think more about persistence and non-disposable environments. See https://github.com/FMCorz/mdk/issues/157 for some other thoughts i've had around this.

[jpahullo]

Hi!

Congrats for this repository.

I need to test my plugins among several Moodle versions quickly. So I needed to test that my changes work ok on several Moodle versions.

I discovered this option docker-compose -p NAME so I proposed a very simple change to the moodle-docker-compose to deal with it. I updated also the README.md.

From a practical point of view, you will see all containers started this way with a prefix name NAME_... instead of a default value.

Nothing else is required to change. It works like a charm for me.

Hoping this helps.

Jordi

[stronk7]

Hi, just reading these old issues and trying to make some to advance...

Maybe the doc changes proposed by @jpahullo @ #79 are enough for providing that multiple support while keeping things simple (unmodified in fact). And done?

Or is there any drawback/restriction with the use of COMPOSE_PROJECT_NAME (apart from having to specify a different web port).

I've not tried, but for me it looks simple and good enough to have the multiple thing available in general.

[abias]

Hi @stronk7 ,

I can report that we have been using COMPOSE_PROJECT_NAME for a long time now without any problems.

The trick is still just to set COMPOSE_PROJECT_NAME to something like moodle-master before the containers are created. As explained in #79, this way all container names get prefixed with moodle-master_ and collisions between multiple concurrent containers can be avoided.

From my point of view, #79 would be the way to go to solve this issue without adding any further automated support for multiple containers.

Cheers, Alex

[jpahullo]

Hi!

Thanks for your words.

Today I have updated my PR with the latest version of the master branch, but there is an error on a case with posgresql, but no related to the code being contributed.

Is there something else I can do to promote that issue being done and accepted? This way we could solve two issues at once. Last time, I was updating the PR several times and CI failed all the time but for other aspects not related to the minimal code changed (nothing about Moodle, but docker).

Just let me know.

Thanks for your time.

Jordi

[stronk7]

Closing this now, the use of COMPOSER_PROJECT_NAME has been documented @ #79.