There has to be a better way. What am I missing?

Not all images from update themselves on startup and this includes some Rock-ons, for example Sonarr.

So how are we supposed to update these Rock-ons within Rockstor? Are we supposed to manually pull, remove and recreate the container using the docker CLI each time there’s an update?

I’ve tried to find this info within the Rockstor site and on Google but I’m not having any luck finding something specific to how Rockstor updates the Rock-ons.

Rockstor doesn’t update rockons, when you run a rockon, the current latest image is obtained from dockerhub.
WIth regards to sonarr, it can update itself inside the container. containers will typically update on startup if the application in the container is not able to update itself (IE: Plex), otherwise they tend to allow the application to update itself (IE: Sonarr, NZBGet).

Thanks. I was under the impression that changes made when the app updates would be lost after the container restart. I’ll give it a try.

As long as the container is stopped and not deleted, I don’t think this would be an issue.
I believe that Rockstor manages this by initially spinning up the container with docker run, and if the container is stopped, restarting with docker start to preserve the existing image, rather than spinning up a new container each time.

This is the difference between docker run, which spins up a new container and docker start, which starts an existing (stopped) container.

I’ve been internally updating my sonarr container since I initially spun it up a year ago, and the container (indeed, the whole system) has been restarted a couple of times since.

@Haioken already answered, but I simply wanted to add that for all other Rock-ons, Rockstor triggers an image pull upon Rock-on install, which means that instead of manually pulling the image, you can simply stop, uninstall, and then re-install the Rock-on using the same shares. This should pull the latest image (if a newer is available) and keep all previous permanent settings of the Rock-on.
Here’s the relevant part, if interested:

That is good to know. You might now see why I’ve been lost. I’m new to messing with Docker containers and still learning.

What I’ve found so far, including your responses, to update a Rockon:

  1. Many but not all images can pull the latest on startup if a newer one is available on the Docker hub.
  2. Some images can be updated from within the application. Interesting thing about this is the image itself does not change version or release date. So only the app would be able to provide the version. There might be a way, I don’t know.
  3. Uninstall/reinstall the Rockon using the same config as the original install.
  4. Oh, and the Emby Rockon has yet another method.

None of the above is in the Rockstor documentation or the Rockon write-ups. I do understand the Rockons are a convenient wrapper to integrate/manage Docker containers within Rockstor. Also that Rockstor does not control those Docker images. I for one appreciate having this tool and wouldn’t have delved into Docker without it.


Regarding 1:
Yes, tends to have auto-update on startup only in the instance that the application cannot self-manage updates.
This makes sense, as there’s no need to bother writing the update script for something that already has the capability.

Regarding 2:
It’s worth noting that the auto-update on startup will also not update the image itself. The auto-updater in the plex docker for example still uses the original container image, but on startup will retrieve the latest package from and install it.

Regarding 3:
Uninstalling and reinstalling will pull the latest dockerfile for that container including it’s install procedure.

Regarding 4:
Does it? I only run the Emby container for a short while, I found that it was extremely slow to scan for media, and the client application interfaces were enourmously slow on libraries containing >3000 individual items.

This is true, and you’ve outlined the reasoning perfectly. It’s not Rockstor’s responsibility to provide this information. I do however think that each Rockon should have a link to it’s dockerhub page describing the usage a little.

Currently, the Emby Rock-on can be updated following the uninstall/reinstall procedure (your point #3).
Note that there used to be (still is?) a “restart to update” button on its server dashboard, but this was functional only in other builds of embyserver (builds for windows, for instance) not its Docker container.
You may also be referring to an older version of their docker container, for which a script existed allowing for an update of the container from the command line. This is now deprecated, however, and the official update procedure is to follow “the Docker way”, which is what you would be doing by uninstalling and reinstalling the Rock-on using the same shares.

Right. The old way was “docker exec emby-server update”. I haven’t been running Emby in a container for some time now and wasn’t aware of the change.

They changed it when they rebased Emby on .NET. They also made some changes to their Dockerfile to allow hardware transcoding more easily and I submitted a PR for an updated Rock-On as a result. Feel free to test it below if you’re interested :wink:

The difference between run vs. start/stop is one that many seem to overlook. So it gets even harder when looking for answers and just finding contradictions. Docker docs has all the answers to the generic questions but I couldn’t reconcile those with the “Rockstor way”. For example, I didn’t want to manipulate the Docker backend to then have the Rock-on parts puke on me because I clobbered something it needed.

From my recent dive into this part of Rockstor’s code, I believe @Haioken is correct:

  1. At Rock-on install, Rockstor triggers a docker run.
  2. After install, when toggling a Rock-on “on” or “off”, Rockstor triggers docker start or docker stop, respectively.