Docker Database automatic "backups" (local copies) + automatic container updates

[anonym-HPI]

To help people to host this easier, we should give an option to enable automatic copies locally, to mitigate errors produced by migrations or so. Also an automatic update process should be introduced, e.g. with the help of watchtower, but the watchtower should only update docker containers of this docker-compose.yml, to not interfere with other stuff on a server/computer.

For watchtower right now using the following, but labels for all containers inside docker-compose.yml should be added, to not interfere with other stuff.

    watchtower:
       image: containrrr/watchtower
       restart: unless-stopped
       environment:
           - WATCHTOWER_INCLUDE_RESTARTING=true
           - WATCHTOWER_SCHEDULE=0 0 4 * * *
           - WATCHTOWER_TIMEOUT=30
       volumes:
            - /var/run/docker.sock:/var/run/docker.sock:ro
            - /etc/localtime:/etc/localtime:ro

Also documentation should be good and easy to understand. Also documentation should include that the local copy of the database is not a real backup and a real backup needs to be on another server/computer and easiest way: just export important exercises. If and what should be enabled by default and maybe controlled via ENVs, can be discussed.

Not high priority, just a quality of life feature, for new people in the whole docker and deployment world.

[lukasrad02]

We don't think that this should be part of this repo. In our opinion, the compose file in this repo serves the purpose of illustrating a minimal deployment with just the steps necessary for all features of the software to work. This enables users to test the software quickly and without having to gain a deeper understanding.

But in case of a deployment that should be used in production, I expect people to have some knowledge about docker, their own environment and their strategies on updates, backups etc. Otherwise, they will have problems setting up a server, domain, and docker at all.

In general, we think that documentation concerning production setup, usage, and features should rather be part of a separate repo, which could, for example, be be based on ReadTheDocs (or similar tools) and be available at docs.fuesim-manv.de, since GitHub might not be the best place for non-technical people.

[anonym-HPI]

We don't think that this should be part of this repo. In our opinion, the compose file in this repo serves the purpose of illustrating a minimal deployment with just the steps necessary for all features of the software to work. This enables users to test the software quickly and without having to gain a deeper understanding.

But in case of a deployment that should be used in production, I expect people to have some knowledge about docker, their own environment and their strategies on updates, backups etc. Otherwise, they will have problems setting up a server, domain, and docker at all.

In general, we think that documentation concerning production setup, usage, and features should rather be part of a separate repo, which could, for example, be be based on ReadTheDocs (or similar tools) and be available at docs.fuesim-manv.de, since GitHub might not be the best place for non-technical people.

Yes, smth like an easier documentation would be good. Right now the README.md can be overwhelming for new people, as much is about development and not just how to test or run it. Maybe the readme could be restructured, to be less text and maybe having a second readme for development?

What I propose though would be watchtower or smth similiar, will probably do a PR at some point. Having automatic docker updates, could help people using it, to have the newest stable version. But I would make it non default (commented out).

Backups can be done via export.