We're going to deploy dozens of small Moodles and we would like to automate the process of upgrades. Each Moodle will go in a docker container, running all in the same host (but increasing hosts & moodle containers).
It's going to be a long post so I'll number my issues so you can answer me the ones you know. Feel free to "break my rules if needed". Thanks in advanced, its a hard work on my part, so any help is really welcome. I hardly have Moodle experience so I can miss some important points, so any suggestion is more than welcome.
First of all, due to our infraestructure, we need to design a system upgrade with some specific requirements:- It should be completely unattended
- Each Moodle could have different plugins that should persist (not defined in the dockerfile)
- As efficient and prone error as possible (being unattended errors could not be seen).
My GitHub repo is https://github.com/juanda99/moodle-docker-production and I would like to integrate the solution as soon as possible (in case anyone finds it useful).
First I thought of just of just doing as Moodle docs say:
git pull && /usr/bin/php admin/cli/upgrade.php
But in a docker way:
docker-compose pull (get new docker image of Moodle)
docker-compose restart
As dockers containers are ephemeral, with the restart command all previous code would be lost (let say for example Moodle 3.7.0) and my container would have code of the new image (for example 3.8.2)
As I don’t want to loose my customization I would try to persist some folders using volumes:
• /path/to/moodle/theme/ - themes
• /path/to/moodle/mod/ - activity modules and resources
• /path/to/moodle/blocks/ - sidebar blocks
• /path/to/moodle/question/type/ - question types
• /path/to/moodle/course/format/ - course formats
• /path/to/moodle/admin/report/ - admin reports
So my first question is, (1)Are all of these the folders with some kind of customization? Do I miss any?
When I looked at that folders I realized they were not empty in a brand new Moodle installation. So my method would have failed as I should sync new 3.8.2 “original plugin folders” with “3.7.0 plugin folders + customization”. Do I make myself clear?
I’ve run into just one solution, run a script (docker entrypoint) to solve this sync issue and to execute the upgrade.php script.
I have 2 approaches in order to sync, using git or using a tar file. The good think is that as I should sync from the base directory (much simpler), I could persist /path/to/moodle and I won’t have to worry about volumes for all custom directories (which I’m not use which they are, and future changes in them).
So now it’s my 2nd question. (2) Which method should work the best? Any other solution?
Git aproach:
I could do git logic in my entrypoint
I don’t like this way because:
- There would be be many network requests at the same time ( too many Moodle containers upgrading at the same time)
- I should add git to my image (small issue)
- I could get issues like git checkout / git pull not possible because you have unmerged files (I guess I could solved it with through git documetation, —force or whatever).
Tar/Zip approach:
- Using a tar file. Currently my docker file work like this. I should untar the new version in Moodle document root.
I like this approach because:
- The tar file is in the image so it’s only downloaded once for all containers (docker cache).
- Its also smaller: 52.8M (tar.gz Moodle release file) vs 292M (Moodle git fetch specific branch).
My drawbacks with the tar approach is that my “new installation” would not be “clean” as I would have old files, not present in the new version that would not been overwritting. But... do the make any harm? Also doing things different to Moodle docs (untar instead of git pull).
