一种“docker方式”是使用docker hub自动构建。当上游容器被重建时，Repository Links特性将重建你的容器，Webhooks特性将向你发送通知。

看起来webhooks仅限于HTTP POST调用。您需要设置一个服务来捕获它们，或者可能使用其中一个POST发送电子邮件服务。

我还没有深入研究，但是新的Docker通用控制平面可能有一个检测更新容器和重新部署的功能。

Docker映像的依赖管理是一个真正的问题。我所在的团队开发了一个名为MicroBadger的工具，通过监视容器图像和检查元数据来帮助解决这个问题。它的功能之一是让你设置一个通知网络钩子，当你感兴趣的图像(例如基本图像)发生变化时，它会被调用。

一种“docker方式”是使用docker hub自动构建。当上游容器被重建时，Repository Links特性将重建你的容器，Webhooks特性将向你发送通知。

看起来webhooks仅限于HTTP POST调用。您需要设置一个服务来捕获它们，或者可能使用其中一个POST发送电子邮件服务。

我还没有深入研究，但是新的Docker通用控制平面可能有一个检测更新容器和重新部署的功能。

你试过这个吗:https://github.com/v2tec/watchtower。 它是一个简单的工具，运行在docker容器中，监视其他容器，如果它们的基本映像改变了，它将拉出并重新部署。

我回答的前提是:

容器使用标签运行。 相同的标签可以指向不同的图像UUID，因为我们喜欢/觉得合适。 对图像的更新可以提交到新的图像层

方法

首先使用安全补丁更新脚本构建所有容器 为以下内容构建一个自动化流程 使用安全补丁脚本将现有映像运行到新容器 提交对映像的更改为 现有标记->，然后逐个重新启动容器 新版本标签->用新标签替换少数容器->验证->将所有容器移动到新标签

此外，可以升级基本映像/可以定期构建具有完整的新基本映像的容器，这是维护者认为必要的

优势

我们在创建新的安全补丁映像时保留映像的旧版本，因此如果需要，我们可以回滚到以前正在运行的映像 我们保留了docker缓存，从而减少了网络传输(只有被更改的层连接到网络上) 升级过程可以在过渡到产品化之前在阶段中进行验证 这可以是一个受控的过程，因此只有在必要/被认为重要时才可以推送安全补丁。

另一种方法是假设您的基本映像很快就会落后(这很可能发生)，并定期强制应用程序构建另一个映像(例如每周)，如果它发生了更改，则重新部署它。

据我所知，像官方Debian或Java这样的流行基础镜像会更新它们的标记来满足安全修复，所以标记不是不可变的(如果你想要更强的保证，你需要使用参考[image:@digest]，在最新的Docker版本中可用)。因此，如果你要用docker build -pull构建你的映像，那么你的应用程序应该得到你引用的base image标签的最新和最好的。

由于可变标记可能令人困惑，所以最好每次都增加应用程序的版本号，这样至少在您的方面，事情会更清楚。

因此，我不确定在前面的答案之一中建议的脚本是否能完成工作，因为它不重新构建应用程序的映像——它只是更新基本映像标记，然后重新启动容器，但新的容器仍然引用旧的基本映像散列。

我不提倡在容器中运行cron类型的作业(或任何其他进程，除非真的有必要)，因为这违背了每个容器只运行一个进程的原则(关于为什么这样更好有各种各样的争论，所以我不打算在这里讨论)。