Docker 是一个流行的容器构建工具，但编写优化和安全的 Dockerfile 是一项挑战。本文介绍了 Cloud Native Buildpacks 的优点，它们消除了编写 Dockerfile 的需要，提供一致的体验、消除了依赖项管理并增强了可重用性。Buildpacks 支持多种语言，允许定制，但避免了不良做法。它们输出 OCI 映像，确保兼容性，简化了依赖项管理，并通过构建优化功能构建更小的映像。对于大规模基础设施，Buildpacks 提供了一个实用的替代方案，简化了容器构建并减少了技术债务。
Docker是构建容器的不二之选，但有一个问题：编写优化且安全的 Dockerfile 并大规模管理它们的库可能是一项真正的挑战。在本文中，我将解释为什么您可能希望使用 Cloud Native Buildpacks而不是Docker。
使用 Docker 的常见问题
当一个公司开始使用 Docker 时，通常会从一个简单的Dockerfile开始。然而，随着越来越多的项目需要使用 Dockerfile，经常会出现以下问题情况：
负责容器化应用程序的开发人员缺乏编写新 Dockerfile 的知识、时间或动力。因此，他们从其他项目复制并粘贴 Dockerfile。
复制的 Dockerfile 中的任何不良做法或安全漏洞都会被传播。
复制的 Dockerfile 可能针对特定堆栈进行了优化，导致新环境中的性能不佳。
每次需要将新应用程序容器化时，这种情况都会重复出现。虽然对于少数应用程序来说，这可能是可控的，但当处理数百个应用程序时，就会出现严重问题。这可能会导致严重的技术债务和安全漏洞。
Buildpacks 提供什么？
一致的体验
在平台工程时代（流程标准化至关重要），面向微服务的基础设施必须适应各种各样的堆栈。Buildpacks 提供了一种标准化方法来创建容器映像，只需一个命令即可将任何应用程序容器化。这个命令pack就是所需的一切（无需编写 Dockerfile 或其他配置文件）。
消除依赖管理
消除了对依赖项管理的担忧。Buildpacks 会自动检测、下载和安装必要的依赖项、库、框架和运行时环境。
可重用性
一个主要优势是可以使用由社区维护的可用于生产的构建包。来自 Google、Heroku、Broadcom/VMware 等公司的专家管理这些构建包映像，以确保您的容器映像针对每个堆栈进行了优化和明确保护。
对 Buildpacks 的误解
大约十年前，当 buildpack 首次被创建时，用户抱怨了一些限制。但大多数限制早已不复存在，所以让我来揭穿这些迷思。
误区一：仅限于少数几种编程语言
Buildpacks 支持所有现代编程语言。Google 、Heroku和开源Paketo Buildpacks项目等提供商支持多种语言，包括Java、Node.js、.NET Core、Go、Python、PHP、Ruby 和 Rust。
误区二：有限的定制
Cloud Foundry 维护者Tim Downey表示：“存在限制，但这是设计使然。” Buildpack 的“限制”将保护您免受不良做法的影响，例如以 root 身份运行容器或运行任意 Shell 命令。如果您需要解决方法，总有一种干净的方法可以做到。例如，如果您需要安装应用程序依赖项中未列出的软件包（例如安装某些 OS 实用程序），则可以使用 apt buildpack干净地执行此操作。
误区三：供应商锁定
Buildpacks 输出类似 Docker 的 OCI 映像，确保与任何托管平台或您的基础设施实现最大程度的兼容性。如果某个 Buildpack 供应商特定的优化对您不起作用，您可以轻松切换到其他提供商，例如开源的 Paketo Buildpacks，它们不依赖任何供应商。
误解四：依赖管理问题
Buildpacks 简化了依赖项管理。它们会自动跟踪和管理依赖项，为具有严格安全要求的复杂应用程序提供强大的方法。Buildpacks 甚至可以使用与构建映像相同的命令为您的容器映像生成软件物料清单 (SBOM)。
误区五：图片未优化
Buildpacks 的设计遵循最佳实践，旨在构建更快、更小的镜像。它们还提供高级功能，例如rebase 功能，该功能允许重建镜像的任何部分，而无需完全重建，而这在基于 Docker 的镜像/工作流中是不可用的。
不要浪费时间编写 Dockerfile：使用 Buildpacks
如果您的基础设施规模较小或只有一名开发人员，那么编写 Dockerfile 是正确的选择，但对于任何基础设施规模足够大的公司，您都应该认真考虑尝试 Cloud Native Buildpacks。学习曲线非常简单，从长远来看可以为您节省大量工作。
