从Docker buildkit获取容器ID以进行交互式调试 [英] Get container ID from Docker buildkit for interactive debugging

问题描述

众所周知，您可以针对失败的构建过程运行 docker commit ，以获取容器快照以进行调试.容器ID是从运行在< ID> 文本中的收集的.但是，在使用Docker较新的BuildKit buildx 功能进行的构建过程中，不会发出此文本.

It's commonly known that you can run docker commit against a failed build process to take a snapshot of a container for debugging purposes. The container ID is gleaned from the running in <ID> text. However, this text is not emitted during builds that happen with Docker's newer BuildKit buildx functionality.

我尝试在Docker build命令上使用-progress plain ，但是并没有显示容器ID.另外，我无法从吐出的图像层ID(SHA哈希)运行新容器.

I tried using --progress plain on the Docker build command, but that hasn't shown me the container IDs. Plus, I cannot run a new container from the image layer IDs (SHA hashes) that are spit out.

使用此命令:

#1 [internal] load build definition from Dockerfile
#1 sha256:0e70418d547c3ccb20da7b100cf4f69564bddc416652e3e2b9b514e9a732b4aa
#1 transferring dockerfile: 32B done
#1 DONE 0.0s

#2 [internal] load .dockerignore
#2 sha256:396b2cfd81ff476a70ecda27bc5d781bd61c859b608537336f8092e155dd38bf
#2 transferring context: 34B done
#2 DONE 0.0s

#3 [internal] load metadata for docker.io/library/node:latest
#3 sha256:1c0b05b884068c98f7acad32e4f7fd374eba1122b4adcbb1de68aa72d5a6046f
#3 DONE 0.0s

#4 [1/4] FROM docker.io/library/node
#4 sha256:5045d46e15358f34ea7fff145af304a1fa3a317561e9c609f4ae17c0bd3359df
#4 DONE 0.0s

#5 [internal] load build context
#5 sha256:49d7a085caed3f75e779f05887e53e0bba96452e3a719963993002a3638cb8a3
#5 transferring context: 35.17kB 0.0s done
#5 DONE 0.1s

#6 [2/4] ADD [trevortest/*, /app/]
#6 sha256:6da32965a50f6e13322efb20007ff49fb0546e2ff55799163b3b00d034a62c57
#6 CACHED

问题:在每个步骤中，特别是在使用Docker BuildKit时，如何获取构建过程的容器ID?

Question: How can I obtain the container IDs of the build process, during each step, specifically when using Docker BuildKit?

推荐答案

BuildKit与旧版docker构建系统的工作方式不同.目前，尚无直接方法可以从构建步骤中派生容器并对它进行故障排除.

The BuildKit works differently than the legacy docker build system. At the moment, there is no direct way to spawn a container from a step in the build and troubleshoot it.

要最大程度地利用BuildKit的潜力，最好的方法是按照较小的逻辑阶段组织构建.一旦以这种方式组织了构建，则在运行构建时，可以使用-target 指定要在特定阶段停止.指定目标后，Docker会创建一个映像，其中包含到该阶段为止的构建结果.您可以使用此容器来进行进一步的故障排除，方法与旧的构建系统相同.

To use the BuildKit potential up to the maximum, best approach is to organize the builds in smaller logical stages. Once the build is organized in this way, When running the builds, you can specify that you want to stop at a certain stage by using --target. When the target is specified, Docker creates an image with the results of the build up to that stage. You can use this container to further troubleshoot in the same way that was possible with the old build system.

以这个例子为例.这里有4个阶段，其中2个是并行阶段:

Take this example. Here I have 4 stages out of which 2 are parallel stages:

FROM debian:9.11 AS stage-01
# Prepare for installation
RUN apt update && \
    apt upgrade -y

FROM stage-01 as stage-02
# Install building tools
RUN apt install -y build-essential

FROM stage-02 as stage-02a

RUN echo "Build 0.1" > /version.txt

FROM stage-02 as stage-03

RUN apt install -y cmake gcc g++

现在，您可以使用-target 选项告诉Docker您要在 stage-02 处停止，如下所示:

Now you can use the --target option to tell Docker that you want to stop at the stage-02 as follows:

$ docker build -f test-docker.Dockerfile -t test . --target stage-02                                                                                                                                   [+] Building 67.5s (7/7) FINISHED
 => [internal] load build definition from test-docker.Dockerfile                                 0.0s
 => => transferring dockerfile: 348B                                                             0.0s
 => [internal] load .dockerignore                                                                0.0s
 => => transferring context: 2B                                                                  0.0s
 => [internal] load metadata for docker.io/library/debian:9.11                                   0.0s
 => [stage-01 1/2] FROM docker.io/library/debian:9.11                                            0.0s
 => CACHED [stage-01 2/2] RUN apt update &&     apt upgrade -y                                   0.0s
 => [stage-02 1/1] RUN apt install -y build-essential                                           64.7s
 => exporting to image                                                                           2.6s
 => => exporting layers                                                                          2.5s
 => => writing image sha256:ac36b95184b79b6cabeda3e4d7913768f6ed73527b76f025262d6e3b68c2a357     0.0s
 => => naming to docker.io/library/test                                                          0.0s

现在您有了名称为 test 的图像，并且可以生成一个容器来进行故障排除.

Now you have the image with the name test and you can spawn a container to troubleshoot.

docker run -ti --rm --name troubleshoot test /bin/bash
root@bbdb0d2188c0:/# ls

使用多个阶段可以简化故障排除，但是由于并行分支可以在不同的实例上进行构建，因此它确实加快了构建过程.而且，大大提高了构建文件的可读性.

Using multiple stages facilitates the troubleshooting, however it really speeds up the build process since the parallel branches can be build on different instances. Also, the readability of the build file is significantly improved.

这篇关于从Docker buildkit获取容器ID以进行交互式调试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！