这是我参与11月更文应战的第14天，活动概况检查：2021最终一次更文应战
找到这个用例examples/buildkit0/buildkit.go之后，袁小白精神为之一振，试了运转了一下测试，能够跑通：
main
func main() {
var opt buildOpt
flag.BoolVar(&opt.withContainerd, "with-containerd", true, "enable containerd worker")
flag.StringVar(&opt.containerd, "containerd", "v1.2.9", "containerd version")
flag.StringVar(&opt.runc, "runc", "v1.0.0-rc8", "runc version")
flag.Parse()
bk := buildkit(opt)
out := bk.Run(llb.Shlex("ls -l /bin")) // debug output
dt, err := out.Marshal(context.TODO(), llb.LinuxAmd64)
if err != nil {
panic(err)
}
llb.WriteTo(dt, os.Stdout)
}
- 首要设置参数，有布尔类型和字符类型，用来阐明用不用
containerd以及containerd和runc的版本信息。据袁小白所知，containerd是CNCF供给的容器运转管理东西，而runc则是容器运转时东西。 - 用配置选项opt初始化buildkit。
- 接着用初始化好的buildkit运转脚本指令
ls -l /bin，列出所有在/bin目录下的文件 - 以linux操作系统，amd64架构规范，整顿Marshal整个数据结构，并生成dt(Definition)
- 最终将成果输出到规范输出os.Stdout
goBuildBase
buildkit方法，依靠于goBuildBase，用来创立src，也便是源镜像
func goBuildBase() llb.State {
goAlpine := llb.Image("docker.io/library/golang:1.17-alpine")
return goAlpine.
AddEnv("PATH", "/usr/local/go/bin:"+system.DefaultPathEnvUnix).
AddEnv("GOPATH", "/go").
Run(llb.Shlex("apk add --no-cache g++ linux-headers")).
Run(llb.Shlex("apk add --no-cache git libseccomp-dev make")).Root()
}
- llb.Image创立goAlpine，创立一个镜像实例，并指明ref索引
- 在goAlpine镜像基础上，添加环境变量，及运转指令行装置相关的依靠 能够了解为创立一个设置好环境的golang基础容器
copy
buildkit里，相对复杂的操作便是copy操作：
func copy(src llb.State, srcPath string, dest llb.State, destPath string) llb.State {
cpImage := llb.Image("docker.io/library/alpine:latest")
cp := cpImage.Run(llb.Shlexf("cp -a /src%s /dest%s", srcPath, destPath))
cp.AddMount("/src", src)
return cp.AddMount("/dest", dest)
}
- 创立一个专门用来复制的基础镜像，完全不用装置什么依靠
- 运转操作，将源目录下的文件都复制到目标目录
- 挂载源目录
- 挂载目录目录，并回来挂载成果 入参里除了srcPath, destPath外，还有src, dest，并且都是llb.State类型，阐明copy操作能够在llb.State等级进行操作，假定src, dest不属于同一个镜像，那就意味着，我们能够用llb.State来表明不同镜像间的操作联系，那这将是现在的dockerfile做不到的。 看到这儿，袁小白忽然进一步了解了，buildkit的定位 – 未来的镜像构建东西。
runc
在看buildkit前，最终来看看其间的一个操作runc:
func runc(version string) llb.State {
return goBuildBase().
Run(llb.Shlex("git clone https://github.com/opencontainers/runc.git /go/src/github.com/opencontainers/runc")).
Dir("/go/src/github.com/opencontainers/runc").
Run(llb.Shlexf("git checkout -q %s", version)).
Run(llb.Shlex("go build -o /usr/bin/runc ./")).Root()
}
和上面的相似，根据golang基础镜像，下载runc源码，进入源码目录，切换到指定版本，最终构建runc可运转二进制文件，并输出到./当前目录下，回来root目录llb.State
buildkit
func buildkit(opt buildOpt) llb.State {
src := goBuildBase().
Run(llb.Shlex("git clone https://github.com/moby/buildkit.git /go/src/github.com/moby/buildkit")).
Dir("/go/src/github.com/moby/buildkit")
buildkitdOCIWorkerOnly := src.
Run(llb.Shlex("go build -o /bin/buildkitd.oci_only -tags no_containerd_worker ./cmd/buildkitd"))
buildkitd := src.
Run(llb.Shlex("go build -o /bin/buildkitd ./cmd/buildkitd"))
buildctl := src.
Run(llb.Shlex("go build -o /bin/buildctl ./cmd/buildctl"))
r := llb.Image("docker.io/library/alpine:latest")
r = copy(buildctl.Root(), "/bin/buildctl", r, "/bin/")
r = copy(runc(opt.runc), "/usr/bin/runc", r, "/bin/")
if opt.withContainerd {
...
} else {
r = copy(buildkitdOCIWorkerOnly.Root(), "/bin/buildkitd.oci_only", r, "/bin/")
}
return r
}
- 创立buildkit源golang环境镜像，
git clonebuildkit源码，并进入到源码目录 - 根据源构建buildkitd.oci_only二进制文件
- 根据源构建buildkitd二进制文件
- 根据源构建buildctl二进制文件
- 创立一个空的镜像
- 将buildctl二进制文件，从上面复制到这个新创立的镜像/bin/目录下
- 将runc二进制文件，从上面复制到/bin目录下
- 假定我们没有设置containerd，那接下来的操作便是将buildkitd.oci_only二进制文件，复制到/bin目录下
那最终当我们进行ls -l /bin脚本时，显现的成果里就有buildctl, runc, buildkitd.oci_only这三个文件了。
可是从最上面的输出来看，如同并不是运转完后的成果，更像是中间进程，也便是Definition。 全体来看，我能够用一个镜像来构建buildkit全家桶 – buildctl, buildkitd, buildkitd.oci_only。 然后用一个镜像来预备runc指令行东西。 并用一个全新的镜像来履行copy操作。 最终用一个干净的镜像来持有所有创立好的东西。
这下袁小白的好奇心算是彻底地被勾了起来：
- LLB是怎样把这些构建联系给组织起来的呢？
- llb.State是怎样作业的呢？
- 如果只是中间状况，那这个Definition和llb.State的联系又是什么呢？Definition是最终状况吗？
- 这儿面有一些过程能够同时运转，那如何高效的履行这些操作，和理清这些依靠呢？
袁小白越想越兴奋 – LLB用起来还挺简略的，一看就明白，可完成起来，如同还真不简略！
