过去的工作中,我们使用微服务、容器化以及服务编排构建了技术平台。为了提升开发团队的研发效率,我们同时还提供了 CICD 平台,用来将代码快速的部署到 Openshift(企业级的 Kubernetes) 集群。
部署的第一步就是应用程序的容器化,持续集成的交付物从以往的 jar 包、webpack 等变成了容器镜像。容器化将软件代码和所需的所有组件(库、框架、运行环境)打包到一起,进而可以在任何环境任何基础架构上一致地运行,并与其他应用“隔离”。
我们的代码需要从源码到编译到最终可运行的镜像,甚至部署,这一切在 CICD 的流水线中完成。最初,我们在每个代码仓库中都加入了三个文件,也通过项目生成器(类似 Spring Initializer)在新项目中注入:
- Jenkinsfile.groovy:用来定义 Jenkins 的 Pipeline,针对不同的语言还会有多种版本
- Manifest YAML:用于定义 Kubernetes 资源,也就是工作负载及其运行的相关描述
- Dockerfile:用于构建对象
这个三个文件也需要在工作中不断的演进,起初项目较少(十几个)的时候我们基础团队还可以去各个代码仓库去维护升级。随着项目爆发式的增长,维护的成本越来越高。我们对 CICD 平台进行了迭代,将“Jenkinsfile.groovy”和 “manifest YAML”从项目中移出,变更较少的 Dockerfile 就保留了下来。
随着平台的演进,我们需要考虑将这唯一的“钉子户” Dockerfile 与代码解耦,必要的时候也需要对 Dockerfile 进行升级。因此调研了一下 buildpacks,就有了今天的这篇文章。
什么是 Dockerfile
Docker 通过读取 Dockerfile 中的说明自动构建镜像。Dockerfile 是一个文本文件,包含了由 Docker 可以执行用于构建镜像的指令。我们拿之前用于测试 Tekton 的 Java 项目的 Dockerfile 为例:
1 | dockerfile复制代码FROM openjdk:8-jdk-alpine |
镜像分层
你可能会听过 Docker 镜像包含了多个层。每个层与 Dockerfile 中的每个命令对应,比如 RUN、COPY、ADD。某些特定的指令会创建一个新的层,在镜像构建过程中,假如某些层没有发生变化,就会从缓存中获取。
在下面的 Buildpack 中也同样通过镜像分层和 cache 来加速镜像的构建。
什么是 Buildpack
BuildPack 是一个程序,它能将源代码转换成容器镜像的并可以在任意云环境中运行。通常 buildpack 封装了单一语言的生态工具链。适用于 Java、Ruby、Go、NodeJs、Python 等。
Builder 是什么?
一些 buildpacks 按顺序组合之后就是 builder,除了 buildpacks, builder 中还加入了 生命周期 和 stack 容器镜像。
stack 容器镜像由两个镜像组成:用于运行 buildpack 的镜像 build image,以及构建应用镜像的基础镜像 run image。如上图,就是 builder 中的运行环境。
Buildpack 的工作方式
每个 buildpack 运行时都包含了两个阶段:
1. 检测阶段
通过检查源代码中的某些特定文件/数据,来判断当前 buildpack 是否适用。如果适用,就会进入构建阶段;否则就会退出。比如:
- Java maven 的 buildpack 会检查源码中是否有
pom.xml - Python 的 buildpack 会检查源码中是否有
requirements.txt或者setup.py文件 - Node buildpack 会查找
package-lock.json文件。
2. 构建阶段
在构建阶段会进行如下操作:
- 设置构建环境和运行时环境
- 下载依赖并编译源码(假如需要的话)
- 设置正确的 entrypoint 和启动脚本。
比如:
- Java maven buildpack 在检查到有
pom.xml文件之后,会执行mvn clean install -DskipTests - Python buildpack 检查到有
requrements.txt之后,会执行pip install -r requrements.txt - Node build pack 检查到有
package-lock.json后执行npm install
BuildPack 上手
那到底如何在没有 Dockerfile 的情况下使用 builderpack 构建镜像的。看了上面这些,大家基本上也都能了解到这个核心就在 buildpack 的编写和使用的。
其实现在有很多开源的 buildpack 可以用,没有特定定制的情况下无需自己手动编写。比如下面的几个大厂开源并维护的 Buildpacks:
但是正式详细介绍开源的 buildpacks 之前,我们还是通过自己创建 buildpack 的方式来深入了解 Buildpacks 的工作方式。测试项目呢,我们还是用测试 Tekton 的 Java 项目。
下面所有的内容都提交到了 Github 上,可以访问:github.com/addozhang/b… 获取相关代码。
最终的目录buildpacks-sample 结构如下:
1 | arduino复制代码├── builders |
创建 buildpack
1 | shell复制代码pack buildpack new examples/maven \ |
看下生成的 buildpack-maven 目录:
1 | python复制代码buildpack-maven |
各个文件中都是默认的初试数据,并没有什么用处。需要添加些内容:
bin/detect:
1 | shell复制代码#!/usr/bin/env bash |
bin/build:
1 | shell复制代码#!/usr/bin/env bash |
buildpack.toml:
1 | shell复制代码api = "0.5" |
创建 stack
构建 Maven 项目,首选需要 Java 和 Maven 的环境,我们使用 maven:3.5.4-jdk-8-slim 作为 build image 的 base 镜像。应用的运行时需要 Java 环境即可,因此使用 openjdk:8-jdk-slim作为 run image 的 base 镜像。
在 stacks 目录中分别创建 build 和 run 两个目录:
build/Dockerfile
1 | dockerfile复制代码FROM maven:3.5.4-jdk-8-slim |
run/Dockerfile
1 | dockerfile复制代码FROM openjdk:8-jdk-slim |
然后使用如下命令构建出两个镜像:
1 | shell复制代码export STACK_ID=com.atbug.buildpacks.example.stacks.maven |
创建 Builder
有了 buildpack 和 stack 之后就是创建 Builder 了,首先创建 builder.toml 文件,并添加如下内容:
1 | toml复制代码[[buildpacks]] |
然后执行命令,注意这里我们使用了 --pull-policy if-not-present 参数,就不需要将 stack 的两个镜像推送到镜像仓库了:
1 | shell复制代码pack builder create example-builder:latest --config ./builder.toml --pull-policy if-not-present |
测试
有了 builder 之后,我们就可以使用创建好的 builder 来构建镜像了。
这里同样加上了 --pull-policy if-not-present 参数来使用本地的 builder 镜像:
1 | shell复制代码# 目录 buildpacks-sample 与 tekton-test 同级,并在 buildpacks-sample 中执行如下命令 |
如果看到类似如下内容,就说明镜像构建成功了(第一次构建镜像由于需要下载 maven 依赖耗时可能会比较久,后续就会很快,可以执行两次验证下):
1 | shell复制代码... |
启动容器,会看到 spring boot 应用正常启动:
1 | shell复制代码docker run --rm addozhang/tekton-test:latest |
总结
其实现在有很多开源的 buildpack 可以用,没有特定定制的情况下无需自己手动编写。比如下面的几个大厂开源并维护的 Buildpacks:
上面几个 buildpacks 库内容比较全面,实现上会有些许不同。比如 Heroku 的执行阶段使用 Shell 脚本,而 Paketo 使用 Golang。后者的扩展性较强,由 Cloud Foundry 基金会支持,并拥有由 VMware 赞助的全职核心开发团队。这些小型模块化的 buildpack,可以通过组合扩展使用不同的场景。
当然还是那句话,自己上手写一个会更容易理解 Buildpack 的工作方式。
本文转载自: 掘金