无需Dockerfile和守护进程的构建方法

无需 Dockerfile 或 Docker 守护程序即可构建 Docker 镜像

这张照片是由 Guillaume Bolduc 拍摄的，图片来自 Unsplash。

在不断演进的软件开发领域中，效率和自动化是成功的关键驱动因素。传统的Docker镜像构建通常需要安装Docker守护进程，这一过程，可能既繁琐又受限，特别是在持续集成和持续交付（CI/CD）管道中，敏捷性和隔离性尤为重要。这可以消除对Docker守护进程甚至Dockerfile的需求，简化了镜像构建过程。本文将探讨诸如Buildpack和Kaniko这些工具，比较它们的功能和需求，并展示如何利用这些工具简化您的CI/CD工作流，从而提高您的开发效率。

构建 Docker 镜像通常需要在你的机器上安装 Docker 守护进程，然后用它来从你的项目中构建 Docker 镜像。然而，在一些情况下，比如 CI 管道，提供 Docker 守护进程有点困难，因为 Docker 在 Linux 机器上需要以特权用户身份运行，这可能降低构建 Docker 镜像的灵活性。一些项目，例如 Buildpack 和 Kaniko，尝试解决这个问题，让构建 Docker 镜像的过程更简单。

如果你想要为你的项目创建一个 Docker 镜像，你需要写一个 Dockerfile。然而，逐个编写 Dockerfile 非常耗时且费力。相反，你可以使用 Buildpack，它可以帮你摆脱编写 Dockerfile 的麻烦。Buildpack 可以自动检测你的项目的编程语言（如 Java、JavaScript、Go、Ruby 等），以及所需的构建工具，并自动为项目生成构建指令并生成镜像。如需深入了解 Buildpack 的运作方式，可以看看我的其他博客文章。

      工具/需求项       │ Dockerfile │ Docker 守护进程    
     ─────────────────┼────────────┼───────────────   
      Docker BuildKit │     支持    │     支持              
     ─────────────────┼────────────┼───────────────   
      Kaniko          │     支持    │     不支持               
     ─────────────────┼────────────┼───────────────   
      Buildpack       │     不支持  │     不支持             

如上所示，我将 Buildpack 与 Kaniko 和 Docker Buildkit 进行了比较。这只是对这些工具构建需求的一个简单的对比。正如您所见，Buildpack 可以在没有 Dockerfile 或 Docker 守护进程的情况下构建 Docker 镜像，而 Kaniko 至少需要 Dockerfile。Docker Buildkit 是创建 Docker 镜像的最传统的方式，需要 Dockerfile 和 Docker 守护进程来构建您的项目所需的 Docker 镜像。

你可以使用 Buildpack 构建器镜像来从你的项目中构建 Docker 镜像，而无需编写 Dockerfile 或与 Docker 守护进程打交道，这在 CI/CD 管道中很常见。假设我想要为下面这个项目构建一个 Docker 镜像，这是一个简单的 Spring Boot 应用程序，没有 Dockerfile：

我在那个项目中使用了GitLab，这是我最喜欢用来构建工作流的工具。这是构建Docker镜像的代码。

    变量定义:  
      IMAGE_URL: mlkmhd/test-buildpack  
      BP_JVM_VERSION: 17  

    阶段定义:  
      - build  

    构建阶段:  
      阶段: build  
      镜像: paketobuildpacks/builder:full  
      脚本: |  
        :set -xe  
        mkdir ~/.docker  
        cp ${DOCKER_AUTH_CONFIG} ~/.docker/config.json  

        /cnb/lifecycle/creator \\\\  
          -app=${PWD} \\\\  
          -uid=1000 \\\\  
          -gid=1000 \\\\  
          -platform=/platform \\\\  
          -process-type=web \\\\  
          -skip-restore=true \\\\  
          -previous-image=${IMAGE_URL} \\\\  
          ${IMAGE_URL}

如上所示的管道中，我有一个名为 build_image （build_image 阶段），它使用这个镜像 paketobuildpacks/builder 来构建该项目的 Docker 镜像文件。以下是该管道执行后的输出：

    ++ /cnb/lifecycle/creator -app=/builds/mallakimahdi/test-buildpack -uid=1000 -gid=1000 -platform=/platform -process-type=web -skip-restore=true -previous-image=mlkmhd/test-buildpack mlkmhd/test-buildpack  
    ...  
    ===> 检测  
    26个构建包中有10个参与  
    paketo-buildpacks/ca-certificates   3.6.3  
    paketo-buildpacks/bellsoft-liberica 10.2.6  
    paketo-buildpacks/syft              1.32.1  
    paketo-buildpacks/gradle            7.3.0  
    paketo-buildpacks/executable-jar    6.7.4  
    paketo-buildpacks/apache-tomcat     7.13.7  
    paketo-buildpacks/apache-tomee      1.7.4  
    paketo-buildpacks/liberty           3.8.2  
    paketo-buildpacks/dist-zip          5.6.4  
    paketo-buildpacks/spring-boot       5.26.1  
    ===> 分析  
    未找到名为 "mlkmhd/test-buildpack" 的镜像  
    跳过构建包层分析  
    ===> 构建  
    Paketo CA 证书构建包版本 3.6.3  
      https://github.com/paketo-buildpacks/ca-certificates  
      启动辅助程序：贡献于层  
        创建 /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper 文件  
    Paketo BellSoft Liberica 构建包版本 10.2.6  
      https://github.com/paketo-buildpacks/bellsoft-liberica  
      构建配置：  
        $BP_JVM_JLINK_ARGS           --no-man-pages --no-header-files --strip-debug --compress=1  配置自定义链接参数 (--output 必须省略)  
        $BP_JVM_JLINK_ENABLED        false                                                        启用运行 jlink 工具以生成自定义 JRE  
        $BP_JVM_TYPE                 JRE                                                          指定 JVM 类型 - JDK 或 JRE  
        $BP_JVM_VERSION              17                                                           指定 Java 版本  
      启动配置：  
        $BPL_DEBUG_ENABLED           false                                                        启用 Java 远程调试支持  
        $BPL_DEBUG_PORT              8000                                                         配置远程调试端口  
        $BPL_DEBUG_SUSPEND           false                                                        配置是否在调试器连接后挂起执行  
        $BPL_HEAP_DUMP_PATH                                                                       在发生错误时将堆转储写入此路径  
        $BPL_JAVA_NMT_ENABLED        true                                                         启用 Java 本地内存跟踪 (NMT)  
        $BPL_JAVA_NMT_LEVEL          summary                                                      配置 NMT 级别，summary 或 detail  
        $BPL_JFR_ARGS                                                                             配置自定义 Java 飞行记录 (JFR) 参数  
        $BPL_JFR_ENABLED             false                                                        启用 Java 飞行记录 (JFR)  
        $BPL_JMX_ENABLED             false                                                        启用 Java 管理扩展 (JMX)  
        $BPL_JMX_PORT                5000                                                         配置 JMX 端口  
        $BPL_JVM_HEAD_ROOM           0                                                            内存计算中的预留空间  
        $BPL_JVM_LOADED_CLASS_COUNT  35% of classes                                               内存计算中的类数量占35%  
        $BPL_JVM_THREAD_COUNT        250                                                          内存计算中的线程数量  
        $JAVA_TOOL_OPTIONS                                                                        JVM 启动标志  
        使用默认的 Java 版本 17  
    ...  
    ===> 导出  
    ...  
    保存 mlkmhd/test-buildpack...

可以看到，Buildpack 自动识别了我的项目和构建工具 gradle，并成功构建了它。

• 细粒度自定义：如果你的项目需要高度可定制的容器构建，比如调整 Dockerfile 中的特定步骤，或者进行性能和安全性的精确优化，Buildpacks 可能无法提供你所需的这种细粒度控制。
• 安全性：对于具有严格安全策略的组织，如需要扫描和固定特定版本的依赖项，或对构建过程进行细粒度的控制，Buildpacks 可能会增加攻击面，并且可能无法达到严格的安全标准。

大规模微服务：如果你正在管理大量的微服务（比如100个以上），并且手动维护Dockerfile变得越来越繁琐，那么可以使用Buildpacks来完全省去Dockerfile。

简化开发人员的体验：如果目标是减少开发者需要处理的复杂性，并尽量减少他们学习Docker相关语法的需求，那么构建包（Buildpacks）就可以大大减少这种复杂性。

频繁的更新：在需要频繁更新的情况下（例如升级基础镜像或依赖如JDK），Buildpacks 可以自动跨多个服务进行更新，而无需手动更改 Dockerfile。

总之，像 Buildpack 和 Kaniko 这样的 Docker 镜像构建工具的发展历程为希望优化其 CI/CD 管道流程的开发人员提供了显著的优势。通过消除对 Docker 守护进程甚至 Dockerfile 的需求，这些工具不仅简化了构建过程，还增强了在孤立环境中的安全性和灵活性。自动检测项目依赖项和构建配置的能力，简化了工作流程，使团队能够更多地专注于编码，而减少对基础设施管理的关注。如上所述的，利用这些现代工具可以导致更高效、可扩展和可维护的软件开发方式。

欢迎你有任何反馈和建议帮助改进我的代码，请在此帖子下留言或在我的LinkedIn上留言。