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

mmmdonuts · October 18, 2018, 12:50am

Not all images from linuxserver.io 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.

Haioken · October 18, 2018, 2:42am

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.

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

mmmdonuts · October 18, 2018, 8:45pm

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.

Haioken · October 18, 2018, 10:30pm

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.

Flox · October 18, 2018, 11:05pm

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

github.com

rockstor/rockstor-core/blob/ccbd952a3217bce3d9e35c0ed5b198ee28c1a89b/src/rockstor/storageadmin/views/rockon_helpers.py#L225


return cargs_list




def envars(container):
var_list = []
for e in DContainerEnv.objects.filter(container=container):
    var_list.extend(['-e', '%s=%s' % (e.key, e.val)])
return var_list




def generic_install(rockon):
for c in DContainer.objects.filter(rockon=rockon).order_by('launch_order'):
    rm_container(c.name)
    # pull image explicitly so we get updates on re-installs.
    run_command([DOCKER, 'pull', c.dimage.name])
    cmd = list(DCMD2) + ['--name', c.name, ]
    cmd.extend(vol_ops(c))
    # Add '--device' flag
    cmd.extend(device_ops(c))
    if (c.uid is not None):
        uid = c.uid

mmmdonuts · October 19, 2018, 12:19am

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:

Many but not all linuxserver.io images can pull the latest on startup if a newer one is available on the Docker hub.
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.
Uninstall/reinstall the Rockon using the same config as the original install.
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.

Thanks

Haioken · October 19, 2018, 1:08am

Regarding 1:
Yes, linuxserver.io 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 plex.tv 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.

Flox · October 19, 2018, 1:00pm

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.

mmmdonuts · October 19, 2018, 7:14pm

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.

Flox · October 19, 2018, 7:18pm

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

github.com/rockstor/rockon-registry

Update Emby Rockon

rockstor:master ← FroggyFlox:emby_dotNET

opened 05:35PM - 23 Sep 18 UTC

FroggyFlox

+30 -9

Fixes #152. This updated Rockon includes a new "devices" object to allow user…s with compatible hardware to mount the corresponding device for hardware transcoding. It also includes a new ENV variable `GIDLIST` to add system users with access to this device. For backward compatibility, this keeps the `--net=host` option, but this also means that, as before, the port selection remains without actual use as the default emby ports can be used (8096 for HTTP, and 8920 for HTTPS). Would somebody know what needs this option?

mmmdonuts · October 19, 2018, 7:30pm

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.

Flox · October 19, 2018, 7:48pm

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

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