4 ms·

Getting VSCode debugger to hook into a process running in a docker container running inside WSL was insanely frustrating. In the end, I stopped using Docker dur

Getting VSCode debugger to hook into a process running in a docker container running inside WSL was insanely frustrating. In the end, I stopped using Docker during development and only use it for deploying to staging/production.

ahepp 6y ago
Did you ever find a satisfying solution? I am trying to make more effective use of docker for development and anticipate needing GDB at some point. I imagine one could install GDB in the container and connect to it remotely? Or from the container's shell?
- trinovantes 6y ago
  I was eventually able to get it to work by digging through a lot of old GitHub issue discussions. Sadly it was so flaky and slow that I just threw out Docker for development after awhile. IIRC, you just need to install gdb when you build your image and use `docker run -it bash` to run any shell commands in your container
- Groxx 6y ago
  Ignoring VSCode's insanely fragile config for this, any debugger with a remote protocol tends to work. Personally I have better luck manually setting up a headless GDB session and connecting with intellij, but it's also difficult sometimes. Since the remote stuff is sometimes an incredible pain to set up and use, I usually install gdb and just use its CLI in the container. That's usually trivial in comparison, and it's a decent skill to learn regardless since so many debuggers use a similar CLI UX. It's extremely cross-platform and cross-language, so you can just jump on a new thing and be a wizard from day 1.
- jgalentine007 6y ago
  For node / php and python I just expose the debugger ports in docker, and if I'm running docker in a VM I just forward them over SSH. VSCode connects to the forwarded port easily, but sometimes you have to struggle with workspace / source mapping and other issues (like connecting to child processes).
martinald 6y ago
I agree. Debugging docker is a total nightmare across various stacks. I don't know how people bother with it. Like you use it for deployments but not for development. I'd rather have slightly more time setting up a project (which in all honesty is usually a few commands) vs hours/days of flakey debugging.

ahepp 6y ago

Did you ever find a satisfying solution? I am trying to make more effective use of docker for development and anticipate needing GDB at some point. I imagine one could install GDB in the container and connect to it remotely? Or from the container's shell?

trinovantes 6y ago
I was eventually able to get it to work by digging through a lot of old GitHub issue discussions. Sadly it was so flaky and slow that I just threw out Docker for development after awhile. IIRC, you just need to install gdb when you build your image and use `docker run -it bash` to run any shell commands in your container
Groxx 6y ago
Ignoring VSCode's insanely fragile config for this, any debugger with a remote protocol tends to work. Personally I have better luck manually setting up a headless GDB session and connecting with intellij, but it's also difficult sometimes. Since the remote stuff is sometimes an incredible pain to set up and use, I usually install gdb and just use its CLI in the container. That's usually trivial in comparison, and it's a decent skill to learn regardless since so many debuggers use a similar CLI UX. It's extremely cross-platform and cross-language, so you can just jump on a new thing and be a wizard from day 1.
jgalentine007 6y ago
For node / php and python I just expose the debugger ports in docker, and if I'm running docker in a VM I just forward them over SSH. VSCode connects to the forwarded port easily, but sometimes you have to struggle with workspace / source mapping and other issues (like connecting to child processes).

martinald 6y ago

I agree. Debugging docker is a total nightmare across various stacks. I don't know how people bother with it. Like you use it for deployments but not for development. I'd rather have slightly more time setting up a project (which in all honesty is usually a few commands) vs hours/days of flakey debugging.