Hello,
I am relatively new to Docker containers, and their inner workings. I am also relatively new to some advanced Linux concepts. Most of my questions get answered by documentation or some tutorials, but a few I still have to ask. This will be a longer text, so I am thankful to anyone willing to spend time reading it. I’ll try to emphasize sections and questions.
My environment is a Proxmox cluster of three nodes and a few Windows machines. Some nodes have a Debian 11 or 12 VM containing Docker installation. All the running containers are Compose-based. I am hopeful that I will be able to make some informed decisions and change all the different YAML files to a personal standard that I would follow with all the future containers I’ll add to my servers.
Bind vs Docker Volumes
Initially, I started with compose
files in form as I found them made by developers of various products I used. I did not trust the Docker Volumes and tried to use bind mounts whenever possible. Since I am more often running into compose files where I am not able to switch to using bind mounts I have to learn more about Docker Volumes. Often I read that Docker Volumes are better than bind mounts, but I did not find the reasoning behind it. So, the first question is:
What makes Docker Volumes a better solution than bind-mounted folders?
My primary concern is the data safety of content inside Volumes and the ease of accessing data from the base system (in my case the VM). I am concerned that something like docker volume prune
would delete important data in the Volume of a container that is not running at the moment. The message following the prune command says that it will remove all anonymous local volumes. However, I could not find what exactly the term means, or what makes a volume anonymous.
If I pass the volume name:
property through the compose file, does it make the not anonymous and safe from accidental deletion?
I’ve also read a few times that Docker Volumes are simpler to manage than binds, but each time without any explanation. What makes them simpler to manage?
Docker root access
There is much controversy on this matter. Many are saying that the docker command shall require the sudo elevated privileges, and others do not agree. Since all my installs followed the official guides I ended up with a system asking for elevated privileges even on basic commands like docker ps
. On the plus side, I see it as a good thing because I never had a folder/file privileges problem since docker is always run as a root. But, I do not know if there are some dangers of using root for all the docker-related commands.
The other questions are more Docker-related Linux questions than Docker questions, but I’ll put them here anyway.
Docker Compose data location
Since my installation is on a single-user VM I put all the relevant data in a docker-related folder inside the user’s home folder. The general structure is: /home/user/dockerdata/container-name/
and inside it is the compose file, an instructions file (for updates and other activities on that container, maintainer link, …), and a set of folders bound to the locations in the container (usually a config folder, a persistent data folder, and one or a few CIFS mount points for external data used by a specific container, like media or documents from another VM on another Proxmox node).
I’ve read that some suggest that one can put that persistent data and config folder anywhere in the file system, some suggest anywhere except the home folder, and some suggest various filesystem folders lie /srv. /opt, /var/lib, … Is there a single right answer to that question? What can be the drawbacks of some locations?
Docker VM running out of space
All my VMs are on Proxmox thin client LVM, and I could give them big partitions. However, since I cannot deflate the once-used space, I try to be conservative, too conservative it seems. I found out that 32GB is not enough, so I opted for 64GB when I remade one, but after having one or two containers pull some metadata from the web it soon also ran out of space.
Recently while researching Nextcloud compose file and documentation, I stumbled upon these instructions explaining how to move the whole Docker folder to another location. They suggested adding a daemon.json
file inside /etc/docker
and adding a new location inside a "data-root:"
property. That gave me the idea that I could put the whole /var/lib/docker
on another virtual disk and if needed exchange it for a bigger one without having to install/reinstall the base system.
What would be the dangers or problems associated with that approach?
Would it then be wise or unwise to also put the compose, and all the other instructional files in a folder inside /var/lib/docker
on the other virtual disk and have a single location to back up all the important data?