在将应用程序部署到服务器上时，应用程序与自身绑定的内容与从平台（操作系统和安装的包）提供的内容之间通常存在分离。 其中一点就是平台可以独立于应用程序进行更新。 例如，当需要紧急将安全更新应用于由平台提供的包而不重build整个应用程序时，这是非常有用的。
传统上，通过执行软件包pipe理器命令在操作系统上安装软件包的更新版本（例如，RHEL上的“yum update”），就可以应用安全更新。 但随着容器技术（如Docker）的出现，容器映像实际上将应用程序和平台捆绑在一起，保持容器系统最新的规范方法是什么？ 主机和容器都有自己的独立套件，需要在主机上更新和更新，不会更新容器内的任何包。 随着特别推出Docker容器的RHEL 7的发布，听听Redhat推荐的处理容器安全更新的方法是很有意思的。
关于几个选项的思考：
所以这些方法都不令人满意。
Docker映像捆绑应用程序和“平台”，这是正确的。 但通常图像是由一个基本的图像和实际的应用程序组成的。
因此，处理安全更新的规范方法是更新基础映像，然后重新构build应用程序映像。
容器应该是轻量级和可互换的。 如果您的容器存在安全问题，请重新构build已修补的容器的版本并部署新的容器。 （许多容器使用一个标准的基础镜像，使用标准的软件包pipe理工具，比如apt-get来安装它们的依赖关系，重build将从存储库中获取更新）
虽然你可以在容器内打补丁，但是这不能很好地扩展。
首先，过去传统上运行的很多更新程序根本就不在容器内部。 容器应该是您以前习惯于看到的完整文件系统的一个相当轻量级的小子集。 你应该更新的包是那些是你的DockerFile的一部分，因为你有DockerFile，你应该能够跟踪那些需要更新的包和容器ID。 Cloudstein将很快发布的用户界面会跟踪这些DockerFile成分，以便您可以构build最适合其容器的更新scheme。 希望这可以帮助
这在SUSE Enterprise Linux中使用zypper-docker（1）自动处理
SUSE / zypper的-泊坞窗
Docker快速入门