Docker-like overlayfs in runC #1040

Closed
ianpark opened this Issue Sep 13, 2016 · 3 comments

Projects

None yet

3 participants

@ianpark
ianpark commented Sep 13, 2016 edited

Does runC support any similar feature like below?
[https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/]
Any file change in a container created by runC will remain in the rootfs, and also affects to the other containers created from the same rootfs. I know you can prevent messing the rootfs by settingread-only but in many cases we also need a container with full disk access. You can do this using Docker, so maybe runC also could do this?

@cyphar
Member
cyphar commented Sep 13, 2016 edited

There's nothing like this "built-in". You can use overlayfs and make the upperdir point to somewhere in /tmp (so the changes are completely lost once you kill the container). The reason this works is because the lowerdir in overlayfs is always considered to be "read only" (it is never changed, all of the changes happen in upperdir). This is basically how things work inside the Docker overlayfs graph driver -- the only difference between runC and the graph driver is that there's no such thing as an "image" in runC. In Docker, they have to do the hardlink tricks to share rootfs instances. If you want to do the same thing, you are free to do it manually (or take the code from Docker to do it).

If you don't want to use overlayfs directly (even though you are already), @mrunalp was working on making it possible for you to mount a tmpfs "over" a mountpoint and essentially we will copy up the contents of the mount into the tmpfs. However, since you have the ability to use overlayfs I wouldn't recommend this method (it is quite expensive in terms of virtual address space, as it will copy every file to a tmpfs). Here's the PR: #845.

@hqhq
Contributor
hqhq commented Sep 14, 2016

runc is a runtime engine, the overlay support is more like a image graph driver work, which I think we can depend on a image-spec implementation (we don't have the concept of 'image' as @cyphar said), unfortunately we are not there yet, once we have, they can combined together and do something like docker overlay support.

@ianpark
ianpark commented Sep 14, 2016

@cyphar @hqhq many thanks guys!

@ianpark ianpark closed this Sep 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment