在将应用程序部署到服务器上时，应用程序本身捆绑的内容与它期望平台（操作系统和已安装的软件包）提供的内容之间通常会存在分离。这样做的一点是平台可以独立于应用程序进行更新。例如，当需要紧急将安全更新应用于平台提供的软件包而无需重建整个应用程序时，这非常有用。
传统上，安全更新只需执行包管理器命令即可在操作系统上安装更新版本的包（例如 RHEL 上的“yum update”）。但随着 Docker 等容器技术的出现，容器镜像本质上将应用程序和应用程序捆绑在一起和平台，保持带有容器的系统最新状态的规范方法是什么？主机和容器都有自己独立的需要更新的软件包集，并且在主机上进行更新不会更新容器内的任何软件包。随着 RHEL 7 的发布，Docker 容器成为主要功能，了解 Redhat 推荐的处理容器安全更新的方法将会很有趣。
对一些选项的想法：
- 让包管理器更新主机上的包不会更新容器内的包。
- 必须重新生成所有容器镜像才能应用更新似乎会破坏应用程序和平台之间的分离（更新平台需要访问生成 Docker 镜像的应用程序构建过程）。
- 在每个正在运行的容器内运行手动命令似乎很麻烦，并且下次从应用程序发布工件更新容器时，更改可能会被覆盖。
因此，这些方法似乎都不令人满意。
答案1
Docker 镜像将应用程序和“平台”捆绑在一起，这是正确的。但通常镜像由基础镜像和实际应用程序组成。
因此，处理安全更新的规范方法是更新基础映像，然后重建应用程序映像。
答案2
容器应该是轻量级且可互换的。如果您的容器存在安全问题，您可以重建已修补的容器版本并部署新容器。（许多容器使用标准基础映像，该映像使用标准包管理工具（如 apt-get）来安装其依赖项，重建将从存储库中提取更新）
虽然你可以修补容器内部，但这样做的扩展性并不好。
答案3
答案4
首先，您过去传统上运行的许多更新根本不会在容器本身内。容器应该是您过去习惯看到的完整文件系统的一个相当轻量级和小的子集。您应该更新的软件包将是 DockerFile 的一部分，由于您拥有 DockerFile，因此您应该能够跟踪需要更新的软件包和容器 ID。即将发布的 Cloudstein 的 UI 会为您跟踪这些 DockerFile 成分，以便您可以构建最适合其容器的更新方案。希望这能有所帮助