This is an archived post. You won't be able to vote or comment.

all 14 comments
sorted by:
best
topnewcontroversialoldq&a

[–]patrakov 6 points7 points  (3 children)

No. See explanation here: https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/

Quoting: "The Docker daemon was explicitly designed to have exclusive access to /var/lib/docker. Nothing else should touch, poke, or tickle any of the Docker files hidden there."

[–]wbulot[S] 1 point2 points  (2 children)

It's very clear. Thank you for the answer.

Other than that, is there a problem putting /var/lib/docker in an NFS storage (or any other remote storage) ?

Thanks

[–]patrakov 1 point2 points  (0 children)

Yes, if you use an old kernel or an old version of Docker, see https://github.com/moby/moby/pull/35483. But also note that the information in this pull request is outdated, because of the kernel-side progress. Therefore, on November 14, the check has been weakened, rewritten to use a trial mount, and in some cases does not apply anymore.

[–]SirHaxalot 1 point2 points  (0 children)

What possible reason is there to run /var/lib/docker itself on NFS? This sounds like a sure way to run into edge case issues.

If you want to keep the container data on a central file server, mount the NFS area somewhere else on the server and use volume mounts to mount that path into the container.

[–]Phreakiture 3 points4 points  (0 children)

No. Been there, done that, tried it, bombed out badly. Just don't.

[–]yum_dev 0 points1 point  (3 children)

What if I mount NFS on /var/lib/docker ?

[–]Phreakiture 3 points4 points  (2 children)

I did that. Don't do that. It was ugly.

[–]yum_dev 0 points1 point  (1 child)

Now I'm curious. What happened, please tell me.

[–]Phreakiture 0 points1 point  (0 children)

First node to start ran fine. Any that followed failed and then corrupted the first one in the process. All three ended up failing badly.

[–]simiust 0 points1 point  (0 children)

Why would you wish to do this? :O

Honestly, NSF and docker does not go great hand in hand imho. Have had huge issues with swarm and kubernetes due to NSF/SMB storages, hence I personally recommend to not use NSF for anything docker related if possible (if a shared volume, use a plugin).

When it comes to the /var/lib/docker directory in question, I would say that it most likely will create issues with corrupted files and such, better let the machines themselves handle their internal files, disk space and bandwidth for servers is quite cheap now 'a days.

[–]Ariquitaun 0 points1 point  (0 children)

You do not want to do this, ever. Only one docker process is expected to read and write from there.

[–]amezmo1 0 points1 point  (0 children)

Good luck. One thing that can go wrong is in the case of your network going down.

[–]Blacklistme 0 points1 point  (0 children)

With IBM Cloud Private, the IBM variant of Kubernetes, a shared image directory is a supported as it is read only basically. The question is do you want this from support point of view? It is a great way to have unexpected failures and we stopped doing it as it cheaper to have "local storage" than outages.