How to upgrade from an old version of MSR?

[toggledbits]

What was the compose file issue? There has been several fixes recently. Where did you get yours?

[Buxton]

@toggledbits The compose file was not pulling down the latest image. Is my specification correct?

 MSR:
  container_name: reactor
  image: toggledbits/reactor:latest-generic-amd64
  restart: "on-failure"
  environment:
   REACTOR_DATA_PREFIX: /var/reactor
   TZ: America/Los_Angeles
  expose:
   - 8111
  ports:
   - 8111:8111
  volumes:
   - /home/kevinb/reactor:/var/reactor
   - /etc/localtime:/etc/localtime:ro
   - /home/kevinb/reactor/tmpfs:/tmp
  logging:
   driver: "json-file"
   options:
    max-file: "5"
    max-size: 2m

When I pulled "docker-compose pull MSR" from the command line, the image updated and all was good. But using "docker-compose up -d -- remove-orphans" at the CLI did not update files (it did, however, rebuild the container).

So like I said, it could be something wacky on my end, or the/my image tags are not correct.

The bug I saw was that:

reactor:
  # baseurl - The base URL to access the Reactor system.
  baseurl: "http://10.17.2.41:8111"

where the baseurl needs an "http://" in front of the ip address. This should be changed in the config template.

[toggledbits]

@buxton said in Docker Compose:

where the baseurl needs an "http://" in front of the ip address. This should be changed in the config template.

Not sure where you got the config template, but that is in the default template.

[Buxton]

@toggledbits I first deleted the reactor image and its volumes, and then I deleted the folder structure that the volumes pointed to. I did this through Portainer and to be extra sure, through docker. Then, using the "docker-compose pull MSR" command, everything was re-created. I know the container was re-created from scratch because my settings in the new config file were gone and the files/folders that were previously deleted were back with the startup example in the config file specified an IP address only.

So make of that what you will, but I can tell you from this experience, that the container will not function without the addition of the http:// designation in the config file. I only caught the problem because of the log entries in Portainer.

[toggledbits]

@buxton said in Docker Compose:

I can tell you from this experience, that the container will not function without the addition of the http:// designation in the config file.

Indeed, and I would not expect it to. Unfortunately, I can't duplicate your results. I can confirm that the default value in the distribution template is:

# See the Reactor documentation at https://reactor.toggledbits.com/docs/
# Template version 21184
---
reactor:
  # baseurl - The base URL to access the Reactor system.
  baseurl: "http://192.168.0.164:8111"
  #

And I can confirm that this is what I see when I use docker-compose to turn up a new container with the bind location of /var/reactor in the container bound to a non-existent directory in the host filesystem (i.e. starting from scratch).

The baseurl here is, in fact, the IP address of one of my test systems, and probably a long shot to be the same IP address that someone else may use. There is no automated construction or replacement of this value, no "guess" as to what your system IP address actually would be, etc. Unless Portainer magically knows something about Reactor, which would be a revelation to me, any value other than http://192.168.0.164:8111 didn't come from the template, at least not without help.

I guess this will remain a mystery.

Edit: You might confirm that the version number shown in the Reactor UI is latest-21270-... (as of this writing). If it's not that, your image isn't the latest; your pull isn't doing what you expect.

Edit 2: Also see this post; seems to describe a problem similar to yours: https://stackoverflow.com/questions/37685581/how-to-get-docker-compose-to-use-the-latest-image-from-repository

[Buxton]

@toggledbits The template I used had your 192... address. I placed my local IP in its place. Trying to use a browser to this IP generated the error. After adding "http://" to the IP in the config file, the container worked as expected.

The portainer aspect is that the reactor container came up using docker compose and was visible in portainer. However, the reactor container wouldn't allow a browser connection and the log errors visible in portainer were complaining about a prefix to the IP.

Everything works now, so I don't know what happened there. Here's a snapshot of the top of the config file

My version of compose was a year old, and that may have had something to do with the container not updating to the latest. My original compose version was manually installed and was missing from my package updaters. It's now part of PIP, so that should keep it up to date.

Thanks for running this down as install errors usually make me throw in the towel before giving an app a chance.

[toggledbits]

@buxton said in Docker Compose:

@toggledbits The template I used had your 192... address. I placed my local IP in its place. Trying to use a browser to this IP generated the error. After adding "http://" to the IP in the config file, the container worked as expected.

Wait, are you saying it had http://192.168.0.164:8111 and you replaced it with 10.17.2.41 without the http:// at first?

[Buxton]

@toggledbits No, the template had "192.168.0.164:8111" as the guide. At first, I replaced the template IP with "10.17.2.41". When that failed, I added the "http://" and everything worked.

[toggledbits]

Well, my testing doesn't reproduce that, and I don't see how it could happen otherwise, so I guess we're back to remaining a mystery.

[parkerc]

Just an FYI - the Docker compose I used to create MSR on my QNAP (intel) is below

version: '3'
services:
    reactor:
        image: toggledbits/reactor:1.0.1-generic-amd64
        container_name: reactor
        environment:
            - PUID=1000
            - PGID=1000
            - TZ=Europe/London
        volumes:
            - /share/Container/reactor:/var/reactor
        network_mode: host
        restart: always