Is the best way to run periodic functions, not necessary time-critical, just needs to happen in the correct hour or day, #cronjobs
I am running a #Python bot in a #Docker container, but want weekly or daily things to happen. Adding this to the main loop seems inefficient, because checks will unnecessary be done.
Should I rather use a #Linux image, run the script in the container and then just have cronjobs running in the container, rather than using a Python image.
Storage, memory and processing isn't actually a problem, so using a larger and beefier image is possible.
@Stark9837 It depends on lots of things, TBH. From the hashtags I assume that it's self-hosted telegram/discord bot somewhere on raspberry pi in your home. How many jobs? How often do they need to be run? Is it ok if sometimes they don't? Can they overlap? How long a job may take? Is the bot running all the time? Does it have any webhooks exposed? Is it asyncio? Does it have to be in the same container?
@Stark9837 running cron in the Docker container has its own drawbacks.
I have multiple containers running automated weekly compile jobs. Rather than run cron in each container, my master loop in each just looks for the presence and content of trigger files in container /tmp. When it detects the trigger files, it removes them and runs.
The trigger files are set by a script run by system cron.
This is actually much lighter and simpler than putting cron in the container.
Looking at the willfarell/crontab image on dockerhub it appears to allow you to run commands in other, running, containers on a schedule. So could potentially access your long running python bot's container when required?
Actually, it doesn't need to access any runtime variable or data. Only the config of the basebase credentials. So I could use docker compose, run two containers, and just share it with a volume maybe
@Stark9837@setebos when you run docker, you actually run one process, (which can start other processes) not a full OS, so installing cron is not useful is cron is not the process you run, it’s not uncommon to run a task scheduler as process, and configure it to run whatever processes you need, e.g supervisord, or you could architect your app around apscheduler or similar, or build your bot process with some thread with a sleep function to run tasks regularly, if you don’t need anything complex.
@Stark9837 My approach for something like that would be to use cron on the host, and make that start up the Docker container when it's actually needed and then perform stuff. Unless you have another reason why the container would need to be running anyway (like if it's a webserver or something)
The #Docker container is running constantly because the bot constantly runs checks. However, I want the bot to generate some stuff for me, which I can totally do manually once a week, but where is the fun in that?
So I thought, why not add #cronjobs to the container, allow it to run automatically in parallel with the bot without requiring additional containers.
Also, the credentials are in a .ENV, so having the jobs running in the same environment is easier, than running an entirely different config.
@Stark9837 If you've already got asynchronous Python code running, it's pretty trivial to also make it run your timed things, without the need for cron. But using cron inside the container should also be an option.
The thing is. If the bot runs in a main-loop. Then a check needs to be made to check for the time and data. Simplest why is an if-statement and ASCII time.
Yes, such a check is very lightweight and trivial. But if the bot runs 24/7 and this check is done every 5 seconds, but is only executed once a week, it just feels weird to me.
Add comment