我对 docker 比较陌生，并尝试实现自动化部署。 就我的理解，容器永远不应该更新。在更新的情况下，需要创建新映像 (1) 并且需要用新实例替换正在运行的容器 (2)。
我通过使用 containerrrr/watchtower 解决了挑战 2。这似乎是唯一的(?) 仍然维护的软件，可以使用较新版本自动更新我的容器。
挑战 1 有点复杂。对于直接来自 docker hub 的图像，除了希望包维护者定期更新之外，我无能为力。然而，在某些情况下，来自 docker hub 的图像是不够的，通常建议创建派生图像。有时，一开始就没有维护的图像。对于这两个用例，我设置了 Jenkins 管道，用于构建图像并将它们推送到我的私人 docker 存储库中，由瞭望塔监控。 到目前为止，一切都很好。
但是我如何在我的 Jenkins 管道上设置触发器以使其保持最新状态？
可能的来源：
我很惊讶没有关于这个主题的更多信息。有很多关于如何初始设置 docker 和 Jenkins 的很棒的指南，它们显示了入门是多么容易，但没有关于如何长时间运行容器。 对于许多开发人员来说，我认为这不是问题，因为源代码中有很多更新，无论如何都会经常触发更新，但是所有定制的图像呢？
这是一个实际的差距还是我遗漏了一条重要的信息？
答案 0 :(得分：2)
据我所知，容器永远不应该更新。在更新的情况下，需要创建新的镜像 (1) 并且需要用新实例替换正在运行的容器。
先简单介绍一下docker：
Docker 提供了在称为容器的松散隔离环境中打包和运行应用程序的能力。隔离和安全性允许您在给定主机上同时运行多个容器。如需更多信息：Docker documentation
将容器视为虚拟机是一种常见的误解，但 docker 不是一种虚拟化技术，它是一种应用程序交付技术。容器的抽象是你的应用运行的服务，一旦进程结束，docker容器就停止了。
每个容器都有自己的隔离环境，为服务运行的需要做好准备。 This is one of the main benefits of docker, you can REPLICATE the environment of the application to run. 完成此快速介绍是为了了解 docker 的这一优势，并作为澄清您的问题的基础。考虑到这一点，让我们看看您的问题：
为什么需要直接从 docker hub 更新正在运行的容器？
假设您正在使用 postgres 映像在您的服务器中运行一个数据库。其他容器需要与此 postgres 容器通信，因此它需要访问此数据库。您的应用程序在当前图像版本中按预期工作。 postgres 镜像有一个新的可用版本，您的系统更新了容器，由于某种原因，容器行为与以前的版本不同，一旦容器更新，您的应用程序就会由于某种原因失败。
这里的主要事情是更新容器应该按照标准来完成，了解您的应用程序的需求，并始终有一种方法来测试此更新版本的行为是否符合您的预期。另一方面，如果您在没有任何标准的情况下自动更新，并且没有对整个应用程序进行先前的断言，那么您就没有利用环境复制。
<块引用>这与第一点密切相关。由于我想为应用程序需求创建我的隔离环境，我需要选择合适的基础镜像来构建我的最终镜像。我只会在特定条件下更新此基础映像。
想象一下，我想为 Java 应用程序创建一个容器。我将使用官方 Java 图像作为基础图像。我将选择适合我项目的 sdk 的图像版本。如果此映像针对较新的 sdk 自动更新，则可能会破坏应用程序的当前行为。
<块引用>但是我如何在我的 Jenkins 管道上设置触发器以使其保持最新状态？
根据之前的所有说明，答案是：这应该是一个手动步骤，根据容器服务需求的标准完成，并且有办法测试这个新镜像版本，作为最终镜像的基础镜像，或者直接在您的系统中使用，不会破坏您的应用程序或系统行为。
我使用环境复制 docker Benefit 来回答您的问题，但是还有许多其他 docker 功能、标准流程和其他发挥重要作用的功能，可以使答案更长。我希望这可以很好地介绍您的问题。
我鼓励您阅读有关编写 docker 映像的最佳实践以及其他有关 docker 的有趣博客，以更好地了解使用该技术的好处，并获得知识以使答案更有意义。我会在下面留下几个有趣的链接：