You're probably using Docker wrong. Yes, even if you've used it for years, there's a good chance you're doing something on this list that you shouldn't be doing. So, here's four ways you're probably using Docker wrong, and what you should be doing instead.
Stop launching containers with Docker Run commands
Docker Compose is so much better
For the longest time, I used Docker Run commands to launch containers. I didn't actually use Docker Run, as I use Portainer for my container management, but I didn't use Docker Compose, and that was the problem.
With Docker Run, you have to remember what command you used last time you launched the container if you ever need to make a change to a running container. On the other hand, with Docker Compose, you can just edit the Docker Compose YAML file with whatever new setting you need then re-launch the container.
Switching from Docker Run to Docker Compose in my homelab significantly improved my Docker workflows. I'm now able to jump into a Compose file, make a simple change, then re-launch a container in seconds. In the past, it took me sometimes a few minutes to make a change.
If you're still using Docker Run (or any other method of launching a container besides a Compose file), then it's time to switch to Compose—you'll thank yourself later.
Only use Docker Volumes when absolutely necessary
Bind mounts give you easy read/write access to configs
I've seen people swear by Docker Volumes in the past, and I've considered using Docker Volumes myself, but I just can't bring myself to do it.
A named Docker Volume is when Docker makes a special folder itself in an area where it controls all the permissions. It can be cleaner and easier for Docker to manage, but it's not always as straightforward for you to manage.
The thing with Docker Volumes is they live wherever Docker decides to put them. Typically, this is in/var/lib/docker/volumes/volume_name/_data, but it can vary depending on what system you're running.
Instead of using named Docker Volumes, I choose to use bind mounts. A bind mount is when you tell Docker to put files and folders in a specific place of your choosing. I use Portainer (a Docker management platform) to manage all of my Docker containers.
So, I put all of my bind mounts under/portainer. This makes it easy for me to know exactly where my Docker files are stored, and, it also makes it easy to back them up. I'm in control of the permissions of that folder, and it's easy for me to find it on any system, as I'm the one who decides where it lives.
I definitely recommend using bind mounts wherever possible as they can make Docker management simpler when compared to Docker Volumes.
Put your secrets and variables in a .env file
Stop putting them in your Docker Compose file or Docker Run command
Patrick Campanale / How-To Geek
I think we've all been there—creating a Docker Compose file or Docker Run command and putting a secrete API key, password, or other secure variable in plain text for everything to see. It's convenient, but it's not secure.
Instead of putting your secrets directly inside of a Compose file, you can put them in a more secure .env instead. This is the traditional way of securing environmental variables, and is very easy to do.
For instance, you could name a variableOPENAI_API_KEY=mysupersecretopenaikeyin the .env file. Then, in the Compose file, you can call that variable with${OPENAI_API_KEY}and it will know to pull it from the .env file.
It takes a bit of time to get used to this kind of workflow, and it's a bit more complicated if you're using something like Portainer, but it's definitely safer then just typing the secrets directly into the Compose file.
Stop using individual Compose files for multiple related services
Deploying related services inside one Compose file is just simpler
Using Compose files is a great first step, but mastering them is when you really start to fully realize the power of Docker.
Let's say you're wanting to utilize several related services, like WordPress, MariaDB, and Nginx Proxy Manager. Instead of launching all three services as three different Compose files, you can launch them all inside of one single file.
Combining related services has a lot of benefits. For one, it keeps your system cleaner and tidier. Secondly, when you need to edit one part of a stack, you often need to edit multiple parts, so it saves you from having to open more than one file.
Also, containers that are created in the same Compose file automatically share an internal network that allows the containers to easily talk to each other. So, instead of trying to point WordPress to the IP address of the MariaDB instance, you can just call it using the container name as a variable and it will automatically work.
Docker is extremely powerful, but also easy to use wrong
I've been using Docker extensively for over half a decade now, but only recently did I really start to uncover a lot of the hidden capabilities that Docker has to offer. The thing is, these features aren't hidden as in they're secret, it's just that sometimes the benefits aren't explicitly obvious.
Docker Compose, for example, is something that I've known about for several years, but I never realized just how much better it was then the old way of what I was doing. Now, I wish I would have switched to Compose much sooner. I'm just glad I'm using it now.
So, if you aren't doing the things on this list yet (or you're still doing the wrong things), then make this summer a point to change what you're doing and bring yourself more inline with the industry's standards.
