构建容器的最佳做法

最新推荐文章于 2024-07-19 21:03:27 发布

Dreamer who

最新推荐文章于 2024-07-19 21:03:27 发布

阅读量766

点赞数

分类专栏： Kubernetes

本文链接：https://blog.csdn.net/doctor_who2004/article/details/104463492

版权

Kubernetes 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

本文介绍构建容器的一系列最佳做法。这些做法涵盖了广泛的目标（从缩短构建时间到创建更小、弹性更佳的映像），旨在使容器更加容易构建（例如，使用 Cloud Build），并且更加容易在 Google Kubernetes Engine (GKE) 中运行。

这些最佳做法的重要性并不相同。例如，成功运行某一生产工作负载可能无需其中某些做法，但必须使用其他做法。特别是，与安全相关的最佳做法的重要性较为主观。是否实现它们取决于您的环境和所受限制。

若要充分理解本文中的内容，您需要了解一些关于 Docker 和 Kubernetes 的知识。此处讨论的一些最佳做法也适用于 Windows 容器，但大多数做法假定您使用的是 Linux 容器。有关运行和操作容器的建议，请参阅操作容器的最佳做法。

每个容器打包一个应用

重要性：高

注意：在此最佳做法的上下文中，“应用”被视为具有唯一父进程且可能具有多个子进程的单个软件。

开始使用容器时，一种常见误解是将它们视为可以同时运行许多不同项的虚拟机。容器可以这样工作，但这样做会减少容器模型的大部分优点。例如，采用经典 Apache/MySQL/PHP 堆栈：您可能非常想在单个容器中运行所有组件。但是，最佳做法是使用两个或三个不同容器：一个用于 Apache，一个用于 MySQL，如果运行 PHP-FPM，则可能还有一个用于 PHP。

由于容器与其托管的应用具有相同的生命周期，因此每个容器应仅包含一个应用。当容器启动时，应用也应该启动，当应用停止时，容器也应该停止。下图展示了此最佳做法。

图 1. 左边的容器符合最佳做法，右边的容器则不符合最佳做法。

如果一个容器中具有多个应用，则这些应用可能具有不同的生命周期或处于不同状态。例如，容器可能最终会运行，但其中一个核心组件崩溃或无响应。如果不进行额外的运行状况检查，则整个容器管理系统（Docker 或 Kubernetes）将无法判断该容器是否运行正常。对于 Kubernetes，这意味着在需要时不会默认重启容器。

您可能会在公开映像中看到以下操作，但不要按照它们的示例进行操作：

使用 supervisord 等进程管理系统来管理容器中的一个或多个应用。
使用 bash 脚本作为容器中的入口点，并使其生成多个应用作为后台作业。如需了解如何在容器中正确使用 bash 脚本，请参阅正确处理 PID 1、信号处理和僵尸进程。

注意：您可能会看到有些知名供应商的官方映像并未实施这种最佳做法。供应商这样做的原因是他们需要多个组件正常工作，并且他们希望用户能够通过单个 docker run 命令来运行他们的软件。虽然此方法可用于测试和实验，但我们不建议在生产中运行这些映像。

正确处理 PID 1、信号处理和僵尸进程

重要性：高

Linux 信号是控制容器内进程生命周期的主要方式。根据以往的最佳做法，为了将应用的生命周期与其所处的容器紧密关联，请确保您的应用正确处理 Linux 信号。最重要的 Linux 信号是 SIGTERM，因为它可以终止进程。您的应用可能还会接收 SIGKILL 信号（用于非正常终止进程）或 SIGINT 信号（在输入 Ctrl+C 时发送此信号，此信号通常被视为类似 SIGTERM）。

进程标识符 (PID) 是 Linux 内核为每个进程提供的唯一标识符。PID 属于命名空间，这意味着容器具有一组自己的 PID，这些 PID 映射到主机系统上的 PID。启动 Linux 内核时启动的第一个进程具有 PID 1。对于常规操作系统，此进程是 init 系统，例如 systemd 或 SysV。同样，在容器中启动的第一个进程将获得 PID 1。Docker 和 Kubernetes 使用信号与容器内的进程通信，特别是终止它们。Docker 和 Kubernetes 都只能向容器内具有 PID 1 的进程发送信号。

在容器的上下文中，PID 和 Linux 信号会产生两个需要考虑的问题。

问题 1：Linux 内核如何处理信号

对于具有 PID 1 的进程，Linux 内核处理其信号的方式与处理其他进程的信号的方式有所不同。系统不会自动为此进程注册信号处理程序，这意味着 SIGTERM 或 SIGINT 等信号在默认情况下不起作用。默认情况下，您必须使用 SIGKILL 来终止进程，防止出现任何正常关闭。使用 SIGKILL 可能会导致面向用户的错误、（数据存储区的）写入中断或监控系统中出现不必要的提醒，具体取决于您的应用。

问题 2：经典 init 系统如何处理孤立进程

经典 init 系统（如 systemd）也可用于移除（回收）孤立的僵尸进程。孤立进程（其父级已结束的进程）被重新附加到具有 PID 1 的进程，该进程应在这些进程结束时回收它们。普通 init 系统即可做到这一点。但在容器中，这一职责由具有 PID 1 的进程承担。如果该进程无法正确处理回收，则可能会出现耗尽内存或一些其他资源的风险。

针对这些问题，有几个常见解决方案，将在以下各部分中进行概述。

解决方案 1：作为 PID 1 运行并注册信号处理程序

该解决方案只解决了第一个问题。如果您的应用以可控方式生成子进程（通常是这种情况），则该解决方案有效，且避免了第二个问题。

实现此解决方案的最简单方法是使用 Dockerfile 中的 CMD 和/或 ENTRYPOINT 指令来启动进程。例如，在以下 Dockerfile 中，nginx 是第一个也是唯一一个要启动的进程。

FROM debian:9

RUN apt-get update && \
    apt-get install -y nginx

EXPOSE 80

CMD [ "nginx", "-g", "daemon off;" ]

警告：nginx 进程会注册自己的信号处理程序。如果使用此解决方案，在许多情况下，您必须在应用代码中执行相同操作。

有时，您可能需要在容器中准备环境，以便进程能够正常运行。在此情况下，最佳做法是让容器在启动时启动一个 shell 脚本。此 shell 脚本的任务是准备环境和启动主进程。但是，如果采用此方法，shell 脚本将具有 PID 1 而不是您的进程，因此您必须使用内置的 exec 命令从 shell 脚本启动进程。exec 命令会将脚本替换为您所需的程序。然后，您的进程将继承 PID 1。

解决方案 2：使用专用 init 系统

正如您在较经典的 Linux 环境中所做的那样，您还可以使用 init 系统来处理这些问题。但是，如果仅出于此目的，普通 init 系统（例如 systemd 或 SysV）太过复杂而庞大，因此我们建议您使用专为容器创建的 init 系统（例如 tini）。

如果使用专用 init 系统，则 init 进程具有 PID 1 并执行以下操作：

注册正确的信号处理程序。
确保信号适用于您的应用。
回收任何最终的僵尸进程。

您可以通过使用 docker run 命令的 --init 选项在 Docker 中使用此解决方案。要在 Kubernetes 中使用此解决方案，必须在容器映像中安装 init 系统，并将其用作容器的入口点。

优化 Docker 构建缓存

重要性：高

Docker 构建缓存可以大幅度加速容器映像的构建。映像是逐层构建的，在 Dockerfile 中，每条指令都会在生成的映像中创建一层。在构建期间，如果可能，Docker 会重复使用先前构建中的层并跳过可能很昂贵的步骤。仅当所有先前的构建步骤都使用 Docker 的构建缓存时，Docker 才能使用该缓存。虽然此行为通常有助于加速构建，但您需要考虑一些情况。

例如，要充分利用 Docker 构建缓存，必须将经常更改的构建步骤置于 Dockerfile 底部。如果将它们放在顶部，则 Docker 无法将其构建缓存用于其他不经常更改的构建步骤。由于通常会为每个新版本的源代码构建一个新 Docker 映像，因此，请尽可能晚地向 Dockerfile 中的映像添加源代码。在下图中，您可以看到，如果更改 STEP 1，则 Docker 只能重复使用 FROM debian:9 步骤中的层。但是，如果更改 STEP 3，则 Docker 可以重复使用 STEP 1 和 STEP 2 的层。

图 2. 如何使用 Docker 构建缓存的示例。绿色表示可以重复使用的层。红色表示必须重新创建的层。

重复使用层还有另外一种结果：如果构建步骤依赖于存储在本地文件系统上的任何类型的缓存，则必须在同一构建步骤中生成此缓存。如果不生成此缓存，则构建步骤可能会通过来自先前构建的过期缓存执行。软件包管理器（如 apt 或 yum）中最常出现此行为：您必须在安装软件包的同一个 RUN 命令中更新代码库。

如果您在下面的 Dockerfile 中更改了第二个 RUN 步骤，则系统不会重新运行 apt-get update 命令，而是使用已过期的 apt 缓存。

FROM debian:9

RUN apt-get update
RUN apt-get install -y nginx

改为在单个 RUN 步骤中合并这两个命令：

FROM debian:9

RUN apt-get update && \
    apt-get install -y nginx

移除不必要的工具

重要性：中

要保护您的应用免受攻击者攻击，请尝试移除任何不必要的工具，以减少应用的攻击面。例如，移除可用于在系统内创建逆向 shell 的 netcat 等实用工具。如果 netcat 未处于容器中，攻击者就必须另寻攻击方法。

此最佳做法适用于任何工作负载，即使是非容器化的工作负载也是如此。不同之处在于，与针对经典虚拟机或裸机服务器实现此最佳做法相比，针对容器实现此最佳做法要简单得多。

这些工具中的某些工具可能对调试很有用。例如，如果您将此最佳做法的适用范围扩大，则详尽的日志、跟踪、分析和应用性能管理系统几乎是必需的。实际上，您无法再依赖本地调试工具，因为它们通常需要很高的特权。

文件系统内容

此最佳做法的第一部分涉及容器映像的内容。请在映像中保留尽可能少的内容。如果您可以将应用编译为单个静态链接的二进制文件，则通过将此二进制文件添加到暂存映像，您可以获得仅包含应用而不包含任何其他内容的最终映像。通过减少映像中打包的工具数，可以减少潜在攻击者在容器中可执行的操作。如需了解详情，请参阅构建尽可能小的映像。

文件系统安全

不在映像中保留任何工具还不够：您必须防止潜在的攻击者安装其自己的工具。您可以结合使用以下两种方法：

避免在容器内以根身份运行：此方法提供了第一层安全，并且可以防止攻击者使用映像中嵌入的软件包管理器（例如 apt-get 或 apk）修改根拥有的文件。要使此方法有用，必须停用或卸载 sudo 命令。避免以根身份运行中更加广泛地介绍了此主题。
以只读模式启动容器，您可以使用 docker run 命令中的 --read-only 标志或使用 Kubernetes 中的 readOnlyRootFilesystem 选项来执行此操作。您可以使用 PodSecurityPolicy 在 Kubernetes 中强制执行此操作。

警告：如果您的应用需要将临时数据写入磁盘，您仍然可以使用 readOnlyRootFilesystem 选项并为临时文件添加 emptyDir 卷。Kubernetes 不支持 emptyDir 卷上的装载选项，因此您无法在启用 noexec 标志的情况下装载此卷，这意味着攻击者可以在此卷中放置二进制文件并执行该文件。

构建尽可能小的映像

重要性：中

构建较小的映像可以带来上传和下载速度更快等优点，这对于 Kubernetes 中 pod 的冷启动时间来说尤为重要：映像越小，节点下载映像的速度越快。但是，构建小映像可能很困难，因为您可能会在最终映像中无意间添加构建依赖项或未优化的层。

注意：这篇博文包含有关此主题的大量有用信息，并提供了各种语言版本的示例。

使用尽可能小的基础映像

基础映像是 Dockerfile 的 FROM 指令中引用的映像。Dockerfile 中的每个其他指令都在此映像基础上构建。基础映像越小，生成的映像越小，下载速度也就越快。例如，alpine:3.7 映像比 centos:7 映像小 71 MB。

您甚至可以使用暂存基础映像，它是一个空映像，您可以在该映像上构建自己的运行时环境。如果您的应用是静态链接的二进制文件，则使用临时基本映像非常容易：

FROM scratch
COPY mybinary /mybinary
CMD [ "/mybinary" ]

distroless 项目为您提供了许多不同语言的最小基础映像。这些映像仅包含特定语言的运行时依赖项，但不包含 Linux 发行版中的诸多工具（shell、软件包管理器等）。

降低映像中的杂乱程度

要减小映像大小，请仅在其中安装严格需要的内容。人们可能会倾向于安装额外的软件包，然后在稍后的步骤中移除它们。但仅仅依靠这种方法还不够。Dockerfile 的每条指令都会创建一层，所以在创建映像之后的步骤中从映像中移除数据无法减小整个映像的大小（数据仍然存在，只是隐藏在更深的层中）。请参考下面的示例：

差 Dockerfile 好 Dockerfile

差 Dockerfile	好 Dockerfile
`FROM debian:9 RUN apt-get update && \ apt-get install -y \ [buildpackage] RUN [build my app] RUN apt-get autoremove --purge \ -y [buildpackage] && \ apt-get -y clean && \ rm -rf /var/lib/apt/lists/*`	`FROM debian:9 RUN apt-get update && \ apt-get install -y \ [buildpackage] && \ [build my app] && \ apt-get autoremove --purge \ -y [buildpackage] && \ apt-get -y clean && \ rm -rf /var/lib/apt/lists/*`

FROM debian:9

RUN apt-get update && \
    apt-get install -y \
    [buildpackage]
RUN [build my app]
RUN apt-get autoremove --purge \
    -y [buildpackage] && \
    apt-get -y clean && \
    rm -rf /var/lib/apt/lists/*

FROM debian:9

RUN apt-get update && \
    apt-get install -y \
    [buildpackage] && \
    [build my app] && \
    apt-get autoremove --purge \
    -y [buildpackage] && \
    apt-get -y clean && \
    rm -rf /var/lib/apt/lists/*

在差版本的 Dockerfile 中，[buildpackage] 和 /var/lib/apt/lists/* 中的文件仍然存在于与第一条 RUN 对应的层中。此层包含在映像之中，必须与其余层一并上传和下载，即使其中所包含的数据在最终得到的映像中无法访问也是如此。

在好版本的 Dockerfile 中，所有内容都在一个仅包含构建应用的层中完成。[buildpackage] 和 /var/lib/apt/lists/* 中的文件不存在于生成的映像中的任何位置，也未隐藏在更深的层中。

如需详细了解映像层，请参阅优化 Docker 构建缓存。

减小映像中的杂乱程度的另一种好办法是使用多阶段构建（在 Docker 17.05 中引入）。多阶段构建允许您在第一个“构建”容器中构建应用，并将结果用于其他容器，同时使用同一 Dockerfile。

图 3. Docker 多阶段构建过程。

在以下 Dockerfile 中，hello 二进制文件在第一个容器中构建，并在第二个容器中注入。由于第二个容器基于暂存映像，因此生成的映像仅包含 hello 二进制文件，而不包含构建期间所需的源文件和目标文件。二进制文件必须静态链接，才能在不需要暂存映像中的任何外部库的情况下正常工作。

FROM golang:1.10 as builder

WORKDIR /tmp/go
COPY hello.go ./
RUN CGO_ENABLED=0 go build -a -ldflags '-s' -o hello

FROM scratch
CMD [ "/hello" ]
COPY --from=builder /tmp/go/hello /hello

尝试创建具有通用层的映像

如果必须下载 Docker 映像，Docker 首先会检查您是否已具有映像中的某些层。如果您具有这些层，则不会下载它们。如果您之前下载的另一映像与您当前正在下载的映像具有相同的基础，则可能会出现此情况。结果是第二个映像的已下载数据量要少得多。

在组织级别，您可以为开发者提供一组通用的标准基础映像，从而利用这一规律减少下载量。您的系统下载各基础映像的次数必须仅为一次。初始下载后，仅需要使每个映像具有唯一性的层。实际上，映像的共同点越多，下载速度就越快。

图 4. 创建具有通用层的映像。

在 Container Registry 中使用漏洞扫描

重要性：中

在裸机服务器和虚拟机领域，软件漏洞是一个众所周知的问题。解决这些漏洞的一种常用方法是，使用列出每个服务器上安装的软件包的集中式库存系统。订阅上游操作系统的漏洞 Feed，以便在漏洞影响服务器时收到通知，并对其进行相应修补。

但是，由于容器应该是不可变的（详情请参阅容器的无状态性和不变性），因此，如果存在漏洞，请勿对其进行就地修补。最佳做法是重新构建映像（包含补丁程序），并重新部署该映像。与服务器相比，容器的生命周期短得多，标识不太清晰明确。因此，使用类似的集中式库存系统来检测容器中的漏洞不是一种好方法。

Container Registry 的漏洞扫描功能可帮助您解决此问题。启用后，此功能可识别容器映像的软件包漏洞。在将映像上传到 Container Registry 时以及漏洞数据库有更新时，系统都会扫描映像。您可以通过以下几种方式处理此功能报告的信息：

创建一个类似 cron 的作业，该作业会列出漏洞并触发漏洞修复过程（如果存在修补程序），
检测到漏洞后，使用 Cloud Pub/Sub 集成来触发组织使用的修补过程。

我们建议自动执行修补过程，并依赖最初用于构建映像的现有持续集成流水线。如果您对持续部署流水线有信心，则可能还想要在准备就绪时自动部署已修复的映像。但是，大多数人更喜欢在部署之前执行手动验证步骤。可通过以下过程实现此目标：

将映像存储在 Container Registry 中并启用漏洞扫描。
配置一个作业，该作业定期从 Container Registry 中获取新漏洞，并在需要时触发映像的重新构建。
构建新映像后，让持续部署系统将它们部署到暂存环境。
手动检查暂存环境是否存在问题。
如果未发现任何问题，手动触发到生产的部署。

注意：在撰写本文时，漏洞扫描适用于基于 Alpine、Debian、Ubuntu、Red Hat Enterprise Linux 和 CentOS 的映像。

正确标记映像

重要性：中

Docker 映像通常由两个部分标识：它们的名称和标记。例如，对于 google/cloud-sdk:193.0.0 映像，google/cloud-sdk 是其名称，193.0.0 是其标记。如果您未在 Docker 命令中提供标记，则系统默认使用 latest 标记。在任意给定时间，名称/标记对都是唯一的。但是，您可以根据需要将标记重新分配给其他映像。

构建映像时，是否正确标记映像取决于您。请遵循一致的标记策略。记录您的标记策略，以便映像用户能够轻松理解它。

容器映像是一种封装和发布软件片段的方式。通过标记映像，用户即可识别特定版本的软件，从而方便下载。因此，请将容器映像上的标记系统与软件的发布政策紧密关联。