4 ms·

In a dockerized single-VPS environment, where should cronjobs live? Should they be part of the main Docker container that had the app code, or a separate contai

In a dockerized single-VPS environment, where should cronjobs live? Should they be part of the main Docker container that had the app code, or a separate container that only has all cronjobs, or simply on the host?

jakejarvis 7y ago
Good question. I have the same setup on one server hosting GitLab, Pi-Hole, Plex, etc., and I have Restic (and its cronjob) installed on the host and only backup the files that I mount to each Docker container, which are all stored in /srv/docker. In theory, you need to be ready to literally delete every container at any time and pull them from scratch and be 100% fine, since all of your actual data should be stored on the host and mounted as Docker volumes [0]. It's a good Doomsday test if you're looking for one. ;) [0] https://docs.docker.com/storage/ https://docs.docker.com/storage/
- tracker1 7y ago
  As mentioned in another post... could manage the backups from another server (not in the network) with a cron job that grabs a snapshot from the docker server's shared volume directory and forwards it to it's final destination. Could be done on a really small instance, and this way your backup information and account details aren't on your production server itself.
OJFord 7y ago
How are you orchestrating them? With kubernetes (and no more specifics than you've mentioned) you should use a Job. With docker-compose I think I'd be tempted to have a different service that isn't long-running, and a cron job on the host that runs it. With swarm, unless it supports something like k8s Jobs, (I don't know if it does or not, only used it once briefly and in anger) I'd probably have a 'cronjob' service which was responsible for launching the short-lived services per compose suggestion above.
witten 7y ago
I don't know about "should", but one way to do it is to put both the backup script and the cron job to run it into a single, separate, backup-only container. Then tell that container (via volume mounts, etc.) what volumes to backup from other containers. Example container (non-Restic) that does this: https://hub.docker.com/r/b3vis/borgmatic/ https://hub.docker.com/r/b3vis/borgmatic/

jakejarvis 7y ago

Good question. I have the same setup on one server hosting GitLab, Pi-Hole, Plex, etc., and I have Restic (and its cronjob) installed on the host and only backup the files that I mount to each Docker container, which are all stored in /srv/docker. In theory, you need to be ready to literally delete every container at any time and pull them from scratch and be 100% fine, since all of your actual data should be stored on the host and mounted as Docker volumes [0]. It's a good Doomsday test if you're looking for one. ;) [0] https://docs.docker.com/storage/ https://docs.docker.com/storage/

tracker1 7y ago
As mentioned in another post... could manage the backups from another server (not in the network) with a cron job that grabs a snapshot from the docker server's shared volume directory and forwards it to it's final destination. Could be done on a really small instance, and this way your backup information and account details aren't on your production server itself.

OJFord 7y ago

How are you orchestrating them? With kubernetes (and no more specifics than you've mentioned) you should use a Job. With docker-compose I think I'd be tempted to have a different service that isn't long-running, and a cron job on the host that runs it. With swarm, unless it supports something like k8s Jobs, (I don't know if it does or not, only used it once briefly and in anger) I'd probably have a 'cronjob' service which was responsible for launching the short-lived services per compose suggestion above.

witten 7y ago

I don't know about "should", but one way to do it is to put both the backup script and the cron job to run it into a single, separate, backup-only container. Then tell that container (via volume mounts, etc.) what volumes to backup from other containers. Example container (non-Restic) that does this: https://hub.docker.com/r/b3vis/borgmatic/ https://hub.docker.com/r/b3vis/borgmatic/