This is the 12th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

Longfei seems to have a hunch that Yuan xiaofai will find new doubts again, because Longfei himself, after combing with Yuan xiaofai last time, also feels that some details were missed in the first combing, and with these new lines, Longfei rearranges Frontends Flow:

Yuan Xiaobai saw this picture, as if the brain is wandering around the information, all of a sudden to find their own position, independence has an obvious law.

Seeing That Yuan Xiaobai’s eyes were attracted by Frontend Flow, Long Fei began to say.

The parse process is indeed a bit convoluted, with a single solve occurring eight times, which raises some questions: Do solve all mean the same thing in different objects, buildCTL, client, control, solver, etc., do solve all mean the same thing in different objects? But don’t worry, let’s go through the process again and see what the author is trying to say.

  • The user invokes the command linebuildctl build --frontend dockerfile.v0 --local dockerfile ...This is the trigger point for the whole process, where we start parsing the user’s build requirements, which are expressed in the format of a Dockerfile
  • Since it is a C/S(Client /server) structure, on the client side, we need to have oneclientTo handle network requests
  • A more precise client may be needed, so a controlClient is needed to send resolution requests
  • Finally, you can parse requests, needs to be sent here is GRPC request – moby. Buildkit. V1. Control/Solve
  • Once the front end sends the request, the back end takes care of the rest, which needs to be well prepared to handle the parse request. For example, frontends instances need to be prepared, since many different frontends need to be supported, and Dockerfile is only one of the frontends, which is a parent and needs to be supported. Secondly, in order to uniformly manage the registration and management of GRPC, what control needs to care about here is to provide corresponding method functions. GRPC service related to controller.Register, such as URL matching, and GRPC service related Settings are prepared in advance. Because of this preparation, Control successfully receives the parse request from the front end.
  • To parse properly, Solver needs to associate frontend that actually provides the parse service, so it needs a Bridge
  • The bridge cannot parse by itself. It needs to find real frontend instances, such as frontend [“dockerfile.v0”], which is the build method provided by the dockerfile in frontend. Note here that although llbbridge-solve is called in both cases, the code branch is different in both cases:

In the first REQ, the character frontend type is passed, and in the second req, the parsed dockerfile has req.Definition, and the parsed Dockerfile information is encapsulated by ResultProxy, only converted to Definition.

Here is also yuan Xiaobai don’t understand the place, why in dockerfile. Build, and there will be C. solve, finally found the answer here.

However, if we want to understand the logic of this more clearly, we need to tease out the formal transformation process of the data:

dockerfile -> Definition -> Edge

So next, we can go to understand dockerfile parsing, and data format conversion in LLB.

It seems that we are just beginning, the road is very long, Yuan Xiaobai deeply took a breath.

Next: First impressions of Moby Buildkit # 13-LLB in depth