VScode devcontainers are ideal. You basically debug your code running inside the container.
Programming
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
I am nervous about using them because I already have a docker compose setup and I worry the dev container won’t match what I am expecting. So I just use the standard docker container from my compose file and call that good enough. VScode integration makes it painless enough anyway.
I don't use Docker for development. I find that it just gets in the way, slows me down, and distracts me. It might be a different experience for software stacks that I don't use. I mostly use C#, Blazor, or React Native while coding in a Windows environment. I'm quite comfortable on the Linux terminal as well, but my current professional work all targets Windows deployments.
I do use Docker for other systems that the thing I am working on needs to connect to. For example, I love MailHog for running a local email server for testing. I usually set up a Docker Compose file for a few external systems that my app needs to use and run them while I'm testing, with my app either running directly on my workstation or in a VMWare machine.
The only exception to this is when I write a Docker Desktop extension, where the container is necessary for testing.
I use a volume mount to mount my source code then start up the container. For debugger breakpoints, I attach to the container and treat it like any other process.
You can start up containers with docker manually, but I use docker compose so I can have multiple containers and a checked in yaml configuration for how they should run and depend on each other.
I develop .NET and python on windows in Visual Studio and do the debugging there, then when it all looks stable I’ll commit to git. Then on an arm system, the docker files will pull from git to build the containers, and I’ll do the end-to-end testing there, and rely on the debug logs rather than bothering attaching a debugger.