This is the third day of my participation in the November Gwen Challenge. Check out the details: the last Gwen Challenge 2021
Long Fei will be the main process, timing diagram to share on TV, can’t wait to speak up.
According to our Happy Path(which is the ideal workflow), we need to focus on the mirror build process first, which is the grey module we can leave out.
That’s the main thread I’ve been focusing on over the past week. I went straight to the P source on GitHub and dove in. Not to mention, the first README image is the main thread I need to focus on:
As you can see from the first line, the usage is simple: pipe the content generated by./example to buildctl build to fetch the image from the remote end and start building it.
This leads me to the buildctl command line. He opened the command line terminal and showed us the location of the code:
Then I began to draw the sequence diagram step by step, starting from the command line:
buildctl
The command line, of course, is the original, using a third-party library, I haven’t rushed to see the details, but it looks very convenient to use
build
Buildkit build registers entry functions with the command line framework, which will be called when the command is triggered. It does several things:
- Get client instance – client, if I remember correctly, a GRPC client
- Parsing configuration parameters, from the point of view of the code, can specify the form of output, such as tar package; You can also specify whether to push the built image to the remote Registry
- Get the cache configuration parameter. I’m not sure what the cache is for, so I’ll skip it
- Stdin reads llb.Definition from stdin. This LLB is similar to the internal data structure of a Dockerfile that has been parsed
./exampleThe output of a shell script - Finally, with the created client, call the client.solve method to initiate the connection
client
Provide a variety of clients, such as HTTP, GRPC, we use GRPC here. The client then initiates the connection request.
solve
The main thing this file does is initiate the actual connection. In the process of running the session, GRPC hijack is also carried out, probably to change the stateless connection into a long connection, probably for the sake of interaction, for example, the standard output generated during the container running needs to be sent back to the client for display. This is just my guess, and has not been verified. Finally, resolve – controller.solve by calling the controller provided by the Buildkitd headguard process
After one breath say that finish, pause meeting, looked at Yuan Xiaobai and Jia Dazhi, ask a way: so far, have any problem? They don’t seem to react. With that said, I’m ready to move on to the next part – buildkitd daemon.
knowledge
Used to record some knowledge points, the knowledge points will be introduced later.
- grpc
- hijack