如何处理Docker容器中的安全更新？

在将应用程序部署到服务器上时，应用程序本身与捆绑在一起的东西与平台（操作系统和已安装的程序包）期望提供的东西之间通常存在分隔。其中一点是，平台可以独立于应用程序进行更新。例如，当需要紧急将安全更新应用到平台提供的软件包而不重建整个应用程序时，这很有用。

传统上，仅通过执行程序包管理器命令来应用安全更新，以在操作系统上安装程序包的更新版本（例如RHEL上的“ yum更新”）。但是随着诸如Docker之类的容器技术的出现，容器映像实际上将应用程序和平台都捆绑在一起，如何使具有容器的系统保持最新状态？主机和容器都有各自独立的软件包集，需要在主机上进行更新和更新不会更新容器内的任何软件包。随着RHEL 7的发布，尤其是Docker容器成为特色，很高兴听到Redhat推荐的处理容器安全性更新的方法是什么。

关于以下几种选择的想法：

• 让软件包管理器更新主机上的软件包将不会更新容器内的软件包。
• 必须重新生成所有容器映像以应用更新似乎打破了应用程序与平台之间的分隔（更新平台需要访问生成Docker映像的应用程序构建过程）。
• 在每个正在运行的容器中运行手动命令似乎很麻烦，并且在下次从应用程序发布工件更新容器时，更改有被覆盖的风险。

因此，这些方法似乎都不令人满意。

Docker映像将应用程序和“平台”捆绑在一起是正确的。但是通常图像由基本图像和实际应用程序组成。

因此，处理安全更新的规范方法是更新基本映像，然后重建您的应用程序映像。

这些容器应该是轻量的并且可以互换。如果您的容器存在安全问题，则可以重建已修补容器的版本并部署新容器。（许多容器使用标准基础映像，该映像使用诸如apt-get之类的标准软件包管理工具来安装其依赖项，重建会从存储库中提取更新）

尽管您可以在容器内打补丁，但扩展性不佳。

这在SUSE Enterprise Linux中使用zypper-docker（1）自动处理。

SUSE / zypper-docker

Docker快速入门

首先，您过去传统上运行的许多更新将完全不在容器本身内部。容器应该是您过去习惯看到的整个文件系统的一个相当轻量级的子集。您必须更新的软件包将是DockerFile的一部分，并且由于拥有DockerFile，因此您应该能够跟踪那些需要更新的软件包和容器ID。即将发布的Cloudstein用户界面将为您跟踪这些DockerFile成分，以便人们可以构建最适合其容器的更新方案。希望这可以帮助

通常，它甚至比您提供的三个选择还要差。大多数docker镜像不是使用程序包管理器构建的，因此您不能仅将其镜像到docker镜像并发布更新。您将需要重建或重新获取Docker映像。

在大多数情况下，您需要重建或依靠他人重建安全补丁这一事实似乎并不合理。

我当时正在考虑在docker容器中部署声纳和雷达，但是知道它们不会获得我的容器获得的常规安全更新会破坏交易。管理我的容器的安全更新很麻烦，而不必处理以某种方式手动将安全更新分别应用于每个docker映像的麻烦。