minecraft-overviewer
minecraft-overviewer copied to clipboard
Regenerate map on schedule
Adds the ability to rerun Overviewer after a set delay so that the map can be automatically updated for players.
I feel like this isn't something best suited to run inside the container produced from this image. Is there a way we could start the running the container in a loop? Something like
SLEEP_SECONDS=0
while :
do
docker run mide/mincraft-overviewer ...
sleep $SLEEP_SECONDS
done
What orchestration tool are you using (Kubernetes, Docker Swarm, Docker Compose, AWS ECS, etc)?
It absolutely could be done like that, and the default container behaviour would still support that workflow. However, I personally prefer to have all of the configuration live with the service config whenever possible, so that I can recreate the functionality of the service without remembering additional configuration steps not described in the docker-compose file that I may have taken at the time I setup the service, e.g. cron jobs.
Personally I'm using Docker Compose.
What about Docker Compose Restart Policies (v2, v3)? From quick glance (and I'm unable to test right now) it looks like if deployed as a Docker Compose Service, it should restart by default.
So the issue with that strategy would be that it would be re-running constantly, and Overviewer is quite CPU intensive. For less busy worlds, you may only want to run Overviewer once every couple hours to once every couple days to save CPU cycles and electricity.
Honestly, #109 would be a more ideal solution to this, so that you can set not only execution frequency, but execution time as well, so you can run it overnight for example. I personally only required a simple scheduler, so that's what I wrote for myself, but cron-style scheduling would be a more complete solution.
EDIT: OK so having read over the Docker documentation more carefully, I guess the proposal would be setting delay:
to something like, 3600 or whatever you'd otherwise have set REFRESH_DURATION
to (just to make sure I'm understanding)? I suppose that would work, I'd not considered using restart_policy
in that way, I usually think of it as a handler for when containers end unexpectedly but I suppose that would also work for this problem.
so the issue with that strategy would be that it would be re-running constantly, and Overviewer is quite CPU intensive.
If you're running with a Docker Compose file configured for 3, you could use delay
. That would let you set a (for example) delay of 8 hours with
version: "3.9"
services:
render:
image: mide/minecraft-overviewer
deploy:
restart_policy:
delay: 8h
The only reason for any pushback here is to avoid "reinventing the wheel" since the concept of container restarts is something that most container orchestration tools support.
Additionally, for the n
hours that this container isn't running, it's not consuming any of the resources that would have been allocated to the container (vs having the resources allocated but unused while in sleep
loops). Letting the orchestration tool manage the container lifecycle feels a little more 'native' to me (but that's just me).
That said, I do see the merit in the request of making a "Minecraft Overviewer Service" that just keeps running, with optional delays.
Your reluctance is quite reasonable, and ultimately I'm not married to my particular solution to this issue, just that scheduled runs is a way that people will likely want to use a container like this. I can test running with a restart policy, and if that works well I can add some documentation if this is the supported way to handle this use-case.
I did some more research regarding the restart_policy
option, and restart_policy
is a subkey of deploy
, which is only applicable to Docker Swarm deployments. Docker Compose only supports the restart
key, so you can't set restart delays leading to the issue described earlier where it runs constantly.
Okay. That's interesting (and a little disappointing that Docker Compose doesn't support that). I will re-evaluate the delay logic, and likely include that in a release.
Sorry for the flip-flopping. 🩴
Not at all, we're collaborating to find the best solution and that's what open source is for :)