Introduction
In this lab, you will learn how to use the docker buildx inspect command to view details about your Docker builder instances. You will start by inspecting the current builder instance, then learn how to specify a builder by name.
You will also explore how to ensure a builder is running before inspection using the --bootstrap flag and how to obtain more detailed information with the --debug flag, gaining a comprehensive understanding of your builder's configuration and status.
Inspect the current builder instance
In this step, you will learn how to inspect the current Docker builder instance. The Docker builder is responsible for building Docker images. By inspecting the builder, you can get information about its configuration and status.
First, let's use the docker buildx inspect command without specifying a builder name. This will inspect the current builder instance.
docker buildx inspect
You should see output similar to this, showing details about the default builder instance:
Name: default
Driver: docker
Nodes:
default:
Status: running
Buildkitd:
Version: v0.10.5
Platforms:
- linux/amd64
- linux/arm64
- linux/riscv64
- linux/ppc64le
- linux/s390x
- linux/386
- linux/arm/v7
- linux/arm/v6
The output provides information such as the builder's name, the driver it uses (in this case, docker), and details about the build nodes, including their status, BuildKitd version, and supported platforms.
Inspect a specific builder instance by name
In the previous step, you inspected the current builder instance. In this step, you will learn how to inspect a specific builder instance by its name. While you might only have the default builder initially, knowing how to specify a name is useful when you have multiple builders configured.
To inspect a specific builder instance, you use the docker buildx inspect command followed by the name of the builder. The default builder is typically named default.
Let's inspect the default builder explicitly by name:
docker buildx inspect default
You should see the same output as in the previous step, confirming that you are inspecting the default builder instance.
Name: default
Driver: docker
Nodes:
default:
Status: running
Buildkitd:
Version: v0.10.5
Platforms:
- linux/amd64
- linux/arm64
- linux/riscv64
- linux/ppc64le
- linux/s390x
- linux/386
- linux/arm/v7
- linux/arm/v6
This demonstrates how to target a specific builder instance for inspection using its name.
Ensure builder is running before inspecting with --bootstrap
In this step, you will learn how to use the --bootstrap flag with docker buildx inspect. The --bootstrap flag ensures that the builder instance is running before attempting to inspect it. If the builder is not running, this flag will start it.
While the default builder is usually running, it's good practice to use --bootstrap when you want to guarantee the builder is active before inspection or other build operations.
Let's inspect the default builder again, this time using the --bootstrap flag:
docker buildx inspect --bootstrap default
You should see the same inspection output as before. The --bootstrap flag ensures that the builder is in a running state before the inspection is performed. If the builder had been stopped, this command would have started it first.
Name: default
Driver: docker
Nodes:
default:
Status: running
Buildkitd:
Version: v0.10.5
Platforms:
- linux/amd64
- linux/arm64
- linux/riscv64
- linux/ppc64le
- linux/s390x
- linux/386
- linux/arm/v7
- linux/arm/v6
Using --bootstrap is particularly useful in scripting or automated workflows where you need to ensure the builder is ready before proceeding with a build.
View detailed information with --debug
In this final step, you will learn how to get more detailed information about a builder instance by using the --debug flag with docker buildx inspect. The --debug flag provides additional output that can be helpful for troubleshooting or understanding the builder's configuration in more depth.
Let's inspect the default builder again, this time including the --debug flag:
docker buildx inspect --debug default
You will see the standard inspection output, but it will be preceded by debug logs. These logs provide insights into the internal operations of the buildx inspect command and the communication with the BuildKit daemon.
The debug output will include lines starting with DEBU[... followed by detailed information about the process. This can include things like API calls being made, configuration loading, and other internal workings.
DEBU[0000] loading config file /home/labex/.docker/config.json
DEBU[0000] Looking for builder "default"
DEBU[0000] found builder "default"
DEBU[0000] loading builder "default"
DEBU[0000] found 1 node(s) for builder "default"
DEBU[0000] loading node "default"
DEBU[0000] connecting to docker
DEBU[0000] running buildkitd container "buildx_buildkit_default"
DEBU[0000] buildkitd container "buildx_buildkit_default" is running
DEBU[0000] connecting to buildkitd
DEBU[0000] buildkitd connection successful
Name: default
Driver: docker
Nodes:
default:
Status: running
Buildkitd:
Version: v0.10.5
Platforms:
- linux/amd64
- linux/arm64
- linux/riscv64
- linux/ppc64le
- linux/s390x
- linux/386
- linux/arm/v7
- linux/arm/v6
The --debug flag is a powerful tool for diagnosing issues or gaining a deeper understanding of how docker buildx interacts with the underlying BuildKit service.
Summary
In this lab, you learned how to use the docker buildx inspect command to view details about Docker builder instances. You started by inspecting the current builder instance without specifying a name, which typically shows information about the default builder. You then learned how to explicitly inspect a specific builder instance by providing its name, confirming that this yields the same details for the default builder.
These steps demonstrated the basic usage of docker buildx inspect for gaining insight into your Docker build environment, including the builder's name, driver, node status, BuildKitd version, and supported platforms.
