Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

set up cron jobs #14

Closed
tabroughton opened this issue Aug 13, 2019 · 7 comments
Closed

set up cron jobs #14

tabroughton opened this issue Aug 13, 2019 · 7 comments
Labels
enhancement New feature or request
Milestone

Comments

@tabroughton
Copy link

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/

@tabroughton tabroughton added this to the Alpha Planning milestone Aug 13, 2019
@tabroughton tabroughton added the enhancement New feature or request label Aug 13, 2019
@tabroughton
Copy link
Author

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

@tabroughton
Copy link
Author

Options:
1. Within the PHP container
The php container running the crm can have cron added to it and a cront tab setting up

  • pros: no extra components needed
  • cons: conflates separate concerns (php and cron) into single container

2. From the host
The host machine can call a docker exec command with the respective crm job through the civicrm-api.

  • Pros: Simple to set up
  • Cons: difficult to port or scale out to more hosts, will run when not needed/a management overhead

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).

  • pros: container with single job, portable and scalable
  • cons: cron is triggered over http(s), more system resource to keep running (debatable: more clients more containers)

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.

@tabroughton
Copy link
Author

tabroughton commented Aug 20, 2019

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

@tabroughton
Copy link
Author

this depends on getting #28 closed first

@tabroughton
Copy link
Author

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

@tabroughton
Copy link
Author

  • In order to use the http cron request we need to have a site key
  • In order to use the rest api and command job.execute we need an api key and a site key
  • We have added an api key to our install process
  • currently there is no way to access the site key or to define one at install time, it is stored in civicrm.settings.php and is created by md5 site_url on install

I'm going to update the install scripts for drush so that this is an optional parameter.

@tabroughton
Copy link
Author

PR has been made to make site_key an optional parameter on install

civicrm/civicrm-backdrop#97

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant