4 ms·

I had this problem too when my team first adopted docker, but you can use a conventional debugger if you run your container interactively (with -i.)

clarry 7y ago
Yea, first you just have to get your debugger (and maybe the rest of your toolchain) installed in the container, along with your source code.. and then you run into things like crazy wonky terminal support. Sucks if you want to use a more advanced debugger interface, because you're not going to install that in the container.
- freeone3000 7y ago
  Have you tried using the remote debugger interface? Python and Java have rather robust remote debugging support over TCP.
- madmax96 7y ago
  Simple solution, use multistage builds. In your `debug` build, include a debugger. Use this to debug. In your `release` build, just include the app and its dependencies. Use this in prod.
- EamonnMR 7y ago
  In my case it was just Python using `pdb` so it wasn't so bad. Though it does get extremely janky if you, say, run a server and hit it with multiple requests that all hit a breakpoint... you end up with your input being sloshed across multiple debug sessions!
smoe 7y ago
Question is, if it is worth the hassle to setup for e.g. a small team with maybe 1-2 apps/services. I think docker is great (although I'm more exited about the future prospects of WASM+WASI), but as a default choice for every single project, in my opinion it often adds more accidental complexity to the system than the value it really adds
- Already__Taken 7y ago
  Even just setting up a new laptop it's a win. I could develop across my laptop, office pc, chromebook and home pc with a project and the only dependencies to keep up to date are docker and git pull/push.
  - smoe 7y ago
    How often do you set up a new laptop? And you still need to keep the dependencies of the project itself updated and tested which is the bulk of the work. Don't get me wrong I think docker adds a lot a value once a system / team goes beyond non-trivial scale. But what I often see are three things: 1. people in pre-mvp stage design and setup a system they think will be able to scale to millions of users when all they have is a landing page/email grab. The time is in my opinion better spent pushing the product forward. 2. people hide problems in containers instead of solving them. E.g. not wanting to deal with outdated versions. 3. people confuse something being easy to use with it being simple.

clarry 7y ago

Yea, first you just have to get your debugger (and maybe the rest of your toolchain) installed in the container, along with your source code.. and then you run into things like crazy wonky terminal support. Sucks if you want to use a more advanced debugger interface, because you're not going to install that in the container.

freeone3000 7y ago
Have you tried using the remote debugger interface? Python and Java have rather robust remote debugging support over TCP.
madmax96 7y ago
Simple solution, use multistage builds. In your `debug` build, include a debugger. Use this to debug. In your `release` build, just include the app and its dependencies. Use this in prod.
EamonnMR 7y ago
In my case it was just Python using `pdb` so it wasn't so bad. Though it does get extremely janky if you, say, run a server and hit it with multiple requests that all hit a breakpoint... you end up with your input being sloshed across multiple debug sessions!

smoe 7y ago

Question is, if it is worth the hassle to setup for e.g. a small team with maybe 1-2 apps/services. I think docker is great (although I'm more exited about the future prospects of WASM+WASI), but as a default choice for every single project, in my opinion it often adds more accidental complexity to the system than the value it really adds

Already__Taken 7y ago
Even just setting up a new laptop it's a win. I could develop across my laptop, office pc, chromebook and home pc with a project and the only dependencies to keep up to date are docker and git pull/push.
- smoe 7y ago
  How often do you set up a new laptop? And you still need to keep the dependencies of the project itself updated and tested which is the bulk of the work. Don't get me wrong I think docker adds a lot a value once a system / team goes beyond non-trivial scale. But what I often see are three things: 1. people in pre-mvp stage design and setup a system they think will be able to scale to millions of users when all they have is a landing page/email grab. The time is in my opinion better spent pushing the product forward. 2. people hide problems in containers instead of solving them. E.g. not wanting to deal with outdated versions. 3. people confuse something being easy to use with it being simple.