Sounds good, the last question I have with this, are you using mergerfs, unionfs, or a similar tool with this?
How has it worked so far?
Without deploying it now, I am having a hard time fully grasping how this would work. I have not used volume mounts with Docker before, but, I assume that is what you are doing? Since the bind mount would only be usable in the container hosting it, unless you do bind propagation?
EDIT: I also might be 100% overcomplicating this. Haha. If there is a blog post or something available around this - happy to read it. However, generally, I haven't found one yet (specific to rclone, mergerfs, and *arr/plex) that isn't related to a AIO NAS system.
I'd simply ask, why are you using a docker at all?
Dockers are good for moving and installing things quickly and scale. We use them to scale applications and installs horizontally across instances as they have some great use cases.
It really over complicates a Plex/rclone setup and adds another layer of virtualization to the setup when it's really not needed.
Self-recovery - If anything breaks, it should recover itself if proper health monitoring/checks are in place. Plex already has checks in place (*arr's are missing it). I also don't have to take down the entire system or restart all docker containers to potentially fix an issue that would require me to restart the docker service to be able to "see" the content hosted under a mount point.
Declarative deployment - I can roll back or roll forward the deployment if something goes wrong, or I want to tweak/mess with things. I can't do that (as easily) with non docker deployments
The ability to run multiple *arr's on a single host - Since several of the *arr's don't properly support specific features (having both 1080p and 4k files, multi-languages, etc), and if you do run multiple on a single host, usually the update process breaks the deployment.
Docker is the way forward - Don't think this needs an explanation.
Dependency Hell - Some applications are a pain in the ass to deploy manually without docker because lib dependencies cause issues on systems (rtorrent/libtorrent)
Coupling all of this together, it makes more sense to move forward with putting everything in to Docker so I can lift and shift the system anywhere, as this seems more efficient then potentially about having to worry about one off solutions when I can cut down time by just running everything under Docker.
I understand it adds complexity, but, it only adds complexity in the fact it isn't running on a traditional OS (this is obviously a broad look at it). Everything else, the underlying applications, are generally still operating the same way.
So I swear I'm not being picky as I'm legit just trying to learn and understand more use cases so take in an eager learning and getting more view points so please take it that as I break ask a few more question
That's independent of a docker though and just standard monitoring. I can't say I've had anything restart in months/years. Docker or not, most of those apps are just stable and they work. Rclone itself is rock solid.
What do you mean with this? If Sonarr is down or something?
+1 here as I fully agree with this statement although the use case is a home media server not an enterprise app. If I need to roll back Plex, I just roll it back. Docker or not, don't you just left Sonarr/Radarr/etc auto update anyway? I can't say I've checked versions or mess with anything for quite some time.
The industry ebbs and flows and over the years we had started with containers and called them something different as we had this years ago in AS400s It shifted to big boxes and shifted back again to containers/microservices/etc. I go with the right tool for the job. I'm running a media server in the basement so the more simple it is, the better it works. If you move to enterprise use cases, we can debate when a container makes sense and when not as they are great uses cases for both. I've yet to move my home media server anywhere other than my basement and if I wanted to spin a new one up, it's got a build script via ansible as there are many tools to leverage for the right job. I also like the fact I control my software choices and I'm not dependent on someone else's docker. If that person does a bad job, you'd suffer so you have trade offs when you depend on someone else's docker.
You don't hit any issues with Plex/Sonarr/etc as the one problem you do list that I agree with is rtorrent, but I'm a qBit guy anyway so I just use the PPA for that. A docker is a great use case for VPN/torrent client so for me, it just depends on the job as they are great fits for the use case.
I guess the overall point I make is the average user at home with a media server doesn't need dockers as it adds confusion to them. A savvy guy like yourself would benefit and use them well.
What do you mean with this? If Sonarr is down or something?
I mean this:
Sonarr, Radarr, etc, are missing these but Plex implements them. This is mainly an issue of LinuxServer's docker container not adding them tbh. Not a fault of Sonarr or Radarr dev team.
A lot of my issues could be due to configuration issues. I notice that my memory usage is high with rclone, but, with that said, I also have several separate rclone instances running, because of the amount of data I am storing (not just for media, I also have book collections, home media/photos/movies, archives, etc).
This tends to eat up a lot of memory usage (I think I am hitting 30 GB right now).
Otherwise, I would agree that for the most part everything has been solid so far. I could easily run this all on baremetal + os if I wanted to. However, I really have an intent to learn the ins and outs of docker and kubernetes and this is an easy(ier) project to do so on.
