How does boot2docker persistence work?

Archive Boot2Docker
1

I can’t find much about how boot2docker persistence works, i.e. how /var/lib/docker is saved? I gather /etc/rc.d/automount sets thing up but I’m not familiar enough with many of those commands to figure out what’s going on. My rough reading is that if it finds a volume labeled boot2docker-data, it uses this, possibly formatting it if necessary? If running boot2docker inside VirtualBox, this means this volume is a Virtual Harddrive right?

Ultimately what I’m after is if it’s possible to switch things so /var/lib/docker is actually a mounted VirtualBox shared folder. I’ve tried doing this and I get errors that look like this:

$ docker pull busybox
...
8c2e06607696: Error pulling image (latest) from busybox, endpoint: https://registry-1.docker.io/v1/, Untar re-exec error: exit status 1: output: symlink busybox /bin/ash: read-only file system
8c2e06607696: Error pulling image (latest) from busybox, Untar re-exec error: exit status 1: output: symlink busybox /bin/ash: read-only file system

So is it possible to use a mounted Virtualbox shared folder for /var/lib/docker, or does this conflict in some way with how persistence is currently handled, or maybe its just not possible at all?

Thanks.

2

yes, you are reading it right.

however, there is pretty much no way that you (should) be able to use a virtualbox shared folder for it - that pseudo-filesystem isn’t complete, nor performant enough.

I’m expecting that your docker daemon will have tried to use the aufs driver - which needs something like ext4 as the underlying fs (which vboxfs is not).

There is one thing you could try though… (goes off to read a few things)

3

yup - there is a vfs storage driver you can try - its a really really bad idea, but it might work.

the real question is - what is the problem you’re trying to solve? There may be a real solution, which doesn’t involve something that no-one will support :slight_smile:

4

I’m extremely glad to see that docker pull debian fails when using vfs on vboxfs - perhaps we can add a test to docker, so that it doesn’t start in the first place.

5

Thanks for the response. Ok, sounds like this isn’t going to work, and I’ll take your advice to stay away from non supported solutions. Knowing little about the details of file systems, I’m still curious in what way is vboxfs insufficient for what Docker is trying to do?

The problem I’m trying to solve is that I’m building a way to run Docker apps on BOINC systems. BOINC already has a nice way to run VirtualBox, and I was simply using that to boot into a boot2docker ISO and run things straight from inside there. Doing persistence in the scenario with a shared folder would not have required any modification to the BOINC VirtualBox “driver”, whereas without it I think I will need to.

6

ah, ok, in that case, you don’t need the docker directory to be on the vboxfs, you only need the container’s persistence directory to be volume bind mounted to it.

ie, don’t move /var/lib/docker, but rather run your BOINC systems in a container like:

docker run -v /Users/your_account/boinc:/wherever/the/container/stores/stuff -d boinc --attach_project ....

that would mean that the BOINC data would be stored on your OSX box, without trying to store your entire Docker images and container filesystems there.

7

I may not have explained clearly enough, or maybe I’m just not understanding your suggestion. The idea is that I run a BOINC project, and the program I am sending to my users to run is a Docker app. The users receive a (slightly modified) boot2docker ISO, and BOINC provides a nice easy way to boot that up in VirtualBox. Inside that VM there is a docker pull and docker run performed, and when the computation is done the VM shuts down. Because the VM is started by this BOINC Virtualbox wrapper, the persistence drive is not set up correctly as if it had been booted by the BOINC Win/OSX client, so next time around docker pull has to redownload everything. Setting that up correctly requires modifying the wrapper, which I was trying to avoid.

8

Btw, is it possible that you could point me to where in the boot2docker-cli code it sets up the persistence drive?

EDIT: To answer my own question, its fairly easy to follow what needs to be done to manually set up the persistence driving starting here.

9

Can I ask a follow up question / possible workaround. Is there anything wrong with shutting down Docker, tar’ing up /var/lib/docker, then at some later point untar’ing it back and starting Docker up again? Will some aspect of the filesystem not be correctly captured by tar?

10

For what its worth, this “persistence via tar’ing” has proven to work perfectly in practice. I’m curious to get any of the developer’s opinion though on how robust this is and might be in the future?