Closed tabroughton closed 5 years ago
It is debatable whether the host or the container (or another container) is best to run cron tasks.
eg https://nickjanetakis.com/blog/docker-tip-40-running-cron-jobs-on-the-host-vs-in-a-container
Options: 1. Within the PHP container The php container running the crm can have cron added to it and a cront tab setting up
2. From the host
The host machine can call a docker exec
command with the respective crm job through the civicrm-api.
3. From another docker container If another container had cron installed and configured it could call the cron job via a url (note, it could also run docker exec if it had access to the docker socket but this has a greater attack vector for very little benefit).
Design Decision: Because we will want to install this with least friction on dev host machines and servers we and we want to continue with the aim of single purpose docker containers then we will go with option 3 for now.
A further option rather than to use cron is to use Jobber, this has a useful job definition and a few extra options to cron. Maybe worth looking at for production though it might be over engineered solution for what we need.
https://dshearer.github.io/jobber/doc/v1.4/ https://hub.docker.com/_/jobber
this depends on getting #28 closed first
We will run the cron in the foreground in the container and specify logs in the crontab https://stackoverflow.com/questions/37458287/how-to-run-a-cron-job-inside-a-docker-container/46220104#46220104
site key
job.execute
we need an api key
and a site key
civicrm.settings.php
and is created by md5 site_url on installI'm going to update the install scripts for drush so that this is an optional parameter.
PR has been made to make site_key an optional parameter on install
we would need a basic set of default cron jobs setting up in both civicrm and os see https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/