blocks|key|147991|text|我要做的是注释掉下面的Dockerfile，并包含有问题的行。然后，您可以手动运行容器和docker命令，并以常规方式查看日志。例如，如果Dockerfile是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|147992|RUN+foo
RUN+bar
RUN+baz|code-block|syntax|javascript|147993|它会在酒吧里死去我会|147994|RUN+foo
#+RUN+bar
#+RUN+baz|147995|然后|147996|$+docker+build+-t+foo+.
$+docker+run+-it+foo+bash
container#+bar
...grep+logs...|147997|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

What I would do is comment out the Dockerfile below and including the offending line. Then you can run the container and run the docker commands by hand, and look at the logs in the usual way. E.g. if the Dockerfile is 

<pre><code>RUN foo
RUN bar
RUN baz
</code></pre>

and it's dying at bar I would do

<pre><code>RUN foo
# RUN bar
# RUN baz
</code></pre>

Then

<pre><code>$ docker build -t foo .
$ docker run -it foo bash
container# bar
...grep logs...
</code></pre>

blocks|key|147999|text|每次docker成功地从docker文件执行RUN命令时，就会提交a+new+layer+in+the+image+filesystem。您可以方便地使用这些层ids作为图像来启动新的容器。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|148000|获取以下Dockerfile：|148001|FROM+busybox
RUN+echo+'foo'+>+/tmp/foo.txt
RUN+echo+'bar'+>>+/tmp/foo.txt|code-block|syntax|javascript|148002|并构建它：|148003|$+docker+build+-t+so-26220957+.
Sending+build+context+to+Docker+daemon+47.62+kB
Step+1/3+:+FROM+busybox
+--->+00f017a8c2a6
Step+2/3+:+RUN+echo+'foo'+>+/tmp/foo.txt
+--->+Running+in+4dbd01ebf27f
+--->+044e1532c690
Removing+intermediate+container+4dbd01ebf27f
Step+3/3+:+RUN+echo+'bar'+>>+/tmp/foo.txt
+--->+Running+in+74d81cb9d2b1
+--->+5bd8172529c1
Removing+intermediate+container+74d81cb9d2b1
Successfully+built+5bd8172529c1|148004|您现在可以从00f017a8c2a6、044e1532c690和5bd8172529c1启动一个新容器|148005|$+docker+run+--rm+00f017a8c2a6+cat+/tmp/foo.txt
cat:+/tmp/foo.txt:+No+such+file+or+directory

$+docker+run+--rm+044e1532c690+cat+/tmp/foo.txt
foo

$+docker+run+--rm+5bd8172529c1+cat+/tmp/foo.txt
foo
bar|148006|当然，您可能希望启动一个shell来探索文件系统并尝试命令：|148007|$+docker+run+--rm+-it+044e1532c690+sh++++++
/+#+ls+-l+/tmp
total+4
-rw-r--r--++++1+root+++++root+++++++++++++4+Mar++9+19:09+foo.txt
/+#+cat+/tmp/foo.txt+
foo|148008|148009|当某个Dockerfile命令失败时，您需要做的是查找前面层的id，并在根据该id创建的容器中运行一个：|BOLD|148010|docker+run+--rm+-it+<id_last_working_layer>+bash+-il|148011|进入容器后：|148012|148013|尝试失败的命令，并重新生成|unordered-list-item|148014|命令，然后修复该命令并对其进行测试|148015|最后使用修复后的命令|148016|更新Dockerfile文件|148017|148018|如果您确实需要在失败的实际层中进行实验，而不是从最后一个工作层开始工作，请参见Drew's+answer。|148019|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.docker.com/storage/storagedriver/#images-and-layers|1|https://stackoverflow.com/a/35387446/107049^0|M|3|X|Z|0|0|0|0|0|0|6|C|J|C|W|C|0|0|0|0|0|V|K|0|0|0|0|0|0|0|0|0|13|D|1|0^^$0|@$1|2|3|4|5|6|7|1T|8|@$9|1U|A|1V|B|C]]|D|@$9|1W|A|1X|1|1Y]]|E|$]]|$1|F|3|G|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|20|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|21|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|22|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|23|8|@$9|24|A|25|B|C]|$9|26|A|27|B|C]|$9|28|A|29|B|C]]|D|@]|E|$]]|$1|S|3|T|5|J|7|2A|8|@]|D|@]|E|$K|L]]|$1|U|3|V|5|6|7|2B|8|@]|D|@]|E|$]]|$1|W|3|X|5|J|7|2C|8|@]|D|@]|E|$K|L]]|$1|Y|3|-4|5|6|7|2D|8|@]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2E|8|@$9|2F|A|2G|B|11]]|D|@]|E|$]]|$1|12|3|13|5|J|7|2H|8|@]|D|@]|E|$K|L]]|$1|14|3|15|5|6|7|2I|8|@]|D|@]|E|$]]|$1|16|3|-4|5|6|7|2J|8|@]|D|@]|E|$]]|$1|17|3|18|5|19|7|2K|8|@]|D|@]|E|$]]|$1|1A|3|1B|5|19|7|2L|8|@]|D|@]|E|$]]|$1|1C|3|1D|5|19|7|2M|8|@]|D|@]|E|$]]|$1|1E|3|1F|5|6|7|2N|8|@]|D|@]|E|$]]|$1|1G|3|-4|5|6|7|2O|8|@]|D|@]|E|$]]|$1|1H|3|1I|5|6|7|2P|8|@]|D|@$9|2Q|A|2R|1|2S]]|E|$]]|$1|1J|3|-4|5|6|7|2T|8|@]|D|@]|E|$]]]|1K|$1L|$5|1M|1N|1O|E|$1P|1Q]]|1R|$5|1M|1N|1O|E|$1P|1S]]]]

Everytime docker successfully executes a <code>RUN</code> command from a Dockerfile, <a href="https://docs.docker.com/storage/storagedriver/#images-and-layers" rel="noreferrer">a new layer in the image filesystem</a> is committed. Conveniently you can use those layers ids as images to start a new container.
Take the following Dockerfile:
<pre><code>FROM busybox
RUN echo 'foo' &gt; /tmp/foo.txt
RUN echo 'bar' &gt;&gt; /tmp/foo.txt
</code></pre>
and build it:
<pre><code>$ docker build -t so-26220957 .
Sending build context to Docker daemon 47.62 kB
Step 1/3 : FROM busybox
 ---&gt; 00f017a8c2a6
Step 2/3 : RUN echo 'foo' &gt; /tmp/foo.txt
 ---&gt; Running in 4dbd01ebf27f
 ---&gt; 044e1532c690
Removing intermediate container 4dbd01ebf27f
Step 3/3 : RUN echo 'bar' &gt;&gt; /tmp/foo.txt
 ---&gt; Running in 74d81cb9d2b1
 ---&gt; 5bd8172529c1
Removing intermediate container 74d81cb9d2b1
Successfully built 5bd8172529c1
</code></pre>
You can now start a new container from <code>00f017a8c2a6</code>, <code>044e1532c690</code> and <code>5bd8172529c1</code>:
<pre><code>$ docker run --rm 00f017a8c2a6 cat /tmp/foo.txt
cat: /tmp/foo.txt: No such file or directory

$ docker run --rm 044e1532c690 cat /tmp/foo.txt
foo

$ docker run --rm 5bd8172529c1 cat /tmp/foo.txt
foo
bar
</code></pre>
of course you might want to start a shell to explore the filesystem and try out commands:
<pre><code>$ docker run --rm -it 044e1532c690 sh 
/ # ls -l /tmp
total 4
-rw-r--r-- 1 root root 4 Mar 9 19:09 foo.txt
/ # cat /tmp/foo.txt 
foo
</code></pre>
<hr />
When one of the Dockerfile command fails, what you need to do is to look for the id of the preceding layer and run a shell in a container created from that id:
<pre><code>docker run --rm -it &lt;id_last_working_layer&gt; bash -il
</code></pre>
Once in the container:
<ul>
<li>try the command that failed, and reproduce the issue</li>
<li>then fix the command and test it</li>
<li>finally update your Dockerfile with the fixed command</li>
</ul>
<hr />
If you really need to experiment in the actual layer that failed instead of working from the last working layer, see <a href="https://stackoverflow.com/a/35387446/107049">Drew's answer</a>.

blocks|key|2938539|text|在每条成功的RUN行之后执行Docker+caches+the+entire+filesystem+state。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2938540|知道这一点：|2938541|2938542|要检查失败的RUN命令之前的最新状态，请在Dockerfile文件(以及任何和所有后续RUN命令)中将其注释掉，然后再次运行docker+build和docker+run。|unordered-list-item|2938543|要检查失败的RUN命令之后的状态，只需向其添加D11以强制其成功；然后按上述方式进行操作(保留注释掉任何和所有后续的D12命令，运行D13和Dockerfile|2938544|2938545|Tada，不需要打乱Docker内部或层ID，并且作为一个额外的好处，Docker自动最小化了需要重新完成的工作量。|2938546|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.docker.com/reference/builder/#run^0|6|3|L|Y|0|0|0|0|6|3|17|3|1Q|C|23|A|0|6|3|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@$9|11|A|12|1|13]]|E|$]]|$1|F|3|G|5|6|7|14|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|15|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|16|8|@$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|L|3|M|5|K|7|1F|8|@$9|1G|A|1H|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|1I|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|1J|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]]]

Docker <a href="https://docs.docker.com/reference/builder/#run" rel="noreferrer">caches the entire filesystem state</a> after each successful <code>RUN</code> line.

Knowing that:

<ul>
<li>to examine the latest state before your failing <code>RUN</code> command, comment it out in the Dockerfile (as well as any and all subsequent <code>RUN</code> commands), then run <code>docker build</code> and <code>docker run</code> again.</li>
<li>to examine the state after the failing <code>RUN</code> command, simply add <code>|| true</code> to it to force it to succeed; then proceed like above (keep any and all subsequent <code>RUN</code> commands commented out, run <code>docker build</code> and <code>docker run</code>)</li>
</ul>

Tada, no need to mess with Docker internals or layer IDs, and as a bonus Docker automatically minimizes the amount of work that needs to be re-done.

blocks|key|145646|text|最好的答案适用于您想要检查失败命令之前的状态的情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|145647|然而，问题是如何检查失败容器本身的状态。在我的情况下，失败的命令是一个需要几个小时的构建，所以在失败的命令之前倒带并再次运行它需要很长的时间，并且不是很有帮助。|145648|这里的解决方案是找到失败的容器：|145649|$+docker+ps+-a
CONTAINER+ID++++++++IMAGE+++++++++++++++COMMAND++++++++++++++++++CREATED+++++++++++++STATUS++++++++++++++++++++++++++PORTS+++++++++++++++NAMES
6934ada98de6++++++++42e0228751b3++++++++"/bin/sh+-c+'./utils/"+++24+minutes+ago++++++Exited+(1)+About+a+minute+ago+++++++++++++++++++++++sleepy_bell|code-block|syntax|javascript|145650|将其提交到镜像：|145651|$+docker+commit+6934ada98de6
sha256:7015687976a478e0e94b60fa496d319cdf4ec847bcd612aecf869a72336e6b83|145652|然后运行镜像(如果需要)，运行bash|145653|$+docker+run+-it+7015687976a4+[bash+-il]|145654|现在，您实际查看的是构建失败时的状态，而不是运行导致失败的命令之前的构建状态。|145655|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|Z|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|11|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

The top answer works in the case that you want to examine the state immediately prior to the failed command.

However, the question asks how to examine the state of the failed container itself. In my situation, the failed command is a build that takes several hours, so rewinding prior to the failed command and running it again takes a long time and is not very helpful.

The solution here is to find the container that failed:

<pre><code>$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6934ada98de6 42e0228751b3 "/bin/sh -c './utils/" 24 minutes ago Exited (1) About a minute ago sleepy_bell
</code></pre>

Commit it to an image:

<pre><code>$ docker commit 6934ada98de6
sha256:7015687976a478e0e94b60fa496d319cdf4ec847bcd612aecf869a72336e6b83
</code></pre>

And then run the image [if necessary, running bash]:

<pre><code>$ docker run -it 7015687976a4 [bash -il]
</code></pre>

Now you are actually looking at the state of the build at the time that it failed, instead of at the time before running the command that caused the failure.

blocks|key|2726264|text|调试构建步骤失败确实非常烦人。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2726265|我找到的最好的解决方案是确保每个真正工作的步骤都成功，并在失败的步骤之后添加检查。这样，您就可以获得一个提交的层，其中包含您可以检查的失败步骤的输出。|2726266|一个#+Run++DB2+silent+installer文件，在Dockerfile行后面有一个示例：|offset|length|style|CODE|2726267|#
#+DB2+10.5+Client+Dockerfile+(Part+1)
#
#+Requires
#+++-+DB2+10.5+Client+for+64bit+Linux+ibm_data_server_runtime_client_linuxx64_v10.5.tar.gz
#+++-+Response+file+for+DB2+10.5+Client+for+64bit+Linux+db2rtcl_nr.rsp+
#
#
#+Using+Ubuntu+14.04+base+image+as+the+starting+point.
FROM+ubuntu:14.04

MAINTAINER+David+Carew+<carew@us.ibm.com>

#+DB2+prereqs+(also+installing+sharutils+package+as+we+use+the+utility+uuencode+to+generate+password+-+all+others+are+required+for+the+DB2+Client)+
RUN+dpkg+--add-architecture+i386+&&+apt-get+update+&&+apt-get+install+-y+sharutils+binutils+libstdc%2B%2B6:i386+libpam0g:i386+&&+ln+-s+/lib/i386-linux-gnu/libpam.so.0+/lib/libpam.so.0
RUN+apt-get+install+-y+libxml2


#+Create+user+db2clnt
#+Generate+strong+random+password+and+allow+sudo+to+root+w/o+password
#
RUN++\
+++adduser+--quiet+--disabled-password+-shell+/bin/bash+-home+/home/db2clnt+--gecos+"DB2+Client"+db2clnt+&&+\
+++echo+db2clnt:`dd+if=/dev/urandom+bs=16+count=1+2>/dev/null+%7C+uuencode+-%7C+head+-n+2+%7C+grep+-v+begin+%7C+cut+-b+2-10`+%7C+chgpasswd+&&+\
+++adduser+db2clnt+sudo+&&+\
+++echo+'%25sudo+ALL=(ALL)+NOPASSWD:ALL'+>>+/etc/sudoers

#+Install+DB2
RUN+mkdir+/install
#+Copy+DB2+tarball+-+ADD+command+will+expand+it+automatically
ADD+v10.5fp9_linuxx64_rtcl.tar.gz+/install/
#+Copy+response+file
COPY++db2rtcl_nr.rsp+/install/
#+Run++DB2+silent+installer
RUN+mkdir+/logs
RUN+(/install/rtcl/db2setup+-t+/logs/trace+-l+/logs/log+-u+/install/db2rtcl_nr.rsp+&&+touch+/install/done)+%7C%7C+/bin/true
RUN+test+-f+/install/done+%7C%7C+(echo+ERROR-------;+echo+install+failed,+see+files+in+container+/logs+directory+of+the+last+container+layer;+echo+run+docker+run+'<last+image+id>'+/bin/cat+/logs/trace;+echo+----------)
RUN+test+-f+/install/done

#+Clean+up+unwanted+files
RUN+rm+-fr+/install/rtcl

#+Login+as+db2clnt+user
CMD+su+-+db2clnt|code-block|syntax|javascript|2726268|entityMap^0|0|0|2|R|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@$F|T|G|U|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|V|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Debugging build step failures is indeed very annoying.

The best solution I have found is to make sure that each step that does real work succeeds, and adding a check after those that fails. That way you get a committed layer that contains the outputs of the failed step that you can inspect.

A Dockerfile, with an example after the <code># Run DB2 silent installer</code> line:

<pre><code>#
# DB2 10.5 Client Dockerfile (Part 1)
#
# Requires
# - DB2 10.5 Client for 64bit Linux ibm_data_server_runtime_client_linuxx64_v10.5.tar.gz
# - Response file for DB2 10.5 Client for 64bit Linux db2rtcl_nr.rsp 
#
#
# Using Ubuntu 14.04 base image as the starting point.
FROM ubuntu:14.04

MAINTAINER David Carew &lt;carew@us.ibm.com&gt;

# DB2 prereqs (also installing sharutils package as we use the utility uuencode to generate password - all others are required for the DB2 Client) 
RUN dpkg --add-architecture i386 &amp;&amp; apt-get update &amp;&amp; apt-get install -y sharutils binutils libstdc++6:i386 libpam0g:i386 &amp;&amp; ln -s /lib/i386-linux-gnu/libpam.so.0 /lib/libpam.so.0
RUN apt-get install -y libxml2


# Create user db2clnt
# Generate strong random password and allow sudo to root w/o password
#
RUN \
 adduser --quiet --disabled-password -shell /bin/bash -home /home/db2clnt --gecos "DB2 Client" db2clnt &amp;&amp; \
 echo db2clnt:`dd if=/dev/urandom bs=16 count=1 2&gt;/dev/null | uuencode -| head -n 2 | grep -v begin | cut -b 2-10` | chgpasswd &amp;&amp; \
 adduser db2clnt sudo &amp;&amp; \
 echo '%sudo ALL=(ALL) NOPASSWD:ALL' &gt;&gt; /etc/sudoers

# Install DB2
RUN mkdir /install
# Copy DB2 tarball - ADD command will expand it automatically
ADD v10.5fp9_linuxx64_rtcl.tar.gz /install/
# Copy response file
COPY db2rtcl_nr.rsp /install/
# Run DB2 silent installer
RUN mkdir /logs
RUN (/install/rtcl/db2setup -t /logs/trace -l /logs/log -u /install/db2rtcl_nr.rsp &amp;&amp; touch /install/done) || /bin/true
RUN test -f /install/done || (echo ERROR-------; echo install failed, see files in container /logs directory of the last container layer; echo run docker run '&lt;last image id&gt;' /bin/cat /logs/trace; echo ----------)
RUN test -f /install/done

# Clean up unwanted files
RUN rm -fr /install/rtcl

# Login as db2clnt user
CMD su - db2clnt
</code></pre>

blocks|key|2726350|text|更新的docker版本20.10及以后的更新|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2726351|Linux或macOS|2726352|DOCKER_BUILDKIT=0+docker+build+...|code-block|syntax|javascript|2726353|视窗|2726354|#+Command+line
set+DOCKER_BUILDKIT=0+docker+build+...
#+PowerShell
$env:DOCKER_BUILDKIT=0|2726355|使用DOCKER_BUILDKIT=0+docker+build+...获取旧版本中已知的中间容器散列。|offset|length|style|CODE|2726356|在较新的版本中，Buildkit是默认激活的。建议仅将其用于调试目的。Build+Kit可以使您的构建速度更快。|2726357|仅供参考:+Buildkit不支持中间容器散列：https://github.com/moby/buildkit/issues/1053|2726358|感谢@David+Callanan和@MegaCookie的投入。|2726359|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/moby/buildkit/issues/1053^0|0|0|0|0|0|2|Y|0|0|O|18|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|19|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1A|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1B|8|@$O|1C|P|1D|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1F|8|@]|9|@$O|1G|P|1H|1|1I]]|A|$]]|$1|W|3|X|5|6|7|1J|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|Z|$10|$5|11|12|13|A|$14|15]]]]

<h1>Update for newer docker versions 20.10 onwards</h1>
<h2>Linux or macOS</h2>
<pre class="lang-sh prettyprint-override"><code>DOCKER_BUILDKIT=0 docker build ...
</code></pre>
<h2>Windows</h2>
<pre class="lang-sh prettyprint-override"><code># Command line
set DOCKER_BUILDKIT=0 docker build ...
# PowerShell
$env:DOCKER_BUILDKIT=0
</code></pre>
Use
<code>DOCKER_BUILDKIT=0 docker build ...</code>
to get the intermediate container hashes as known from older versions.
On newer versions, Buildkit is activated per default. It is recommended to only use it for debugging purposes. Build Kit can make your build faster.
For reference:
Buildkit doesn't support intermediate container hashes: <a href="https://github.com/moby/buildkit/issues/1053" rel="noreferrer">https://github.com/moby/buildkit/issues/1053</a>
Thanks to @David Callanan and @MegaCookie for their inputs.

blocks|key|149643|text|目前使用最新的docker-desktop，还没有办法退出新的Buildkit，它还不支持调试(在这个GitHub线程上关注最新的更新：https://github.com/moby/buildkit/issues/1472)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|149644|docker首先让docker尝试构建，并找出它在docker文件中的哪一行失败了。接下来，在您的docker文件中，您可以在顶部添加一个构建目标：FROM+xxx+as+debug|style|CODE|149645|Then，in+|unordered-list-item|149646|149647|在失败的命令前添加一个额外的目标FROM+xxx+as+next+(因为您不想构建该部分)。示例：|149648|149649|149650|FROM+xxx+as+debug
#+Working+command
RUN+echo+"working+command"

FROM+xxx+as+next
#+Example+of+failing+command
RUN+echoo+"failing+command"|code-block|syntax|javascript|149651|然后运行docker+build+-f+Dockerfile+--target+debug+--tag+debug+.|149652|Next，您可以运行docker+run+-it+debug+/bin/sh|149653|
+|149654|149655|149656|您可以通过按CTRL+P%2B+CTRL+Q退出shell|149657|如果你想使用docker+compose+build而不是docker+build，可以通过在你的docker-compose.yml+under+build中添加target:+debug来实现。|149658|然后通过docker+compose+run+xxxYourServiceNamexxx启动容器，并使用以下任一选项：|149659|要了解如何在container.|149660|Or中运行|149661|+second+top+answer，请在Dockerfile文件中的FROM+xxx+as+next行之前添加ENTRYPOINT+/bin/sh。|149662|149663|149664|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/moby/buildkit/issues/1472|1|https://github.com/compose-spec/compose-spec/blob/master/build.md#target|2|https://stackoverflow.com/a/35387446/3801276^0|1W|18|0|0|22|H|0|0|0|G|G|0|0|0|0|4|1J|0|A|S|0|0|0|0|0|6|K|T|C|22|5|2A|D|1D|U|1|0|4|14|0|0|0|Z|G|1K|I|1|H|2|0|0|0^^$0|@$1|2|3|4|5|6|7|1S|8|@]|9|@$A|1T|B|1U|1|1V]]|C|$]]|$1|D|3|E|5|6|7|1W|8|@$A|1X|B|1Y|F|G]]|9|@]|C|$]]|$1|H|3|I|5|J|7|1Z|8|@]|9|@]|C|$]]|$1|K|3|-4|5|J|7|20|8|@]|9|@]|C|$]]|$1|L|3|M|5|J|7|21|8|@$A|22|B|23|F|G]]|9|@]|C|$]]|$1|N|3|-4|5|6|7|24|8|@]|9|@]|C|$]]|$1|O|3|-4|5|6|7|25|8|@]|9|@]|C|$]]|$1|P|3|Q|5|R|7|26|8|@]|9|@]|C|$S|T]]|$1|U|3|V|5|6|7|27|8|@$A|28|B|29|F|G]]|9|@]|C|$]]|$1|W|3|X|5|J|7|2A|8|@$A|2B|B|2C|F|G]]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|2D|8|@]|9|@]|C|$]]|$1|10|3|-4|5|J|7|2E|8|@]|9|@]|C|$]]|$1|11|3|-4|5|6|7|2F|8|@]|9|@]|C|$]]|$1|12|3|13|5|6|7|2G|8|@]|9|@]|C|$]]|$1|14|3|15|5|6|7|2H|8|@$A|2I|B|2J|F|G]|$A|2K|B|2L|F|G]|$A|2M|B|2N|F|G]|$A|2O|B|2P|F|G]]|9|@$A|2Q|B|2R|1|2S]]|C|$]]|$1|16|3|17|5|6|7|2T|8|@$A|2U|B|2V|F|G]]|9|@]|C|$]]|$1|18|3|19|5|6|7|2W|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|J|7|2X|8|@]|9|@]|C|$]]|$1|1C|3|1D|5|J|7|2Y|8|@$A|2Z|B|30|F|G]|$A|31|B|32|F|G]]|9|@$A|33|B|34|1|35]]|C|$]]|$1|1E|3|-4|5|6|7|36|8|@]|9|@]|C|$]]|$1|1F|3|-4|5|6|7|37|8|@]|9|@]|C|$]]|$1|1G|3|-4|5|6|7|38|8|@]|9|@]|C|$]]]|1H|$1I|$5|1J|1K|1L|C|$1M|1N]]|1O|$5|1J|1K|1L|C|$1M|1P]]|1Q|$5|1J|1K|1L|C|$1M|1R]]]]

Currently with the latest docker-desktop, there isn't a way to opt out of the new Buildkit, which doesn't support debugging yet (follow the latest updates on this on this GitHub Thread: <a href="https://github.com/moby/buildkit/issues/1472" rel="nofollow noreferrer">https://github.com/moby/buildkit/issues/1472</a>).
<ul>
<li>First let docker try to build, and find out at which line in your Dockerfile it is failing.</li>
<li>Next, in your Dockerfile you can add a build target at the top: <code>FROM xxx as debug</code></li>
<li>Then, in your Dockerfile add an additional target <code>FROM xxx as next</code> just one line before the failing command (as you don't want to build that part). Example:</li>
</ul>
<pre><code>FROM xxx as debug
# Working command
RUN echo &quot;working command&quot;

FROM xxx as next
# Example of failing command
RUN echoo &quot;failing command&quot;

</code></pre>
<ul>
<li>Then run <code>docker build -f Dockerfile --target debug --tag debug .</code></li>
<li>Next you can run <code>docker run -it debug /bin/sh</code></li>
</ul>
You can quit the shell by pressing CTRL P + CTRL Q
If you want to use <code>docker compose build</code> instead of <code>docker build</code> it's possible by adding <code>target: debug</code> in your <a href="https://github.com/compose-spec/compose-spec/blob/master/build.md#target" rel="nofollow noreferrer">docker-compose.yml under <code>build</code></a>. 
Then start the container by <code>docker compose run xxxYourServiceNamexxx</code> and use either:
<ul>
<li>The <a href="https://stackoverflow.com/a/35387446/3801276">second top answer</a> to find out how to run a shell inside the container.</li>
<li>Or add <code>ENTRYPOINT /bin/sh</code> before the <code>FROM xxx as next</code> line in your Dockerfile.</li>
</ul>

blocks|key|147073|text|在我的例子中，我必须具备：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|147074|DOCKER_BUILDKIT=1+docker+build+...|code-block|syntax|javascript|147075|正如Jannis+Schönleber在他的回答中提到的，在这种情况下目前没有可用的调试(即没有创建中间图像/容器)。|147076|我发现我可以使用以下选项：|147077|...+--progress=plain+...|147078|然后在现有的RUN+...上添加各种RUN+...或其他行，以调试特定命令。这给了我完全访问的感觉(至少如果你的构建相对较快的话)。|offset|length|style|CODE|147079|例如，您可以像这样检查变量：|147080|RUN+echo+"Variable+NAME+=+[$NAME]"|147081|如果您想知道某个文件是否安装正确，您可以这样做：|147082|RUN+find+/|147083|等。|147084|在我的情况下，我必须调试一个带有私有存储库的Go应用程序的docker版本，这是相当困难的调试。我有关于那个here的其他细节。|147085|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/69717228^0|0|0|0|0|0|6|7|I|7|0|0|0|0|0|0|1I|4|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1D|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1E|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1F|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|1G|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|1H|8|@$O|1I|P|1J|Q|R]|$O|1K|P|1L|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1M|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1N|8|@]|9|@]|A|$E|F]]|$1|W|3|X|5|6|7|1O|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|10|3|11|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1R|8|@]|9|@$O|1S|P|1T|1|1U]]|A|$]]|$1|14|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]]]

In my case, I have to have:
<pre><code>DOCKER_BUILDKIT=1 docker build ...
</code></pre>
and as mentioned by Jannis Schönleber in his answer, there is currently no debug available in this case (i.e. no intermediate images/containers get created).
What I've found I could do is use the following option:
<pre><code>... --progress=plain ...
</code></pre>
and then add various <code>RUN ...</code> or additional lines on existing <code>RUN ...</code> to debug specific commands. This gives you what to me feels full access (at least if your build is relatively fast).
For example, you could check a variable like so:
<pre><code>RUN echo &quot;Variable NAME = [$NAME]&quot;
</code></pre>
If you're wondering whether a file is installed properly, you do:
<pre><code>RUN find /
</code></pre>
etc.
In my situation, I had to debug a docker build of a Go application with a private repository and it was quite difficult to do that debugging. I've other details on that <a href="https://stackoverflow.com/questions/69717228">here</a>.

I'm trying to build a new Docker image for our development process, using <code>cpanm</code> to install a bunch of Perl modules as a base image for various projects.

While developing the Dockerfile, <code>cpanm</code> returns a failure code because some of the modules did not install cleanly.

I'm fairly sure I need to get <code>apt</code> to install some more things.

My question is, where can I find the <code>/.cpanm/work</code> directory quoted in the output, in order to inspect the logs? In the general case, how can I inspect the file system of a failed <code>docker build</code> command?

Morning edit After biting the bullet and running a <code>find</code> I discovered

<pre><code>/var/lib/docker/aufs/diff/3afa404e[...]/.cpanm
</code></pre>

Is this reliable, or am I better off building a "bare" container and running stuff manually until I have all the things I need?

How can I inspect the file system of a failed `docker build`?

文件系统

容器

Docker

GitHub

Ubuntu

Linux

Perl

我正在尝试为我们的开发过程构建一个新的Docker镜像，使用cpanm安装一组Perl模块作为各种项目的基础镜像。在开发Dockerfile时，由于某些模块没有干净地安装，cpanm返回了一个失败代码。我相当确定我需要让apt安装更多的东西。我的问题是，在哪里可以找到输出中引用的/.cpanm/work目录，以便检查日...

问如何检查失败的` `docker build`的文件系统？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何检查失败的` `docker build`的文件系统？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何检查失败的` `docker build`的文件系统？
EN