How to set breakpoint in Dockerfile itself?

VonC :

The recent (May 2022) project ktock/buildg offers breakpoints.\nSee "Interactive debugger for Dockerfile" from Kohei Tokunaga\n\nbuildg is a tool to interactively debug Dockerfile based on BuildKit.\n\nSource-level inspection\nBreakpoints and step execution\nInteractive shell on a step with your own debugigng tools\nBased on BuildKit (needs unmerged patches)\nSupports rootless\n\n\nThe command break, b LINE_NUMBER sets a breakpoint.\nExample:\n$ buildg.sh debug --image=ubuntu:22.04 /tmp/ctx\nWARN[2022-05-09T01:40:21Z] using host network as the default \n#1 [internal] load .dockerignore\n#1 transferring context: 2B done\n#1 DONE 0.1s\n\n#2 [internal] load build definition from Dockerfile\n#2 transferring dockerfile: 195B done\n#2 DONE 0.1s\n\n#3 [internal] load metadata for docker.io/library/busybox:latest\n#3 DONE 3.0s\n\n#4 [build1 1/2] FROM docker.io/library/busybox@sha256:d2b53584f580310186df7a2055ce3ff83cc0df6caacf1e3489bff8cf5d0af5d8\n#4 resolve docker.io/library/busybox@sha256:d2b53584f580310186df7a2055ce3ff83cc0df6caacf1e3489bff8cf5d0af5d8 0.0s done\n#4 sha256:50e8d59317eb665383b2ef4d9434aeaa394dcd6f54b96bb7810fdde583e9c2d1 772.81kB / 772.81kB 0.2s done\nFilename: "Dockerfile"\n 2| RUN echo hello > /hello\n 3| \n 4| FROM busybox AS build2\n => 5| RUN echo hi > /hi\n 6| \n 7| FROM scratch\n 8| COPY --from=build1 /hello /\n>>> break 2\n>>> breakpoints\n[0]: line 2\n>>> continue\n#4 extracting sha256:50e8d59317eb665383b2ef4d9434aeaa394dcd6f54b96bb7810fdde583e9c2d1 0.0s done\n#4 DONE 0.3s\n...\n\nFrom PR 24:\n\nAdd --cache-reuse option which allows sharing the build cache among invocation of buildg debug to make the 2nd-time debugging faster.\nThis is useful to speed up running buildg multiple times for debugging an errored step.\nNote that breakpoints on cached steps are ignored as of now.\nBecause of this limitation, this feature is optional as of now. We should fix this limitation and make it the default behaviour in the future.\n",

2022-05-19T07:58:30

David Maze :

You can't set a breakpoint per se, but you can get an interactive shell at an arbitrary point in your build sequence (between steps).\nLet's build your image:\nSending build context to Docker daemon 2.048kB\nStep 1/3 : FROM ubuntu:20.04\n ---> 1e4467b07108\nStep 2/3 : RUN echo "hello"\n ---> Running in 917b34190e35\nhello\nRemoving intermediate container 917b34190e35\n ---> 12ebbdc1e72d\nStep 3/3 : RUN echo "bye"\n ---> Running in c2a4a71ae444\nbye\nRemoving intermediate container c2a4a71ae444\n ---> 3c52993b0185\nSuccessfully built 3c52993b0185\n\nEach of the lines that says ---> 0123456789ab with a hex ID has a valid image ID. So from here you can\ndocker run --rm -it 12ebbdc1e72d sh\n\nwhich will give you an interactive shell on the partial image resulting from the first RUN command.\nThere's no requirement that the build as a whole succeed. If a RUN step fails, you can use this technique to get an interactive shell on the image immediately before that step and re-run the command by hand. If you have a very long RUN command, you may need to break it into two to be able to get a debugging shell at a specific point within the command sequence.",

2020-07-26T10:17:27

Nick ODell :

I don't think this is possible directly - that feature has been discussed and rejected.\nWhat I generally do to debug a Dockerfile is to comment all of the steps after the "breakpoint", then run docker build followed by docker run -it image bash or docker run -it image sh (depending on whether you have bash installed inside the container).\nThen, I have an interactive shell, and I can run commands to debug why later stages are failing.\nI agree that being able to set a breakpoint and poke around would be a handy feature, though.",

2020-07-26T06:35:44

Antti Kervinen :

You can run commands in intermediate containers using Remote shell debugging tricks.\nMake sure your container images include basic utilities like netcat (nc) and fuser. These utilities enable "calling home" from any intermediate container image. At home you'll answer calls with netcat (or socat). This netcat will send your commands to containers, and print their outcomes. This debugging approach will work even on Dockerfiles that are built on unknown worker nodes somewhere in cloud.\nExample:\nFROM debian:testing-slim\n\n# Set environment variables for calling home from breakpoints (BP)\nENV BP_HOME=<IP-ADDRESS-OF-YOUR-HOST>\nENV BP_PORT=33720\nENV BP_CALLHOME='BP_FIFO=/tmp/$BP.$BP_HOME.$BP_PORT; (rm -f $BP_FIFO; mkfifo $BP_FIFO) && (echo "\\"c\\" continues"; echo -n "($BP) "; tail -f $BP_FIFO) | nc $BP_HOME $BP_PORT | while read cmd; do if test "$cmd" = "c" ; then echo -n "" >$BP_FIFO; sleep 0.1; fuser -k $BP_FIFO >/dev/null 2>&1; break; else eval $cmd >$BP_FIFO 2>&1; echo -n "($BP) " >$BP_FIFO; fi; done'\n\n# Install needed utils (netcat, fuser)\nRUN apt update && apt install -y netcat psmisc\n\n# Now you are ready to run "eval $BP_CALLHOME" wherever you want to call home.\n\nRUN BP=before-hello eval $BP_CALLHOME\n\nRUN echo "hello"\n\nRUN BP=after-hello eval $BP_CALLHOME\n\nRUN echo "bye"\n\nStart waiting for and answering calls from a Dockerfile before launching a Docker build. On home host run nc -k -l -p 33720 (alternatively socat STDIN TCP-LISTEN:33720,reuseaddr,fork).\nThis is how above example looks like at home:\n$ nc -k -l -p 33720\n"c" continues\n(before-hello) echo *\nbin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var\n(before-hello) id\nuid=0(root) gid=0(root) groups=0(root)\n(before-hello) c\n"c" continues\n(after-hello)\n...\n",

2021-08-16T08:25:58