需要时重建容器答案

【问题标题】：Rebuilding containers when needed需要时重建容器
【发布时间】：2020-08-26 16:10:41
【问题描述】：

一个应用容器一般由三部分组成：

在 Linux 情况下包含核心 POSIX 工具和系统库的基本映像（例如 FROM debian:stable）
运行时库或帮助工具通常从某种包中安装（例如RUN apt-get update && apt-get python3-numpy && …——对于基础 python 或 java 等。通常有一个现成的基础容器可供使用，但应用程序可能仍有其他依赖项）。
- 同样的问题适用于链接到应用程序的依赖项（例如，由 maven 或 nuget 等引入的外部依赖项）。如果有一个通用的解决方案也能解决这个问题，那就太好了，否则将寻求另一种特定于工具的解决方案。
应用程序本身（例如COPY …/application/ /usr/local/python3.8/dist-packages/application/ 和设置入口点）。

将进入生产环境的容器通常构建在构建服务器上。现在，当对应用程序进行更改时重建它是显而易见的，以及 CI 服务器的设计目的。

但是前两个组件可能并且经常有针对它们的安全建议文件，当它们出现时，还应该重建映像并将其推送到集成测试，然后要么更新生产环境，要么更新管理员通知尽快触发它。

那么有没有一些方法或工具可以帮助我们设置合适的触发器来在基础容器或其他依赖项有更新时重建容器？ Docker 默认是 Debian 基础镜像，但如果它对此有更好的支持，我们会使用另一个发行版。

请注意，只运行docker build --pull --no-cache nightly 不是一个解决方案，因为即使依赖项实际上没有因安装文件的不同时间戳而发生变化，这也会产生一个新容器。并且只运行docker build --pull 也不起作用，因为缓存在那里，但是它只检查Dockerfile 是否已更改并且实际上不检查包列表，或者缓存不存在，因为它正在运行在不同的构建代理上或构建代理被清理，因为它通常应该获得可靠的构建。

它可以使用任何容器构建器，不一定是 docker。

【问题讨论】：

标签： docker kubernetes continuous-integration jib buildah

【解决方案1】：

每周运行一次docker build --pull --no-cache 是一个合理的折衷方案。在那个时间范围内，操作系统级包中很可能会有一些修复，因此您将使用新映像重新启动容器以获取安全更新，这是合理的。根据您部署到生产环境的频率，“在每次生产环境部署”可能也可能不是执行此操作的好时机。

如果跨环境的一致性对您很重要，请考虑使用带有日期戳的 debian 映像 (FROM debian:stable-20200422) 版本，或者构建您自己的基础映像，然后将其存储在注册表中。然后，您可以使用 Dockerfile ARG 来指定日期戳，如果这样做，您将永远不需要 --no-cache。（但是，您必须手动发现当前版本。）

# Build with
#   docker build --build-arg DATE_STAMP=-20200422
# This must have a leading hyphen
ARG DATE_STAMP

FROM debian:stable${DATE_STAMP:-}

对于语言包，还要考虑到大多数包管理器都有一个锁定文件，它指定要使用的包的确切版本（NPM package-lock.json、yarn.lock、Ruby Bundler Gemfile.lock、Python requirements.txt 或 Pipfile.lock)。在这些情况下，您必须运行某种“更新”操作来更新锁定文件；这样做会生成一个提交，触发 CI 系统，以及一个文件更改，这将使 Docker 构建缓存失效。

【讨论】：

【解决方案2】：

对于许多其他与 docker 相关的问题，答案是放弃 docker 并切换到buildah。 buildah bud 是docker build 的直接替代品，buildah commit 是用于通过其他方式编写构建脚本的--timestamp 选项，它强制将时间戳写入清单和新层中文件的时间戳到指定值。这似乎是工具本身唯一的不确定性。标准确定性构建技术仍然需要应用于应用程序本身的构建，但这显然超出了 buildah 的范围。

【讨论】：