A lightweight docker image for cronjobs

Manual example with docker

Pull it with:

docker pull ghcr.io/2franix/cron-docker:latest

Create a ./crontab file:

# Create this file in the current directory and name it crontab
* * * * * echo "It works!"

Run it!

docker run --rm --mount="type=bind,src=./crontab,dst=/crontab" ghcr.io/2franix/cron-docker:latest

On the next minute, you should see in the output that it is working:

crond: crond (busybox 1.36.1) started, log level 8
crond: USER worker pid  15 cmd echo "It works!"
It works!

With compose

services:
  cron:
    image: ghcr.io/2franix/cron-docker:latest
    restart: unless-stopped
    volumes:
      - ./crontab:/crontab

See the sample compose.yaml file in the examples folder for a more detailed example.

Features

The image runs the cron daemon as root but uses the worker user to run the cron job. At runtime, it installs the crontab file specified by the CRON_SPEC_FILE environment variable as worker's crontab.

If you need additional scripts to run the job, two approaches are available:

• mount them in worker's home directory (defaults to /worker, configurable via the CRON_USER_HOME environment variable). At startup, the container recursively changes ownership of the home directory, which guarantees that those files are owned by the worker user at runtime. The drawback is that the files ownership is changed on the host as well, which may not be suitable to all use cases
• create a derived image and copy the files in worker's home directory at build time. Unlike the other approach above, the files on the host are not modified, since this is a copy.

If you need to perform additional actions as root before starting the cron daemon, mount shell scripts in the /entrypoint.pre.d directory. Those files are executed in alphabetical order.

Note that the mounted crontab is installed at startup, so modifying it while the container is running does not have any effect on cron.

SMTP with msmtp

It is possible to configure msmtp in the container so that any output produced by the cronjobs is automatically sent by email. See the SMTP_* and CRON_MAILTO variables below. This feature is disabled by default and is only enabled when SMTP_HOST is set.

Environment variables in the image

Instead of storing the value directly in some of the variables, it is possible to write it to a file in the container and store the path to this file in the XXX_FILE variable. For example, rather than storing the SMTP password in SMTP_PASSWORD, one can store it in the /etc/smtp_password file in the container and set SMTP_PASSWORD_FILE=/etc/smtp_password. This is mainly useful to leverage docker secrets to pass sensitive data.

Not all variables support this feature. Refer to the "Has _FILE variant" column in the table below.