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