这是我参与11月更文挑战的第6天，活动详情查看：2021最后一次更文挑战
说完代码阅读思路后，龙飞将时序图向右边滑了滑。
剩下的流程就是OP - Operation如何构建的过程，这里的OP，指的是由Dockerfile解析过后，需要执行的操作。
比如：FRAOM UBUNTU:14.04，这个会被理解为Source OP；而RUN ls则为被解析成Exec OP。
不过具体怎么实现的数据转换，我还没来得急花时间整理。
先说source ops
source
可以理解为解析到了关键字FROM，可以想像的是，为了高效完成伤。
我们需要缓存，如果缓存命中，那就可以直接使用，如果没有，就需要从远端去取。
这里的对应的是source manager和Puller。
前者就是资源管理器，里面会用cacheKey对资源进行索引，如果没有缓存，就需要通过pull，去取镜像的Manifest制品清单信息，那这个又要说到Image Bundle了，后面我们可以参考OCI相应的说明。
Puller
因为制品清单里很多信息，并且都是可以并行执行的，所以buildkit直接用的是containerd的拉取器，并没有所有的轮子都自己造。
这些执行完后solver会调用exporter，通过cm.Differ缓存管理器的differ，取差集，最终生成变更后的layer。
最后会调用client.Response，返回请求结果。
这差不多就是完整的流程了。
全流程
简单来回顾一下：
- 用户调用
buildctl命令行，运行build命令，并传入解析好的Dockerfile，这里并不是Dockerfile的字符流，而是解析过后的llb.Definition - 客户端
client会用solver向buildkitd守护进程发送grpc网络请求 - 守护进程需要提前启动，以做好为网络请求提供服务的准备
control是真正的服务组织者，会提前初始化好所需要对象，像worker，exporter，等等solver是真正的重点所在，需要高效运行构建任务，那需要考虑如何编排任务，设置好缓存策略- 在
scheduler的协调下，最后面向一个个的operation，进行具体的任务执行，其中source op是而向资源的，目的就是准备好资源；而exec op，则是负责具体执行任务的 - 最终将所有操作处理的结果取差异，生成layer，计算
blob chain块链索引后，进行持久化 - 返回请求
response响应
一口气说完后，龙飞吸了口气，好像刚才耗费了大量的体力。 然后习惯性的问了句：大家还有什么问题吗？
袁小白，脑子还在抓紧运行中，没来得急想还有什么问题。
到是贾大智的声音响了起来。
讲的不错，我有两个问题：
- 一个
OP到哪一步执行完的？比如source op，这里只看到了puller下载所需的bundle资源文件，但没看到下载完后干了什么？ buildkit这个新工具的业务价值是什么？为什么要重新写一个呢？
第一个问题到是和技术相关，龙飞想了想，确实这一部分在时序图里没有呈现出来，不过接下来可以花时间了解下。 这第二个问题到是没想过，不过应该是什么大问题。 龙飞把自己对于这两个问题的想法说了出来，大家也都觉得这两块可以花时间再研究一下。
袁小白到是不觉得这两个是什么大问题，已经很厉害了吧！
我也找到些关于架构的资料。 当袁步白就贾大智的不尽人情嘟囔时，贾大智的声音响了起来。
下一篇：深入理解Moby Buildkit系列 #7 - 用户价值驱动架构设计
知识点
用来记录一些出现的知识点，以后会把这些知识点展开来介绍。
- OCI
- Image Manifest
- Containerd
