Iterapp has support for running basic cronjobs. The actual cronjob is run by kubernetes, iterapp is just making the setup easier. For instance you can add the following to iterapp.toml:
[cronjobs.update-thing] schedule="13 * * * *" path="/api/v1/run_scheduled_task" [cronjobs.update-thing.headers] Authorization = "Bearer asdf123"
This will make kubernetes do a GET HTTP-request to
13 minutes after every hour. Timestamps for Iterapp cronjobs are specified in
UTC, so if you want to run a task 8 AM GMT summer time, you'll need to convert
that to 6 AM UTC, and then to
0 6 * * * in cron syntax.
The cronjobs are deployed together with the app, and in the same environment. This means that deploying an app with a cronjob to the test-environment will create requests to the pods in test.
Because this is HTTP-requests and HTTP-requests are load-balanced, even when you have multiple pods running (like in prod) only one of them will get the request.
Note that cronjobs are not sticky (like all HTTP requests), so when deploying a new version of your app, the request will go to a random pod off all the pods of both the new and old version.
For long-running jobs you should probably return 200 early and then start the job in the background.
The kubernetes documentation has some notes about limitations of CronJobs.
What happens for the above configuration is that iterapp will create a kubernetes-cronjob with a curl-command, something like this:
apiVersion: batch/v1beta1 kind: CronJob metadata: namespace: apps-shedil-prod name: update-thing spec: concurrencyPolicy: Forbid jobTemplate: spec: template: spec: containers: - args: - curl - "-H" - "Authorization: Bearer asdf123" - "http://shedil:5000/api/v1/run_scheduled_task" image: "curlimages/curl:latest" name: update-thing restartPolicy: OnFailure schedule: 0 * * * *