Including developer tooling in a Docker image is missing one of the really useful things about Docker: not needing all that stuff. By using a multi-stage build, you can do all the slow dev stuff at image build time, then only include the output in the image, and that includes things like building a library which wants a different set of conditions to build than your application wants to run.
It also adds an additional level of risk - if your image is compromised, but all that is running in it is your app, oh well. If it's compromised, and it's able to call out to other parts of your stack (yes, some of this is down to the specific deployment process), that's much worse.
That's a good idea. I usually have a 'myproject-debugtools' container that just operates on the same volume and maybe even shares a network with the 'myproject-prod' container. Just set it to `--restart no` and even when someone forgets to shut it down it'll be gone on reboot. That way all the non-prod stuff isn't even in the image at any point.
Or if that is too much work just have a 'myproject-dev' image/tag if you need to debug a live environment.
It also adds an additional level of risk - if your image is compromised, but all that is running in it is your app, oh well. If it's compromised, and it's able to call out to other parts of your stack (yes, some of this is down to the specific deployment process), that's much worse.