@XGTG-yokelet updated to 247.
@danny That would work, but I think it would be better if Roon just took this over and bumped it as part of your existing release process 
Wondering if we could set this up so that you just have to send a REST trigger to DockerHub and it would do all the work for you… I can look into it.
I agree with you. I really appreciate what you’ve done to keep Roon running in Docker. It seems to run more stable and for much longer periods of time in Docker. I have some peculiar intermittent issues with running Roon in Ubuntu on my media server, for whatever reason and I’ve stop worrying about it because of time constraints. Docker runs all my other media apps flawlessly and roon runs most of time just fine. I know my experience isn’t typical, but It’s just easier to restart the Roon container from ssh on chance occasion when my android roon remotes can’t communicate with Roon for whatever reason. I would love it if Roon would maintain a Docker image.
I’ve not taken over your Dockerfile because you’ve done exactly what I would have done.
However, I’m now seeing that both you and I were wrong in that strategy, since now there is a RoonServer baked into the image sitting on the docker.
This has 2 issues:
For example, the QNAP qpkg grabs the latest RoonServer upon install of the qpkg, which avoids both issues above.
I can look into taking this over, but I can’t do it immediately… It’d help a lot if you moved your Dockerfile ADD/RUN commands to a script at CMD time and either started installed RoonServer or ran RoonServer’s start.sh if it was already installed.
@danny I agree with Mike here. The goal of distributing something as a Docker container is so that it runs consistently every time. The best practice is to build a container each time you build the software, and ideally even run your unit tests inside that container. That way the behaviour is the same regardless of what else was installed on the server, and the same when you run it on another machine. Think of it as a replacement for a RPM/DEB/MSI file, rather than a replacement for a shell script.
I think the best thing here would be to publish to Docker Hub at each Roon release. This would enable us early adopters to try new versions before you update the other install channels, and revert back if needed. I’ve considered automating the publishing but refrained because it could be considered disallowed redistribution.
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:
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.
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
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
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).
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.