一段时间以来，我已经过渡到使用带有 cron 的 docker，但我不确定我的设置是否最佳。我有一个运行大约 12 个不同脚本的 cron 容器。我可以编辑脚本的时间表，但为了部署正在运行的新版本软件（一些脚本运行大约 1/2 天），我必须创建一个新容器来运行一些脚本，而其他脚本则完成。
我正在考虑每个脚本运行一个容器（容器将共享映像中的所有内容，但 crontab 除外）。但这仍然会使共享一些相同代码的多个容器的更新协调变得困难。
我正在考虑的另一种选择是在主机上运行 cron，每个命令都是 docker run 命令。这样做可以让我通过使用crontab 中的环境变量来更新下一个运行映像。
有人对这两种解决方案有任何经验吗？还有其他解决方案可以提供帮助吗？
【问题讨论】：
如果您只是运行 docker 独立（单主机）并且需要运行一堆 cron 作业而不考虑它们对主机的影响，那么在主机上简单地运行它们就可以了。
如果您从 docker 功能（例如限制内存和 cpu 使用）中受益，那么在 docker 中运行它们会很有意义（因此它们不会做任何破坏性的事情）。如果您还使用将容器日志写入某些外部日志服务的日志驱动程序，以便您可以轻松地监控作业......那么这是另一个很好的理由。最后一个（但很明显）的优势是，使用 docker 镜像而不是在主机上乱搞来部署新软件通常是赢家。
制作一张包含您需要的所有代码的图像要简洁得多。然后，您从主机的 cron 守护程序触发 docker run 命令并覆盖命令/入口点。然后，容器将在作业完成后死亡并自行删除（您可能需要捕获容器输出以在主机上进行日志记录，具体取决于配置的日志记录驱动程序）。尽量不要发送您经常更改的配置值或参数，以便您的 cron 设置尽可能保持静态。如果新图像还意味着您必须在主机上编辑您的 cron 数据，它可能会变得一团糟。
当您像这样使用docker run 时，您不必担心在作业运行时更新图像。只需确保使用例如latest 标记它们，以便下一个作业将使用新图像。
让 12 个容器在后台运行它们自己的 cron 守护进程也会浪费一些内存，但最糟糕的是 cron 不使用父进程中的环境变量，所以如果你用 env vars 注入配置，你'将不得不解决这些混乱（在容器启动时将它们写入磁盘等）。
如果您担心作业并行运行，那么您可以使用大量的任务调度服务，但对于单个 docker 独立主机来说，这可能是多余的。
【讨论】：