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