Clarification Regarding Cron Jobs & Setup/Config

[wwe]

@keunes

What is the benefit of running it in a separate container; why not run cron in the ‘main’ (App) container?

the philosophy of the docker is each container does exactly one thing.

@keunes

I suppose in your case the db.env contains the details of the db container (host, user, pw). But if Cron really needs access to the NC database, why does the Cron container in the example compose.yml only have the volume nextcloud:/var/www/html, and not the volume db:/var/lib/mysql (as specified for the Db container) or the (env) details necessary to access the database server?

the cron container does not access database files stored on the disk - it rather connects to the DB server through the network (exactly the same way application does)

@keunes

Might the cron container also need access to other files & folders under / var/www/html, besides data, config and custom_apps? And if so, why?

if your don’t define persistent files changes happen within container instance (review difference to the image) -this can result in different files within specific container instance (e.g. you install new application which only exist within app container, but not within cron) I don’t expect issues, give it a try. otherwise it makes no difference from the admin point of view if you persist the folder and share them…

@keunes

• Specifically: given that cron.sh loads www-data’s cron tab, which in turn initiates cron.php every 5 minutes; shouldn’t www-data’s cron tab be persistent to allow apps to add other/new cron jobs? (From your set-up and the example compose.yml this seems not to be the case, but I find it a bit surprising.)
• Can I make do without creating a volume for the parent directory?

only in case you manipulate the crontab, otherwise I expect it to be managed by the maintainers of the image. yes you can persist a single file as well