Docker 镜像和操作系统安全更新

Ale*_*ler 6 docker

假设我使用 Node.js 10.8.0 node:10.8.0-jessie Docker 镜像作为我的应用程序的基础镜像Dockerfile。该应用程序在生产中运行稳定,并且有一段时间(几个月)没有更新。

Node.js10.8.0镜像是基于buildpack-deps:jessie image 的,而image本身也是基于buildpack-deps:jessie-scm image 的。这是基于buildpack-deps:jessie-curl 图像,其基本图像debian:jessie

系统/安全更新Debian Jessie会定期发布。在经典的托管环境中,我会使用更新我的主机sudo apt-get update && sudo apt-get upgrade,我很好。

但是如何确保我在容器中运行的 Node.js 应用程序获得最新的Debian Jessie更新和补丁,同时保持在 Node.js 上node:10.8.0-jessie

在我的 CI 中运行sudo apt-get update && sudo apt-get upgrade我的应用程序Dockerfile并定期为我的应用程序创建一个新映像并重新部署容器并不是正确的方法。

由于这一切都从debian:jessie图像开始,我希望它会定期更新,并且所有相关图像也会更新。

然后我将通过10.8.0再次拉取 Node.js镜像来重建我的应用程序镜像( --no-cache) 并重新部署它。

我的问题是:这个假设正确吗?是否有任何关于该工作流程的官方 Docker 文档对我来说似乎必不可少?我如何获得有关debian:jessie并最终node:10.8.0-jessie 发布映像补丁的通知?

BMi*_*tch 6

首选工作流程是提取更新的基础映像,或者重建基础映像(如果是本地构建的)。然后重建你的孩子图像。如果可能的话,您运行的唯一命令应该是安装,而不是升级。要修复应用程序的特定版本,请在安装命令中添加该版本依赖项。

出于以下几个原因,这比升级现有映像中的包更可取:

  • 升级映像仍然会将旧版本的包保留在映像层中,导致映像的大小不必要地增加。
  • 升级需要为每个新版本创建一个新的 Dockerfile,并将父映像设置为以前的版本,从而造成维护挑战。
  • 复制通过升级过程创建的映像需要首先安装大量旧版本并再次构建层。
  • 为每次升级添加层会降低联合文件系统的性能。某些存储驱动程序还对可以创建的层数有限制,在升级周期进行足够多的迭代后,这些层最终会失败。
  • 升级会带来状态漂移的风险。如果升级链中的一个映像包含在 Dockerfile 链中丢失的更改,或者先前安装的状态更改了全新安装的运行方式,那么您将获得一个无法重现的环境,该环境可能会因未知原因而中断。

我可能执行升级的唯一情况是上游基础映像未得到维护。最好我会找到一个不同的基础镜像,或者在本地构建它。但是,当这些都不可能时,我可以构建一个本地基础映像,它是未维护的外部基础映像的子级,第一步是升级软件包。在 Dockerfile 中,这看起来像:

FROM scratch as remote-unmaintained
ADD unmaintained.tgz /

FROM remote-unmaintained as local-base
RUN upgrade-cmd

FROM local-base as app
COPY app /
CMD /app
Run Code Online (Sandbox Code Playgroud)