Docker Community Forums

Share and learn in the Docker community.

DTR Filesystem Storage Backend Cannot Change

After installing DTR on a 3 Node UCP cluster, I looked into DTR > Settings > Storage and then the Filesystem storage backend only to find that there wouldn’t be any option to change my filesystem storage directory from the default docker volume path to my non-default path.

Looking at the docker config storage guide:

I can see aside from the UI there is a way to upload a YAML file to do the same thing. S3, Azure and Swift all have their menus with Save buttons show without error and I’m not sure if this is a bug with dtr 2.1.3 or if I had misconfigured something. Also, would it be possible to configure dtr container volumes on installation? Thank you for your time.

Through Docker support I have the answer, which is the KB listed here:

I thought that there might be a GUI way to do this but the solution is simple enough.

What type of storage are you using to back the cluster? If you’re using NFS, the preferred method is to use the –nfs-storage-volume option. The KB article is a bit out of date, so I’ll follow up with the storage team to get it corrected.

Thank you for the reply, we would be using NF, and with this correct option it would be:

mount -o --nfs-storage-volume /nfs/on/system /var/lib/docker/volumes/docker-registry-$REPLICA_ID/_data

like this? I was thinking I would need to add a volume driver for NSF but with that option I would imagine I should be able to mount with that.

Sorry, I mistyped it earlier! It’s actually --nfs-storage-url. If you’ve already got three DTR replicas installed, you can use the docker run -it --rm docker/dtr:[version] reconfigure [ucp options] --nfs-storage-url [nfs path]. You can also specify it when you’re running install, and it will automatically set up any new replicas when you do a join.

The NFS path should look something like nfs://myhost/mountpoint, and will automatically configure all of the required client settings for you. You can see the docs here:

That did it perfectly. If you wouldn’t mind me asking a bit more, now that this is done and I know how to add replicas with NFS, would I see my images and all other data somewhere inside my mount-point? I was hoping I could configure something with nfs://myhost/mountpoint /path/on/server but would I be thinking about it wrong?

Yes and no. What DTR is doing here is creating a docker volume which is backed by the NFS mount point. If you want to see what’s inside of the volume, you can use the command docker volume ls to find the actual volume name (it should be the one with “dtr”, “registry” and “nfs” in the name). You then have a couple of choices.

You can either docker volume inspect <vol name> which should list out the mount point and you can just access it on your local file system, or, alternatively, you can mount that volume to a new container and look inside of it with something like docker run -it --rm -v <vol name>:/nfs alpine sh. That will create the new container, mount the volume and run a shell. You can look in the /nfs dir to see what’s inside of it.

So when I go to my DTR Web UI > Settings > Storage and I see dtr-registry-nfs-4a58bcd7746a and then run the volume inspect, following the path I see exactly what you mean now. I very much appreciate the detailed responses here but would have one more question/comment if I could:

as I created a separate directory specifically for DTR, is there any way to specify a mount point target destination after the mount? My concern was that now that its mounted to the root of the NFS share that its going to put all of its files within the root directory instead of an organized separate directory. Or, is this just by design and I’ll have to create a new NFS share solely for DTR? Perhaps in terms of security best practice this may be better anyway. Thanks again.

I believe you should be able to specify that as part of the path in your NFS URL. i.e. nfs://<myhost>/my/custom/path would point to your customized path inside of your NFS export.

Perfect, this was a lot of help, thanks again.