Enable use of paths instead of volumes

[fryfrog]

Hey, I think you can pretty easily enable the use of paths instead of volumes. On mine, I just pass them into the right place. And for the database, a quick initialization in the case of an empty folder does the trick.

See https://github.com/fryfrog/unifi-protect for details.

PS: Thanks for using macvlan which gave me the hint to make mine work! :)

[jameslikeslinux]

Thanks for the suggestion, but this need is met by bind mounts, as documented in the README. In my opinion, mapping directories directly should be reserved for getting data into a container. Named volumes are the correct tool for persisting internal app data, as this is. Again, that's just my opinion, and I'm glad it looks like we will have many robust UniFi Protect images in the community, assuming Ubiquiti allows it, or at least looks the other way.

[fryfrog]

Do you consider the actual video files as internal app data? Seems like at least those should be stored in a way that is easier to access than volumes.

Edit: I guess creating the volume somewhere else accomplishes that.

[fryfrog]

I've not really run across this opinion, is there somewhere I can read about it? It actually makes a lot of sense, especially for the postgresql db stuff.

[jameslikeslinux]

I consider the actual video files as internal app data because its format and storage structure has not been documented by Ubiquiti and is subject to change at any time. In the particular case of UniFi Protect, the video files are in a proprietary format, so they aren't much use to a user anyway. There is still value in being able to get at the data to back it up and put it on the right class of storage, and both of those needs are met by named volumes.

Docker describes the following benefits of named volumes over mapped directories, or bind mounts, as they call them:

Volumes have several advantages over bind mounts:

Volumes are easier to back up or migrate than bind mounts.
You can manage volumes using Docker CLI commands or the Docker API.
Volumes work on both Linux and Windows containers.
Volumes can be more safely shared among multiple containers.
Volume drivers let you store volumes on remote hosts or cloud providers, to encrypt the contents of volumes, or to add other functionality.
New volumes can have their content pre-populated by a container.

See: https://docs.docker.com/storage/volumes/

For me, the clear benefit is that Docker initializes the named volumes with the contents of the directory inside the image. That means I don't ever have to worry about whether or not the volumes need to be initialized; I don't have to worry about what to initialize them with; and I don't have to worry about permissions because all of it is handled for me.

[fryfrog]

In the particular case of UniFi Protect, the video files are in a proprietary format, so they aren't much use to a user anyway.

Dang, they're not even .mp4 or whatever like Unifi Video?

Thanks for the details on volumes vs. bind mounts, I'll poke around and maybe switch mine to it. I guess since you have to create the folders for a bind mount before docker run, it isn't much different than creating the volumes.

Thanks again! :)

[fryfrog]

Also, I'm not super familiar w/ postgresql, but why don't you need to preserve the /etc/postgresql/10/main? Is it because you're initializing it every time and it doesn't actually contain any unique data?

[jameslikeslinux]

As far as I can tell, there is no variable data in /etc/postgresql/10/main, so I've just baked it into the image. When we rebuild the image, /etc/postgresql/10/main may change depending on any updates from the Ubuntu repositories, but that would not be so different than if we did an apt-get upgrade on a real host.