-
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
Signed-off-by: David Karlsson <[email protected]>
Signed-off-by: David Karlsson <[email protected]>
✅ 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?
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.
f43d4de
to
28e9388
Compare
Signed-off-by: David Karlsson <[email protected]>
28e9388
to
710cae8
Compare
Various freshness updates to improve the flow and structure of the documentation related to storage mounts.
Preview: