Open tobias-kuendig opened 4 years ago
Thanks for the input. The cron examples need some attention.
Which method do you prefer using to trigger your cron process?
I'm currently using the ENABLE_CRON method, but mostly because of a current hosting setup that we don't control ourselfes, so it's easier to have everything in one container.
I do think the separate cron container is the nicer solution and I would prefer it for other projects.
By default, cron does not care about the environment variables that are set in the Dockerfile. This means that all scheduled cronjobs will run with a completely different configuration ‒ in my case they run against the wrong database.
A workaround for this is to print all env variables to
/etc/environment
where crontab will pick them up.Adding this line to the entrypoint script will fix this problem:
printenv >> /etc/environment
Thanks, tobias. But where exactly did you add the line in the entrypoint script?
I did add this right before the exec
line:
# Put env variables to /etc/environtment
printenv | grep -v "no_proxy" >> /etc/environment
exec "$@"
I don't remember why the exclusion of the no_proxy
variable was necessary in our case (it's been a while :see_no_evil:)
By default, cron does not care about the environment variables that are set in the Dockerfile. This means that all scheduled cronjobs will run with a completely different configuration ‒ in my case they run against the wrong database.
A workaround for this is to print all env variables to
/etc/environment
where crontab will pick them up.Adding this line to the entrypoint script will fix this problem: