-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
engine: storage/mounts freshness #21420
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
f12ad59
to
f43d4de
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just some first comments; will need to take a closer look later
- [Volume mounts](#volume-mounts) | ||
- [Bind mounts](#bind-mounts) | ||
- [tmpfs mounts](#tmpfs-mounts) | ||
- [Named pipes](#named-pipes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is still so odd to have in this section (as it's not about storage). Not sure what a good solution is though to distinguish it from "storing data").
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should consider/frame named pipes as a type of bind mount?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Named pipe is a separate mount type (type=npipe
) in our API, so from our perspective I don't think it should be put under a bind mount (type=bind
).
However, on the lower level it's still a regular mount AFAIK.
For performance-critical data processing, Volumes are the best way to persist | ||
data in Docker, as they're generally speaking faster than bind mounts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also somewhat relates to that, because the storage location used is on the daemon host, so you'd get the same raw file-performance as you'd get when running directly on your host.
Use bind mounts when you need to be able to access files from both the | ||
container and the host. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the place to mention the pitfalls?
- bind-mounts happen from the host where the daemon runs (docker desktop mostly takes care of that, but it means that you cannot bind-mount a local directory if the daemon is remote)
- bind-mounts grants your container access to your host; you're punching a hole in its security boundary, so never grant it access to paths it should not have access to.
There's also the difference between volumes "propagating" the content from the image, and for bind-mounts it's purely "grant access" (but don't copy files to the location).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this information is for here, but we should include it on the bind mounts page.
28e9388
to
710cae8
Compare
from the container runtime. | ||
Volumes are persistent storage mechanisms managed by the Docker daemon. They | ||
retain data even after the containers using them are removed. Volume data is | ||
not directly accessible from the host filesystem; it can only be accessed by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not directly accessible from the host filesystem; it can only be accessed by | |
not directly accessible from the host filesystem; it can only be accessed by |
Well, technically it is 😅 But we consider volumes to be managed by the daemon and only support interacting with them by mounting them to containers.
Perhaps we should phrase it more as: it is stored on the filesystem, but you should only use them via mounting to container and direct access is an undefined behavior.
A tmpfs mount stores files directly in the host machine's memory, ensuring the | ||
data is not written to disk. This storage is ephemeral: the data is lost when |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ensuring the data is not written to disk
Note: While it's true in general, as in the content is not persisted, in some cases the data MAY be written to swap (and so written physically on the disk).
Perhaps we should clarify that tmpfs
directly maps to the kernel's tmpfs
mount: https://en.wikipedia.org/wiki/Tmpfs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good callout!
710cae8
to
7eeb4a0
Compare
Signed-off-by: David Karlsson <[email protected]>
Signed-off-by: David Karlsson <[email protected]>
7eeb4a0
to
0ace39d
Compare
Various freshness updates to improve the flow and structure of the documentation related to storage mounts.
Preview: