从Docker buildkit获取容器ID以进行交互式调试

pgx2nnw8  于 2023-08-03  发布在  Docker
关注(0)|答案(2)|浏览(133)

众所周知,您可以针对失败的构建进程运行docker commit,以获取容器的快照用于调试目的。容器ID从running in <ID>文本中收集。但是,在使用Docker的较新BuildKit buildx功能进行构建时不会发出此文本。
我尝试在Docker build命令中使用--progress plain,但没有显示容器ID。另外,我不能从吐出的图像层ID(SHA哈希)运行新容器。

BuildKit输出示例

使用此命令:

#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

字符串

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

nkoocmlb

nkoocmlb1#

BuildKit的工作方式与传统的Docker构建系统不同。目前,还没有直接的方法从构建中的一个步骤生成容器并对其进行故障排除。
为了最大限度地利用BuildKit的潜力,最好的方法是将构建组织在较小的逻辑阶段中。一旦以这种方式组织了构建,在运行构建时,您可以通过使用--target指定要在某个阶段停止。当指定目标时,Docker会创建一个镜像,其中包含构建到该阶段的结果。您可以使用此容器以与旧构建系统相同的方式进一步进行故障排除。
举个例子。这里我有4个阶段,其中2个是并行阶段:

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处停止,如下所示:

$ 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的映像,您可以生成一个容器来进行故障排除。

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


使用多个阶段有助于故障排除,但它确实加快了构建过程,因为并行分支可以在不同的示例上构建。此外,构建文件的可读性也得到了显著提高。

deikduxw

deikduxw2#

Docker从直接在Docker引擎中运行的经典构建器迁移到在containerd中运行的buildkit。因此,使用buildkit构建的镜像不会在Docker引擎中留下构建的中间步骤的悬空镜像。对于大多数人来说,这是一个优势,以消除混乱。然而,对于调试,这意味着您需要以不会失败的方式构建映像。
对于一个小的,你可以注解掉Dockerfile的结尾来构建失败点,或者使用多个阶段来构建,并使用docker build --target来构建工作阶段。
但是,如果你发现自己经常这样做,我推荐buildg,它可以作为buildkit构建的交互式调试器。它允许您在构建中插入断点,从任何步骤启动shell,甚至可以在IDE中使用。

相关问题