传统上，仅通过执行软件包管理器命令来安装更新的版本即可应用安全更新。操作系统上的软件包数量（例如，RHEL上的“ yum更新”）。但是随着诸如Docker之类的容器技术的出现，容器映像实际上将应用程序和平台都捆绑在一起，如何使具有容器的系统保持最新状态？主机和容器都有自己独立的软件包集，需要在主机上进行更新和更新不会更新容器内的任何软件包。在特别具有Docker容器功能的RHEL 7发行版中，很有趣的是，听到Redhat推荐的处理容器安全性更新的方法是什么。
关于以下几个选项的思考：
在主机上保留程序包管理器更新程序包不会更新容器内的程序包。
必须重新生成所有容器映像以应用更新程序似乎打破了应用程序与平台之间的分隔（更新平台需要访问生成Docker映像的应用程序构建过程。）
在每个正在运行的容器中运行手动命令似乎很麻烦，并且在下次从应用程序更新容器时更改有被覆盖的风险
所以这些方法似乎都不令人满意。
#1 楼
Docker映像将应用程序和“平台”捆绑在一起是正确的。但是通常该映像由基本映像和实际应用程序组成。因此，处理安全更新的规范方法是更新基本映像，然后重建您的应用程序映像。
评论
谢谢，这听起来很合理。仍然只是希望更新平台，可以这么说，不必触发整个应用程序的重新打包（例如，考虑到必须更新100个不同的应用程序映像，因为要更新单个基本映像）。但这可能是Docker不可避免的将所有内容捆绑在一个映像中的哲学。
–马库斯·霍尔曼（Markus Hallmann）
2014年11月20日在11:54
@ValkoSipuli您总是可以编写脚本来自动执行该过程。
–dlyk1988
15年1月16日在14:28
为什么不在容器内进行apt-get升级，dnf升级，pacman -syu等等效？您甚至可以创建一个执行该操作的shell脚本，然后运行该应用程序，然后将其用作容器的入口点，以便在启动/重新启动容器时，它会升级其所有软件包。
– Arthur Kay
2015年9月29日下午16:53
@ArthurKay的两个原因：1）您扩大了容器的大小，因为所有升级的软件包都将添加到容器层，同时将过时的软件包保留在映像中。 2）它击败了（容器）映像的最大优势：运行的映像与您构建/测试的映像不同，因为您在运行时更改了程序包。
–约翰内斯（Johnhannes）的鱼Ziemke
2015年9月30日在9:32
我不了解一件事：如果您是一家公司，购买作为docker容器运输的软件，那么每次安全问题出现时，您是否必须等待该软件的制造商重建应用程序包？ ？哪家公司会以这种方式放弃对其开放漏洞的控制？
–圣淘沙
17-10-17在13:04
#2 楼
这些容器应该是轻便的和可互换的。如果您的容器存在安全问题，则可以重建已修补容器的版本并部署新容器。 （许多容器使用标准基础映像，该映像使用诸如apt-get之类的标准软件包管理工具来安装其依赖项，重建会从存储库中获取更新）虽然您可以在容器内打补丁，但这并没有很好地扩展。
#3 楼
在SUSE Enterprise Linux中使用zypper-docker（1）自动处理此问题SUSE / zypper-docker
Docker快速入门
#4 楼
首先，您过去传统上运行的许多更新将根本不在容器本身内。容器应该是您过去习惯看到的完整文件系统的一个相当轻量级的子集。您必须更新的软件包将是DockerFile的一部分，并且由于拥有DockerFile，因此您应该能够跟踪那些需要更新的软件包和容器ID。即将发布的Cloudstein用户界面将为您跟踪这些DockerFile成分，以便人们可以构建最适合其容器的更新方案。希望这会有所帮助#5 楼
通常，它甚至比您提供的三个选择还要差。大多数docker镜像不是使用程序包管理器构建的，因此您不能仅将其镜像到docker镜像中并发布更新。您将需要重建或重新获得docker映像。在大多数情况下，您需要重建或依靠他人重建安全补丁这一事实似乎不合理。
我当时正在考虑在docker容器中部署声纳和雷达，但知道它们将无法获得我的容器获得的常规安全更新，这会破坏交易。管理容器的安全更新很麻烦，而不必处理必须手动将安全更新分别应用于每个docker映像的问题。
评论
您的帖子不会被视为答案，因为您没有提供该问题的答案。请添加它作为对问题的评论，并删除您的“答案”。 StackExchange不是论坛，而应被视为问答，专家可以回答他们可以提供帮助的问题。
–菲利普-Zyan K Lee- Stockmann
19年5月1日在19:13
哈，很幸运，我应该为对问题的理解做出贡献而受到否决。响应中有一个答案“您将需要重建或重新获得Docker映像。”
–李·伯奇（Lee Burch）
20年1月15日在22:12
评论
到目前为止，我所见过的最好的主意是原子项目。我认为目前尚不适合黄金时段。Valko，您最终得到了什么工作流程？我正在运行长期容器（例如托管php-cgi），到目前为止，我发现的是：docker pull debian / jessie更新映像，然后重建我现有的映像，然后停止容器并再次运行它们（带有新图像）。我构建的映像与以前的映像具有相同的名称，因此通过脚本完成启动。然后，我删除“未命名”图像。我当然希望有更好的工作流程。
miha：这听起来与我最终所做的类似。基本上，不断进行更新和重建所有映像，作为发布新版本的一部分。然后使用新映像重新启动容器。
最好的答案很有帮助，因为有一个脚本包含主要命令行，这些脚本可以完全执行Johannes Ziemke所说的：
有趣的问题。我自己对此感到奇怪。如果您在一台Docker主机上运行20个应用程序，则必须升级基本映像，重建并重新启动！ 20个应用程序，您甚至都不知道安全更新是否影响了所有应用程序，或者只是其中之一。例如，当安全更新仅影响libpng时，您必须重建Apache的映像。因此，您最终会进行不必要的重建并重新启动...