Crond #

Sometimes what we are familiar with most, works best.

When containerizing an application there are constantly new things to learn and time is often of the essence. Using a familiar technology such as crond can save time (initially) which can be of advantage.

We don't recommend the following method but we like and value pragmatic problem-solving. Please read up on [delayed restarts](/common-tasks/cronjobs/delayed-restarts/) and [swarm-cronjob](/common-tasks/cronjobs/swarm-cronjob/) as well and consider a more Docker-friendly approach to running periodic tasks.

Example #

Building upon the example setup we mentioned, we add the following to the project:

A file with a your crontab, my-crontab:

*/15 * * * * /usr/local/bin/mc cp -r /backup minio-alias/bucket > /proc/1/fd/1 2>/proc/1/fd/2

This instructs crond to execute /usr/local/mc every 15 minutes.

… and a Dockerfile:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

FROM debian

RUN apt-get update \
    && apt-get install -y --no-install-recommends cron \
    && mkdir -p /etc/cron.d

ADD my-crontab /etc/cron.d/my-crontab
RUN chmod 0644 /etc/cron.d/my-crontab \
    && crontab /etc/cron.d/my-crontab

ADD https://dl.min.io/client/mc/release/linux-amd64/mc /usr/local/bin/mc
RUN chmod +x /usr/local/bin/mc

VOLUME /backup

CMD ["cron", "-f"]

In detail:

1. The cron package is installed, crontab file is copied (into the image) and setup.
2. The mc utility is copied into the image.
3. We start cron(d) in the foreground (to be able to see potential logs from runs).

Build and publish the docker image:

$ docker build -t registry.example.org/project/backup:latest .
...
$ docker push registry.example.org/project/backup
...

Add the following to your stack’s docker-compose.yml and deploy the stack:

10
11
12
13
14
15
16

...
  backup:
    image: registry.example.org/project/backup
    volumes:
      - backup:/backup:ro
    deploy:
      replicas: 1

Further updates to the schedule require an image rebuild and another deployment.