Others have pointed out that docker containers aren’t idiomatically like VMs and you interact with them differently. Some workflow tips:
Don’t edit configs in containers. Mount your config files as a volume. Edit them from your host using your normal editor and restart your container when they change.
Don’t exec into your running container and then try to install debugging tools as you need them. Use a Dockerfile to build an image that has the debugging tools you need and launch your container using that.
In general, mess with your container less while its running. Use dockerfiles, compose, and entry point scripts to set things up in your container so it’s the way you want it on startup. While its running, just use docker logs to see what it’s doing or run the occasional debugging command via exec if you must… but do more during container-build and startup and less after it’s running. Rebuild and restart the container a lot during debugging to make your changes take effect.
The other issue in play here is that the fundamentals necessary to understand how docker containers run aren’t actually docker fundamentals. They’re:
Networking fundamentals. The container networking stack is really configurable and really complicated.
Volumes and config mounts are based on overlay filesystems.
Lots of docker issues are related to complex security systems like Linux capabilities.
All of these systems are configurable, and different docker setups use them different ways.
These things aren’t trivial to learn, a thorough understanding of these things is the difference between a junior sysadmin and a senior one, and you WILL get exposed to them when things break. But step one in learning more is definitely to recognize that the hards parts of docker are rarely docker itself. Rather, the hard parts are their own thing. Figure out what Linux system you’re struggling with and start learning about that and how docker uses it rather than narrowly focusing your research on docker itself. Anything focusing on the docker piece must necessarily gloss over the real foundations which are often very complex… so this will start you expose you to deeper material that you can assemble in your own mind into an understanding of your own specific docker setup.