深入理解Moby Buildkit

SourceOp构建完后，就轮到了ExecOp。 现在所有的Op都执行完了，也就是我们的Edge都得到了遍历。 还记得我们从哪儿来的吗？ 让我们一起来回顾一下。 没错，jobs收到构建请求后...

通过传入的inputs，execOp可以准备好镜像索引refs，并准备好挂载点，并得到挂载好的PreparedMounts。 准备好后，我们就可以开始运行这个操作了： 剩下的执行逻辑就不复杂了...

SourceOp执行完毕后，会触发ExecOp同样的操作，一个是CacheMap，另一个则是Exec。 ExecOp CacheMap 相对SourceOp的CacheMap，ExecOp的相对简单

带着镜像基础信息准备好后，又将要用来做什么的问题。 袁小白重新回到edge.go的unpark函数里，看到了接下来的动作： 顺着代码就找到了接下来需要发生的操作：e.execReq...

要想理解递归，除了抽象出同样的行为外，再就是找到循环的出口。 在上一次梳理的结果中可以看到，Edge1是递归的最后一个edge，在edge中，由于SourceOp的inputs为空...

scheduler.build 现在有两个Edge，Scheduler会怎么编排任务呢？ Scheduler开始构建的地方： 可以看到，最先获取edge，然后创建EdgePipe来处理Edge...

为了理解龙飞讲解的scheduler，袁小白先是去了解了pipe的使用方法和设计原理，现在回忆起来，有以下特点： pipe由sender和receiver组成...

袁小白也看过类似的设计模式，如pipe。 大体的思路就是抽象出运行操作的环境，有输入，有输出。 将操作的执行有序的衔接起来。 如果想要做得灵活一点，输入和输出可以不用统一，甚至可以自定义...

龙飞介绍完scheduler后，袁小白感觉是懂非懂。 说懂呢，因为大概了解到scheduler是如何将edge进行构建的，是如何拆解的，等等。 但要说到底是如何工作的，却又理不清，道不明...

果然不出袁小白所料，这scheduler还真不简单 - 因为没看懂，自己琢磨了一个星期，愣是没弄明白调度器是scheduler是怎么调度的。 没耐住性子，又求助了龙飞。 龙飞一如既往的没有让袁小白失望

从龙飞给出的buildctl build全景时序图中可以了解到： Worker是用来真正运行容器的，那jobs的定位又是什么呢？

为了加强自己的理解，袁小白像以往一样，梳理了下流程图： solver接受到请求后，在Solve方法中调用Bridge的Solve方法，开始解析 在bridge中调用Frontend进行解析...

梳理完State - Definition - Edge，已经过去将近一个月了。 袁小白感觉实现纯手工打造，24K容器化运行生态，是越来越有信心了！ 可话说回来。 我们看到哪儿了？

梳理完了数据三剑客中的State和Definition后，现在就差Edge了。 袁小白找回到代码之前读到的位置：client/llb/llbtest/platform_test.go

袁小白开开心心的在例会上分享了关于llb.State和Definition的理解。 得到了龙飞和贾大智的一致好评。 能在短短的时间里掌握到关健的数据结构用法，确实是件了不起的事情。

袁小白听贾大智提到过，读文章可以沿着文章的主线来读。 代码也一样，也有自己的脉络，其中一种方法就是按数据的流向来理解源码。 到目前为止，那就从buildctl build来看...

为了更好的理解作者的意图，袁小白决定把看过的代码，结合状态图再梳理一遍： llb.Image("foo") 因为我们只是传入了一个image ref，并没有其它的任何参数，代码可以简化为...

回想起因为dockerfile.Build里如何使用llb的场景： 袁小白想着，对llb有了大概的理解后，如何找到一个难度适宜的例子，对llb.State进行学习呢。 经过一番查找，真是黄天不负有心人

找到这个用例examples/buildkit0/buildkit.go之后，袁小白精神为之一振，试了运行了一下测试，可以跑通： 虽然从结果来看，好像没有太多信息，但这说明可以借助一些日志信息帮助理解

转眼一周就过去了，周五的例会上袁小白分享了这一周的曲折经历，和对代码结构的理解。 龙飞也进行了补充。 贾大智看到大家的热情，对两人赞不绝口。 但没有太多关于代码的更新，这让袁小白心生不满...