File: engine/tutorials/dockervolumes.md, CC @mstanleyjones
Using volumes in docker-compose has very little documentation. If there are corresponding commands in docker-compose then, IMHO they should be written here as well.
I'm not sure we should document things that are specific to docker-compose in those articles, but we should definitely improve the docs on how to use volumes in your compose files.
As an example, this article deserves to be reviewed, since it uses two different syntaxes for using volumes.
Given that the syntax
image: nginx:alpine
volumes:
- type: volume
source: mydata
target: /data
volume:
nocopy: true
- type: bind
source: ./static
target: /opt/app/static
is easier to understand, we should start removing from the docs instances of the old syntax
volumes:
- "/var/run/postgres/postgres.sock:/var/run/postgres/postgres.sock"
- "dbdata:/var/lib/postgresql/data"
There is a lot of confusion about what the internal docker volumes are and how are they different from the ones that are mounted. I am not sure where that should reside, the things referred to in volumes page mostly apply to docker run statement.
We could describe details about volumes in the same page or in the docker-compose volume section. Describing how internal docker volumes are different from the ones that are mounted.
Maybe I'm not really understanding your problem 馃
Can you clarify what do you mean by
There is a lot of confusion about what the internal docker volumes are and how are they different from the ones that are mounted
I think my confusion is around what "internal docker volumes" and "mounted volumes" mean to you?
Keep in mind that there is not right or wrong answer here. Just the fact that we're discussing volumes, shows that there's room to improve the docs 馃槃
Internal docker volumes are labeled volumes. They seem to be very useful and free from any problems associated to ownerships and user ID mappings.
When mounts are made by mapping volumes from host then user id mappings are not made.
The fact that userId mappings are not made, can be included in docs. I recently had this problem in logging mysql
Got it! Also don't forget that docker volumes are more portable, in the sense that if they don't exist Docker will create them for you.
When mounting, if the directory doesn't exist in the host, Docker will not create it, and fail to run the container.
The --mount option in the tutorial is new I believe and that improves things for docker run.
But I don't understand how could it be used in compose. In this article we should also mention about arguments that could be used with options:
Example:
volumes:
-type: <possible_variations>
Hi @AyushyaChitransh, I'm sorry you've had trouble understanding what volumes are all about. You might find the new guide about managing your application data helpful! There are specific topics under that heading about volumes vs bind mounts. There are a few key differences between volumes and bind mounts.
After you understand the differences between volumes and bind mounts and know which one you want, check out the volume configuration reference for compose. When defining a service using a Compose file, you define the volume as a top-level element and also mount it into the service. To see the differences in using volumes vs bind mounts in the compose file, see the example which shows both in action.
It's on my list to add some Compose examples to the Managing application data article, but for now hopefully this will help clear up your confusion.
That was very informative :smiley: and after the updates, I believe this issue should be closed now.
Most helpful comment
Hi @AyushyaChitransh, I'm sorry you've had trouble understanding what volumes are all about. You might find the new guide about managing your application data helpful! There are specific topics under that heading about volumes vs bind mounts. There are a few key differences between volumes and bind mounts.
After you understand the differences between volumes and bind mounts and know which one you want, check out the volume configuration reference for compose. When defining a service using a Compose file, you define the volume as a top-level element and also mount it into the service. To see the differences in using volumes vs bind mounts in the compose file, see the example which shows both in action.
It's on my list to add some Compose examples to the Managing application data article, but for now hopefully this will help clear up your confusion.