牢记 10 个容器化最佳实践

容器化的使命是提高可用性，但这很少发生在容器身上。当您想到用户友好的应用程序时，加倍努力符合每个人的最大利益。您可以通过以下 10 件事来创建和维护用户友好的容器化应用程序。

#1：隔离构建和运行时依赖
多阶段构建与否，不要将构建时间依赖项放入运行时：通过减少对有恶意意图在容器中使用和利用的实体的放弃来缩小攻击面。这种方法符合以 distroless 镜像为代表的最佳实践，同时也有人认为没有依赖的镜像并不比依赖丰富的镜像安全。

#2：为工作选择合适的图像
请记住，当您想要使用的图像适合您的确切用例时。有一些通用的、事实上的图像可能在任何给定场景中都有帮助，但一般的经验法则是检查图像大小和基本行为。几个例子：

scratch： scratch 是一个空图像，您可以使用它来创建新图像。它没有任何文件或文件夹，您所能做的就是调用 FROM scratch 命令向其中添加文件等。如果某物具有绝对零依赖性，则效果最佳。
busybox：这个轻量级镜像有超过 200 个可定制的实用程序，它是嵌入式 Linux 自称的瑞士军刀。
alpine：轻量级 Linux 发行版，您可以将其想象成类固醇上的 busybox，因为它实际上是围绕它构建的。随着周围社区的不断壮大，alpine 注定会成为最受欢迎的发行版之一，因为它只有 5 兆字节，而且速度快如闪电，而且非常注重安全性。重要提示：它比 glibc 更复杂。
debian：多功能 Linux 发行版，由于具有 apt 功能，它提供了功能丰富的包管理。它是最早可追溯到 1993 年的免费开源项目之一，这使得它不可避免地成为比 Alpine 更成熟的 Linux 发行版。
高山还是 Debian？
Alpine 更适合作为容器在资源受限的情况下使用，而 Debian 的软件包速度稍慢，但它也提供了更多功能并且得到了更多支持（systemd、glibc）。

#3：逻辑组织缓存层
Dockerfile 中的每个 Docker 构建指令都会生成一个新层，这些层会被存储，因此会被缓存。为了节省时间，从静态指令开始，转向动态指令。例如，复制已编译的应用程序通常应该是最后一步。

#4：确保你有可重现的构建
可重现的构建对于实现图像的一致行为很重要。它将允许您验证二进制文件的来源，更快地解决发生的问题，使您能够在给定规格的情况下获得相同的输出。

#5：一个进程，一个容器
一般来说，这是正确的做法。将进程彼此分离是降低堆栈复杂性的最简单方法。隔离一个进程可以消除干扰其他进程的风险，可以更轻松地升级，有助于构建和测试。单一关注容器也为一般用途铺平了道路，它可以作为构建块。如果您需要其他实用程序进程，请查看边车模式。

#6：在没有 root 的情况下运行容器
除非您更改容器运行时的默认行为并部署它们，否则它们将以根用户身份运行。大多数时候容器不需要 root 权限。这是一个不必要的漏洞因素，因为如果有人利用它，您之前设置的权限将对他们毫无用处，因为 root 权限将使他们能够按照自己的意愿行事，获得给定机器的完全所有权。这就像将钥匙扣挂在屋外一样。

Podman 和 OpenShift 是无根运行容器的可行解决方案，但 Docker 也支持无根运行时。此外，如果您需要以 root 权限运行它，您可以在不使用主机的 root 用户的情况下执行此操作。

精心设计的容器默认是非根的。

#7：添加默认公开端口
默认情况下具有公开端口的容器更易于使用，因为它们很少单独使用。当容器的创建者定义公开的端口时，用户不必特意为自己配置它，当容器使用 docker 启动时，它会公开这些端口。

使用EXPOSE使容器监听其本地环境，您还可以配置协议是 TCP 还是 UDP。使用时默认为 TCP。

#8: 定义 ENTRYPOINT 和 CMD
ENTRYPOINT并且CMD在专为可用性而设计的容器中是不可或缺的。没有上下文的用户将无法理解容器的行为，因此必须设置有助于提高可用性的约束。

#9：添加 OCI 注释
通过在 Dockerfile 中使用 LABEL 指令添加注释，您可以为容器的用户提供额外的信息。这些注释可以帮助容器的可用性或验证。OCI 标准预定义了一堆注释，但我们建议使用来源、许可、修订、供应商和标题。

#10：经常进行安全分析
如果存在漏洞，您可以评估您是否有受影响的代码段以及它是否在您的应用程序中使用。漏洞可能很严重，并且当您的容器中有库时，代码永远不会调用受影响的部分。

您可以使用静态图像分析器，例如Trivy、Anchore Engine或Quay Container Security Operator。

关注我的博客，您将在其中获得提示、技巧和挑战，以保持您的技能敏锐。记得关注我哦！