我们的是一个作为cron作业运行的nodejs应用程序，它也依赖于环境变量。

下面的解决方案适用于我们。

码头工人文件:

# syntax=docker/dockerfile:1
FROM node:12.18.1
ENV NODE_ENV=production

COPY ["startup.sh", "./"]

# Removed steps to build the node js application

#--------------- Setup cron ------------------
# Install Cron
RUN apt-get update
RUN apt-get -y install cron
 
# Run every day at 1AM
#/proc/1/fd/1 2>/proc/1/fd/2 is used to redirect cron logs to standard output and standard error
RUN (crontab -l ; echo "0 1 * * * /usr/local/bin/node /app/dist/index.js  > /proc/1/fd/1 2>/proc/1/fd/2") | crontab
    
#--------------- Start Cron ------------------
# Grant execution rights
RUN chmod 755 startup.sh
CMD ["./startup.sh"]

startup.sh:

!/bin/bash
echo "Copying env variables to /etc/environment so that it is available for cron jobs"
printenv >> /etc/environment
echo "Starting cron"
cron -f

下面是我的基于docker-compose的解决方案:

  cron:
    image: alpine:3.10
    command: crond -f -d 8
    depends_on:
      - servicename
    volumes:
      - './conf/cron:/etc/crontabs/root:z'
    restart: unless-stopped

带有cron条目的行在./conf/cron文件中。

注意:这将不会运行不在alpine映像中的命令。

此外，任务的输出显然不会出现在docker日志中。

专注于在接收到SIGTERM或SIGQUIT信号时优雅地停止cronjob(例如在运行docker stop时)。

这并不容易。默认情况下，cron进程只是被杀死，而不注意运行cronjob。我在详细阐述pablorsk的回答:

Dockerfile：

FROM ubuntu:latest

RUN apt-get update \
    && apt-get -y install cron procps \
    && rm -rf /var/lib/apt/lists/*

# Copy cronjobs file to the cron.d directory
COPY cronjobs /etc/cron.d/cronjobs

# Give execution rights on the cron job
RUN chmod 0644 /etc/cron.d/cronjobs

# similarly prepare the default cronjob scripts
COPY run_cronjob.sh /root/run_cronjob.sh
RUN chmod +x /root/run_cronjob.sh
COPY run_cronjob_without_log.sh /root/run_cronjob_without_log.sh
RUN chmod +x /root/run_cronjob_without_log.sh

# Apply cron job
RUN crontab /etc/cron.d/cronjobs

# to gain access to environment variables, we need this additional entrypoint script
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

# optionally, change received signal from SIGTERM TO SIGQUIT
#STOPSIGNAL SIGQUIT

# Run the command on container startup
ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh:

#!/bin/bash
# make global environment variables available within crond, too
printenv | grep -v "no_proxy" >> /etc/environment

# SIGQUIT/SIGTERM-handler
term_handler() {
  echo 'stopping cron'
  service cron stop
  echo 'stopped'
  echo 'waiting'
  x=$(($(ps u -C run_cronjob.sh | wc -l)-1))
  xold=0
  while [ "$x" -gt 0 ]
  do
    if [ "$x" != "$xold" ]; then
      echo "Waiting for $x running cronjob(s):"
      ps u -C run_cronjob.sh
      xold=$x
      sleep 1
    fi
    x=$(($(ps u -C run_cronjob.sh | wc -l)-1))
  done
  echo 'done waiting'
  exit 143; # 128 + 15 -- SIGTERM
}

# cron service with SIGTERM and SIGQUIT support
service cron start
trap "term_handler" QUIT TERM

# endless loop
while true
do
  tail -f /dev/null & wait ${!}
done

的计划

* * * * * ./run_cronjob.sh cron1
*/2 * * * * ./run_cronjob.sh cron2
*/3 * * * * ./run_cronjob.sh cron3

假设您将所有cronjob包装在run_cronjob.sh脚本中。这样，您就可以执行任意代码，关机将优雅地等待。

Run_cronjobs.sh(保持cronjob定义干净的可选帮助脚本)

#!/bin/bash

DIR_INCL="${BASH_SOURCE%/*}"
if [[ ! -d "$DIR_INCL" ]]; then DIR_INCL="$PWD"; fi
cd "$DIR_INCL"

# redirect all cronjob output to docker
./run_cronjob_without_log.sh "$@" > /proc/1/fd/1 2>/proc/1/fd/2

run_cronjob_without_log.sh

your_actual_cronjob_src()

顺便说一下，当接收到SIGKILL时，容器仍然会立即关闭。这样你就可以使用docker-compose stop -t 60 cron-container这样的命令来等待60秒，让cronjob优雅地完成，但仍然在超时后终止它们。

如果映像不包含任何守护进程(因此只有短时间运行的脚本或进程)，还可以考虑从外部启动cron，只需用cron信息定义一个LABEL，再加上调度器本身。这样，您的默认容器状态是“exited”。如果您有多个脚本，这可能会比拥有多个并行运行的cron实例减少系统占用空间。

参见:https://github.com/JaciBrunning/docker-cron-label

示例docker-compose.yaml:

version: '3.8'

# Example application of the cron image
services:
  cron:
    image: jaci/cron-label:latest
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
      - "/etc/localtime:/etc/localtime:ro"

  hello:
    image: hello-world
    restart: "no"
    labels:
      - "cron.schedule=* * * * * "

虽然这旨在通过Docker的exec接口在容器中运行进程的旁边运行作业，但您可能会感兴趣。

我已经编写了一个守护进程，用于观察容器并调度在其元数据中定义的作业。例子:

version: '2'

services:
  wordpress:
    image: wordpress
  mysql:
    image: mariadb
    volumes:
      - ./database_dumps:/dumps
    labels:
      deck-chores.dump.command: sh -c "mysqldump --all-databases > /dumps/dump-$$(date -Idate)"
      deck-chores.dump.interval: daily

“经典”，cron一样的配置也是可能的。

这是文档，这是图像存储库。

在生产环境中，公认的答案可能是危险的。

在docker中，你应该每个容器只执行一个进程，因为如果你不这样做，fork和后台进程就不会被监控，可能会在你不知道的情况下停止。

当你使用CMD cron && tail -f /var/log/cron.log时，cron进程基本上会分叉，以便在后台执行cron，主进程退出，让你在前台执行tailf。后台cron进程可能会停止或失败，但你不会注意到，你的容器仍然会默默地运行，你的编排工具也不会重新启动它。

你可以通过直接将cron的命令输出重定向到分别位于/proc/1/fd/1和/proc/1/fd/2的docker stdout和stderr中来避免这样的事情

使用基本的shell重定向，你可能想做这样的事情:

* * * * * root echo hello > /proc/1/fd/1 2>/proc/1/fd/2

你的CMD将是:CMD ["cron"， "-f"]

但是:如果你想以非根用户的身份运行任务，这就行不通了。