Recent searches
Search options
Administered by:
#GlusterFS was the right choice. My cluster is working so well now. I have a few more things to learn about networking to get my setup perfect, but it's getting awfully close - I am offloading services from the ancient MacBook, and should be able to remove it from the top of the cabinet just as soon as I figure out the best way to host #FoundryVTT in #Docker.
After a few months, I've migrated everything to my cluster, removed the old MacBook, even got 2 versions of #FoundryVTT running and a couple other fun services.
The problem is even though #GlusterFS was the right choice in the moment, *arr apps absolutely HATE network storage. #SQLite is the culprit, and the devs for #Lidarr, #Radarr, #Sonarr, and others appear completely uninterested in switching away from SQLite. I would prefer #MySQL, but evidently, even though this issue repeatedly comes up, folks like me who want to run *arr apps on a swarm are edge cases.
So, I could restrict each app to a specific node, which I don't want to do because a couple of my nodes will randomly stop working and require me to manually restart them. Or, I can continue to put up with DB corruption, which is proving to be a real pain.
Or search for another solution to replace *arr? Truth be told, I use Lidarr the most and it isn't super great at what it does.
I think #Lidarr would work well for folks who want to keep up with current artists and grab their latest releases. My music tastes are for older artists who aren't releasing anymore. Aside from the nice GUI for grabbing torrents from various trackers, I don't really need it to download music or to sort it - #Beets does an awesome job keeping my music library sorted and up-to-date.
#Sonarr is the one I definitely need to keep, I grab some kids shows with that. #Radarr can be replaced or removed - it's nice to keep up with movie series and download recent releases in those series, but otherwise I can just find movies myself.
Looks like I will need to research a replacement for Lidarr. Dunno why I felt committed to making it work when it refuses to play nice on swarms.
I think I have one other service that uses SQLite on my swarm, but I don't use it nearly as much and I haven't seen it throw problems like *arr does.
Apparently I'm an idiot, and I'm glad I popped into the *arr Discord to ask. #Lidarr, #Sonarr, #Radarr, and others have a #PostgreSQL option that's a bit more setup but works.
In my defense, in all of my searching for a solution to *arr using SQLite on Docker Swarm not once did I come across any indication that they had support for another DB. In fact, it seems like I came across indication that the opposite was true.
Regardless I have a project now for after we get back from camping this week. And with any luck, I'll finally stop losing my mind with DB corruption issues and have a more robust setup.
@juddium I run my servarr apps in a small k3s cluster with Longhorn as storage solution and I have no issues moving my apps between nodes. The config and dbs live in a Longhorn volume, which is replicated across my cluster and backed up to object storage. When a deployment moves to a different node Longhorn takes care of it all.
Media storage can stay on network storage if you want without any issues.
@douglascamata I'll have to take a look at Longhorn, although I kinda like this Postgres solution as all of my *arr app data is in one place. Still, if Longhorn does a better job of replicating data than Gluster that will be something for me.
@juddium the only issues I had operating Longhorn were:
1. They had a problem with the Helm chart when used together with ArgoCD. Something about how ArgoCD installs the chart and its impact on charts using hooks to run migration Jobs. This was fixed somehow.
2. I didn't name my PVs and PVCs myself. Made backup restores require some manual fixes. Now I named them all and it's smooth. I intentionally ran through a DR scenario to test it out.
I also like their Web UI. Pretty neat stuff. I never tried anything else in my homelab before, so I'm biased.