@mikedickey, I think you were too quick to remove your existing docker hub images. No actual request was ever made, nor I did not mean to imply that it was critical for you to stop distributing RoonServer binaries ASAP, just that we should do something to solve the issues at hand, for both of us. I’d like a solution that works for everyone without breaking anyone in the meanwhile.
I have suggested what solution Roon Labs would like, what we were willing to do about it, and I also loosely defined the schedule at which we can do it ourselves.
I’m open to discussion and/or someone to step up here. Given @mikedickey’s original gusto in releasing this stuff, I assumed he would be the one to do that. If I read that intent wrong, I apologize and welcome being corrected.
I looked into this, and I do not understand how this is any better. It helps us control the distribution slightly, but still adds another point of from which distribution occurs, with history.
Can you tell me if you have concerns with my suggestion of running the installer on first run of the image? If so, what would those concerns be?
I could not resist creating a little docker image doing exactly what most of us want (if I interpreted correctly - please correct me if I am wrong).
Docker image: steefdebruijn/docker-roonserver
It is too big to my liking (build on debian) because I had issues with alpine/glibc but it works for now. It is about the same size as @mikedickey version.
It uses docker volumes for the app, the data(base), the music and backups. The app volume is used to pull the RoonServer software from roonlabs on first run if this volume is empty. This is useful if you use a scheme of recreating application containers on every restart (as I do). Selfupdates from roonlabs should work as expected.
You can use this image as a drop-in replacement of the @mikedickey version if you like. Adjust startup parameters (volume mappings) to your liking.
Well Steef… It works brilliantly! I noticed the Roon update today when I issued a ‘docker restart ROON’ command and allowed Roon to ‘Update and Restart All’ apps. Everything came back up after the restart updated everything and it’s working, and for the first time I might ad, without any intervention by me or you to update the Docker image.
Maybe someone from the Roon team can chime in (of course anyone can suggest a solution) but I want to fix an annoying problem with this image (the mikedickey one had this too):
Often, but not always, I must re-authorize the Roon service after container restart. I must say I start all my docker services by checking for latest image version and always recreating the containers (of course using persistent volumes). It is minor to re-authorize Roon after server restart but I want this problem fixed nonetheless
Can someone tell me what server file(s) is(are) used to check authorization? Maybe it is easy to make these persistent across image updates and container recreations to avoid the re-authorization of Roon
I think you at least should keep the MAC the same. I assume between the one and the next execution of the container it might retrieve a new MAC address and when I had this with a VM this also failed my authorisation.
Can we revisit distributing Roon in a Docker image the correct way? Bootstrapping at run-time with an installer is not best practice and breaks the reason for using Docker containers.
The ideal thing to do is add to your build process a step to generate a Docker image and push it to Docker Hub. If Roonlabs has an issue with the public registry, then consider using the Store. There you will find commercial software that’s distributed in Docker images (namely Oracle).
i have no issues running Roon in docker container. Whether i kill it with . docker kill roonserver
or stop it with . docker stop roonserver
or just reboot or poweroff my linux server
i never ever lost Roon Data.
so it seems to me it’s not the containerisation that is causing the problems you have.
Thanks for replies. I can confirm no audio analysis data was lost when I was killing the docker instances. Also I was definitely having system problems even without dockerized roon:
I reinstalled my system in order to move docker and roon away from the root filesystem, and then I could not start Steef’s roon docker at all (it could not start the roon instance). Troubleshooting a docker that can’t start the app could be easier.
Finally I gave up on docker and decided to install roon directly on my system. I noticed the roon performance was slightly better without docker, but there were still serious issues. My ipad and iPhone did not show up at roon’s audio menu, and eventually I found out the cause was something used up my inotify watches. The fix in that link immediately returned my audio devices. I think that could also fix my docker issues, but I did not yet reinstall my system to confirm.
I am also wondering what caused my latest roon backup to have failed when I was using dockerized roon, but luckily the previous backup did restore without error. I think a failure to restore from backup should create some alarm before the user meets any need to use that backup. Could roon be cabable of testing whether the backup is working before it is needed?
To get back to the docker discussion, I feel it would be ideal if roon could supply a limited but functional stress-testing docker to expose the system limitations without extensive user testing and troubleshooting. That check script that comes with the linux installer is great, but certainly it isn’t thorough.
I’m a bit uneasy with letting roon run on my system without any isolation before making a purchase decision. There are many things that I need to test, because I hate the idea of having to maintain a dedicated windows box just for roon’s requirements (I think that is the recommended way for ever growing collection). If a windows box is the only way I can make roon work, I’m afraid it reduces roon’s value proposition dramatically. A separate linux box (or ROCK) seems kind of silly when I have 2 linux servers with spare capacity.
New to Roon and curious if Roon Labs has released an official docker or if we should use @Steef_de_Bruijn or @mikedickey image? Running unRAID and rather not have to stand up a VM to run core or deal with waking my Macbook from sleep inorder to listen to music.
I’ve been using @Steef_de_Bruijn’s docker image on unRAID for some time now without issues. Docker runs fine and updates itself when needed (I’m using “CA Auto Update Applications” plugin for automatic updates).