Echoing the sentiment that you should adjust your perspective in approaching containerization, otherwise you’re in for a tough time.

Jerome Petazzoni, one of the more recognizable names in the container community, has a site where he puts all of his workshops, slides, etc. This is his one for getting started with Docker.

Sounds like you, like a lot of others, have come to docker from the perspective of “it’s like a mini virtual machine”. Maybe you’ve used VMs before, like virtualbox or VMware or EC2. Maybe you have experience with setting up a cluster of VMs, each with their own OS, own SSH client, own suite of applications, and an overlay network between them all. Maybe someone told you “you should use docker instead, it’s like mini lightweight VMs”. And you’d be right to assume this is the wrong perspective to approach docker, because it leads to the problems you have faced.

Instead, try to think of docker containers as standalone applications. They don’t contain a kernel, they don’t have SSH, no Nano or VIM, just simply the Application, in a container, with enough supporting filesystem and OS libraries to make the application work.

That perspective is what helped me to get better at docker, I know it’s not exactly answering your question, but it might help.

It doesn’t make any sense to me from the perspective that I’ve approached it.

I think you’ve already identified the issue. Docker is pretty “simple”, but you’ve got to approach it from the right angle or else it doesn’t make sense. Apart from suggesting the official documentation I can’t give you much advice on how to learn it because my path to understanding Docker was pretty much just trying things out and iterating on it. That said here’s a tips that could help:

• If you aren’t using Docker Compose already, you really should. Just having your entire configuration for a service in a single file really helps.
• Aside from debugging, you normally aren’t meant to run commands manually in a container. It’s best to act like every container is just a black box that simply does its thing.
• If you need to edit config files, the easiest way is to just directly on the host if you’re using bind mount volumes, or spin up a temporary container running Debian or Alpine for example that also has the Docker Volume mounted.

As @housepanther@lemmy.goblackcat.com has already mentioned, building your own images is also pretty helpful since it strips a lot of the “black magic” away and teaches you how to further “mod” existing images.

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.

Some pointers that might help you:

You can mount the same directory in multiple containers. So you can totally have a container reading files from a directory, and access the same files on that directory from, say, a VSCode server container. Just make sure the containers both use the same UID and GID to prevent permission issues.

I started learning docker first by how to customize an image. Since Alpine Linux is a popular light weight distro, I started with customizing it and moved from there. I also explored other people’s Dockerfiles to see how to use a Dockerfile to customize an image to containerize an app.

I found almost every YouTube howto on the subject matter very frustrating and often making the assumptions that you note. I also read the reference documentation on docker’s website. It’s not easy and it’s time consuming. I’d say I am good enough to be dangerous, not much more than that. Mostly, I’ve modified other people’s images to suite my needs

This might not be a popular opinion, but I had a very short period of time between graduating school and starting work where I needed to learn docker and I found this course: https://serversforhackers.com/shipping-docker to be very helpful, they had a sale and I got the course and it taught me everything I needed in a few days.

You absolutely don’t need a course to learn it, but sometimes these can be easy shortcuts.

Lots of great information and suggestions in this discussion. Thank you everyone who are offering your input. I’d like to ask as well, how easy is it to setup docker for use in windows? I ask this because almost every guide I’ve found has docker running in Linux. I realize you are able to setup a docker in windows, but I was struggling to get basic instructions for windows, and even the tutorial in docker required me to switch back to docker types that don’t work in windows.

I took a look at Dashy, I think I see the confusion. If you are looking at this article, then yes they mention Code Server, but that’s purely in the context of using Dashy in a non-docker context. But to be honest, any text editor works.

But I think that’s a red herring. That in itself has nothing to do with docker.

What you’ll need to do, once you understand the fundamentals of running docker, pull images, start a container based on an imagine, is to expose a docker volume that points to /public/conf.yaml. A docker volume ensures that the file or directory it’s mapped to in the container is available and persists outside of the container. This allows you to persist files and directories without losing them once the container stops or restarts.

Once the volume is exposed, then you can use your favorite text editor to update the dashy config file. Code Server is fine, powerful, but overkill.

But first, try getting familiar with pulling, starting stopping docker images using the cli. Gotta start there first before tinkering with docker parameters like volumes.

Containers are hard. This should at least get docker running without sudo: https://www.baeldung.com/linux/docker-run-without-sudo

I’ve been using my library’s membership to LinkedIn Learning to take a Docker Essentials course