Docker images for Roon

That won’t really work for real installs. Often, if you go forward a version, the database format changes and if you go backwards in your install, things will get corrupt or just crash.

It would be, and we don’t want that due to the above mentioned issue with downgrades and the support burden related to that.

Oh, I do. It’s also why we don’t distribute RPM/DEB/MSI either.


For us to take over the docker image, we’d have to:

  1. publish on our own registry, and not the docker hub.
  2. new releases would remove the old tags so one couldn’t go back in time.

With these requirements, what’s the point? Just run the installer on first run.

I’ve removed the images from Docker hub, as requested. Note that it’s trivial to build images from the Dockerfile on GitHub. Just run “docker build --no-cache .”

Danny, I recommend looking into redistribution via Docker Store. This is intended to address any commercial concerns you might have regarding license acceptance, tracking, compliance, etc.

1 Like

This is an exceptionally disappointing discussion – like many people, I would much rather run RoonServer in a container.

@Neil_Carpenter, no one is suggesting you can’t.

@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?

You’re quite right…but, today, I would have to invest the effort into building my own. I appreciate that you’re working with Mike towards a solution.

Hi all,

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.

Any comments welcome.
Steef

5 Likes

Thank you, sir! - Steef_de_Bruijn

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.

Very happy, very impressed, and very thankful! =)

Thanks for Docker image for Roon Server! It works brilliantly and has made it through 3 Roon updates and functions perfectly! Thanks for accomplishing what nobody else did. You are my hero!

Cheers Mate,

Jonathan

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 :slight_smile:

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

Tia for all your input,
Steef

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.

Thanks for the suggestion Rob!

I use --net=host however so I cannot use --mac-address option (and assume it would do nothing). Same yields for IP address…

Can improper shutdown be a culprit?

Steef

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).

2 Likes

Sorry to post into an old discussion, but how does one stop dockerized roon server properly?

I am asking because I seem to only be able to kill it dead, and I suspect this also causes me to lose any analysis roon does on my imported files.

not at all.

hi @micmac,
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.

3 Likes

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.

1 Like

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).

1 Like

With all this new software and all… just updated the docker image to base image debian:9.6. Old version still available as tag debian:9.0.

No other changes.

Greetings
Steef

3 Likes