I bought an Intel NUC 10 Performance Kit equipped with 32GB of RAM, 256GB M.2 nVME SSD, and 2TB SATA SSD. I currently have ROCK installed on it and it is running just fine. I’m new to Roon but am a tech-savvy person.
At this point, I feel that the hardware I have is too powerful for ROCK alone and that I can use it for other purposes. I’m planning on wiping everything and replacing the OS with a standalone Debian Linux and just use docker containers for both the Roon Server and Plex Media Server.
Questions:
Is there any reason/disadvantage of using a Roon Server docker container compared to just using the install script available in the website? Of course, the docker container adds overhead but that I think that’s negligible. It’s how docker technology is designed in the first place. I have a couple of docker containers in my Synology NAS so I’m familiar on how to use it.
Is there a recommended container in docker hub for the Roon Server? This is the most updated container with a lot of downloads that I saw.
If I decided to install Roon directly to the Debian Linux OS, what package pre-requisites are needed?
The biggest concern with using a docker container compared to a traditional install is that it adds a layer of complexity to manage. Many people use docker containers with Roon without a problem, but we’ve also seen issues pop up stemming from the configuration of a docker container.
If you’re comfortable with maintaining a docker container and configuring settings as-needed, great! If this isn’t something you know much about, it could add some complexity if things go wrong. Docker containers are technically something we consider to be in the #tinkering realm, and while they can be a good option for some, our support team does not assist with the configuration and troubleshooting of docker-specific issues.
I understand. So there’s really no fully-maintained docker container, right? Not like other containers, there are devoted groups (like LSIO) that maintains their containers and we just consume them and update as needed. I’m not an expert in container maintenance, I must admit, but I thought the container I linked to above is maintained. I’m not 100% sure though.
So if I understand correctly, if I’m installing the Roon Core I just need to install the Roon Server and not the Roon Bridge, correct? Roon Bridge is mostly for endpoints like Raspberry Pi’s?
There is very rarely officially maintained Docker containers from companies. They are almost always done by someone else, even Unifi doesn’t provide official containers. Because containers are… not the solution. Kubernetes is about the only thing that makes sense, and that’s for stuff you build and run yourself. Docker is especially bad at doing updates, since it operates on the “throw everything except the config directory away and replace it all” mentality. And that’s how you corrupt yourself when you are dealing with software that wasn’t architected with containers as the deployment scheme from the getgo.
Either just install Roon Server into the root OS on the system, or install it in a VM and use QEMU/virt-manager to run that. Or if you put ProxMox as the host OS and really want to go the container route, use an LXC container to load a child Linux OS and then install Roon Server into that container yourself.
I see, that makes complete sense. I’m using docker containers for personal use. I wouldn’t use them for production but I know some companies that do. But I get what you’re saying about the mentality you just mentioned. I guess the docker realm is more of an experimental strategy but so far so good for me.
I don’t have anything against installing Roon Server into the root OS of the system. I do see that you guys also provide an uninstall script to rollback any changes if need be. I just find that docker containers are very flexible in a way that I can create/destroy containers in an instant. But since this NUC will be dedicated only for Roon and Plex anyway, I think I can leave with installing stuff directly to the OS.
You do not need to load Roonbridge. The Server also acts as a local output. RoonBridge is for PCs, Macs, Windows, or Linux, where you just want it to be an endpoint. No control. No Core. Very lightweight.
Since I already have ROCK installed on the NUC, what steps do I need to take care when transitioning the system over to a Linux-based OS to ensure that I retain all data/settings/customizations, etc.? Do you guys have any documentation regarding that process?
The only thing you can do is have a good database backup. You would then restore that database backup to your new Core. If you look at the Roon Faq pages there are a number of them on Migration.
See:
and
and
Don’t forget to turn off the old core, install a different OS. Lifted from the Migration page to highlight
It is important that you “clean up” the machine that was previously running your database. You do not want the same database running on two machines .
Thanks, I’ll give those a read. Well, technically I’m converting the ROCK to a Linux box with the Core installed using the same machine so the old ROCK will no longer exist. No problems with running the same database on two Core servers.
Ok, so I was able to successfully install RoonServer on a Debian Buster Linux OS and restored my Roon database and everything is working. It was pretty straightforward. However, I have one question.
Why is it that whenever I create a partition (using gdisk) in the internal storage of my NUC (2TB Samsung 860 EVO SSD), Roon automatically creates an ext4 filesystem on it? Why does it not allow me to create a filesystem manually? Here’s what I mean:
See how after I created the partition, there’s automatically an ext4 filesystem there labelled “ROONSTORAGE”? Does Roon do this for all partitions I create for local storage drives?
Nevermind, I figured it out. It looks like that filesystem is the old filesystem (when I was still using ROCK). I didn’t realize that deleting the partitions on a Linux filesystem won’t delete the associated filesystem. When you recreate the partition on the same drive, it just associates the filesystem back.
