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

Feature: Use CronJob resources instead of a container with crond #577

Open
pschichtel opened this issue May 31, 2024 · 10 comments
Open

Feature: Use CronJob resources instead of a container with crond #577

pschichtel opened this issue May 31, 2024 · 10 comments
Labels
enhancement New feature or request

Comments

@pschichtel
Copy link

pschichtel commented May 31, 2024

Description of the change

I would like to use k8s' CronJob resources to run nextcloud's cronjob tasks instead of having them executed by the cron container.

Benefits

  • easier to add new cronjobs (e.g. for certain apps like image preview pre generation or duplicate detection)
  • more/easier insight into failed cronjobs through cluster monitoring
  • separate resource limits when multiple cronjobs are configured

Possible drawbacks

I'm not entirely clear on how this might interact with nextcloud during upgrades, but I don't think it changes much compared to the status quo.

Additional information

@pschichtel pschichtel added the enhancement New feature or request label May 31, 2024
@provokateurin
Copy link
Member

Some long time ago this was how the crons were implemented, but it had quite some problems which I don't remember anymore. Please search in the issues and PRs of this repo to dig up the history of this. If the problems can be avoided now it definitely makes sense to use the k8s cron instead.

@pschichtel
Copy link
Author

pschichtel commented May 31, 2024

I've found quite a few issues related to cronjobs, but I haven't found any that would suggest an issue with running them as CronJob resources. The cronjob resource used curl to invoke webcron, I can imagine how this could cause various issues like network timeouts. My intent would be to use the same nextcloud/docker image and run the same command the current cron container uses as well.

History of the cronjob.yaml: https://github.com/nextcloud/helm/commits/main/charts/nextcloud/templates/cronjob.yaml

@provokateurin
Copy link
Member

I guess that makes sense, just execute the cron.php script which can not timeout instead of using curl which can timeout. I wonder why nobody thought about this 😅

@pschichtel
Copy link
Author

If I were to submit a PR to implement this: Should I keep the current cron mechanism around (e.g. introduce an option to select sidecar vs cronjob)?

@provokateurin
Copy link
Member

I don't think that would be necessary as there is no real breaking change, as long as you use the same container image and mount all the same volumes etc. You're effectively switching https://github.com/nextcloud/docker/blob/13f51c4f70676edb464ce5ea03631403b54623df/29/fpm/Dockerfile#L18 against the k8s Cronjob resource.
@jessebot what do you think?

@jessebot
Copy link
Collaborator

jessebot commented May 31, 2024

Yeah, I like the idea of this being a k8s cronjob 👍 I don't see a big a deal with removing the cron container either.

@JuniorJPDJ
Copy link

This also allows proper scaling of nextcloud pod, as scaling cron container is a bad idea.

@provokateurin
Copy link
Member

Not really, you can have as many cron jobs concurrently as you want (especially useful and necessary on large instances). 1:1 scaling of server and cron is probably a bad idea though as the resource usages are different.

@pschichtel
Copy link
Author

fyi I still have this on my todo, the last few weeks where a little busy.

@keliansb
Copy link

Another use case for a Kubernetes CronJob is to run the cron container as a non-root user, because at the moment this doesn't seem possible (see this issue)

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

5 participants